Subject: Re: New Version Notification for draft-leiba-rfc2119-update-00.txt

From: Barry Leiba <[email-masked]>
Date: Tue, 9 Aug 2016 15:08:38 -0500

This draft should be self-explanatory -- and please be sure to look at
Section 1.1 for some explanations that may short-cut some of the
discussion.

The bottom line is to update BCP 14 (RFC 2119) to
(1) make it clear that the key words MUST(/NOT), SHOULD(/NOT), and MAY
are only key words when they're in ALL CAPS, and
(2) deprecate the use of the variants (SHALL, RECOMMENDED, OPTIONAL)
so as to avoid reserving an unnecessarily number of key words.

Discussion here, please, before Ben, who has kindly agreed to
AD-sponsor this, sends it out for last call.  And we do expect there
to be some significant discussion on this one.

Barry

On Tue, Aug 9, 2016 at 2:55 PM,  <[email-masked]> wrote:
>
> A new version of I-D, draft-leiba-rfc2119-update-00.txt
> has been successfully submitted by Barry Leiba and posted to the
> IETF repository.
>
> Name:           draft-leiba-rfc2119-update
> Revision:       00
> Title:          Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
> Document date:  2016-08-09
> Group:          Individual Submission
> Pages:          4
> URL:            https://www.ietf.org/internet-drafts/draft-leiba-rfc2119-update-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-leiba-rfc2119-update/
> Htmlized:       https://tools.ietf.org/html/draft-leiba-rfc2119-update-00
>
>
> Abstract:
>    RFC 2119 specifies common key words that may be used in protocol
>    specifications.  This document aims to reduce the ambiguity by
>    clarifying that only UPPERCASE usage of the key words have the
>    defined special meanings, and by deprecating some versions of the key
>    words.
>

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 09 Aug 2016 13:31:30 -0700

> to be some significant discussion on this one.

+1. It is short, focused, and makes RFCs easier to understand.

--Paul Hoffman

---

From: Ted Hardie <[email-masked]>
Date: Tue, 9 Aug 2016 13:34:58 -0700

Hi Barry,

Do screen readers and other assistive technologies differentiate between
lower case and upper case appropriately and consistently?  When I try a
basic screen reader (the one that came with my Ubuntu distro), it doesn't
seem to make a distinction, but this may be misconfiguration on my part (I
don't use it in general).

regards,

Ted

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 9 Aug 2016 21:18:31 +0000

The MacOS “VoiceOver” utility gives you four options when reading a capital letter: change pitch, play tone, speak cap, do nothing.  Default is “change pitch”.
Stephan

From: ietf <[email-masked]<mailto:[email-masked]>> on behalf of Ted Hardie <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 9, 2016 at 13:34
To: Barry Leiba <[email-masked]<mailto:[email-masked]>>
Cc: IETF discussion list <[email-masked]<mailto:[email-masked]>>
Subject: Re: New Version Notification for draft-leiba-rfc2119-update-00.txt

Hi Barry,

Do screen readers and other assistive technologies differentiate between lower case and upper case appropriately and consistently?  When I try a basic screen reader (the one that came with my Ubuntu distro), it doesn't seem to make a distinction, but this may be misconfiguration on my part (I don't use it in general).

regards,

Ted

On Tue, Aug 9, 2016 at 1:08 PM, Barry Leiba <[email-masked]<mailto:[email-masked]>> wrote:
This draft should be self-explanatory -- and please be sure to look at
Section 1.1 for some explanations that may short-cut some of the
discussion.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Tue, 9 Aug 2016 16:19:42 -0500

> don't use it in general).

That's a good question; thanks.  I should reach out to Sam Hartman and ask him.

Barry

---

From: Sam Hartman <[email-masked]>
Date: Tue, 09 Aug 2016 17:22:58 -0400

>>>>> "Ted" == Ted Hardie <[email-masked]> writes:

    Ted>    Hi Barry, Do screen readers and other assistive technologies
    Ted> differentiate between lower case and upper case appropriately
    Ted> and consistently?  When I try a basic screen reader (the one
    Ted> that came with my Ubuntu distro), it doesn't seem to make a
    Ted> distinction, but this may be misconfiguration on my part (I
    Ted> don't use it in general).  regards, Ted

I have not found this to be an issue.  In general, I don't distinguish
between caps in running text, but all the screen readers I've used
(including even the one on Android) can distinguish caps if you ask them
too.

In the specific case of Orca, the Ubuntu screen reader you're probably
looking at, you have a couple of options.  You can go into the voice tab
on preferences and set up a different caps voice from the normal voice.
What I tend to do though is simply use  the spell word feature when I
think it's ambiguous; that will include caps in spelling.

In several years of participating in the IETF I've had relatively little
confusion reading RFCs whether keywords were intended to be all caps.
Sometimes I do have to check, but I've found that to be
sufficient--sufficiently so that I've had neither a desire to complain
about the ambiguity nor to turn on explicit caps notification all the
time on the screen readers that support it.

Others may have different experience.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 9 Aug 2016 14:33:25 -0700

On 8/9/2016 2:22 PM, Sam Hartman wrote:
>  In general, I don't distinguish

I'd expect that change in screen reader mode to add quite a bit of noise 
the the output, as all the case changes are noted, where only a tiny 
number matter.  Low signal to noise like that seems likely to be 
distracting, at best.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Sam Hartman <[email-masked]>
Date: Tue, 09 Aug 2016 18:03:21 -0400

>>>>> "Dave" == Dave Crocker <[email-masked]> writes:

    Dave> On 8/9/2016 2:22 PM, Sam Hartman wrote:
    >> In general, I don't distinguish between caps in running text, but
    >> all the screen readers I've used (including even the one on
    >> Android) can distinguish caps if you ask them too.

    Dave> I'd expect that change in screen reader mode to add quite a
    Dave> bit of noise the the output, as all the case changes are
    Dave> noted, where only a tiny number matter.  Low signal to noise
    Dave> like that seems likely to be distracting, at best.

Yes, that's generally why it's available as an option but not on by
default.

