[Sip] Draft minutes for SIP at IETF 69

[Dean Willis]

Draft minutes are now available at: http://www.softarmor.com/mediawiki/index.php/Minutes_for_SIP_at_IETF_69 HTMLized text follows for those reading offline: Contents 1 Session One, Monday July 23 2007 0900-1130 1.1 Agenda Bash and Status 1.2 SIPS 1.2.1 Issue: How to reject SIP or SIPS requests 1.2.2 Issue on Section 3.3.2 1.3 Outbound 1.3.1 Issue: Flow token algorithm 1 - remove? 1.4 Issue: Merge 'keep-stun' and 'keep-crlf' into 'keep' 1.5 Issue: Abuse of option tags 1.6 Resource Priority Header in Responses 1.7 Resource Priority Header Namespaces 1.8 Delivering Request URI and Parameters to UAS, aka UA Loose Routing 1.9 MIME Body Handling 1.9.1 Issue: multipart/alternative 1.9.2 Issue multipart/mixed 1.9.3 Issue: content-disposition 1.9.4 Issue: Content-Transfer-Encoding 1.9.5 Issue: 415 Response Codes 1.9.6 Issue: References to body parts 1.9.7 Additional conclusions: 2 Session Two, Tuesday July 24 2007 0900-1130 2.1 Agenda Bash and Status 2.2 Fork Loop Fix 2.2.1 Issue: Max-Breadth vs Whole Tree approach 2.3 Essential corrections 2.4 SAML 2.4.1 Issue: URI format 2.4.2 Issue: Relationship to RFC 4474 2.4.3 Issue: By-Value delivery and end-host addition 2.4.4 Issue: privacy 2.4.5 Issue: WG Review 2.5 eTags for Notification 2.5.1 Issue: Wild cards if suppressed match 2.5.2 Issue: Option tag 2.5.3 204 Response Code 2.6 UA-Driven Privacy 2.6.1 Issue 1: what should be the privacy flag? 2.6.2 Issue 2: is it problematic that the proxy-inserted headers besides P-A-ID are disclosed? 2.6.3 Issue 3: TURN for signaling 2.6.4 Conclusions: 2.7 Domain Certificates 2.7.1 Issue: Extended key usage 2.8 Authentication Using Certificates 2.9 INFO Considered Harmful 2.10 Media Identity [edit] Session One, Monday July 23 2007 0900-1130 Agenda Bash and Status Led by chairs Keith Drage and Dean Willis. The agenda was accepted as presented. The chairs reviewed the working group's progress since the last meeting. A brief slide on draft-hilt-sip-correction-503 was presented by the chairs, and teh working group was asked to consider the draft and discuss it on the mailing list. [edit] SIPS Led by Francois Audet. Slides presented. Issues raised during WGLC discussed. [edit] Issue: How to reject SIP or SIPS requests currently two error codes 418 - SIPS not allowed 419 - SIPS required Proposal is to have one error code with Allow-URI and Require-URI header pro - would support other URI schemes (e.g. sipsec) con - adds 2 new headers Discussion ranged widely. Topics included: Possibility of using 416 error code. Meaning of 416 vs 418 error codes: 416 means I don't understand the scheme, 418 means I understand it, but it is not allowed. Semantics of not allowing SIPS. Does this degrades security? Do we need a more specific and targeted solution rather than general one? What is the real meaning to "support" something. Context defines reasons it support. its the same problem here with 416. Need for a hard failure when cannot forward to UA because of sip/sips. Option for a 480. 416 when proxy does not support sips. Use 480 because there are no contacts registered for the scheme. Worried that this might overload 480. Using 480 confusing for backward compatibility. do need something that is explicit. dont like EKR idea of using a string. do 416 or 418. Do not wish to make it more convenient to downgrade security. People's default behavior is to ignore the warnings and it is bad to encourage this trap. Need to use a Warning header that automata can use. using 480 would require more thought by implementor to automatically downgrade. If we hide it, people will be less likely to be stupid. semantics should be that there are no resources registered with that scheme. Conclusion:No conclusion noted. Chairs are to schedule a conference call. (Ed: Topic has subsequently been raised on SIP mailing list). [edit] Issue on Section 3.3.2 Conclusion: Consensus is that this section has been superceded and shall be deleted. [edit] Outbound Led by Rohan Mahy. Slides presented. Changes to draft since last meeting reviewed. [edit] Issue: Flow token algorithm 1 - remove? Conclusion: Consensus: no objection to removing it. [edit] Issue: Merge 'keep-stun' and 'keep-crlf' into 'keep' Conclusion: Consensus: no objection to proposed merger. [edit] Issue: Abuse of option tags Conclusion: Consensus: Change draft to correct the error. [edit] Resource Priority Header in Responses Led by James Polk Slides presented. Suggestion: That more text be added to illustrate the utility of this change. Suggestion: Stop updating Table 2 (chairs to take to list). Poll on "WG Adoption" reported moderate response with no one opposing. Poll on "Accepting this document as baseline" reported weak response with no opposition. Conclusion: Adopt as WG item. Chairs to work with ADs for milestone. [edit] Resource Priority Header Namespaces Led by James Polk. Slides presented. Author to remove description of semantics of '-', just establish registry. Conclusion: Adopt as WG item. Chairs to work with ADs and establish a milestone. [edit] Delivering Request URI and Parameters to UAS, aka UA Loose Routing led by Jonathan Rosenberg. Slides presented. Alternative proposed on the list: use P-Called-Party-ID. Discussion centered on P-Called-Party-IDs lack of standards-track status and need for further work to meet requirements. However, tehre are some existing implementations. Noted that this is like the e-mail "faceted address problem". URI parameters might be made to work. It would be desirable to avoid "local knowledge". Further work is needed to address issues with re-targeting & routing. Noted that if solution is a parameter, input & output both have to be a sip URI Suggested that a writeup of the suggested P-Called-Party-ID would be useful. Noted that we need to coordinate any changes to P-Called-Party-ID with 3GPP, as IMS might be affected. Poll: make decision now? or later when more documentation available? Conclusion: To revisit problem later when there is more documentation of the other solutions. [edit] MIME Body Handling Led by Gonzalo Camarillo Slides presented. Conclusion: General consensus that our specifications must proplerly exercise MIME. "Profiling" of MIME is not acceptable. [edit] Issue: multipart/alternative Conclusions: Support for multipart/alternative in UAs is a MUST parts with disposition of 'session' MUST have different content-types parts with disposition of 'early-session MUST have different content-types [edit] Issue multipart/mixed Conclusion: Support for multipart/mixed in UAs is a MUST. [edit] Issue: content-disposition Conclusion: Default for multipart/mixed is 'render', and we do not need a new disposition type. [edit] Issue: Content-Transfer-Encoding Conclusion: Agreed that transfer encoding for binary payloads in SIP messages MUST be binary. [edit] Issue: 415 Response Codes Conclusions: alternative: new 4xx code for Content Type of Disposition Type not supported in this context. proposal: clarify current 415 approach [edit] Issue: References to body parts Conclusion: No consensus, discussion deferred to the list. [edit] Additional conclusions: Include guidance on reasonable usage via SHOULD change the encoding requirement to an explicit MUST Consensus to make a WG item for this document. Chairs are to coordinate with AD for a milestone. [edit] Session Two, Tuesday July 24 2007 0900-1130 [edit] Agenda Bash and Status Agenda accepted as presented. Document draft-ietf-connect-reuse discussed, including a new abstract and change of scope. WG showed a consensus to continue the work and publish the document. Jonathan Rosenberg strongly objected, and is to meet offline with Vijay Gurbani and attempt a compromise. [edit] Fork Loop Fix Led by Robert Sparks. Slides presented. [edit] Issue: Max-Breadth vs Whole Tree approach Conclusion: Agreed that we would work with Max-Breadth approach and see if Security ADs will accept it. [edit] Essential corrections Led by Robert Sparks. Slides presented. Open question on format. Many readers find current approach difficult to follow. Suggested that we should replace whole chapters, but these can be very long. Suggested that we do fixes like extensions; do not make a list of several small corrections. Alternative proposal: cite the text which was changed Suggested that implementors need a complete document that is readable (meaning a new RFC 3261), and that a diff is too hard to read. It would be good to have an automatic way to get a final document, but change ordinality would make this very difficult. Conclusion: Apparently there was no real conclusion here. [edit] SAML Led by Jeff Hodges. Slides presented. [edit] Issue: URI format Noted that should no be restricted to http/htttps. For example, cid: might be needed. [edit] Issue: Relationship to RFC 4474 Will update RFC 4474. [edit] Issue: By-Value delivery and end-host addition Agreed that we need by-value and by-reference. [edit] Issue: privacy Authors asked to add discussion of privacy. [edit] Issue: WG Review Authors were asked to propose and discuss changes "on list" instead of just making them, Conclusion: WG is mostly confused, and more work is needed on the doc. [edit] eTags for Notification Led by Aki Niemi. Slides presented. [edit] Issue: Wild cards if suppressed match Two use cases were presented: heartbeat metadata headers without body, e.g. subscription state Conclusion: Document is confusing. Authors are to clarify in document. [edit] Issue: Option tag No current justification for option tag. Conclusion: Remove from document. [edit] 204 Response Code Semantics of 204 response code may be unclear, although it has a use case (lost messages). Conclusion: Author to check on references for 204, clarify if needed. There may also be some relation here to the NOTIFY paise work, which may need to be clarified before WGLC. [edit] UA-Driven Privacy Led by Mayumi Munakata Slides presented. [edit] Issue 1: what should be the privacy flag? Privacy: id alone is not sufficient [edit] Issue 2: is it problematic that the proxy-inserted headers besides P-A-ID are disclosed? Via, Record-Route, History-Info reveal network information [edit] Issue 3: TURN for signaling JDR had previously objected here, but has withdrawn his objection. Comments: WRT issue 1: we can not re-use the id tag - a new option tag would be helpful. Proxy-require can not be used as suggested by one speaker - what happens if a proxy in the middle doesn't recognize the new option? Can not prevent non-compliant proxies from adding additional information. The only solution would be proxy-require, which might suggest using a new privacy-id. If a message has really been anonymomized how can a hop later add privacy information? [edit] Conclusions: The majority sees a problem which the WG needs to work on The WG wants to work on UA initiated privacy The WG will adopt the draft for future work. Chairs are to coordinate with ADs for milestones. [edit] Domain Certificates led by Scott Lawrence Slides presented. [edit] Issue: Extended key usage PKIX reviewer noted that the CN usage in this draft is inconsistent with current specifications. Rohan Mahy reports that certs issued today use CN. Poll: Does the WG wish to work on this problem? Conclusion: The WG wishes to work on this problem. Poll: Does the WG wish to adopt this document as baseline text toward a working group effort? Conclusion: The WG wishes to adopt this draft. Chairs are directed to work with AD to schedule. [edit] Authentication Using Certificates Led by Steve Dotson. Slides presented. Discussion focused on whether the requirements are clear based on the current draft, and especially the use case therein. The general consensus is that this is not clear, and that the draft fails to make a case for the mechanism proposed. Several use cases were proposed during discussion. Suggestions were made that the draft be revised to account for these concerns, and that more emphasis be explained on why existing mechanisms, such as SIP Identity, might not be suitable. It was also suggested that the authors may wish to discuss user versus device certification and authentication, and explain how things like pre-provisioned device certificates might be reasonably exercised in the scenarios addressed by the draft. Conclusion: Authors to revise as suggested. [edit] INFO Considered Harmful Led by Eric Burger. Slides presented included in proceedings. Discussion covered history of INFO, prior guidance on INFO usages, non-standard usages such as DTMF, the SIP extension architecture, and what, if anything, could now be reasonably addressed. Three options were proposed: Developing an RFC to explain the issues with INFO and proscribe further usages beyond those specified by existing RFCs. It was noted that this approach, if taken, would require that we include substantial background on the architectural issue and give clear guidance on the preferred way to do things including using alternatives such as URI parameters, new SIP methods, new SIP header fields and parameters, and media sessions. Developing an INFO usage registry, documentation guidelines, and negotiation mechanism similar to that of RFC 3265. Continuing to refrain from further specification. Conclusions: The meeting responded unanimously to the question "does this working group need to do something about INFO?", thereby discarding option #3 above. The clear majority of those responding in the room preferred the option of prohibiting new usages of INFO to the option of developing an INFO usage registry and negotiation mechanism. The chairs refrained from judging consensus at this time and have brought the topic to the mailing list for further consideration, proposing that the working group adopt option #1 above. [edit] Media Identity Led by Dan Wing. Slides presented. Dan Wing reports that Cisco has made IPR claims related to this material. Discussion centered on difficulties with applying RFC 4474 techniques through session border controllers and other B2BUA. Some participants in the discussion questioned the use case or wondered whether the problem posed by the use case needs to be solved. Conclusion: There was no consensus to pursue the work at this time, but the WG might be willing to reconsider if more convincing use cases can be provided. Back to SIP Notes and Minutes at IETF 69

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip