Session One, Monday July 23 2007 0900-1130

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.

The posted agenda was:

Session 1, Monday July 23 0900-1130 Red Lacquer

Session 2, Tuesday July 24 0900-1130 Red Lacquer

SIPS

Led by Francois Audet.

Slides presented.

Issues raised during WGLC discussed.]

Issue: How to reject SIP or SIPS requests

currently two error codes

1. 418 - SIPS not allowed
2. 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).

Issue on Section 3.3.2

Conclusion: Consensus is that this section has been superceded and shall be deleted.

Outbound

Led by Rohan Mahy.

Slides presented.

Changes to draft since last meeting reviewed.

Issue: Flow token algorithm 1 - remove?

Conclusion: Consensus: no objection to removing it.

Issue: Merge 'keep-stun' and 'keep-crlf' into 'keep'

Conclusion: Consensus: no objection to proposed merger.

Issue: Abuse of option tags

Conclusion: Consensus: Change draft to correct the error.

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.

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.

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.

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.

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

Issue multipart/mixed

Conclusion: Support for multipart/mixed in UAs is a MUST.

Issue: content-disposition

Conclusion: Default for multipart/mixed is 'render', and we do not need a new disposition type.

Issue: Content-Transfer-Encoding

Conclusion: Agreed that transfer encoding for binary payloads in SIP messages MUST be binary.

Issue: 415 Response Codes

Conclusions:

• alternative: new 4xx code for Content Type of Disposition Type not supported in this context.
• proposal: clarify current 415 approac

Issue: References to body parts

Conclusion: No consensus, discussion deferred to the list.

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.

Session Two, Tuesday July 24 2007 0900-1130

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.

Fork Loop Fix

Led by Robert Sparks.

Slides presented.

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.

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.

SAML

Led by Jeff Hodges.

Slides presented.

Issue: URI format

Noted that should no be restricted to http/htttps. For example, cid: might be needed.

Issue: Relationship to RFC 4474

Will update RFC 4474.

Issue: By-Value delivery and end-host addition

Agreed that we need by-value and by-reference.

Issue: privacy

Authors asked to add discussion of privacy.

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.

eTags for Notification

Led by Aki Niemi.

Slides presented.

Issue: Wild cards if suppressed match

Two use cases were presented:

1. heartbeat
2. metadata headers without body, e.g. subscription state

Conclusion: Document is confusing. Authors are to clarify in document.

Issue: Option tag

No current justification for option tag.

Conclusion: Remove from document.

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.

UA-Driven Privacy

Led by Mayumi Munakata

Slides presented.

Issue 1: what should be the privacy flag?

• Privacy: id alone is not sufficient

Issue 2: is it problematic that the proxy-inserted headers besides P-A-ID are disclosed?

• Via, Record-Route, History-Info reveal network information

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?

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.

Domain Certificates

led by Scott Lawrence

Slides presented.

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.

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.

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:

1. 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.
2. Developing an INFO usage registry, documentation guidelines, and negotiation mechanism similar to that of RFC 3265.
3. 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.

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.