Being able to use must and should in running text where the keyword
meaning is not intended is valuable in writing RFCs.
"can" is the right choice some of the time, but not always.

Obviously, taste and correctness matter.
It still won't be a good idea to say "The reserved bit must be zero on
send and must be ignored on receive," arguing "Well, we don't want to
use MUST because some implementations don't do that so it can't be
normative."
The point of lower case keywords shouldn't be to allow people to be
sloppy and to avoid normative text to make a false consensus easier.
This SHOULD be about writing clearer RFCs and not having to contort
language when should and must are perfectly good non-normative things to
say.

---

From: Joe Touch <[email-masked]>
Date: Tue, 9 Aug 2016 15:07:39 -0700

Although I agree with dropping SHALL/SHALL NOT and requiring uppercase,
I'm not sure it's useful to drop REQUIRED, RECOMMENDED, and OPTIONAL.

I.e., MUST/MAY/SHOULD are directives to a person. The others are
adjectives describing the resulting features.

I appreciate that we say things like "X is a MUST", but it hurts
readability vs. "X is REQUIRED".

I'm in favor of retaining those three adjectives.

Joe

---

From: "Scott O. Bradner" <[email-masked]>
Date: Tue, 9 Aug 2016 18:52:08 -0400

my only suggestion would be to consider removing SHOULD

(semi-serious) 

Scott

> On Aug 9, 2016, at 4:08 PM, Barry Leiba <[email-masked]> wrote:
>

---

From: "John Levine" <[email-masked]>
Date: 9 Aug 2016 23:28:19 -0000

>use MUST because some implementations don't do that so it can't be

I'd write "The reserved bit is set to zero on send and is ignored on
receive" and save the command terms for things where one might think
that there was a reason to do something else.

>language when should and must are perfectly good non-normative things to

Yup.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Wed, 10 Aug 2016 09:58:53 +1000

> that there was a reason to do something else.

RFC2671/RFC6891 has

   Z
      Set to zero by senders and ignored by receivers, unless modified
      in a subsequent specification.

which resulted in 2% of deployed nameservers just copying reserved
bits to the reply or 3% of nameservers not answering because a
reserved bit is set.

https://ednscomp.isc.org/compliance/ts/alexa.flagsfail.html

A bit more emphasis may have changed the result.

At least the TLD servers no longer copy the reserved bits.  The
last server doing that was just upgraded a week or so ago.

https://ednscomp.isc.org/compliance/ts/tld.flagsfail.html

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "John R Levine" <[email-masked]>
Date: 9 Aug 2016 21:41:49 -0400

> bits to the reply or 3% of nameservers not answering because a

I suppose, but how many of the people who wrote the broken code would have 
paid attention if it said YOU MUST SET THE BIT TO ZERO AND THEN IGNORE IT 
YOU MORON.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 10 Aug 2016 12:15:36 +1000

> paid attention if it said YOU MUST SET THE BIT TO ZERO AND THEN IGNORE IT 

We will never know.

"MUST be set to zero by senders and MUST be ignored by receivers,
unless modified in a subsequent specification." would have caught
those that scan for MUST, SHOULD and MAYs.

At the moment we have draft-ietf-dnsop-no-response-issue-03 to try
and clean up the mess out there.  I'm waiting on Tim for promised
feedback before I publish -04.

Mark

---

From: Michael Richardson <[email-masked]>
Date: Tue, 09 Aug 2016 22:26:06 -0400

re: section 1.1:

So as I understand it, documents which adhere to rfc2119-update will
cite BCP14 and the RFCXXXX which this document will have?
or will it cite RFC2119 and RFCXXXX?

Are you suggesting that we should be citing BCP14 though?

It seems that retaining section 1.1 might be worth it.

XML format and screen readers.

I have not looked deeply into the final RFC-format XML spec.
Does it already markup SHOULD/MUST/MAY in some useful way?
Could it?  If it does, should this document point out this?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Tue, 09 Aug 2016 22:27:27 -0400

> (including even the one on Android) can distinguish caps if you ask them

If only we had an audio recording of Postel saying "SHOULD", "MUST", "MAY"...
Maybe we do.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Dave Crocker <[email-masked]>
Date: Tue, 9 Aug 2016 19:33:11 -0700

> If only we had an audio recording of Postel saying "SHOULD", "MUST", "MAY"...

If we had it, it is unlikely he would have said "uppercase SHOULD is 
different from lowercase should".

On the average, he did not seek to impose basic changes in the semantics 
of English text rules.

d/

-- 

   Dave Crocker

---

From: Randy Bush <[email-masked]>
Date: Wed, 10 Aug 2016 11:43:02 +0900

> I suppose, but how many of the people who wrote the broken code would
> have paid attention if it said YOU MUST SET THE BIT TO ZERO AND THEN
> IGNORE IT YOU MORON.

it is our job to write clear specs which folk can follow and implement
in ways that interoperate.  where they don't, it's our fault for being
unclear.  calling them idiots will not improve their implementations.
clearer and unequivocal specs may.

randy

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 10 Aug 2016 10:38:10 +0100

I am neutral to inclined to leave in SHALL/SHALL NOT. Other standards bodies
prefer those terms and leaving them in is at worst harmless.

I strongly agree with Joe on REQUIRED, RECOMMENDED, and OPTIONAL.
These are useful terms and ought to be retained.

As to the document, I really see no need to change a text that has
served us so well for nearly 20 years. As a change to RFC2119 it is
not going to be noticed by anyone other than the mainstream IETF
community, and I suspect will cause more confusion than it resolves.

I do not think we should publish this document.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 10 Aug 2016 10:47:12 +0100

SHOULD meaning "do it unless you have a good reason not to do it"
as opposed to MUST meaning "do it under all circumstances" is a
term that I have found useful over the years.

It is particularly useful when you want to set defaults in a control
protocol, but recognise that operators may wish to express
an alternative behaviour in a configured system.

It is also useful in some backwards compatible situations.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 10 Aug 2016 12:47:40 +0100

Having thought a little more about this, I am wondering about
unintended consequences in the 5K documents that we have
written since RFC2119 was published.

If we effectively change RFC2119 as we propose, is there
a danger that readers will incorrectly interpret old text
with new semantics. T

