On Tue, Jun 25, 2013 at 11:51 AM, Doug Ewell <doug@xxxxxxxxxxx> wrote:
Since SHOULD and RECOMMENDED are treated as being strictly equivalent, it seems to me that a document that uses the terms with distinct meanings that are compatible with the 2119 use should say so.Scott Brim <scott dot brim at gmail dot com> wrote:
> 2119 overrides anything you might think you know about what words
> mean.
No, 2119 PURPORTs to do that. It can try but it probably isn't going to succeed.
The purpose of RFCs is to communicate ideas. In ordinary language there is a clear distinction between RECOMMENDED and SHOULD. There is a useful distinction between them in the context of writing a standard.
There are in fact standards bodies apart from the IETF. I have always interpreted 2119 the same way I interpret the RFC describing ASCII: it is the local source of a convention that has been established collectively by the standards organizations as a whole.
RFCs make local definitions all the time, that does not mean that an RFC is free to make any definitions it chooses. For example:
White: The color that is seen in the absence of any light source whatsoever.
The point I was making is that RECOMMENDED is used with a distinct meaning by a large fraction of the standards community and the IETF could benefit from the same approach.
and Dave Cridland <dave at cridland dot net> wrote:Documents that intend these magic words to have their RFC 2119 meanings
> If a document explicitly states that the term "RECOMMENDED" is to
> be interpreted as in RFC 2119, then that really is the only
> interpretation, and RFC 2119 does then become the only source of
> consequence. This is beyond personal opinions.
include boilerplate text:
"The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in RFC 2119."
If a document wants to impart different meaning to one or more of the
words, wouldn't a simple list of the exceptions, immediately following
the boilerplate, solve the problem?
If an implementer finds language of the form "Implementations SHOULD support AES-128" I expect them to implement unless they have a good reason not to.
If on the other hand the language is "RECOMMENDED algorithms: AES-128", I expect them to take that as a warning signal that the basis for the author's recommendation may be dependent on assumptions that may not hold for a particular circumstance (e.g. Moores law continues to 2050 and we all have heptaflop computing engines in our shoe.)