Last Modified: 2005-01-31
| 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) | |
| Mar 04 | Application Interaction to IESG (BCP) | |
| Mar 04 | Resource Priority signaling mechanism to IESG (PS) | |
| Done | Presence Publication to IESG (PS) | |
| Apr 04 | Connection reuse mechanism to IESG (PS) | |
| Apr 04 | Enhancements for Authenticated Identity Management to IESG (BCP) | |
| Done | Guidelines for Authors of SIP extensions submitted as Informational | |
| May 04 | Mechanism for obtaining globally routable unique URIs to IESG (PS) | |
| Jun 04 | MIB spec to IESG | |
| Sep 04 | Review WG status (consider closing) and/or submit a future milestones plan to IESG | |
| Done | Request History mechanism to IESG (PS) |
| 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) |
Minutes, SIP at IETF 62Revised 4/8/2005 Minutes edited by Dean Willis based on notes by Paul Kyzivat, Spencer Dawkins, Vijay Gurbani, Amy Pendleton, and Miguel Angel Garcia-Martin. Monday, 1930-2200 Topic: Agenda Bash and Status by Chairs Slides presented and to be included in proceedings. Agenda accepted as presented. Chairs reviewed status of current work. It was noted that the current charter and milestones are completely obsolete, despite having had changes submitted several times by the chairs and the ADs. Apparently there is some sort of process problem with the IETF web site. Topic: GRUU Remaining Issues (Knowing AOR, Rewriting by SBC, etc.) by Jonathan Rosenberg see draft-ietf-sip-gruu-03.txt Slides presented and to be included in proceedings. Changes to previous doc reviewed. The redundancy issue has been declared out of scope, and discussion suggested that this should perhaps be placed into the Jennings "outbound" draft. The current model assumes that both "sip" and "sips" versions of a GRUU are created when a GRUU is, and that they route to the same resource. The URI scheme of the "To:" header is used to select the appropriate GRUU. It was suggested that this should be clarified in RFC 3261, perhaps as an errata. Several record-routing cases were discussed based on slides. There was inconclusive discussion of a scenario where the use of GRUU creates an undesirable "tromboning" effect back to the upstream entity after resolution 1) Open Issue: Discovering AoR from A GRUU Discussed issue about getting AOR from gruu - why this is/isn’t a need. Objections were raised to the proposed compromise in the draft. Various other alternatives discussed. Cullen Jennings didn't see a compelling reason for it. Paul Kyzivat (who had raised the issue initially) said he no longer found this a need- solutions other than GRUU were sufficient. Aki Niemi and Orit Levin still expressed a desire for this feature. Dean, as chair, said we have no requirement for this, and a domain can do it anyway if it wants. Inconclusive discussion followed. 2 )Open Issue: relationship of Identity to GRUU The relationship between these two elements was discussed without conclusion, although Jon Peterson (author of the Identity work) asserted an pinion that a GRUU and an identity are not the same thing. Topic: Non-Invite Transactions by Robert Sparks see draft-sparks-sip-nit-future-01.txt Slides were presented and should be included in the proceedings. 1) Proposed that we accept and refine Time left concept, and not define general "Try again later" behavior. This approach uses a new header indicating how much time the downstream element has left. Adam roach argued that it was not a good idea - if we don't get any hints from proxies who are not aware of this extension, we will go round in circles. Robert called for a hum on if this work should continue or not. The consensus was for neither the timeline nor the "try again later" work to continue. 2) Proposed that we pursue address success and failure caching. The goal is to allow next NIT to avoid non-responding address. Question is how often to probe the non-responding address? No concrete way. Jonathan Rosenberg proposed that we use Jenning's outbound I-D. Cullen Jennings stated that this may work for UA - Proxy, but Proxy-Proxy may not quite work. Robert Sparks proposed that for now we carry a blacklist; put these addresses in a cache with a timeout (let the developer determine the timeout). And we continue to pursue Cullen's outbound I-D as a possible better answer. Discussion followed. The conclusion was that for now we will use some weighted back to list algorithm that will be fleshed out on the mailing list. Topic: REFER Extensions by Orit Levin see draft-ietf-sip-refer-with-norefersub-01.txt Slides were presented that should be included in proceedings. Only one open issue remained for the draft since its WGLC. This was "How does a REFER-Issuer enable the feature?". Alternatives include: a) Commonly preceded by OPTIONS, b) supported header in the request, c) required header in the response, d) require header in the request. Discussion agreed that the Supported header is the wrong approach, as it indicates which features are supported by the sender, not required for the respondent. Discussion became prolonged, and the participants were moved to the hallway for a focused discussion. This discussion reached the following conclusion: 1) Add a new header to be used with REFER request and the corresponding response 2) Keep option tag 3) Including this option tag in Require header is NOT RECOMMENDED. This conclusion was shared with the WG, and no objections were noted. The "hallway" conversation necessitated a slight juggling of the agenda, with Resource Priority being discussed during the hallway discussion. Topic SIP Resource Priority by James Polk See: draft-ietf-sip-resource-priority-06.txt Slides were presented and should be included in proceedings It was noted that this draft is just 2 weeks shy of its 5th anniversary, making it one of our longer-lived discussions. Changes since previous version were discussed. The plan of record is to submit and WGLC a revision of this draft with minor cleanup as proposed here. The authors requested: "For those who care, please approach us and let us know of any concerns. If someone can read this as an innocent bystander and provide comments, please do". The chairs polled the room: "Does everyone who cares about this draft think their issue have essentially been met?" The consensus of the room was favorable and no issues were raised. It should be noted that Mike Pierce, a long time participant in this discussion, was not present as of this poll. Topic: Request Identity by Jon Peterson See: draft-ietf-sip-identity-04.txt Slides were presented and should be included in the proceedings. New open issues: 1) Display name handling - should identity signature cover the display name? All clients (MS Outlook, for instance) use the display name, and not the name-addr. Jonathan noted that this is usually a good thing; the service provider bears the burden of coming up with the display name and the client is provided a bit-by-bit rendering of the display name. Following discussion indicated a strong consensus to protect the display name if feasible. The consensus was to protect display name, and in the display name, just put quoted strings and prohibit LWS. In the security section of the draft there should be a discussion of the disadvantages of including display names (account minting a la Yahoo!)...) 2) Applicability to REGISTER - why provide authentication info to a authentication server as well as to the registrar? Jonathan Rosenberg presented an acceptable use case, and the authors concluded that they would amend the draft to indicate the usability of Identity in REGISTER transactions. Topic: Response Identity by Jon Peterson No slides presented. Jon lead a discussion about the meaning and critical aspects of response identity. Jon says he has lost his way on this draft. The sip-identity work doesn't work for responses because of retargeting. Who do responses actually come from? What are intermediaries allowed to do when routing SIP requests? How would a UAC make authentication decisions based on response identity? Anyone can impersonate a requester, but impersonating a responder is a lot harder - need dialog identifiers, etc. Improve channel security to make it even harder to impersonate a responder? Provide causal trace after-the-fact? Let UAC explore new targets for a request? Assume bar is high enough for impersonators now? - what if the real responder tries to impersonate someone else? Jonathan Rosenberg said major threat is if someone fakes a connected party id, assuming we had that, and that such is a requirement. Rohan Mahy thought History-Info is the right solution and said he plans to write up something about it. Consensus: We're generally headed in the right direction but have a long way to go. Topic: Accept-Disposition by Gonzalo Camarillo See: draft-camarillo-sip-accept-disposition-00.txt Slides presented and should be included in proceedings open question: How do we say we don't understand content-disposition? Add Accept-Disposition (equivalent to Accept header)? We have several ways to require support for something - method, option tag, body with handling=required. Want to pick one and clarify content disposition handling Combining two problems - Accept is used as hint about how you goofed. Isn't Warning closer to what we're getting at? Accept headers became useless because everyone Accept: * (everything). Don't we really want an explicit code that tells us what we want to know? How to tell refusal from lack of comprehension? What is scope of Accept-Disposition? Conclusion: Rather than pursue this approach, for the application (exploder) that stimulated this draft there was a decision to use an option tag to negotiate support for the needed combination of features. Separately, there was interest by some (at least Gonzalo and Paul) in starting to investigate the underspecification of Content-Disposition. Tuesday, 1300-1500 Agenda by Chairs Agenda accepted as proposed in slides. The proposed topic of "Connection Reuse" was withdrawn by author Rohan Mahy. If time allows, a discussion of retargeting led by Jon Peterson will be undertaken. Topic: SIP Interaction Framework by Jonathan Rosenberg See: draft-ietf-sipping-app-interaction-framework-04.txt Slides presented and should be included in proceedings The current state of the draft has raised a requirement for other work that Jonathan calls the "target dialog" approach and has fleshed out. Discussion of this approach ensued. Alan Johnston noted that an option tag is needed. Robert Sparks spoke in favor of the approach. Following discussion, the chairs polled the room and a consensus to proceed with this approach was reported. The chairs are instructed to work with the Area Director to add the target dialog draft to the working group charter. Topic; Management of Outbound Connections by Cullen Jennings See: draft-jennings-sipping-outbound-01.txt Slides were presented and should be included in proceedings Open issue: Do we need an option tag to know if registrar supports flow-id and if UA supports this. Rohan argued against the option tag. Jonathan proposed that it would be needed it in the Require in the REGISTER. Rohan countered that one could check in the response what it came back, and perhaps add a Contact header field parameter to discover if the functionality is supported by the registrar. Alan H. noted that if the registrar does not support the functionality, you end up with a wrong binding that you have to fix later. After discussion, there were no sustained objections to adding an option tag, and a quick poll indicated consensus for this approach. Cullen agreed to make this change in the next revision. Topic: Using Certificates with SIP by Cullen Jennings see draft-ietf-sipping-certs-01.txt Slides were presented and should be included in proceedings 1) Robert Sparks commented that the draft needs further text about caching certs, and checking certificate revocation. 2) Jon Peterson suggested that we make sure to clarify subscription duration, which Cullen noted should not cache beyond validity time 3) Rohan observed that we need to refresh the subscription even if the cert is still is valid, when there hasn't been a NOTIFY for some long period of time. 4) Francois Audet noted issues with retargeting and forking. For example,the sales group example does not work properly. An other case is retargeting. Use case: the help desk. You don't care who is going to answer, but the requirement is the conversation to be encrypted. Cullen observed that the assumption of this draft is indeed that all devices for the ID have the same credentials. Jon Peterson suggested that RFC 3261 with SIPS resolves theses cases. Cullen observed that there are separate problems: a) to determine who the certificate belongs to, and b) acquiring the certs. This draft addresses only b. It was resolved that the scope of the draft should be clarified, and that we should change the name to "credential management" instead of "certificate management". 5) Jonathan asked:"What happens if I send a SUBSCRIBE for a GRUU? Do I get the cert for the AOR?" Cullen responded that the draft discusses users, not devices. Jon Peterson stated that this problem should be resolved in the identity draft, not here. Topic: End-to-middle security by Kumiko Ono see draft-ono-sipping-end2middle-security-04.txt Slides were presented and should be included in proceedings Chairs noted that they expect this work to migrate from SIPPING to SIP fairly soon, as has gone beyond the requirements consensus and into implementation. 1) Open issue: Signatures inside, encryption outside or the other way around? Jon reported that we did some analysis about this when drafting RFC 3261, and think the signature should go inside, the encryption outside. Cullen believes that signature inside the encrypting part will give better security properties (from the security group). Catherine also stated that the crypto community thinks signature inside is generally better, although there are sometimes exceptions. Conclusion: consensus to have signature inside. 2 )Open issue: How a proxy can tell a UA to disclose a body while protecting data integrity? Options include new error response, existing resp with warning header, or existing resp instruct UA one task at a time. James Polk asked if we could use CID and Reason header? Jon Peterson noted that CID is valid is the scope is a partial body of the multipart, but if you talk about the whole body, you don't need a CID. Dean asked: can the proxy request a body? Jon responded: if it is undecipherable, how can it point to one body? The proxy only knows the whole multipart body, not the individual parts. It is better to do it at the high level -- the proxy says I need to read this body, without indicating which one. Dean and Jonathan noted that Content-Disposition may also be applicable. No conclusion noted for this issue. Chairs Poll: This is a proposal for an implementation of the end-to-middle requirements established by SIPPING. Do we wish to adopt this as a working group item? A consensus in favor of adoption was reported, and the chairs are instructed to work with the D to get this item added to the SIP WG milestone list. Topic: Extension Negotiation by Volker Hilt See: draft-hilt-sip-ext-neg-00.txt Slides were presented and should be included in the proceedings. Discussion followed. Paul K noted that this aggregates on not being clear of what is the scope of what an Accept header is. Does it apply to OPTIONS? Severe discussion about when to include or not the Accept header, in which methods. Jonathan replied: There is not a not clear answer, but interoperability is maximized when you put everything you support in the header. OPTIONS carries a permanent scope: this is what I support. Gonzalo observed that, at the end of the day what we want to disclose is the desired Content-Disposition. Dean also observed that RFC 3261 scopes the Accept header to the duration of a dialog and that RFC 3264 scopes the Accept header for the duration of a SUBSCRIBE dialog. Dean suggested that this would be a good time time to have guidelines for Accept headers. Cullen and Jonathan maintain that it is simpler to populate the Accept header with everything that is supported, even if this set becomes very large. Jonathan clarifies that the use case is when the server can provide an alternative extension in case the client does not support a given extension. The example: if the presence server knows that the client does not support RPID, then the server might put the contents of activity elements in note elements. Adam noted that there is currently no way for the server to determine that something is not supported at the client. There does not seem to be a clear path forward, and we should perhaps look more closely at use cases. Topic: Retargeting by Jon Peterson Slides presented and should be included in proceedings. Discussion followed. Rohan Mahy observed that sometimes an unanticipated respondent is a desirable outcome. And sometimes it isn't. Keith Drage proposed that response identity should be connected party ID. Jon observed that the response identity problem is defined as the ability from the UAC to determine that the response came from an impersonator. Implementation of connected party is likely to occur security problems, and a UAC doing wrong authorizations. Jonathan suggested that we reduce the scope of the requirements to something that we can solve today. There are other harder problems that we can't solve today. Jon proposed that we need to solve the problem that ends up in SRTP, starting from SIP identity, SIP certs, Mikey, SRTP. Discussion of endpoint vs proxy trust followed, with the general consensus being that, at least to some extent, proxies must be trusted, because "the SIP proxy allocates you with a SIP URI and can take it out of you at any time". Jon proposed that we takes this work as an informational document in SIPPING discussing the kind of attacks. Jonathan noted that we need to update the SIPS behavior in SIP, there are a few open holes. Jon restated that the scope of this work is to detect that there has been a retargeting, not to prevent that retargeting to happen. No further conclusions were noted. The meeting of the SIP working group concluded on schedule. |