I have no idea whether anything of significance will occur
but considering the thought put into terms like SHOULD
there exists a risk that would be mitigated if we picked
a new RFC number whereupon the reader would know
which definition the writers and reviewers were using.

- Stewart

---

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Aug 2016 08:19:54 -0400

I think the right approach to take with this document is not as an explicit
update to RFC 2119 text, but rather as a Talmudic commentary on RFC2119.
This document should do two things: it should help readers of old documents
who are unclear about what 2119 says, and it should be available as a
document that can be normatively reference by authors of new documents who
want more clarity than RFC2119 provides.

The document should be explicit that while it updates 2119, documents that
refer only to 2119 and not to this document are not updated: if this
document helps the reader to better understand the context in which the
RFC2119 keywords are used, great, but nothing more than that is intended.

For documents that do normatively reference this document and not just
RFC2119, the update is normative.

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 10 Aug 2016 13:23:57 +0100

That would be a satisfactory approach.

However I suspect that just as IDs still put Network Working Group in 
the top left corner, so I suspect  RFC2119 will be the normal reference 
used.

Stewart

On 10/08/2016 13:19, Ted Lemon wrote:
> I think the right approach to take with this document is not as an 
> explicit update to RFC 2119 text, but rather as a Talmudic commentary 
> on RFC2119.   This document should do two things: it should help 
> readers of old documents who are unclear about what 2119 says, and it 
> should be available as a document that can be normatively reference by 
> authors of new documents who want more clarity than RFC2119 provides.
>
> The document should be explicit that while it updates 2119, documents 
> that refer only to 2119 and not to this document are not updated: if 
> this document helps the reader to better understand the context in 
> which the RFC2119 keywords are used, great, but nothing more than that 
> is intended.
>
> On Wed, Aug 10, 2016 at 7:47 AM, Stewart Bryant 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Aug 2016 08:34:17 -0400

I think the right thing for new documents to do is reference both 2119 and
this document, not _just_ this document.

On Wed, Aug 10, 2016 at 8:23 AM, Stewart Bryant <[email-masked]>
wrote:

> However I suspect that just as IDs still put Network Working Group in the
> top left corner, so I suspect  RFC2119 will be the normal reference used.
>
> Stewart
>
> explicit update to RFC 2119 text, but rather as a Talmudic commentary on
> RFC2119.   This document should do two things: it should help readers of
> old documents who are unclear about what 2119 says, and it should be
> available as a document that can be normatively reference by authors of new
> documents who want more clarity than RFC2119 provides.
>

---

From: John Leslie <[email-masked]>
Date: Wed, 10 Aug 2016 08:37:00 -0400

> written since RFC2119 was published.

   Actually, there is an obvious meaning of citing RFC xxxx or BCX xx:
which implies, "at the time of this publication".

   Nonetheless, I urge including text if leiba-rfc2119-update becomes an
RFC: stating that going forward, a reference to RFC 2119 will continue
to include-by-reference RFC 2119 as published, whereas a reference to
BCP 14 will include-by-reference whatever BCP 14 may be (or have been)
at the time any RFC referencing it is published.

   (This really doesn't change much of anything; but the opportunity for
confusion is _so_ great that I'm sure it will arise.)

   We must leave it to the RFC Editor to do whatever _can_ be done to
ensure that nobody "unintentionally" cites RFC 2119 or BCP 14 in such
a way as to cause further confusion.

> If we effectively change RFC2119 as we propose, is there a danger that
> readers will incorrectly interpret old text with new semantics. 

   RFC 2119 _cannot_ change.

   Nor, alas, _can_ we change the confusion in existing documents which
cite RFC 2119.

   We can only reduce that confusion going forward -- and that only if
the RFC Editor agrees to discourage citing RFC 2119 in future documents.

> I have no idea whether anything of significance will occur but
> considering the thought put into terms like SHOULD there exists a risk
> that would be mitigated if we picked a new RFC number whereupon the
> reader would know which definition the writers and reviewers were using.

   I would have recommended this, too, if I were writing the document.
But I stand by my previous statement: we can only reduce the confusion
if the RFC Editor discourages citing RFC 2119 after draft-leiba becomes
an RFC.

--
John Leslie <[email-masked]>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Aug 2016 08:54:51 -0400

I think it's generally a bad idea to assume that everybody's implicit
assumptions about process match what the people who wrote the process
documents envisioned.   It's better to be explicit.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 10 Aug 2016 08:12:36 -0500

> Are you suggesting that we should be citing BCP14 though?

Is there really something unclear about the boilerplate update in Section 2?:

   Authors who follow these guidelines should incorporate this phrase
   near the beginning of their document:

      The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and
      "MAY" in this document are to be interpreted as described in
      BCP 14 [RFC2119],[RFCxxxx] when, and only when, they appear
      capitalized, as shown.

That is suggesting that we *call* this "BCP 14", and that the
citations be to RFC 2119 and to this document.  That makes it clear
that 2119 applies, as updated by this.

> It seems that retaining section 1.1 might be worth it.

Perhaps, though I don't think it really has archival value.  Do others
think it should be retained?

> Could it?  If it does, should this document point out this?

That's a good point, and I will look into what this might need to say
with respect to the XML markup.

Barry

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Aug 2016 10:56:40 -0400

> Is there really something unclear about the boilerplate update in

No, maybe not unclear, but maybe I just didn't grok the [] clearly at first.
So, we would have [RFC2119] and [RFCxxxx] in my references, but not BCP14.

    > think it should be retained?

I don't feel strongly that it MUST be retained, just that it SHOULD.
:-)

    > with respect to the XML markup.

Thank you!
I think that markup on these keywords would help screen readers if they learn
to use the XML instead.
(I also have some illusion that web browsers might soon render XML directly
via something like XSLT rather than doing this offline. )

---

From: Time Warner Cable <[email-masked]>
Date: Wed, 10 Aug 2016 11:35:14 -0400

I don't like this update.

Almost every sentences uses the passive voice. I think the use of "can," "are often," "do not have to be," and so on, is an awkward attempt to work around the use of the keywords as currently defined, or as redefined. These two usages do not help readability and clarity.

