Re: [secdir] RFC2119 vs "ought" etc, was: SECDIR review of draft-ietf-httpbis-p7-auth-24

[Barry Leiba <[e-mail]>]

>>> Why do you feel the need to avoid SHOULD and MAY here?  They don't place
>>> any more burden on implementors than "ought" and "might".
>>> --Richard
>>
>> I believe in following the guidance in RFC 2119:
>
> The key word there, though, is "imperatives".  Nothing we're talking about
> here is an imperative, just a recommendation (or RECOMMENDATION).  Skimming
> through the instances of "ought to" in the document, it seems like they all
> meet the definition of "SHOULD" in 2119, i.e., things that implementations
> should only diverge from if they have a good reason.  (In fact, there are
> some that seem like they should be "MUST", but that's a different topic.)

First: I think it's a good idea, in a document that defines protocol,
to separate the requirements for the protocol from the recommendations
for implementation aspects that speak to quality of implementation and
user experience, but that don't affect protocol operation (and
interoperation).

Second, because the use of "should", "must", "may", and "recommended"
in lower case is controversial (for reasons that I don't agree with,
but never-you-mind that), I think using alternatives (as, for example,
proposed here, which was not intended for 1 April publication:
http://tools.ietf.org/html/draft-hansen-nonkeywords-non2119 ) is a
fine thing.

Third, these situations in the httpbis documents *are* things that
don't affect the protocol.  How should a browser treat [whatever]?
Well, a browser that makes bad choices could be considered a crummy
browser, so giving advice is good and useful.  But the server won't
know nor care, so this isn't a protocol issue.  I don't think,
therefore, that in a protocol document we should use 2119 language for
that.  Save the 2119 language for the protocol.

Fourth, this is starting to get into nitty wordsmithing (the part
about whether "ought" is a good word... not the part about whether
it's normative or not), which I don't think is really appropriate at
this stage of document development.  That is, it's fine to bring it up
editorial things for the editors to consider, but pushing on them at
the expense of time spent on substantive issues doesn't seem wise at
this stage.

Barry