Last Modified: 2005-06-27
| Done | Submission of event package for presence to IESG for publication as Proposed Standard | |
| Done | Submission of watcher information drafts to IESG for publication as Proposed Standards | |
| Done | Submission of proposed event list mechanism to the SIP working group | |
| Done | Submission of requirements for event publishing to the IESG for publication as Proposed Standard | |
| Done | Submission of proposed mechanism for event publishing to the SIP working group | |
| May 04 | Submission of SIMPLE PIDF profile to IESG for publication as Proposed Standard | |
| May 04 | Submission of base XCAP draft to IESG for publication as Proposed Standard | |
| May 04 | Submission of XCAP event package to IESG for for publication as Proposed Standard | |
| May 04 | Submission of Partial Notification mechanism to IESG for publication as a Proposed Standard | |
| May 04 | Submission of indication of instant message preparation using SIP to IESG for publication as a Proposed Standard | |
| Jun 04 | Submission of XCAP usage for manipulation of presence document content | |
| Jun 04 | Submission of XCAP usage for setting presence authorization to IESG for publication as Proposed Standard | |
| Jul 04 | Submission of Filtering mechanisms to IESG for publication as a Proposed Standard | |
| Jul 04 | Submission of CPIM mapping draft to IESG for publication as Informational | |
| Jul 04 | Submission of instant messaging session draft to IESG for publication as a Proposed Standard | |
| Jul 04 | Submission of instant messaging session relay drafts to IESG for publication as Proposed Standards | |
| Aug 04 | Submission of advanced messaging requirements draft to IESG for publication as Informational | |
| Sep 04 | Submission of proposed mechnisms meeting the advanced messaging requirements to the IESG or appropriate working group | |
| Sep 04 | Submission of Presence/IM System Architecture draft to IESG for publication as Informational |
| RFC | Status | Title |
|---|---|---|
| RFC3856 | Standard | A Presence Event Package for the Session Initiation Protocol (SIP) |
| RFC3857 | Standard | A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP) |
| RFC3858 | Standard | An Extensible Markup Language (XML) Based Format for Watcher Information |
| RFC3994 | Standard | Indication of Message Composition for Instant Messaging |
|
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. |