Subject: [Sip] Draft minutes for SIP at IETF 69

From: Dean Willis <[email-masked]>
Date: Wed, 01 Aug 2007 13:52:14 -0500

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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip