NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Robert Sparks <firstname.lastname@example.org>
Jon Peterson <email@example.com>
Ned Freed <firstname.lastname@example.org>
Patrik Faltstrom <email@example.com>
Patrik Faltstrom <firstname.lastname@example.org>
To Subscribe: http://mailman.dynamicsoft.com/mailman/listinfo/simple
Archive: Archive: http://mailman.dynamicsoft.com/pipermail/simple
This working group focuses on the application of the Session Initiation Protocol (SIP, RFC 2543) to the suite of services collectively known as instant messaging and presence (IMP). The IETF has committed to producing an interoperable standard for these services compatible with the requirements detailed in RFC 2779 and in the Common Presence and Instant Messaging (CPIM) specification, developed within the IMPP working group. As the most common services for which SIP is used share quite a bit in common with IMP, the adaptation of SIP to IMP seems a natural choice given the widespread support for (and relative maturity of) the SIP standard.
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 and in CPIM and in BCP 41 (so that the transport implications of the extension with respect to network congestion are considered in the design). The extension will document the mappings from its operations to CPIM.
2. One or more proposed standard SIP extensions documenting a subscription and notification service within SIP, used to support presence, compliant to the requirements for presence outlined in RFC 2779 and CPIM. The extension will document the mappings from its operations to CPIM.
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 new security capabilities are needed from SIP, 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 method across the other applications being defined for its use.
Submission of Extensions for Instant Messaging to IESG
Submission of Extensions for Presence to IESG
SIMPLE Minutes 51st IETF
SIMPLE Charter Changes:
Aug01 -- IM document set to IESG
Sep01 -- Presence extension to IESG
Jonathan Rosenberg (JDR) suggests swapping these dates as presence is running ahead of messaging.
IM Session Open Issues -- Ben Campbell
Ovelapping MESSAGEs -- overlapping transactions prohibited by 2543bis.
JDR: Three approaches
1) declare non problem
2) allow overlapping transactions by overruling spec using ordering in the content.
3) Define a message transport
4) Telnet approach -- additive transmissions until ACKed.
Question : Can we discard solution 1? This could be a real issue for machine-driven systems.
Much discussion on whether this is really a problem. The difference is in waiting for the ACK, and where reordering is done. There may also be a question of rate-liimiting. The real issue is delay from ping-pong effect.
Poll: Can we live with no overlap? General response: no.
Question: Do we want to fix SIP for this or use something not-SIP for message transport.
Question: : For session-mode, SIP has a lot of overhead. We could do something more stream-lined. What?
Question: Would text-rtp work for this? We need to do an analysis and determine if it meets requirements. There are likely to be real challenges with NATs. There are also problems with non-reliability as text-RTP is not acknowledged. What about delimiters and framing with RTP? Is this an issue for CPIM conversion? We may need a message delimiter in-body.
Question: Is ability to cross a CPIM boundary a requirement -- consensus yes. It is probably acceptable to make the CPIM gateway session stateful.
Question: Why are we limiting the "signaling session" to MESSAGEs? Could this be generalized? Can a SIP session running messages transport other messages, like OPTIONS or INVITE? Arguments in both directions presented.
Proposal: Always use ";method=MESSAGE" when referencing the URL.
Question: Should we move URL out of m= line and into c= line. Will SDP support this? SDP seems to define c=values as addresses, not URIs. ATM uses ATM addresses, so it might be possible. PINT did something similar, and the SDP guys haven't complained loudly. Consensus: yes, may need clarification from MMUSIC.
Question: How to get MESSAGE request to follow same signal path as enclosing INVITE? Do we require this ability? Proposal: save this for later.
Question: MESSAGEs hitting forking proxied will fork. Is this a problem? This says a couple of things: 1) using SIP for message transport is using a very large hammer for a small nail. This may be further cause for finding a different transport for messages in streams. Discussion postponed. Followup: We'd need alternative proposals -- and must make sure that it gets through NATs. Suggestion: We should keep in mind that session and page based messaging are separate, split the deliverables, and go ahead and get message mode into the IESG. Session mode is to be delegated to design teams to generate real proposals (goal three weeks). Ben Campbell volunteered for non-SIP. Sean Olson olunteered for SIP transport.
Question: Currently, MESSAGE follows initial path. This may be very strange if original INVITE follows non-optimal path. We will insert new text to recommend this not happen.
Question: Current proposal uses two one-way streams where persistent connections are used. Okay? It appears that commedia (in MMUSIC) will resolve this in general.
Presence Open Issues -- Jonathan Rosenberg
Privacy of Auth Policy:
Basic question: If a party subscribes, is there an issue with revealing whether they have been accepted or declined. Is this a problem? Should we solve it? Arguments on both sides. This adds complexity, and may not be doable in many implementation domains. Perhaps a set of guidelines for "authorization policy hiding" can be provided to allow specific domains to implement local policy. There are two problems here: leakage of policy (the "hurt feelings" problem) and leakage of presence (rapid vs. slow denials might indicate whether they are there).
Proposal : Don't solve, and add cautionary/implementation guidance text to the document.
Predicts that much authentication will be based on transitive trust. SIP.
Remote-Party-ID may be useful for this. Question: Should we reference it?
Presence Doc Format:
Open issues with presence document composition and upload. REGISTER may not be the right thing. Do we want to solve these? Consensus: yes.
Dicsusion: It is important to be able to feed in presence document components from multiple sources using a common interface method. This is required to be able to composite presence information.
Question: How do we want to upload presence? New method? Is there a general purpose uploading method that would work for CPL, etc.? How to prevent madness?
Proposal: Property-value management mechanism based on content-disposition. This might actually be able to replace the whole registration payload work, which is currently on-charter for SIPPING.
Consenus to explore this line of work.
Background: Use of user-supplied authorization policy, and notification of the lack of authorization policy.
Proposal: watcherinfo package with data set for each subscription. Poll for dissenters: none. Discussion: Do we wish to include type or class of authorization in the data set? Consensus no due to complexity. Audience requested to folloow up with more consideration of mechanism and proposed FSM.
Settting Authorization Policy:
1) Say nothing -- app specific
2) Include approve/reject URLs in wathcerinfo to allow GUI processing at client
3) Define policy doc and upload mehod
Much discussion. If policy is semantically self-contained, this would allow a great deal of interoperability. The URL suggestion requires web servers and HTML renderers. Proposals:
1) Leave the solution to the implementaion, potentially using other-defined "upload" procedure, and leave open the option of defining a policy document in the future.
2) Punt to IMPP for a policy document format. Probably no result.
Consensus seems to favor proposal 1.