Last Modified: 2004-06-14
The primary work of this group will be to generate:
1. A proposed standard SIP extension documenting the transport of Instant Messages in SIP, compliant to the requirements for IM outlined in RFC 2779, CPIM and in BCP 41 (so that the transport implications of the extension with respect to network congestion are considered in the design).
2. A proposed standard SIP event package and any related protocol mechanisms used to support presence, compliant to the requirements for presence outlined in RFC 2779 and CPIM.
3. An architecture for the implementation of a traditional buddylist-based instant messaging and presence application with SIP. Included might be new mechanisms for message confirmation delivery, indications for when a party is in the process of typing a message, secure buddylist manipulation operations, and the extension of the CPIM presence format to describe typical IM states. Each of these mechanisms will be consistent with a SIP-based architecture, as well as meeting the constraints otherwise described in this charter.
All SIMPLE proposals fulfilling these goals must document the mappings of their operation to CPIM. Any SIP extensions proposed in the course of this development will, after a last call process, be transferred to the SIP WG for consideration as formal SIP extensions.
The working group will work within the framework for presence and IM described in RFC 2778. The extensions it defines must also be compliant with the SIP processes for extensions. The group cannot modify baseline SIP behavior or define a new version of SIP for IM and presence. If the group determines that any capabilities requiring an extension to SIP are needed, the group will seek to define such extensions within the SIP working group, and then use them here.
The working group will operate in close cooperation with the IMPP working group, which will be completing CPIM in parallel. The working group will also cooperate with any other groups defined to standardize other presence and IM systems, to ensure maximum sharing of information and avoid reinvention of the wheel. The working group will cooperate with the SIP working group, soliciting reviews to ensure its extensions meet SIPs requirements. The working group will also collaborate with the SIP WG to ensure consistent operation of the SUBSCRIBE and NOTIFY methods across the other applications being defined for its use.
| 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 |
|
SIMPLE Working Group
Minutes - IETF 60 August 2, 2004 1300 and August 3, 2004 0900 Chairs: Robert Sparks, Hisham Khartabil Notetakers: Dean Willis, Spencer Dawkins, Chris Boulton Summary - - The core SIMPLE documents are finally in AUTH48 - The group reviewed the agressive project plan it is working against to complete many of its current work items - The MSRP base spec was rewritten for clarity. The number of open issues is going down. Several will be closed based on discussion from this meeting. (See the detailed notes for specifics on each issue.) - The MSRP relay spec is being revised to track the base spec. It will help the editors if group members start reporting inconsistencies to the list. - The XCAP discussions during this meeting focused mostly on remaining issues in xcap-base and list. - XCAP Package is being reconciled with the configuration framework. The resulting components may meet the requirements for a directory. - The room expressed an interest in addressing the topic in draft-peterson-pidf-ice-00.txt as a SIMPLE WG effort. - The room expressed support for the data model expressed in draft-rosenberg-simple-presence-data-model. ---------------------------------------------------------------------- Detailed Notes: (We were fortunate to have two notetakers for each session) Session One: recorded by Dean Willis. Topic: Chairs Report -------------------- Core SIMPLE docs in Auth 48 and should complete soon. Project plan presented. Topic: MSRP Base, Ben Campbell ------------------------------ Slides presented. Discussion of Status and Changes follows. Reports changes: Discussion: There is no minimum size of an MSRP message. Can a report get chunked by a relay? Ans: No. Reports don't get chunked. Framing: No discussion apart from changed reviewed in slides. Chunking: Changes reviewed in slides. Noted that recent email suggested that draft should note that S/MIME must be applied before by chunking. Also, guidance received that chunking be imposed at 2kB boundary. VISIT: Removed from spec, replaced with a utilization of SEND, which could be empty. No further discussion in meeting. Transport and Protection: No discussion. Max-Size: No discussion. Discussion of Open Issues follows. Issue: Terminating long-message transmissions without accidental rendering of incomplete message: Possibility of "abort" flag on the transmission raised. There seems to be a consensus to adopt this approach. Issue: Range header: Proposed: if you think there is any chance that a message might be interrupted (over 2k) go ahead then the last field in the byte range header should be set to "*". There seems to be a consensus to use this approach in conjunction with the "abort" flag. Issue: MSRPS vs MSRP. Is this justifiable due to DNS-cert matching resolution requirements and/or NAPTR options? Rough conensus seems to be that the usage is justified. Issue: Report Handling. Discussion of whether report headers can be present in a REPORT request -- answer is no, they are not allowed. There may be an error in the spec or examples that needs to be corrected. These headers only apply to SEND. Issue: Extensibility. Do we need versioning? Proposed that a URL parameter for version be added. This relates to whether we wish to develop an innate extension negotiation mechanism as per SIP, use completely new protocol definitions and negotiate with SDP. This could fall back to making a SIP option tage for understanding the version option. Action item: Document the selected extension approach as part of the MSRP spec. Issue: What does max-size mean? How does it apply to body parts inside of multipart? Proposed that it apply to any matching body part, regardless of encapsulation. For example, if a multipart has text, html, and text parts, then these qualify as three individual parts. Suggested that we have a max-size apply across the whole set of multiparts. Ensuing discussion indicates a lack of clear requirements. Proposed: We seem to have sufficient annecdotal evidence that justifies a max-size parameter that applies to all body parts. We should adopt this now, and unless someone comes up with a good justification for part-by-part sizing, we drop that requirement. There seems to be consensus for this approach. Proposed approach is a new a-line entry "max-size". Discussion: Is this data "a hint" or normative behavior for the sender? There seems to be consensus that it is a hint. Issue: Page vs. session mode. Should there be a discussion of when to use each mode? Proposed that this belongs in a SIMPLE architecture document, not in MSRP. There seems to be consensus not to discuss this in the MSRP spec. Issue: DSN. Now that we have have status information in a report, what does DSN do for us? Is there a reason to keep it? Seems to be consensus that we do not need DSN body parts any more. Proposed: Change from SHOULD send DSN to MAY send DSN, and to deprecate body preparation to be free-form text. Alternate proposal: Drop DNS discussion from draft entirely. Question: Do we allow bodies on REPORT? Proposed: No. Counterproposed: Yes, up to 2k, negotiated as an SDP option. Message-context header discussed as a possibility. Suggested that this needs to be handled as part of the alleged SIMPLE architecture document. Further discussion: Do we need guidance on resource starvation and utilization, like weighting algorithms and discard and stuff? Discussion was inconclusive. Issue: being able to put information like a "From" header in the MSRP request that identifies the source so that intermediaries like mixers can relay this on. This might be applicable to an MSRP conferencing model. Even though the focus knows who is talking, how does it pass this on to the other recipients so that utterances can be associated with sources? Clarifying question: Given that the focus might be multiprotocol, should the utterance identifier be a protocol-indicating URI? Question -- Would this identifier be mandatory, or optional? Comment: The source can present its identity in CPIM. Issue: If this is an "anonymous" identity, how does this correlate to the roster? We would need some way for the focus to transmit the focus-assigned anonymous identity value to the user agent for inclusion in the CPIM wrapper. Thought: Wow, this is just like the proxy identity-rewrite problem in SIP, isn't it? Comment: Something we did in SIP that was a mistake was the failure to distinguish between identity-targeted headers vs. end-to-end significance. The CPIM-wrapper method is clearly end-to-end, and may as a result be better than the SIP approach. Conclusion: Author will attempt to document use of CPIM with focus-provided identifier valuesd to addresses anonymous-conference requirements. Topic: MSRP Relays, Rohan Mahy ------------------------------ Slides presented. Status: Document is known to still contain inconsistencies. Poll on reading of base draft: about 10% of room. About 3% indicated that they have read the relay draft. Changes summarized. Issue: Refreshing AUTHs. Proposal that client periodically send new AUTH requests, targeted to a specific URI in the To-Path. Consequently, a full refresh would do a "full telescope" but not necessarily in order of traversal. Discussion: This conflcts with refresh approach chosen in Canada interim meeting two years ago. This might have been related to the n-way timer negotiation as envisioned during the Ottawa meeting. Since the new model is one of one-to-one relationships between clients and relays, the proposed approach seems to work better. Noted: Editor requests that people start sending inconsistencies between relay and base drafts. Discussion: The time-limiting aspect of authentication nees to be clarified. Session One : recorded by Spencer Dawkins 13:00-13:05 Agenda Bashing, Chairs Report o IMPP documents are in AUTH-48 - should be published really soon o Filter has been through WGLC, please send comments o XCAP base draft and PIDF manipulation draft in WGLC now o Want to send MSRP base and relay drafts to IESG back-to-back 13:05-14:15 MSRP Base (Ben Campbell) o Version 07 is major re-write of this document o Going for readability and fixing 'cut-and-paste-itis' o Changes are report handling, framing, chunk handling, eliminating VISIT method, transport and TLS, and adding max-size to media o Two headers for report selection (Report-Success and Report-Failure) - Report-Failure needed to accommodate relay operation o Chunking very intrinsic to MSRP, so promoted to a Byte-Range header o Recommended chunking at 2KB boundaries o VISIT semantics became almost identical to SEND, so replaced with an initial SEND request o Transport parameter added (TCP is only defined value, but would accommodate TLS in future) o Max-Size refers to complete message content - entire message body o Chunking - Adam proposed two flags on the list - allow an additional flag that says "chunk, I'm abandoning this message"? - OK o If you have real numbers in byte range numbers, header should reflect this - but there's an issue with interrupting streaming media - require "stars" as last byte in byte-range header if the message is bigger than 2KB? - OK o What certificate identities do you present for TLS? Relay draft doesn't have quite the same language as HTTP-S - should copy that language exactly. Cullen - should match what we did with SIP-S. Jon - does the SRV record match the URI? That's the important part. o Open issues o Transaction responses are tied to error reports - should they be separated? Proposal - leave tied together - o Extensibility - we're not going to have a version number, we need to document our decision not to have version numbers - non-backward compatible extensions become new protocols instead o Max-size will refer to all media types, not per-media type o Page mode vs session mode - need to give guidance, but not in this document. SIMPLE architecture? Where? o How to slow down packet rates? No other way than slowing down request rates. o Is DSN still required? We can send reports, don't need human-readable DSNs. Still allowed - it's a body part - but what's the guidance here? Is anything required beyond what people can Accept: today? o Need to map MSRP headers to SIP headers to avoid confusion. o Need to make sure that focus won't be inserting identities - we rejected this previously, and it's creeping back in - this doesn't work for anonymous participants - but can't they provide their own anonymous identities? Need to map what they provide to a participant roster, though. Need to take this offline, with two concrete proposals. o Need to be clear about headers that are end-to-end vs hop-by-hop - we blew this in HTTP and inherited the problem into SIP - can we be smarter? o Ready for WGLC of next draft, in a week or so? Please send open issues ASAP. 14:15-15:00 MSRP Relay (Rohan Mahy, Cullen Jennings) o Last-nanosecond editing pass doesn't quite align with the base spec (which is now complete enough for the relay functions) - need one more pass to complete this. o SEND and AUTH responses are end-to-end o Client which needs multiple relays sends AUTH to each one, inside out, and relay uses complete path to authorize requests o Relay to Relay is always TLS with mutual authentication, client to its relay is always TLC with Digest, foreign relay to client can be either TCP or TLS. o Relays can re-chunk, and must be able to interrupt chunks bigger than 2 KB. o Refreshing AUTHs - suggesting periodic new AUTHs, but need to work out details - but WG chose not to go this way, a long time ago - can we remember why? Maybe because that was end-to-end and this is relay-to-relay. Maybe OK. o Need to catch up with base protocol, make document self-consistent. What other changes are needed? Rohan - how to do AUTHs that aren't one-AUTH-per-session? o This is like base GRUUs - if people know my relay MSRP URI, they can pass out that URI to their friends and I'll relay anything they send using that URI. o Talking with Ted about security aspects of this - sufficiently complicated to require security assistance in getting this right. o What does "passing out" mean? Does it matter if eavesdroppers hear the URI? o Does "time-limited" help? The URI doesn't last forever. Session Two: recorded by Dean Willis Topic: XCAP -- Jonathan Rosenberg --------------------------------- Slides presented. Changes since last rev reviewed. Changes were discussed also on list. No questions or comments raised in meeting. Issue: DELETE idempotency. Discussion: Could we do away with the positional syntax and use a ".next" style iterator? Discussion followed. Initial Conclusion: Will add text to spec that describes URI constructor constraints for delete idempotency. This led to extended discussion -- is idempotency really required here? Key issue: What happens when you have issued a command and lose network access before the response is returned? If the request is not processed idempotently, there is no way to just reissue it. Heated debate followed. Comment: In choosing to use HTTP with DELETE as done. we have chosen to use the entire implied infrastructure, including HTTP proxies. HTTP proxies can retry these commands on your behalf, without your knowledge or consent, and if the requests are not idempotent, this will break the application. Restatement of proposal: Soften the requirement of a server to enforce idempotency to only enforce it in the presence of an ETag in an If-Match header. Issue: XPath Namespace Context. Extended discussion followed, with no conclusions. Author will research and bring up on list. Issue: ETag and DELETE. When a resource is deleted, it doesn't exist. But some servers return the ETag of the deleted element. Several options proposed in slides. Meeting proposed fourth option: DELETE response contain a body that references some related resource, presumably the parent. The third proposal, the "MODIFY TO EMPTY" approach, was universally recognized as "crap". Comment: Unless we are introducing transactions across multiple requests, we are simply going to have this problem. Final Proposal: XCAP will have normative ref to xcap-diff format and will state that if a DELETE request includes an accept header for that MIME type then the server SHOULD return a diff body that indicates the etag of the resource following the DELETE operation. Issue: Caching. Proposal: Add discussion of caching issues to XCAP document. Topic: XCAP List, Jonathan Rosenberg ------------------------------------ Slides presented. Four issues to be discussed. Question on whether indirection URI in a rls-service document has to point to XCAP or can point to other destination -- author will consider. Topic: Resource List Document, Jonathan Rosenberg ------------------------------------------------- Issue: Embedded vs external lists. Proposed: retain as is. Poll on readership: about twenty people indicated they had read it. No objection to proposal. Issue: Simpler structure. Proposed retain as is. No objections. Issue: Membercode attribute proposed by Hiller draft. Problem: Schema doesn't allow attribute extensibility. Proposal: Add attribute extensibility. Comment: We need to go through the extensibility discussion for everything. Question: Can the membercode be done as an element instead of an attribute? This needs to be reviewed in the Hiller draft. (probably not, as it seems to be used with XCAP selection). Question: How can we develop extensibility guidelines for consistency? Discussion followed. Topic: XCAP Package/DIFF, Jonathan Rosenberg -------------------------------------------- Slides presented. Document is radically changed, including a great deal of reconciliation with Config Framework. Changes reviewed in presentation. Question: Is the providing of a starting point ETag in addition to a diff helpful? Yes, otherwise you don't know whether an intermediate change was missed that would make the sequence of changes not add up. Issue: Relationship to directory. Proposed that this restructure makes a seperate directory unneeded. Poll indicates that about twentyfive people in meeting had read the document. Further list discussion on proposal is appropriate. Topic: XCAP Directory, Miguel-Angel Garcia Martin ------------------------------------------------- Comment: The heirarchicalization is inconsistent with XCAP. Comment: The size is going to be hard to compute. Discussion: The functionality seems to be needed. The question is how to implement. Is rls-services adequate? Need to evaluate rls-services against this requirements raised in this document. comment: The config framework truly does what this does -- give me all the servcies related to me. The rls-services document is a related thing, that provides an index of the documents related to me, in a linkage tree. As there may be unreferenced documents, rls-services may not get everything. Author is to vet requirements against rls and config work. Topic: PIDF-ICE, Jon Peterson ----------------------------- Slides presented. Idea is to get the information that one would request from ICE through presence, allowing evaluation of probability as to whether a real-time multimedia session establishment might succeed. This could be of use to users making contact decisions. Discussion: This seems to have value as a presence accuracy enhancer, and some would like to see it move forward. There seems to be a general consensus to follow this work in SIMPLE. Topic: Presence Data Model, Jonathan Rosenberg ---------------------------------------------- Slides presented. Goal is to establish a common understanding of what opresence documents mean in order to achieve interoperability. Issue: One vs. many Presentity. Model allows one presentity per document. Proposal to handle conflicts at attribute level. No comments from meeting. Issue: Devices or Not. We now have a definition of device clear enough to understand what we are debating, but not clear enough for a final definition. Open issues remain around distributed devices. Comment: We need to simplify the use-purpose of the device tuple. This probably includes some kind of device identifier that allows the UI to display an appropriate icon. If one doesn't actually use this description to guess device properties, the information is useful. Discussion: There is a useful correlation property, when a user can see that a specific device offers multiple services. Debate continued on whether the device classification (like PDA, mobile phone) implies enough about the utilization characteristics. Further discussion deferred. Comment: It seems like the presnetity being modeled is seen as a collection of devices, and this doesn't really give the correct picture. Discussion: We are modeling the user, its services, and the devices forming the context on which those services execute. Issue: Resources and capabilities. Design team believes that association of resources nad capabilitiesare not useful as part of "device" and are probably mroe useful as part of "service". Issue: Correlation. Design team conclusion is that the state of a given service cannot in general be inferred from knowledge of the state of other services executing on the same device. Comment: This relates to the use of user-supplied identfiers, e.g. cellphone vs mobile. The key thing is that services are identified by URIs, and these URIs can be mapped to devices under applicaton control. Question: Do we have in mind that certain elements will be used only with certain tuple types? Proposed: Go through RPID, and for each thing, describe where it can be and what the limitations are. Issue: Idle. Discussion on restricting the amount of information going to the watcher. Counterpoint that this needs to not be restricted, but well-defined. Comment: Less is better to display, in most cases. Discussion on whether this work will delay anything. We are not anticipating changes that would restructure any of the related documents. Comment: Restricting presence to people is speciesism. Discussion: The idea is to model things that have human-like properties, as opposed to places or organizations. This discussion proceeded to devolve into pseudoreligiosity and was deferred to the list. Poll: Do we believe, as a group, that this model is the one that we want to pursue, at least in a directional basis? None opposed noted. Session Two: recorded by Chris Boulton XCAP Base Document - No questions on initial resolved open issues slide. DELETE Idempotency - Cullen - proposed removal positional insertion - JR Conclusion -Add text to draft regarding URI construction for deletion. - Is there a requirement for idempotency checking? - Ted - Suggested that not using would be choosing a different protocol from HTTP - JR to add text to cover 2 scenarios for idempotency checking that rejects the request if there wasn't an "if-match" header and allows if present. Consensus agreed. XPATH Namespace Context - Rohan questions the need for this feature. - JR to consider options and propose to the list ETag and DELETE - What is the meaning as the resource doesn't exist - Ted Proposal to add a resource body to signify entity tag status o This could be the XCAP diff format - Empty Content proposal discarded - Concrete proposal for entity body in response to delete to signify entity tag status - No objections Caching Add discussions of caching XCAP List Usage document - List of resolved issues reviewed - Issues since WGLC reviewed XCAP Package/Diff - Radical change - aligned with Config framework - Now just a format that can be used with the config package XCAP Directory - Do we need functionality? - Miguel to check config package to cross reference functionality. PIDF-ICE - Is this useful - Consensus seems to be it is. Presence Data Model - Need a resolution of "What is a Tuple" discussion for interoperable systems. - JR provided update on Design team discussions - Still confusion regarding "device" definition - Group feedback required on discussion/conclusion - Discussion needs to take place on the list - Poll to see if the group is happy with direction of this model - consensus was "Yes" |