Subject: [Sip] Last Call: draft-ietf-sip-answermode (Requesting Answering Modes for the Session Initiation Protocol (SIP)) to Proposed Standard

From: The IESG <[email-masked]>
Date: Tue, 10 Jul 2007 17:44:14 -0400

The IESG has received a request from the Session Initiation Protocol WG 
(sip) to consider the following document:

- 'Requesting Answering Modes for the Session Initiation Protocol  
   (SIP) '
   <draft-ietf-sip-answermode-04.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2007-08-05. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sip-answermode-04.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14099&rfc_flag=0

_______________________________________________
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

---

From: "Steve Langstaff" <[email-masked]>
Date: Wed, 11 Jul 2007 01:18:44 -0700

Section 4.3.2 states:

   The Answer-Mode and Priv-Answer-Mode header fields have equivalent
   functions, except that Priv-Answer-Mode requests a higher level of
   privilege in granting the answering mode specified by the request.

Would it not make sense to have a single header that performs both of
these equivalent functions, using a parameter (e.g. 'high' or
'level=high') to distinguish between the two?

This might have the following benefits:

1) The document would be smaller.
2) The implementation may be simpler.
3) If the need for more than just two levels of privilege were found in
the future then this could be easily extended, rather than following the
current pattern of needing another header, e.g.
Really-High-Priv-Answer-Mode:
4) 'Priv' might be misinterpreted to mean 'private' rather than
'privilege' by the unfamiliar.

> -----Original Message-----
> From: The IESG [mailto:[email-masked]] 
> Sent: 10 July 2007 22:44
> To: IETF-Announce
> Cc: [email-masked]
> Subject: [Sip] Last Call: draft-ietf-sip-answermode 
> (Requesting Answering Modes for the Session Initiation 
> Protocol (SIP)) to Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and 
> solicits final comments on this action.  Please send 
> substantive comments to the [email-masked] mailing lists by 
> 2007-08-05. Exceptionally, comments may be sent to 
> [email-masked] instead. In either case, please retain the 
> beginning of the Subject line to allow automated sorting.
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Dean Willis <[email-masked]>
Date: Wed, 11 Jul 2007 16:57:57 -0500

Thanks for the feedback.

> 'level=high') to distinguish between the two?

Sure would. If I recall correctly, that approach was taken by an earlier 
version of the draft, about ten revisions back.

For some reason I never fully understood, people argued that distinct 
header field names made for less of a security issue than having 
parameterized privilege levels. Since we don't have separate option tags 
for negotiating support for the header fields independently, it strikes 
me as making no difference either way.

Argument went back and forth for a while, and the WG seemed to develop 
consensus around the approach as documented (different header field names)

> 1) The document would be smaller.

True.

> 2) The implementation may be simpler.

Probably not.

> Really-High-Priv-Answer-Mode:

Also true, but the effort of documenting another header field name is no 
higher than that required to document a new parameter value on a header 
field name.

> 'privilege' by the unfamiliar.

Also true, but it's shorter. The WG settled on this syntax as a 
compromise between readability and compactness.
--
dean