Last Modified: 2005-11-03
Done | Server Features Negotiation submitted to IESG | |
Done | Complete IESG requested fixes to provrel and servfeat | |
Done | Revised proposed standard version of SIP (2543bis) submitted to IESG | |
Done | SIP Events specification to IESG | |
Done | The UPDATE Method submitted for Proposed Standard | |
Done | SIP extensions for media authorization (call-auth) submitted as Informational | |
Done | Preconditions extensions (manyfolks) spec to IESG | |
Done | SIP Privacy specification to IESG | |
Done | SIP Privacy and Security Requirements to IESG | |
Done | The MESSAGE Method submitted for Proposed Standard | |
Done | The Replaces Header submitted for Proposed Standard | |
Done | Refer spec to IESG | |
Done | SIP NAT extension submitted to IESG | |
Done | SIP over SCTP specification and applicability statement | |
Done | Mechanism for Content Indirection in SIP submitted to IESG for Proposed Standard | |
Done | The SIP Referred-By Header submitted to IESG for Proposed Standard | |
Done | Session Timer spec, revised to IESG | |
Done | Caller preferences specification submitted to IESG | |
Done | Submit SIP Identity documents to IESG for Proposed Standard | |
Done | The SIP Join Header submitted to IESG for Proposed Standard | |
Done | Replaces header to IESG (PS) | |
Done | Upgrade S/MIME requirement for AES in 3261 to IESG (PS) | |
Done | Application Interaction to IESG (BCP) | |
Done | Presence Publication to IESG (PS) | |
Done | Resource Priority signaling mechanism to IESG (PS) | |
Done | Guidelines for Authors of SIP extensions submitted as Informational | |
Done | Enhancements for Authenticated Identity Management to IESG (BCP) | |
Done | MIB spec to IESG | |
Done | Request History mechanism to IESG (PS) | |
Oct 2005 | Mechanism for obtaining globally routable unique URIs (GRUU) to IESG (PS) | |
Oct 2005 | Mechanism for REFER without implicit SUBSCRIBE to IESG (PS) | |
Nov 2005 | Connection reuse mechanism to IESG (PS) | |
Dec 2005 | Mechanism for Target-Dialog to IESG (PS) | |
Jan 2006 | Mechanism for feature parameters with REFER To IESG (PS) | |
Feb 2006 | Mechanism and guidelines for outbound connections to IESG (PS) | |
Feb 2006 | Guidelines for Using Certificates with SIP to IESG (BCP) | |
Mar 2006 | Location Conveyance with SIP to IESG (PS) | |
Apr 2006 | Mechanism for End-to-Middle Requests to IESG (PS) | |
Apr 2006 | Mechanism for Response Identity to IESG (PS) | |
Jul 2006 | Using SAML for SIP (PS) | |
Jul 2006 | Revise Charter, including developing a task for a roadmap that will identify the "critical supporting specifications" and map out the Draft Standard interoperability report effort |
RFC | Status | Title |
---|---|---|
RFC2976 | PS | The SIP INFO Method |
RFC3204 | PS | MIME media types for ISUP and QSIG Objects |
RFC3261 | PS | SIP: Session Initiation Protocol |
RFC3262 | PS | Reliability of Provisional Responses in SIP |
RFC3263 | PS | SIP: Locating SIP Servers |
RFC3265 | PS | SIP-Specific Event Notification |
RFC3310 | I | Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) |
RFC3311 | PS | The Session Initiation Protocol UPDATE Method |
RFC3312 | PS | Integration of Resource Management and SIP |
RFC3313 | I | Private Session Initiation Protocol (SIP)Extensions for Media Authorization |
RFC3319 | PS | Dynamic Host Configuration Protocol (DHCPv6)Options for Session Initiation Protocol (SIP) Servers |
RFC3323 | PS | A Privacy Mechanism for the Session Initiation Protocol (SIP) |
RFC3325 | I | Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks |
RFC3326 | PS | The Reason Header Field for the Session Initiation Protocol (SIP) |
RFC3327 | PS | Session Initiation Protocol Extension for Registering Non-Adjacent Contacts |
RFC3329 | PS | Security Mechanism Agreement for the Session Initiation Protocol (SIP) Sessions |
RFC3361 | PS | DHCP Option for SIP Servers |
RFC3420 | PS | Internet Media Type message/sipfrag |
RFC3428 | PS | Session Initiation Protocol Extension for Instant Messaging |
RFC3486 | Standard | Compressing the Session Initiation Protocol |
RFC3515 | PS | The Session Initiation Protocol (SIP) Refer Method |
RFC3581 | PS | An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing |
RFC3608 | Standard | Session Initiation Protocol Extension Header Field for Service Route Discovery During Registration |
RFC3840 | Standard | Indicating User Agent Capabilities in the Session Initiation Protocol (SIP) |
RFC3841 | Standard | Caller Preferences for the Session Initiation Protocol (SIP) |
RFC3853 | Standard | S/MIME AES Requirement for SIP |
RFC3891 | Standard | The Session Inititation Protocol (SIP) 'Replaces' Header |
RFC3892 | Standard | The SIP Referred-By Mechanism |
RFC3893 | Standard | SIP Authenticated Identity Body (AIB) Format |
RFC3903 | Standard | An Event State Publication Extension to the Session Initiation Protocol (SIP) |
RFC3911 | Standard | The Session Inititation Protocol (SIP) 'Join' Header |
RFC3968 | BCP | The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP) |
RFC3969 | BCP | The Internet Assigned Number Authority (IANA) Universal Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP) |
RFC4028 | Standard | Session Timers in the Session Initiation Protocol (SIP) |
RFC4032 | Standard | Update to the Session Initiation Protocol (SIP) Preconditions Framework |
RFC4092 | Standard | Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP) |
RFC4168 | Standard | The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP) |
Minutes, SIP Working Group, IETF 64Edited by Dean Willis from notes by:
Initial Agenda, Session 1: Tuesday, November 8, 1300-1500
Topic: AgendaGRUU will be added to the agenda when possible due to new issues on-list. Certs dropped from agenda due to no open issues requiring discussion.
Topic: Charter and StatusDiscussion led by chairs Slides presented and included in proceedings. Issue: Charter. The only element of the new charter
receiving substantial discussion was the milestone “Draft
standard versions of SIP and critical supporting
Issue: draft-cao-sip-response-auth-00. Few comments received on list. Attendees asked to review. Issue: Certs draft. This draft is moving from SIPPING to SIP as a charter deliverable. A poll of the room indicated that at least seven parties plan to implement the specification. All parties are asked to review the draft, but Rohan will pick out at least two of the implementers to assist in a detailed review. TODO: Rohan to coordinate review of Certs draft. Issue: MIB Document. The review of this document has been delayed by slow responses to MIB doctor requests. The editors report that there is some controversy over method identifiers, which the MIB doctors apparently asked to have deleted from the document, then asked to have added back. Topic: Connected IdentityDiscussion led by John Elwell Slides presented and included in proceedings. Issue: Basic mechanism. Several approaches proposed. Discussion rapidly converged on modification of “From:” header fields to reflect identity as used in the Identity draft. Tieing this change to the Outbound draft seems to provide for most aspects of backward compatibility, but several participants argued strongly that we should go ahead and “really fix” the “From: header without cruft to support backward compatibility. The changing of From: in mid-dialog requests also seemed to have a general consensus, but didn't appear to be generally understood. The discussion concluded with a strong consensus on this general line of work, but a general feeling tht there are probably some lurking issues that won't become clear until the approach is specified in a draft. Topic: SAMLDiscussion led by Hannes Tschofenig Slides presented and included in proceedings. There seems to be a strong general interest in the approach, but the working group seemed to agree that we need a draft with more discussion of practical mechanism and examples in order to really get started here. There was no consensus to adopt the draft at this time as baseline text toward the charter deliverable, but the author was encouraged to proceed with the work and continue the discussion with the working group in hopes of reaching critical mass. Topic: Answer and Alert ModesDiscussion led by Dean Willis and Andrew Allen Slides presented and included in proceedings. Discussion centered on possible security issues relating to the combination of auto-answer and null alert modes providing a “bug my phone” or “baby monitor” attack. The group reached consensus on revising the draft to eliminate the alert-mode functionality, with a general agreement that the use of Alert-Info with URN behaviors as proposed in SIPPING is a more attractive approach. The revised draft shall also include stronger guidance on the “bug my phone” aspect. Robert Sparks noted that several aspects of the draft would be likely to be misunderstood by implementers and might result in “train wreck” implementations, and agreed to send text to the editor to correct these flaws. The group did agree that completing this work for OMA is critical and consistent with the new charter of the working group. TODO: Chairs to coordinate new milestone with AD. Topic: Trust Path DiscoveryDiscussion led by Kumiko Ono Slides presented and included in proceedings. Issue: Scaling and “push” vs “pull” model. Noted that push model requires advance calculation of several degrees of connectivity, which can become very large very quickly. It was reported that AOL cannot three degrees of connectivity for the AIM database as the problem space becomes too large. Noted that the IAB messaging workshop recommended investigation of a distributed reputation system. Noted that there is a problem relationship to DKIM, so there could be a similarity in the solution. Suggested that this material is worth holding a BOF on and perhaps chartering a working group. The chairs requested the author to keep the working group informed of progress in this area, but the general consensus is that this problem is outside the scope of SIP.
Topic: SAML for SPITDiscussion led by David Schwartz Slides presented and included in proceedings. Discussion indicated a general interest in the problem and approach if it can be shown to scale to practical problem sets. It was noted that the current draft is domain-oriented, but that it could be extended to end-user devices if those devices supported SAML. The author was also encouraged to further explore the idea of federated domains.
Topic: Remote Call ControlDiscussion led by Rohan Mahy Slides presented and included in proceedings. Question: Would full arbitration of end-point (not just dialog) state be in scope for this draft? The authors don't feel it to be in scope at this time. Noted that revisions should explain how this interacts with REFER. Noted that this is approaching “full CTI (computer telephony integration)”, which has previously been out of scope in SIP. The room was asked to show hands if they thought this discussion to be in/out of the interest of SIP. About 20 responded positively, with about 2 opposed. The meeting session concluded on-schedule. Initial Agenda, Session 2: Thursday, November 10, 1300-1500 (Note: conflicts with SAAG)
Topic: AgendaJames Polk suggested that there is no need to discuss location conveyance. We agreed to have a minimal discussion. GRUU added to agenda. Outbound and Refer Feature Parameters reordered due to slide availability issues. If time permits, we will discuss Dale Worley's draft on dialog event package implementation guidelines, draft-worley-sipping-dialog-00.txt Topic: Connection reuseDiscussion led by Rohan Mahy Rohan reports that there have been conflicting proposals to fix open issues and that the draft has been languishing. He will reopen discussion of the draft on the mailing list. No slides presented Topic: GRUUDiscussion led by Jonathan Rosenberg Slides presented and included in proceedings Issue: Indicating URI is a GRUU. Consensus emerged on not using a URI parameter to indicate that a URI is a GRUU, but to rely on normative behavior that clients supporting GRUU will always use a GRUU. The text will be amended based on text submitted by Dale Worley on the SIP list. The text will also be revised to clarify that one does not make the assumption of GRUUness based on “Supported: gruu”.
Issue: Difference between retargeting and routing. Definitions:
Proposal: 305 implies re-routing, Other 3xx imply re-targeting. Tie to SIP outbound. Put registered contact in Route header instead of request-URI. Issue: GRUU usage as proposed breaks Outbound as written. This point was agreed, and led to intense discussion. Suggested by Sean Olson that the GRUU be placed in the route header, not in the contact. Jonathan asked for written clarification on this. Discussion raged interminably, resulting in a decision to have an after-hours discussion. Noted that this represents a substantial change, but a huge improvement, in general SIP routing methodology. Should this increment or change the SIP version number? The consensus here was “no”, although we appear to be getting very close to that threshold. Topic: OutboundDiscussion led by Cullen Jennings Slides presented and included in proceedings Issue: Config framework requires a subscribe before UA has credentials to perform registration. Resolution: Use of pin-route option tag in require header agreed to by group. Issue : Record-Route and Reliability Proposal: Use GRUU and don't record-route in EP No discussion of issue – seemed to be general consensus on proposal. Issue: Service Route Proposal: Start with configured outbound proxy, each registration returns a service route, this service route replaces the outbound just for that registration. Discussion finally concluded that this was a not major issue, but that some changes to Service-Route would be needed. Issue: Should outbound have a dependency on draft-rosenberg-sip-route-construct? Resolution: Take it to the list Issue: Terminology The flow/flow-id/connection terms are confusing and Cullen asked for suggested new wording. Topic: Location ConveyanceDiscussion led by Brian Rosen, supported by James Polk Issue: Need people to look at draft Issue: Do we need a separate package or should we just use presence package? Proposal: State that it works with presence and it can be included in other packages Resolution: Discuss on list Topic: Refer Feature ParametersDiscussion led by Orit Levin Slides presented and included in proceedings Issue: What feature tags should be included in REFER? Proposal: Update 3840 and callerprefs use cases, include all feature tags that were listed in the most recent contact header field of the REFER-Target. Alternate proposal (Cullen proposal): Need to have a document that gives implementers information on what feature tags to include in what messages. Resolution: Consensus as judged by chair: Move forward with proposal for REFER as presented. Deal with Cullen's proposal separately. Topic: Target DialogDiscussion led by Jonathan Rosenberg Slides presented and included in proceedings Issue: Proposal to extend target-dialog Resolution: Don't do it Issue: Handling of request with target-dialog that doesn't exist. Proposal on list was to use 481. Resolution: Don't use 481, use existing text. Noted by Cullen Jennings & Robert Sparks that 3261 already recommends the use of crypto-random tag values, but that existing implementations do not use enough bits to have sufficient randomness. This shows a need for more than rough guidance on this sort of thing. Action: Revise and resubmit document. Topic: Route ConstructionDiscussion led by Jonathan Rosenberg Slides presented and included in proceedings Discussion was generally favorable and the working group was asked to consider whether this document provides sufficient additional clarity to SIP that it should be considered under the revised charter scope of “increasing the stability of the SIP specification”. The consensus is favorable, and the chairs are directed to work with the AD to establish a milestone. TODO: Chairs to work with AD to establish a milestone for Route Construction. Topic: Dialog Event PackageDiscussion led by Dale Worley Slides presented and included in proceedings Implementations do not currently contain the information needed to be useful. So, this draft provides guidelines on how to use dialog even package. Need implementers to review this draft and see if it helps. Cullen Jennings noted that there is an ambiguity with respect to how to signal state at the end of a call and that it would be useful to address this in future revisions.
|