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

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

Thanks for the feedback.

Steve Langstaff wrote:
> 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?

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)

> This might have the following benefits:
> 
> 1) The document would be smaller.

True.

> 2) The implementation may be simpler.

Probably not.

> 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:

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.

> 4) 'Priv' might be misinterpreted to mean 'private' rather than
> 'privilege' by the unfamiliar.

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

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf