Re: Uppercase question for RFC2119 words

[Warren Kumari <[e-mail]>]

On Wed, Mar 30, 2016 at 11:55 AM Lee Howard <[e-mail]> wrote:

>
>
> On 3/28/16, 3:09 PM, "ietf on behalf of Barry Leiba"
> <[e-mail] on behalf of [e-mail]> wrote:
>
> >> The wishy washy descriptive rather than proscriptive language in the
> >>abstract was because I,
> >> the IESG and the community were not of one mind to say that the use of
> >>such capitalized
> >> terms should be mandatory - quite a few people felt that the english
> >>language was at
> >> least good enough to convey  the writer¹s intent without having to
> >>aggrandize specific words.
> >> Thus the abstract basically was saying: if you want to use capitalized
> >>words here is a standard
> >> way to say what they mean
> >
> >Ah.  Then perhaps the clarification needs to go a little further and
> >make this clear:
> >- We're defining specific terms that specifications can use.
>
> ³can² = ³MAY²?
>
> >- These terms are always capitalized when these definitions are used.
>
> ³are always² = ³MUST²?
>
> >- You don't have to use them.  If you do, they're capitalized and
> >their meanings are as specified here.
> >- There are similar-looking English words that are not capitalized,
> >and they have their normal English meanings; this document has nothing
> >to do with them.
>
> Gee, I thought rfc2119 was to say, ³These words have their normal English
> meanings.²
>
>
> >
> >...and I'd like to add one more, because so many people think that
> >text isn't normative unless it has 2119 key words in all caps in it:
> >
> >- Normative text doesn't require the use of these key words.  They're
> >used for clarity and consistency when you want that, but lots of
> >normative text doesn't need to use them, and doesn't use them.
>
> I like rfc2119 for specifying protocols, because it very clearly describes
> what MUST be implemented for interoperability to work, what SHOULD be done
> for it to work well or as expected, and what MAY also be included.
>

So, sometimes MUST is too strong, and SHOULD is too weak. Lucking, back in
2012, Ron Bonica and I solved this critical issue, by allowing you much
more granularity in RFC2119 language.

http://www.rfc-editor.org/pipermail/rfc-interest/2012-March/002990.html

We thought it was really cool, but unfortunately, when trying to send it to
RFC Editor my mailer's autocomplete autocompleted to RFC Interest instead
:-(
W




> However, I run into lots of cases with documents that are not intended for
> Standards Track where people tell me I¹m not allowed to use the English
> language because the IETF has defined it otherwise.[1]
>
> I love the English language. It has a beautiful irregularity and dynamism
> that gives it a richness rare among other languages. Romance languages
> have grace, Mandarin has a melody, Japanese has an appealing order, German
> has flexibility, but English is a strong mutt.
>
> Let us not define jargon such that we raise barriers to contributing or
> comprehending internet-drafts. The words ³should,² ³may,² and ³must² are
> natural English. When necessary for normative protocol language, we should
> [2] specify that we mean them in their rfc2119 sense, and may [3]
> capitalize them. In the absence of text saying ³I mean rfc2119,² they have
> natural English language meanings.
>
> Lee
>
>
> [1] To say nothing of rfc6919
> [2] rfc2219 MUST
> [3] rfc2119 MAY
>
> >
> >Barry
> >
> >
>
>
>