How does this update affect interpretation of existing documents?

It's ironic, I think, that the active voice clause, "Authors who follow these guidelines should incorporate this phrase" uses an uncapitalized "should," and I think it should be a "MUST."

To Scott's semi-serious suggestion to deprecate "SHOULD," I'm hesitant. If there were another word for "do this unless you have a really good reason not to," I'd go for it. "Reasons not to" must be documented wherever possible, though sometimes not all reasons can be foreseen (see what I did there?).

To another comment in the thread: I imagine that setting a reader to emphasize all caps would be annoying when reading specs with pronounceable acronyms. 

Lee

---

From: Barry Leiba <[email-masked]>
Date: Wed, 10 Aug 2016 11:06:52 -0500

> I think that markup on these keywords would help screen readers if they learn

I have checked, and I propose this change to the draft:

OLD

   === NEW ===
   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized, as shown below, but they do not have to be.  This
   document defines how these words are interpreted in IETF documents
   when the words are capitalized.

NEW

   === NEW ===
   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized, as shown below, but they do not have to be.  This
   document defines how these words are interpreted in IETF documents
   when the words are capitalized and/or marked as <bcp14> in the
   XML source (see [draft-iab-xml2rfc], Section 2.9).

END

The reference to draft-iab-xml2rfc would be informative.  Comments?

Barry

---

From: Barry Leiba <[email-masked]>
Date: Wed, 10 Aug 2016 11:18:43 -0500

> Almost every sentences uses the passive voice. I think the use of "can,"
> "are often," "do not have to be," and so on, is an awkward attempt to
> work around the use of the keywords as currently defined, or as redefined.

It's not, actually; partly, it's to keep the tone similar to the
current RFC 2119, but partly, well, I think it reads well this way.  I
could propose the following version that recasts the sentence into the
active voice.  Does that help you?:

   === NEW ===
   Many standards track documents use several words to signify
   the requirements in the specification.  Authors often capitalize
   these words, as shown below, but they do not have to.  This
   document defines how these words are interpreted in IETF documents
   when the words are capitalized.

   o  Authors can use these words as defined here, but they are not
      required to.  Specifically, normative text does not require the
      use of these key words.  Authors may use them for clarity and
      consistency when they want that, but a lot of normative text does
      not use them, and does not need to use them.

   o  The words have the meanings specified herein only when they are
      capitalized.

   o  When these words are not capitalized, they have their normal
      English meanings; this document has nothing to do with them.

      Readers are to interpret the key words "MUST", "MUST NOT",
      "SHOULD", "SHOULD NOT", and "MAY" in this document as
      BCP 14 [RFC2119],[RFCxxxx] describes them when, and only
      when, they appear capitalized, as shown.

   === END ===

> How does this update affect interpretation of existing documents?

It does not; that's why you need to use both references, to show that
both 2119 and this document apply.  Documents that only cite 2119 only
get 2119 applied.

> It's ironic, I think, that the active voice clause, "Authors who follow these
> guidelines should incorporate this phrase" uses an uncapitalized "should,"
> and I think it should be a "MUST."

There's no irony here: this document intentionally does not use BCP 14
key words, neither does 2119, and I think they should not.  I'd rather
that BCP 14 not be self-referential.

> To Scott's semi-serious suggestion to deprecate "SHOULD," I'm hesitant.
> If there were another word for "do this unless you have a really good
> reason not to," I'd go for it. "Reasons not to" must be documented
> wherever possible, though sometimes not all reasons can be foreseen
> (see what I did there?).

Used passive voice, you mean?  And it reads just fine, really.

Barry

---

From: Dave Cridland <[email-masked]>
Date: Wed, 10 Aug 2016 17:37:57 +0100

>    XML source (see [draft-iab-xml2rfc], Section 2.9).

You also need to change the text for authors to include in this case.
A document will (one hopes) use either CAPITALIZATION or
<bcp14>markup</bcp14> but not a mixture. I'd propose, therefore, that
two sets of text be offered for use by authors. The alternate might
be:

      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
and
      "<bcp14>MAY</bcp14>" in this document are to be interpreted as
described in
      BCP 14 <xref anchor="RFC2119"/>,<xref anchor="RFCxxxx"/> when,
and only when, they appear
      styled as shown.</t>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Aug 2016 14:36:39 -0400

> <bcp14>markup</bcp14> but not a mixture. I'd propose, therefore, that

No, that's not correct.  We aren't inserting literal "&lt;bcp14/&gt;"
into the output.

1) An XML submission will use <bcp14>SoMeThInG</bcp14> and will be
   rendered as SOMETHING in txt.
      (And maybe as <homerSimpsonFlashTag>SOMETHING</homer> in HTML!!!)

2) A TXT submission, will use SOMETHING, and the RFC-editor will
   edit it into <bcp14>SOMETHING</bcp14>.

---

From: John C Klensin <[email-masked]>
Date: Wed, 10 Aug 2016 17:09:22 -0400

--On Tuesday, August 09, 2016 18:03 -0400 Sam Hartman
<[email-masked]> wrote:

>...
> The point of lower case keywords shouldn't be to allow people
> to be sloppy and to avoid normative text to make a false
> consensus easier. This SHOULD be about writing clearer RFCs
> and not having to contort language when should and must are
> perfectly good non-normative things to say.

It seems to me that this is key.  I'd even favor some text that
discourages the use of the lower-case forms except when the
meaning (normative status) is clear from context or the
alternatives would be really awkward.  For example, something
like the following could be added to the second bullet in
Section 2:

	"As a matter of editorial style and to reduce possible
	confusion, especially with alternate presentation
	methods, it is generally preferable to avoid the
	uncapitalized forms in documents where the capitalized
	ones are used unless the intent is very clear from
	context",   

That doesn't say "SHOULD NOT" or 'MUST NOT" use, but provides
general guidance and a basis for the RFC Editor doing some
negotiating when they deem it appropriate.

--On Wednesday, August 10, 2016 10:44 +1200 Brian E Carpenter
<[email-masked]> wrote:

