SIMPLE Minutes
IETF 63
Thursday, August 4, 2005
1400-1630 Afternoon Session I
Executive Summary
------------------
In IETF 63, the SIMPLE working group met once for a 2.5 hour session.
The chairs presented a short-term roadmap outlining the WGLC and IESG
submission plans for the next 2-3 months. Those included RPID and
related drafts, MSRP and MSRP relay drafts, presence rules drafts, and
partial notification and related drafts.
Presence Data and Presence processing model drafts seem to be at their
final stages with very minor issues. WGLC will be called soon. Presence
Authorisation is at the same stage and the processing model drafts.
There is consensus from the group.
These is still a cotroversy over XML diff and its deviation from what
the WG asked for. The issue also exteds to XCAP diff where it has its
own XML diff solution different from what is in the XML diff draft.
Consolidation work between XCAP diff and XML diff drafts is needed or
narrowing of scope of the XML diff work to be specific to partial
notification is needed. There is no consensus from the group one way or
the other. More work is needed by the authors of the 2 drafts.
Composition policy ideas where presented in the meeting. The group
feels that this work is too early.
Message delivery reporting ideas were also presented. The group
indicated interest in such work and the authors of the 2 drafts that
were presented agreed to merge their efforts.
Jonathan Rosenberg noted a mistake in the notes taken for the data
model.
Issue 4: PIDF-LO integration: Proposal to keep definition of PIDF-LO
encapsulation out of data model spec. Argued that this makes for a lot
of documents to read in order to get an implementation. General
consensus on proposal.
Jonahtan recalls that Henning argued against this, and the conclusion
was to just put words in. No one objected to such comment.
Detailed Minutes
----------------
Topic: Chair Update
Chairs
XCAP is RFC editor queue
Short-term roadmap presented
Topic: Presence Data Model
Jonathan Rosenberg
Slides presented
Note: the schema needs to be updated to match what;s in the SIP Foundry
repository.
Issue 1:
Verified/Unverified. Solution accepted as proposed. The impact of GI/GO
should be noted in the text, at a SHOULD rather than MUST level.
Suggested text add: When you create an originally new document, it must
be valid. Rohan promised to send appropriate text.
Issue 2:
Aliasing. Solution accepted as proposed.
Issue 2; Schema.
fromUntil vs sinceUntilProposal to adjust RPID schema accepted.
Issue 3: Schema. deviceID:
Proposed to define only as a global element. Proposal accepted. Note
that this will change the schema in RPID.
Issue 4: PIDF-LO integration: Proposal to keep definition of PIDF-LO
encapsulation out of data model spec. Argued that this makes for a lot
of documents to read in order to get an implementation. General
consensus on proposal.
Topic: Presence Processing Model
Slides presented
Changes since last rev reviewed
Proposed that further work here be deferred until more critical
documents are done and more experience gained. There was general
consensus on this approach.
Topic: Presence Authorization
Jonathan Rosenberg
Slides presented
Changes since last rev reviewed.
Issue; Sphere determination.
To Do: Make the hook for sphere composition more explicit.
Topic: XCAP Diff
Jonathan Rosenberg
Slides presented
Changes since last rev presented
No known open issues except disconnection with partial publication
(different patch format). many documents blocked on this.
Proposed that we have review and WGLC.
Noted that the impact of different patch implementation might not have
a dramatic impact.
Suggested that we use a multipart MIME approach to Basically, we
would put the metadata in an initial text data. This would prevent the
CDATA escaping need to handle embedded markup in the current format.
Proposed: Punt and say that the xml-diff format indicates only that the
document has changed (notification of change by reference rather than
by value).
AD comment: Not worthing doing this just to advise people a document
has changed. But the CDATA problem probably bears closer examination.
And this task DOES need completion, even if only a piece is split off
to meet the near-term requirements.
Next steps; Talk to the XML folks about solving the problem, and if
necessary, fall back to change-by-reference.
Topic: Partial PIDF format 04
Jarri
Slides Presented
Noted by chair that scope of this draft seems to have expanded since
last rev, possibly in disagreement with consensus of last
meeting. This may require some examination. The authors are
cautioned to inform the WG if they see a future need for this sort of
scope change.
Noted that this approach has been implemented and seems to work.
Comment: One implementor believes that this spec will be much more
difficult to implement than core XCAP was.
Proposed: People should look a drafts using this function and see if
this draft has enabled a better solution, then decide.
Noted that the developer of partial notify and related material has
found this approach very useful.
Poll: How many people are actively following: Few
How many are actively implementing? Even less. . .
Open question: Can we produce a general XML patch mechanism? AD
comment: Very concerned that this may not meet the XCAP design goals.
If it does, then it's OK if it's also generally usable. But we have no
need to prove that it is a general mechanism in order to proceed.
Chair comment: We can present this as specific to partial notification,
even if the algorithms are more useful.
Proposed that we have a con-call with the XML directorate to review
this. The ADs will assist with scheduling and selecting the right
people.
Proposed by Chair: This seems to be a reasonable way to move forward if
it works, and after review with the XML people the WG will be informed.
Topic: Common Policy
Henning Schulzrinne
Slides presented
Current solution reviewed.
Issue: Authenticated vs Asserted
The current draft has some discussion without use cases.
Suggested that this text be deleted and a richer discussion elsewhere
be referenced. Debate followed with no clear conclusion.
Issue: Processing Logic
Question: Allow OR conditions within various sections? Currently
defined only for <identity>.
Question; Allow >=1 (groups) .
Discussion followed.
Question: Can this accept everybody BUT a specific individual? Yes, it
could.
Seems to be general consensus to accept proposal.
Issue: Tel URIs;
Proposal to only allow domain identifiers in <many /> clauses.,
and non-domain identifiers in <one/> clauses.
Discussion followed.
Noted that tel: is not the only class of non-domain identifiers.
Noted that this proposal prevents exclusions on ranges of numbers
Suggested that exclude clauses be restricted to members of the
surrounding group element.
Suggested that each rule element apply to a single URI scheme type,
like sip: or xmpp:.
Chair comment: How long do we think it would take to navigate our way
through this? Would it be reasonable to plan for EGLCZ on presence
rules at the end of September? The sense of the room is favorable to
this position.
Proposed that we need to do a requirements document. This proposal was
met with general disdain.
These general discussion questions need to be raised on the mailing
list.
Topic: Presence Composition
Henning Schulzrinne
Slides presented
Previous discussions summarized.
Comment: It might be nice to be able to apply credibility factors to
the composition. This is complicated by the lack of a source
attribution in each element.
Issue: Source Labeling
Issue; Simple Composition Policy Language
Comment: Composition of "lunch" and "meeting" is difficult -- is this a
lunch meeting, lunch, or a meeting?
Comment: Presence extrapolation is an interesting problem.
Comment: This problem is similar to the configuration merging problem.
Comment Yes, but presence composition errors aren't going to result in
device crashes or interop failures.
Comment: This is a very low priority topic.
Comment: A recent exercise in client-side composition revealed that
there are 4 or 5 categories of data, with one type of merging algorithm
appropriate for that data type.
Comment: Conflicting information can be presented to and analyzed by
humans.
Comment; There DOES need to be a way for the user to influence the
composition policy in order to get useful information in/out of a
system.
Comment: One the things that was in the presence processing model was
guidance about how a user sets things.
Topic: Messaging and Delivery Notfication
Hisham Khartabil
Slides presented
Topic: IMDN
Eric Burger
Slides presented
Discussion of two preceding:
Comment: Recent experience with customers indicates a need to solve
this problem. Both drafts look like a good start but would be better
combined.
Comment: Delivery notification would be useful for calendar
notifications.
Discussion of XML vs not-XML inconclusive.
Topic: Translation of Schema to WebDAV
Rohan Mahy
Slides presented
Comment: JDR sees no value in this approach.
Comment: The functionality of locking mechanism could be very useful.