Last Modified: 2004-11-01
| 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 | |
| Sep 04 | 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 |
| 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 |
|
Minutes of SIP WG: IETF 61 Monday, November 8 Session -------------------------- Agenda bash and Status - Chairs Seven RFCs since last IETF, including PUBLISH WGLC - GRUU, non-Invite-Transaction Some things are late Proposing new milestones - two REFER drafts - two different milestones? Rohan has new sponsor and new e-mail address Connection Reuse Rohan Mahy, Cullen Jennings - draft-ietf-sip-connect-reuse-03.txt Non-trivial security problems with existing digest-based reuse mechanisms Now support reuse of mutual-authenticated TLS connections Cullen has an open issue (the only one on the table) Based on Via: header with ;alias Certificate could contain multiple domain names URIs Cullen suggests basing the alias on the TLS peer value Vulnerable to DNS cache poisoning, but easier to do Rohan suggests going with existing proposal - Lots of discussion about many other ways to authorize connections - Long discussion ensued about the scope. Is there any time you don't want to reuse a connection? Yes, for load balancing. How does this mechanisms interact with existing DNS SRV weighting algorithm from RFC3263. - Jonathan taking action to provide scenarios Cullen - lots of problems between UA and proxy - firewalls, etc. Proxy keeps track of "connection" (whether TCP or UDP four-tuple). 1. TCP keepalive every periodic number of seconds? CRLF? REGISTER? New message (PING)? Comments: - REGISTER is horrifically expensive - not a general solution - CRLF doesn't generate an application ACK - have to wait for TCP keepalives. question about if standard TCP interface allows check. We think we can check unacked bytes in most(?) socket interfaces and use CRLF. 2. UDP keepalive - same problem plus small residential NAT rebooting can't be detected (still respond to PINGs) Use STUN for UDP "connections"? No objections in the meeting 3. Redundant connections? Need a unique device id in the registration Allow this? yes May need Quick Reconnect to reduce proxy load on avalanche restarts, etc. - the limiting factor on scaling most deployments. Don't add load when the proxy is most loaded! Identity - Jon Peterson - draft-ietf-sip-identity-03.txt New version of the draft, removes response identity text, added examples Added text on privacy and providing identities for telephone numbers ("punting until later") Identity-Info schemes: allow CID? DNS URLs? but don't be TOO generous (interoperability problems) Commment: What's the mandatory-to-implement scheme? RFC 3840 already has "schemes I support". Q: Does everyone implement CID URI? apparently not, at least not the people in the room :-) What's the relationship to the -certs draft? We're concerned about required modifications to installed base Rohan - normative dependence on -certs not a good thing. the draft does not require UAs to implement certs draft. Shopping for response codes? can't dereference Identity-Info, don't like your certificate, bad Identity in From field... Do we need three new response codes? We only have 100 4XX response codes, so ... Room concensus is three new response codes Q: we're assuming use of global PKI. It's harder than it looks A: but it does work for the WWW today, and no root or trust model is mandated by the draft Q: but on the WWW, users are making choices. In this case, proxies are making choices. That's harder. Q: Is "don't like your certificate" a provisional response? No, it's final. Jon believes it is possible for servers to make these decisions in some scenarios. Look at message-identity draft - it's 44 pages of analysis about how we got where we are today! GRUU - Jonathan Rosenberg - draft-ietf-sip-gruu-02.txt General problem - what should gruu specification say about sips and gruu? Want to avoid two two registrations to get a sip and sips URI for the same resource. Existing spec allows upgrade from sip to sips (resource must be the same for both schemes) Assume both don't have to exist, but if they do, they must point to the same resource. If contact is sip, GRUU is sip URI, but server creates sips URI, too. If contact is sips, GRUU is sips URI, but server does not create sip URI. Does this work for everyone? Q: if sips URI is created and then used, we may/may not be able to tell a connection is secure. This is bad. Q: creating sips GRUU is implicit behavior (client didn't request this) A: creating a sips GRUU doesn't mean much - don't have to create a TLS connection, etc. Q: problem is that if we're not doing TLS, we may be doing something else (present or future protocols) Q: The recipient can do the same upgrade to sips anyway. Q: Does this require unnecessary resources on the server? A: We have the same problem with people trying to connect to people who don't support SIPS now Q: When we register, do we see sip and sips URIs? A: Depends on what you send as the contact URIs. Should work the same as AOR registrations Jonathan to add text reflecting his proposal Connection reuse/GRUU reuse has been problematic - when we have multiple connections, we get wrapped around the axle Allow multiple contacts in a GRUU for redundancy (all to the same instance)? Q: If my TCP connection dies and comes back, is my connection-id the same? If so, it's not a connection-id... Q: If I'm hosting these things, how many do I know to create? A: Maybe just two, but this is provider policy - does the client know how many interfaces it has? Maybe... Who understands the issue here? a critical mass - please send e-mail to list/Jonathan and chairs Conflict Resolution - current spec requires since contact per instance, which helps avalanche restarts Does AOR map to a GRUU? how does edge proxy know it should record-route? Should not record-route if client uses GRUU - this happens in IMS architecture, for instance 200 OK contains Supported: GRUU EP? Remove record-route on response Q: Shouldn't edge router be authoritative anyway and route without GRUU? A: IMS proxy may be in a different domain (HSP and VSP domains) - spiral is expensive - don't use GRUU in these cases * (resumed here) Does GRUU map to AOR? AORs map to contacts, so do you redirect to a GRUU or to a contact? You get different proxy behaviors for AOR->GRUU and GRUU->contacts Q: If GRUU was just a higher-priority contact, would that solve this problem? A: Would depend on the logic of routing Proposal: AOR -> GRUU -> contacts? Register and refresh up the chain, AOR -> GRUU mapping disppears when GRUU contacts disappear Q: This is the wrong direction, we're going to explode. Enumerate new behavior reflecting GRUU extension We have a real terminology problem with contacts and connections - sometimes they are headers, sometimess not Cullen - we're confused, we need a room with a white board Q: Should reg-extension be merged with this draft? Content Indirection - Eric Burger - draft-ietf-sip-content-indirect-mech-05.txt 05 draft provides optional content, content-disposition entity header now a MUST (from SHOULD) Using hash, not base64 Open Issues - e-tags and content-ID? work this week URI scheme negotiation - full negotiation needed? ("yes" = hack SDP, out of scope) History Info - Mary Barnes - draft-ietf-sip-history-info-04.txt Added protocol structure text as descriptiove Added text on scenario when TLS not available Some editorial changes Should -> MUST for applications lacking History-Info and privacy impacts Updated response processing to reflect privacy Added text for reason header in response Added appropriate characters for escaped example URI Have identified indexing error, 480 timeouts should be 408s, missing quote on "Busy Here" WGLC ends on November 29 Feedback, especially with text, is always appropriate, especially now. SIP Working Group Meeting: Session 2, 11-11-04 Resource Lists : Adam Roach - Updated Schema - Added text on S/MIME Handling - Open Issue: Credential Transfer – How can you be sure user has authorized being on resource list? Using Identity covers 95% of cases: for now, resource list server needs to be either in the domain of the subscriber of the list or in the domain of the notifier. Will put off solving the three domain model (list server is in an orthogonal domain), but make sure text doesn’t prevent doing this in the future. Resource Priority: James Polk - Updates from 04 to 05 were extremely controversial. Intended to address expected IESG concerns on interoperability, normative inspecificity, and IANA registration. - Proposal to remove confusion about Modes. Agreed to Remove Semi-strict Mode. - Editor proposed New Table describing Resource Priority namespaces for IANA. - Big fight occurred here: 04 vs 05 agreement on specifically defining terms people adjourned, and issues will be brought to the list Refer Extensions – Orit Levin - Split refer extensions into two separate drafts: REFER with no implicit Subscription, and Feature tags with REFER - Refer with no implicit subscription should be included Cert Usage: Cullen Jennings - Draft describes both HTTP and SIP method for Fetching Certs and Credentials. One open issue: Which mechanism is mandatory to SUBSCRIBE over SIPS or HTTPS GET: - Using HTTPS expected to scale easier (no subscriptions) and is lower bar for server implementation, while SIP mechanism allows for automatic certificate revocation and reuse of a protocol known to be implemented in the client. - There was very rough consensus to go forward with SUBSCRIBE/NOTIFY as the mandatory mechanism SAML for SIP - Latest draft Covered Identified Problems in previous version - Need to Document Assertion Constraints and scope solution approaches - Comments were solicited Other: Rough Consensus on making multipart-mime mandatory in all SIP implementations to be taken to list |