>>    REQUIRED, SHALL, SHALL NOT, RECOMMENDED, NOT RECOMMENDED,
>>    OPTIONAL
> 
> I will be glad to see the back of SHALL, but I object to
> deprecating the adjectives. They are useful - indeed,
> sometimes required - for the construction of readable
> sentences and, for example, tables of RECOMMENDED and OPTIONAL
> values.

It seems to me that we have tested the model of using different
terms, avoiding the 2119 terms entirely except when they are
used in normative form.  At least for me,
draft-hansen-nonkeywords-non2119 offers fairly conclusive proof
that avoiding the 2119 terms entirely just causes the language
to be too stressed and convoluted, increasing confusion
(especially for people who are not expert in English).  YNMD
about that, but I think the option of returning SHALL and the
adjectives to non-specialized use and forcing more convoluted
language to avoid the entire 2119 set are the alternatives and
that there is little point discussing one strategy in isolation
from the other.

Incidentally, as part of what I see as if we are going to do
this, let's clean things up, rather than merely
clarifying/modifying the case rules, it would be worth taking a
look at the five year old draft-saintandre-2119bis-01 for some
potential clarifications.

I think that means I disagree with draft-leiba-rfc2119-update-00
and its argument that it is best to fix 2119 piecemeal.  We are
just too dependent on that document to apply a lot of separate
patches to it, a situation that will almost certainly lead to
confusion about which patches are in effect.  Even if authors
are very careful about what they reference, readers at not
likely to be careful to check those references.

On the other hand, I am sympathetic to Barry's argument that
we've wasted altogether too much time arguing about what
lower-case "must" (etc.,) means and believe that some
clarification (almost independent of which one is chosen) would
be helpful.   If the community wants to do that as a small
incremental change, it seem to me that this draft should confine
itself to the matter of case distinctions and avoid engaging in
the (obviously from the discussion) much more controversial
topic of getting rid of the synonyms or even, as an alternative,
explicitly discouraging, but not forbidding, their use.

--On Wednesday, August 10, 2016 10:03 -0800 Melinda Shore
<[email-masked]> wrote:

> Not much, I don't think.  I certainly cannot think of
> an instance where a document has been anything other than
> trivially delayed by a discussion about normative language.
> And of course there are serious discussions about whether
> something should be mandatory or recommended, and this
> document really doesn't help those at all.

