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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf