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/