Actually, I can think of several instances, but they were not
associated with arguments about case sensitivity (Ted Lemon's
note about this, which I'm sure is correct, notwithstanding).
Instead, they were about another issue that I thought 2119 was
clear about until I encountered the problem. This I-D not only
doesn't fix that problem but might make it worse.  The issue has
to do with whether 2119 language is required in normative
standards-track specs or whether an author can choose to use
other terminology or the same terminology with other
definitions.  

MUST, SHOULD, etc., became prominent in our vocabulary with RFC
1122/1123, but the terms were used there in the sense of
"required to conform to this specification".   RFC 2119 defines
them in terms of requirements to interoperate, not to conform.
The two are often the same, but certainly not always so.  RFC
2821 does not reference 2119 and uses the terms in the RFC 1123
sense.  When its successor, the I-D preceding RFC 5321, reached
the IESG with the same definition (IIR, a bit more explicitly
than in 2821), the IESG balked and insisted that there be a
reference to 2119 and that usage in the document conform to 2119
usage.  Again IIR, since the IESG member(s) involved were
adamant and those those who had worked on proto-5321 were
running out of energy, the latter was adjusted to 2119
terminology, an effort that took some weeks.

The I-D now says (under "=== NEW ===" in Section 2), "This
document defines how these words are interpreted in IETF
documents when the words are capitalized."  That is not "when
the words are capitalized and BCP 14 and/or this document is
referenced" or any such thing; it applies the definition to all
"IETF documents".  The next paragraph (first bullet) appears to
contradict that ("...can be used as defined here, but it is not
required that they be.  Specifically, normative text does not
require the     use of these key words.").   The combination is
a recipe for continued, possibly increased, confusion.

Finally, please either get rid of "capitalized" and/or
substitute "written in all capital letters" or equivalent.   The
term "capitalized" is, itself, ambiguous and is correctly used
in the sentence "'Must' is capitalized". 

best,
    john

---

From: Dave Crocker <[email-masked]>
Date: Wed, 10 Aug 2016 14:24:32 -0700

On 8/10/2016 2:09 PM, John C Klensin wrote:
> I'd even favor some text that
> alternatives would be really awkward.

That sounds appealing.  Except that it has no objective or even reliable 
basis for its application.

d/

-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Wed, 10 Aug 2016 20:32:36 -0400

--On Wednesday, August 10, 2016 14:24 -0700 Dave Crocker
<[email-masked]> wrote:

> That sounds appealing.  Except that it has no objective or
> even reliable basis for its application.

First, I tried to make it clear that it was advice to authors,
not any sort of normative requirement, so I'm not even sure what
a presumed requirement for an "objective or reliable basis..."
would mean in that context.

Second, and equally important, when last I checked, we still had
an RFC Editor Function at the end of the pipe and that process
is charged with editorial clarity and quality of documents.  If
they have a guideline like the one I suggested and see
lower-case forms used where they might be confusing, I'd
expected them to either fix them or at least negotiate with the
author(s) and relevant stream.  Absent any guidelines, I think
the evidence is that their response is "stream problem, we don't
need to worry about it" and the confusion goes into the final
document.

best,
    john

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 11 Aug 2016 11:27:52 +0000

Grammatically, RECOMMENDED is sometimes useful, as using SHOULD instead can produce less clear sentences. In principal the same applies to OPTIONAL, but I've never had cause to use it.

I wouldn't miss SHALL. Except that SHALL is often the word used outside the IETF rather than must, and there may be many RFCs using it, so do need to keep the explanation, even if deprecated to use it in new documents.

-- 
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: [email-masked]

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

-----Original Message-----
From: ietf [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: 09 August 2016 21:09
To: IETF discussion list
Subject: Re: New Version Notification for draft-leiba-rfc2119-update-00.txt

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

This draft should be self-explanatory -- and please be sure to look at Section 1.1 for some explanations that may short-cut some of the discussion.

The bottom line is to update BCP 14 (RFC 2119) to
(1) make it clear that the key words MUST(/NOT), SHOULD(/NOT), and MAY are only key words when they're in ALL CAPS, and
(2) deprecate the use of the variants (SHALL, RECOMMENDED, OPTIONAL) so as to avoid reserving an unnecessarily number of key words.

Discussion here, please, before Ben, who has kindly agreed to AD-sponsor this, sends it out for last call.  And we do expect there to be some significant discussion on this one.

Barry

On Tue, Aug 9, 2016 at 2:55 PM,  <[email-masked]> wrote:
>
> A new version of I-D, draft-leiba-rfc2119-update-00.txt has been 
> successfully submitted by Barry Leiba and posted to the IETF 
> repository.
>

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 11 Aug 2016 12:44:23 +0100

Optional is useful in a requirements RFC.

Feature x is REQUIRED

Feature y is OPTIONAL

- Stewart

---

From: Ted Lemon <[email-masked]>
Date: Thu, 11 Aug 2016 08:57:03 -0400

The problem with SHALL is that in other contexts it often means MUST, which
is kind of weird, and not really what the english word means.   I tend to
agree that it's worth advising against its use.

On Thu, Aug 11, 2016 at 7:44 AM, Stewart Bryant <[email-masked]>
wrote:

>> Grammatically, RECOMMENDED is sometimes useful, as using SHOULD instead
>> can produce less clear sentences. In principal the same applies to
>> OPTIONAL, but I've never had cause to use it.
>>
>> I wouldn't miss SHALL. Except that SHALL is often the word used outside
>> the IETF rather than must, and there may be many RFCs using it, so do need
>> to keep the explanation, even if deprecated to use it in new documents.
>>
>>
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 11 Aug 2016 13:38:36 +0000

Plenty of standards use shall, but never must, as their imperative word. For example (the first standard I had to hand) ISO 27001 has many occurrences of shall (not capitalised, that seems to be an IETF special) and none of must.

Shall is hard in English (outside standards). For a start there’s the shall/will issue, see for example http://www.oxforddictionaries.com/words/shall-or-will

(And where it says “In practice”, that may or may not be so if you have an editor or a customer with strong views. Or hold such views yourself.)

But since standards are not written in the first person,  when shall and will are differentiated, from that link, shall is “a strong determination to do something”. Not quite that same as a standardese instruction (unless we view it as the strong determination of the instructor).

Which all is why RFC 2119 exists.

T:  +44 (0)1245 242194  |  E: [email-masked]<mailto:[email-masked]>

www.baesystems.com/ai<http://www.baesystems.com/ai>

From: Ted Lemon [mailto:[email-masked]]
Sent: 11 August 2016 13:57
To: Stewart Bryant
Cc: Dearlove, Christopher (UK); Barry Leiba; IETF discussion list
Subject: Re: New Version Notification for draft-leiba-rfc2119-update-00.txt

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
The problem with SHALL is that in other contexts it often means MUST, which is kind of weird, and not really what the english word means.   I tend to agree that it's worth advising against its use.

On Thu, Aug 11, 2016 at 7:44 AM, Stewart Bryant <[email-masked]<mailto:[email-masked]>> wrote:
Optional is useful in a requirements RFC.

Feature x is REQUIRED

Feature y is OPTIONAL

- Stewart

---

From: Barry Leiba <[email-masked]>
Date: Thu, 11 Aug 2016 08:48:38 -0500

> Optional is useful in a requirements RFC.

I think it's clear from the discussion that we do not have consensus
on deprecating the adjectives and are not likely to, so I will remove
those in the next update.  That makes me inclined to remove the whole
section and, as John suggests, keep this purely to the issue of
capitals... unless there's a real interest in deprecating "SHALL" and
"SHALL NOT", as they add nothing to the "MUST"s other than
history/custom.

Barry

---

From: John C Klensin <[email-masked]>
Date: Thu, 11 Aug 2016 10:55:36 -0400

--On Thursday, August 11, 2016 13:38 +0000 "Dearlove,
Christopher (UK)" <[email-masked]> wrote:

> Plenty of standards use shall, but never must, as their
> imperative word. For example (the first standard I had to
> hand) ISO 27001 has many occurrences of shall (not
> capitalised, that seems to be an IETF special) and none of
> must.
>...

Hi.

This may be OBE given Barry's recent note about dropping the
text deprecating the synonyms but let me try to explain one
other issue just in the hope of increasing understanding as we
go forward.  Several people have commented that (most or all)
other standards bodies tend to use "SHALL" rather than "MUST",
etc.  At least some of the reason is that they, historically,
have thought about standards-writing in terms of conformance.
One "shall" do something if one is to conform and, because there
is almost never a notion of partially conforming, terms
equivalent to the way we use "SHOULD" have no role.

Traditionally, the IETF and its predecessors have been more
interested in interoperability than in conformance.   In an
interoperability context, statements like "you MUST do things
this way if implementations are to interoperate" and "you SHOULD
do things this way because it will increase the likelihood of
interoperation and operational success" make perfect sense.  

If the wording sounds a little awkward relative to the way other
SDOs write about conformance, that may actually be an advantage
for alerting people to the difference.

There is an additional complication: we make a formal
distinction between Technical Specifications (which should
always be about whet is needed for interoperability) and
Applicability Statements (which may reasonably contain
conformance clauses as well as making recommendations (note that
word) about the use of particular features.  Perhaps, in
retrospect, we should have separated non-technical (e.g., IETF
procedural) BCPs from ones about technical practices and TS
documents from AS ones and then specified different terminology
or definitions for each.  We didn't, and that has led to other
types of (IMO, time-wasting) arguments about whether the use of
2119 terms in BCPs, especially IETF process BCPs, is legitimate.
Similarly, if the focus is really as narrowly on
interoperability as 2119 seems to imply, a "MUST" in an
Experimental specification to express "this may be an
experiment, but we already know that, if you fail to do
so-and-so, things won't interoperate" makes perfectly good
sense, but we've had seemingly-endless arguments about that too.

Scott may remember how much those distinctions and
considerations figured into 2119 and how much, or if, they were
discussed at the time.  I don't remember.  But it seems to me
that those distinctions suggest that, unless there is consensus
that 2119 is broken enough for us to open up all of these issues
and completely revise how we do things, we should confine
ourselves to find-tuning (Section 2 of
draft-leiba-rfc2119-update, plus or minus further tuning seems
consistent with that) and editorial advice --to authors and to
the RFC Editor about what we consider a likely source of
problems that should be given attention-- and avoid trying to
mess with principles piecemeal.

best,
    john

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Thu, 11 Aug 2016 14:59:46 +0000

+1

    
    
    Barry

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 11 Aug 2016 10:14:07 -0500

> that BCP 14 not be self-referential.

While I don't have strong feelings whether this draft should use 2119 
keywords, I don't follow that line of reasoning. It's normal for RFCs to 
define terms, then use them. And for the record, 2119 does have at least 
one MUST (see section 6).

Ben (with no hats).

---

From: Ted Lemon <[email-masked]>
Date: Thu, 11 Aug 2016 11:25:04 -0400

I don't think this document should be deprecating anything, but I think a
strong recommendation not to use SHALL would be entirely in order.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 11 Aug 2016 18:25:55 +0200

> via something like XSLT rather than doing this offline. )

Browsers have been doing that for something like 10 years 
(https://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html).

Best regards, Julian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 11 Aug 2016 14:19:06 -0400

Julian Reschke <[email-masked]> wrote:
    >> ...  Thank you!  (I also have some illusion that web browsers might
    >> soon render XML directly via something like XSLT rather than doing
    >> this offline. )

    > (https://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html).

wow.... the future was already here.... and is now past...

So, is it in fact universal?  Will our XML files then have right the right
    <?xml-stylesheet
in them by default?

---

From: Julian Reschke <[email-masked]>
Date: Fri, 12 Aug 2016 01:17:52 +0200

> wow.... the future was already here.... and is now past...

It's the future as well, as it already implements large parts of the 
proposed V3 vocab.

> So, is it in fact universal?  Will our XML files then have right the right

That's something you'd need to ask the RFC Series Editor.

Best regards, Julian

---

From: Pete Resnick <[email-masked]>
Date: Fri, 12 Aug 2016 18:13:32 -0500

> Optional is useful in a requirements RFC.

One last (and perhaps fruitless) attempt to keep this section and 
deprecate the adjectives:

Using REQUIRED and OPTIONAL results in exactly the problem of using 
passive voice anywhere: REQUIRED by whom? OPTIONAL for whom? If you say, 
"A MUST do X and B MAY do Y", it is perfectly clear which actor is 
responsible (and in network protocols there are inevitably at least 2). 
If you say "X is REQUIRED and Y is OPTIONAL", you'll end up needing more 
text to explain the actors and their roles.

Using REQUIRED and OPTIONAL is lazy. It makes specs less clear. They 
ought to be dropped.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Aug 2016 16:15:10 -0700

+1

d/

-- 

   Dave Crocker

---

From: Joe Touch <[email-masked]>
Date: Fri, 12 Aug 2016 17:04:45 -0700

It's inefficient to repeat the phrase "X MUST be supported by any
implementation that complies with this specification".

The phrase "X is REQUIRED", RECOMMENDED, or OPTIONAL corresponds to the
incorrect English of "X is a MUST".

I.e., these are reasonable adjective forms of the adverbs
MUST/MAY/SHOULD. Omitting these adjectives then requires authors to
select their own adjective forms or to have to rewrite everything as an
adverb.

IMO, if you want to drop anything, drop the MUST/MAY/SHOULD - directives
of protocol specs should describe the spec, not the actions of the
implementer.

Joe

On 8/12/2016 4:13 PM, Pete Resnick wrote:
> passive voice anywhere: REQUIRED by whom? OPTIONAL for whom? If you
> say, "A MUST do X and B MAY do Y", it is perfectly clear which actor
> is responsible (and in network protocols there are inevitably at least
> 2). If you say "X is REQUIRED and Y is OPTIONAL", you'll end up
> needing more text to explain the actors and their roles.
>
> Pete Resnick http://www.qualcomm.com/~presnick/
> <http://www.qualcomm.com/%7Epresnick/>

---

From: Pete Resnick <[email-masked]>
Date: Fri, 12 Aug 2016 19:20:04 -0500

> implementation that complies with this specification".

Perfect example. That passive construction is just as bad as "X is 
REQUIRED". That's a compliance statement, not an interoperability 
statement as required by 2119. When "X" is a feature (not a protocol 
operation) what does "X MUST be supported" even mean? Why MUST it be 
supported? What interoperability problem does it cause if I choose to do 
otherwise? 99 times out of 100, when I've see "X is REQUIRED" or "X MUST 
be supported", it's a completely bogus use.

> incorrect English of "X is a MUST".

And I would say don't use any of them. ("X is a MUST" is an 
abomination.)

> select their own adjective forms or to have to rewrite everything as 

Rewriting things to use an adverb is good because it requires you to 
have a verb. If the verbs are "support" or "comply", it's a pretty good 
sign that you're making the spec less clear.

> of protocol specs should describe the spec, not the actions of the

Violent agreement on that one.

pr

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Aug 2016 17:34:21 -0700

On 8/12/2016 5:20 PM, Pete Resnick wrote:
> REQUIRED".

These sorts of exchanges remind me of just how differently people view 
the concept of clarity in writing.

And that tends to prompt me to recall a rather interesting article in 
Datamation magazine, many years ago, back when I was first learning 
concepts of clear programming and the world was wresting with different 
views on how to achieve it, with Dijkstra's "GOTO Statement Considered 
Harmful" article holding particular sway.

In this midst of that, it took me an embarrassingly long time to comprehend:

    https://www.fortran.com/come_from.html

d/
-- 

   Dave Crocker

---

From: Joe Touch <[email-masked]>
Date: Fri, 12 Aug 2016 17:47:44 -0700

FWIW, I was being glib in trying to toss out MUST/MAY/SHOULD (I should
have used a smiley :-)).

Both adverbs and adjectives are need because protocols include both
actions and state:

Adverbs indicate constraints on action (of the protocol, implementer, or
operator).

Adjectives indicate constraints on state.

It's equally awkward to use either one for both types of constraints, IMO.

Joe

On 8/12/2016 5:20 PM, Pete Resnick wrote:
> supported? What interoperability problem does it cause if I choose to
> do otherwise? 99 times out of 100, when I've see "X is REQUIRED" or "X
> MUST be supported", it's a completely bogus use.
>
> And I would say don't use any of them. ("X is a MUST" is an abomination.)
>
> have a verb. If the verbs are "support" or "comply", it's a pretty
> good sign that you're making the spec less clear.
>
>         |Optional is useful in a requirements RFC. Feature x is
>         REQUIRED Feature y is OPTIONAL |
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Aug 2016 16:26:43 +1200

On 13/08/2016 11:13, Pete Resnick wrote:
> passive voice anywhere: REQUIRED by whom? OPTIONAL for whom?

I think that overstates the case. Certainly, they will be used as part of
a passive construct, but I really can't see a problem with something like:

The foobar header is OPTIONAL but the barfoo header is REQUIRED in all messages.

Of course, I could construct an equivalent sentence using MAY and MUST.
However, I think the adjectives are also useful in feature lists:

foobar  OPTIONAL
barfoo  REQUIRED
frooba  RECOMMENDED
foobra  OPTIONAL

   Brian

> If you say,

---

From: Gmail <[email-masked]>
Date: Sat, 13 Aug 2016 08:28:29 +0100

Sent from my iPad

> On 13 Aug 2016, at 00:13, Pete Resnick <[email-masked]> wrote:
> 
> One last (and perhaps fruitless) attempt to keep this section and deprecate the adjectives:
> 
> Using REQUIRED and OPTIONAL results in exactly the problem of using passive voice anywhere: REQUIRED by whom?
> 
I could have said:

Foo is a REQUIRED feature of a complete implementation of this specification.

Perhaps I used too small an illustrative fragment. As to passive voice, it seems that many, including myself, prefer this style of technical writing.

> OPTIONAL for whom? If you say, "A MUST do X and B MAY do Y", it is perfectly clear which actor is responsible (and in network protocols there are inevitably at least 2). If you say "X is REQUIRED and Y is OPTIONAL", you'll end up needing more text to explain the actors and their roles.
> 
> Using REQUIRED and OPTIONAL is lazy. It makes specs less clear. They ought to be dropped.
> 
That really is not true when listing requirements, as is illustrated later in the thread.

Stewart

---

From: "Randall Gellens (IETF)" <[email-masked]>
Date: Sat, 13 Aug 2016 14:05:20 +0100

I've written text such as "For clients, support for X is REQUIRED."

Sent from my iPad

> On Aug 13, 2016, at 12:13 AM, Pete Resnick <[email-masked]> wrote:
> 
> Using REQUIRED and OPTIONAL results in exactly the problem of using passive voice anywhere: REQUIRED by whom? OPTIONAL for whom? If you say, "A MUST do X and B MAY do Y", it is perfectly clear which actor is responsible (and in network protocols there are inevitably at least 2). If you say "X is REQUIRED and Y is OPTIONAL", you'll end up needing more text to explain the actors and their roles.
>

---

From: "John Levine" <[email-masked]>
Date: 13 Aug 2016 15:19:56 -0000

In article <[email-masked]> you write:
>-=-=-=-=-=-

So have I, but then I rewrote it as "Clients MUST support X."

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sat, 13 Aug 2016 08:25:10 -0700

> So have I, but then I rewrote it as "Clients MUST support X."

Really, John.  That's unfortunate.

The first form is so much more... literary.

Besides that, it really is much better to have multiple ways to 
formulate the same semantic.  We like doing it in protocols, so why 
shouldn't we enjoy doing it in our specifications?

d/
-- 

   Dave Crocker

---

From: "John R Levine" <[email-masked]>
Date: 13 Aug 2016 11:43:11 -0400

> Besides that, it really is much better to have multiple ways to formulate the 
> same semantic.  We like doing it in protocols, so why shouldn't we enjoy 
> doing it in our specifications?

Now that you point it out, of course.

With the new UTF-8 friendly XML formats approved, it occurs to me that 
this is the ideal time to add 必 and 能 along with MUST and MAY.

Note that 必 and 能 only have the 2119bis meaning when written in 
simplified characters, not when written in traditional characters.

Multiculturally,
John

---

From: John C Klensin <[email-masked]>
Date: Sat, 13 Aug 2016 17:20:13 -0400

--On Saturday, August 13, 2016 11:43 -0400 John R Levine
<[email-masked]> wrote:

> With the new UTF-8 friendly XML formats approved, it occurs to
> me that this is the ideal time to add 必 and 能 along with
> MUST and MAY.
> 
> Note that 必 and 能 only have the 2119bis meaning when
> written in simplified characters, not when written in
> traditional characters.

This suggests an even better, and far more precise, alternative,
which is to deprecate all of the English (coded in ASCII) terms
of RFC 2119 and, instead, use "Sie müssen" or "es muss", "Sie
können" or "es kann", etc. (or in Jari's honor, sen täytyy,
sinun täytyy, se saattaa, sinä voit, etc.) any of which is
required to be written in boldface Fraktur if the special
meaning were intended.  If the rule remains that the language of
RFCs is US English, no one would have any trouble determining
when the special meanings were intended.  Because of the change
of language, even fairly dumb screen readers would be clear on
the matter (or so hopelessly confused as to make it clear that a
special meaning or phrasing is involved).  Unfortunately, it
would not be possible to use Chinese characters, not only
because of absence of case, but because an obviously-different
type style (considered a separate script in some quarters) is
not readily available.  On the other hand, I suppose one could
consider a member of the Seal script (style) family, which might
not be much more difficult for a typical reader of Chinese to
read and understand than Fraktur is for a typical reader of more
typical Latin script.

:-)

   john