On Tue, Jun 25, 2013 at 11:51 AM, Doug Ewell <d...@ewellic.org> wrote:

> 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:
>
> > 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.
>
> Documents that intend these magic words to have their RFC 2119 meanings
> 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?
>

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.

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.)


-- 
Website: http://hallambaker.com/

Reply via email to