Subject: Re: SHOULD and RECOMMENDED

From: "Doug Ewell" <[email-masked]>
Date: Tue, 25 Jun 2013 08:51:54 -0700

Scott Brim <scott dot brim at gmail dot com> wrote:

> 2119 overrides anything you might think you know about what words
> mean.

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?

--
Doug Ewell | Thornton, CO, USA
http://ewellic.org | @DougEwell

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 25 Jun 2013 13:58:13 -0400

> > 2119 overrides anything you might think you know about what words

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.

> 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/

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Jun 2013 08:43:15 +1200

On 26/06/2013 05:58, Phillip Hallam-Baker wrote:
> There are in fact standards bodies apart from the IETF. 

Yes, and when they explicitly cite RFC 2119, they accept the definitions
therein, one of which equates SHOULD and RECOMMENDED. You can dislike
that equation but it becomes an axiom. They both mean "there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course."

If you don't like this, it's easy to avoid: don't cite RFC 2119.

    Brian