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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf