Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-01.txt

From: [email-masked]
Date: Sun, 20 Mar 2016 15:31:16 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Real-Time Communication in WEB-browsers of the IETF.

        Title           : WebRTC IP Address Handling Recommendations
        Authors         : Justin Uberti
                          Guo-wei Shieh
	Filename        : draft-ietf-rtcweb-ip-handling-01.txt
	Pages           : 8
	Date            : 2016-03-20

Abstract:
   This document provides best practices for how IP addresses should be
   handled by WebRTC applications.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-ip-handling-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Justin Uberti <[email-masked]>
Date: Sun, 20 Mar 2016 16:46:07 -0700

This update incorporates changes suggested by Adam in his review of the -00
document, mainly around clarifying how the combined permission for cam/mic
and IPs should be discussed, and also how the force proxy mode should work.

On Sun, Mar 20, 2016 at 3:31 PM, <[email-masked]> wrote:

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Justin Uberti <[email-masked]>
Date: Sun, 20 Mar 2016 16:48:32 -0700

[fixing to: line]

On Sun, Mar 20, 2016 at 4:46 PM, Justin Uberti <[email-masked]> wrote:

> This update incorporates changes suggested by Adam in his review of the
> -00 document, mainly around clarifying how the combined permission for
> cam/mic and IPs should be discussed, and also how the force proxy mode
> should work.
>

---

From: Sean Turner <[email-masked]>
Date: Mon, 21 Mar 2016 11:49:28 -0400

I updated the “Replaces” info so everybody can easily see the history of changes from the original individual draft.

spt

> On Mar 20, 2016, at 19:48, Justin Uberti <[email-masked]> wrote:
> 
> [fixing to: line]
> 
> This update incorporates changes suggested by Adam in his review of the -00 document, mainly around clarifying how the combined permission for cam/mic and IPs should be discussed, and also how the force proxy mode should work.
>

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Tue, 22 Mar 2016 10:31:46 +0000

The header of this document says "standards track".

The title of the document says "recommendations" which would equate to a normative document of SHOULD strength

The abstract says "best practices"

Throughout the document I detected lots of lower case usage of RFC 2119 terms but did not see any upper case usage (but may have missed it).

All of which leaves me confused.

Would the chairs like to clarify the intent of this document in terms of document type?

Regards

Keith Drage

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of EXT [email-masked]
Sent: 20 March 2016 22:31
To: [email-masked]
Cc: [email-masked]
Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-01.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 22 Mar 2016 16:10:10 -0700

Speaking as an individual, rather than chair:

On Tue, Mar 22, 2016 at 3:31 AM, Drage, Keith (Nokia - GB) <
[email-masked]> wrote:

> Throughout the document I detected lots of lower case usage of RFC 2119
> terms but did not see any upper case usage (but may have missed it).
>
I don't think this document describes any new protocol mechanisms, so the
lack of upper case RFC 2119 terms seems to me personally fairly natural.
What it does instead is lay out the results of doing IP address handling in
specific modes, along with a recommendation on which would make a
reasonable default.

Clearly it could have been part of JSEP, which would have made it part of a
standards track doc.  The value to me of it being separate is that the
advice can be revised independently of the core protocol specification.  To
that extent, it is somewhere between "Applicability statement" and "BCP" in
our formal terminology, with a thumb very slightly on the scale toward BCP.
Ultimately, though, I am willing to be guided by our ADs or the community
about the exact status.  The high order bits are the advice and its
decomposability.

regards,

Ted

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Wed, 23 Mar 2016 09:09:08 +0000

Assuming it does not contain normative language in its own right, then it might well be a BCP, but then it needs to tighten up on some of its internal language – if we don’t mean RFC 2119 language then we should try and avoid the lower case forms as well, in order to avoid confusion.

I’d note that in the past there has been some discussion of what a BCP really is so that might also require some more debate.

My understanding of an applicability document is that it is a PROFILE as defined by ISO 9646. That means that it converts optional capabilities into mandatory ones and so on. Those in themselves are normative statements that would require RFC 2119 language. This document does not appear to be such a document.

Regards

Keith

From: EXT Ted Hardie [mailto:[email-masked]]
Sent: 22 March 2016 23:10
To: Drage, Keith (Nokia - GB)
Cc: [email-masked]
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-01.txt

On Tue, Mar 22, 2016 at 3:31 AM, Drage, Keith (Nokia - GB) <[email-masked]<mailto:[email-masked]>> wrote:
The header of this document says "standards track".

Regards

Keith Drage

I don't think this document describes any new protocol mechanisms, so the lack of upper case RFC 2119 terms seems to me personally fairly natural.  What it does instead is lay out the results of doing IP address handling in specific modes, along with a recommendation on which would make a reasonable default.

Clearly it could have been part of JSEP, which would have made it part of a standards track doc.  The value to me of it being separate is that the advice can be revised independently of the core protocol specification.  To that extent, it is somewhere between "Applicability statement" and "BCP" in our formal terminology, with a thumb very slightly on the scale toward BCP. Ultimately, though, I am willing to be guided by our ADs or the community about the exact status.  The high order bits are the advice and its decomposability.
regards,
Ted

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 27 Mar 2016 10:42:45 +0200

Den 23. mars 2016 10:09, skrev Drage, Keith (Nokia - GB):
> Assuming it does not contain normative language in its own right, then
> it might well be a BCP, but then it needs to tighten up on some of its
> internal language – if we don’t mean RFC 2119 language then we should
> try and avoid the lower case forms as well, in order to avoid confusion.

Matter of principle:

I've argued against this idea for the last 10 years .... avoiding common
verbs makes it harder to write English. Enough people have a hard time
with that already that we shouldn't make it harder.

If we mean something by the UPPERCASE form, we should stop trying to
police the lowercase ones. Indeed, the policing of the lowercase forms
serves to increase confusion between the forms, not decrease it: "if
this lowercase should is still there, does it mean that it wasn't
policed out, or that it was intended to be uppercase?"

> 
>  
> 
> I’d note that in the past there has been some discussion of what a BCP
> really is so that might also require some more debate.

BCP is a blanket term used to cover a multitude of sins.

In this particular instance, I'd prefer to have it standards track. It's
a practice that might change over time, and where multiple variants can
exist at the same time (each endpoint practices it independently of all
the others).
I haven't made specific wording change proposals yet; I might get to it.

> 
> My understanding of an applicability document is that it is a PROFILE as
> defined by ISO 9646. That means that it converts optional capabilities
> into mandatory ones and so on. Those in themselves are normative
> statements that would require RFC 2119 language. This document does not
> appear to be such a document.

The number of ASes emitted is low....

RFC 7603 Energy Management AS
RFC 7057 Update to the EAP AS for...
RFC 6944 AS: DSNS ecurity (DNNSSEC) DNSKEY Algorithm Implementation Status
RFC 6936 AS for the use of IPv6 UDP Datagrams with Zero Checksums

There are a few.

> 
>  
> 
> Regards
> 
>  
> 
> Keith
> 
>  
> 
> *From:*EXT Ted Hardie [mailto:[email-masked]]
> *Sent:* 22 March 2016 23:10
> *To:* Drage, Keith (Nokia - GB)
> *Cc:* [email-masked]
> *Subject:* Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-01.txt
> 
>  
> 
> On Tue, Mar 22, 2016 at 3:31 AM, Drage, Keith (Nokia - GB)
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I don't think this document describes any new protocol mechanisms, so
> the lack of upper case RFC 2119 terms seems to me personally fairly
> natural.  What it does instead is lay out the results of doing IP
> address handling in specific modes, along with a recommendation on which
> would make a reasonable default.
> 
> Clearly it could have been part of JSEP, which would have made it part
> of a standards track doc.  The value to me of it being separate is that
> the advice can be revised independently of the core protocol
> specification.  To that extent, it is somewhere between "Applicability
> statement" and "BCP" in our formal terminology, with a thumb very
> slightly on the scale toward BCP. Ultimately, though, I am willing to be
> guided by our ADs or the community about the exact status.  The high
> order bits are the advice and its decomposability.
> 
> regards,
> 
> Ted
> 
> 
>

---

From: Stephan Wenger <[email-masked]>
Date: Sun, 27 Mar 2016 16:19:24 +0000

>policed out, or that it was intended to be uppercase?"

This can be trivially accomplished, without policy change.  I have put the language below on most (or all?) of my recent drafts and RFCs.  An example from RFC 7798:

"
   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
   BCP 14, RFC 2119 [RFC2119].

   In this document, these key words will appear with that
   interpretation only when in ALL CAPS.  Lower case uses of these
   words are not to be interpreted as carrying the RFC 2119
   significance.

“

Stephan

---

From: Suhas Nandakumar <[email-masked]>
Date: Sun, 27 Mar 2016 13:28:32 -0700

On Sunday, March 27, 2016, Stephan Wenger <[email-masked]> wrote:

>
>
>
>
>
> On 3/27/16, 01:42, "rtcweb on behalf of Harald Alvestrand" <
> [email-masked] <javascript:;> on behalf of [email-masked]
> <javascript:;>> wrote:
>
> This can be trivially accomplished, without policy change.  I have put the
> language below on most (or all?) of my recent drafts and RFCs.  An example
> from RFC 7798:
>
> "

Like this approach +1

> [email-masked] <javascript:;>

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 28 Mar 2016 10:51:20 +0900

>> policed out, or that it was intended to be uppercase?"

<comment severity='minor' hint='see later for major comment'>
If I'd have to decide, I'd lean to the other side, because while for 
some people, the difference between upper and lower case is very strong, 
for others, it's not perceived that strongly. Examples may include 
people who's native script doesn't make such a distinction, and those 
people for whom software makers create OSes which treat upper and lower 
case as (mostly) equivalent, or default to case-insensitive for search 
and similar stuff.

In addition to that, there's the issue of getting it right, which is 
more difficult if the difference is only one of case, and the issue that 
styling may change case. Also, for those who have difficulties finding 
additional words, there's 
https://tools.ietf.org/html/draft-hansen-nonkeywords-non2119.

On the other hand, for those really addicted to case differences, there 
was also an RFC that defined keywords such as MUst and mUsT. You can 
guess the date of that one.
</comment>

<comment severity='major'>
As Harald says, this issue has come up many times over the past 10 (or 
more) years, in many different places. It would be good if the relevant 
entity (I have copied the IESG and the RFC Editor, but somebody else may 
be in charge here) would just decide. That way, WGs wouldn't have to 
spend time on this. And readers (who may not check the start of a 
document every time they check some detail), when they see a "must", 
won't have to worry whether it's a "MUST" erroneously spelled lower 
case, or just the equivalent of "need" or so.
</comment>

Regards,   Martin.

---

From: John Leslie <[email-masked]>
Date: Mon, 28 Mar 2016 06:47:31 -0400

On the issue of lower-case "must", etc.,

=?UTF-8?Q?Martin_J. _D=c3=bcrst?= <[email-masked]> wrote:
> 
>... It would be good if the relevant entity (I have copied the IESG
> and the RFC Editor, but somebody else may be in charge here)

   (indeed, the IESG may or may not be in charge here; but this is a
definite mine-field as we try to escape the ASCII straitjacket when
preparing RFCs)

> would just decide. That way, WGs wouldn't have to spend time on this.

   I truly wish WGs WOULD avoid spending time on this!!!

> And readers (who may not check the start of a document every time they
> check some detail),

   Alas, that is being too careless: RFC 2119 simply _doesn't_ apply
unless its warning-sentence is inculded.

> when they see a "must", won't have to worry whether it's a "MUST"
> erroneously spelled lower case,

   There is _no_ error there: just an ambiguity!

> or just the equivalent of "need" or so.

   IMHO, the intent (when 2119 was written), was to define new words
using ASCII uppercase, not to redefine English words.  As evidence, I
cite the three uses of lowercase "must", four uses of lowercase "should",
and five uses of lowercase "may", which are a true challenge to
interpret as 2119 keywords.

   But I specifically disclaim that my _opinion_ has any value!

   Please do remember that when RFC2119 was written, there was no
question that RFCs were written in English, using ASCII (where uppercase
is a different code from lowercase).

   (I've always thought that draft-hansen-nonkeywords would be good an
an April-first RFC, myself... ;^)

--
John Leslie <[email-masked]>

---

From: Barry Leiba <[email-masked]>
Date: Mon, 28 Mar 2016 08:03:29 -0400

Martin says:

> If I'd have to decide, I'd lean to the other side, because while for some
> people, the difference between upper and lower case is very strong, for
> others, it's not perceived that strongly. Examples may include people who's
> native script doesn't make such a distinction

This has been brought up before.  I know Martin lives in such a
country, so perhaps he has different data, but I have checked with my
own Chinese colleagues, and they confirm that they *do* understand,
notice, and pay attention to the difference in case when they're
reading the documents.  (It's entirely possible that they're more
prone to making case errors when they're writing, but that speaks to
the "getting it right" part, which I always consider a problem --
there are a great many wrong uses of 2119 key words that show up
often, and some of those are, no doubt, due to authors writing
"should" or "may" or "must" and thinking they ought to put that in
upper case.)

> definite mine-field as we try to escape the ASCII straitjacket when

I believe the IESG is *not* in charge here, other than to have
different ADs pick at different things in our reviews.  I believe the
community is in charge.  The key point is the second sentence of the
Abstract from RFC 2119:

   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.

The problem here is that it's explanatory, not normative.  The
explanation -- and the usage custom -- leads many of us to think we
can use capitalization to make the distinction, while the fact that
its not normative leads many of us to think that "should" means
"SHOULD".

My suggestion is to write a tiny draft (I'm willing to be the editor
of that) that updates 2119, which makes one of the following changes:

NEW -- alternative 1
   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 have special, requirements
   meanings regardless of capitalization.

NEW -- alternative 2
   In many standards track documents several words are used to signify
   the requirements in the specification.  These words have special,
   requirements meanings only when they appear in ALL CAPITALS,
   as shown below.

The hard bit, of course, will be to determine which of those
alternatives the community has rough consensus on.

Perhaps I will post an I-D when the pre-meeting fog lifts, and we can
bash it out on the IETF discussion list.

Barry

---

From: John Leslie <[email-masked]>
Date: Mon, 28 Mar 2016 09:28:59 -0400

NB this IMHO belongs on <[email-masked]>, and I'm directing Reply-To there

Barry Leiba <[email-masked]> wrote:
> Martin says:
> 
>>... while for some people, the difference between upper and lower case
>> is very strong, for others, it's not perceived that strongly. Examples
>> may include people whose native script doesn't make such a distinction
> 
> community is in charge.

   I agree with Barry: the community should be in charge.

> The key point is the second sentence of the Abstract from RFC 2119:
> 

   Please note that an Abstract is never supposed to override the
document itself. (But I agree this is the source of the issue.)

> its not normative leads many of us to think that "should" means

   I think Barry has it right; but I hope our readers don't confuse the
Abstract with the explanation in the body of the document.

>    requirements meanings only when they appear in ALL CAPITALS,

   Needless to say, I prefer alternative 2...

> alternatives the community has rough consensus on.

   And for that determination, the IESG _is_ in charge.   

> bash it out on the IETF discussion list.

   Actually, I suggest on-list discussion before that, and Barry posting
_after_ the plenary, when he has left the IESG (and returned to the
_actually_ important work of IESG scribing ;^)

   I know this is a religious-war; and I apologize in advance for not
being present in Buenos Aires to receive the in-person flamage.

   Nonetheless, I restate my opinion:

] IMHO, the intent (when 2119 was written), was to define new words
] using ASCII uppercase, not to redefine English words.  As evidence,
] I cite the three uses of lowercase "must", four uses of lowercase
] "should", and five uses of lowercase "may", which are a true challenge
] to interpret as 2119 keywords.

And I beg folks to respect the convention that an Abstract must not
_change_ the meaning of a document.

   (I'll wait for later to argue why I believe alternative 2 is a better
way to run a railroad...)

---

From: Barry Leiba <[email-masked]>
Date: Mon, 28 Mar 2016 10:09:51 -0400

> 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.
- These terms are always capitalized when these definitions are used.
- 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.

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

Barry

---

From: Barry Leiba <[email-masked]>
Date: Mon, 28 Mar 2016 15:09:53 -0400

> one minor tweak

A fine tweak.  I'll write it up and pass it to a few people before I
post the I-D.

I'd rather do it as an update to 2119, rather than a complete
revision, even though 2119 is so short, for two reasons:

1. I don't want to get into arguments about other changes.

2. I don't want to make 2119 obsolete: there's value in continuing to
refer to it with that RFC number.

Barry

>> On Mar 28, 2016, at 10:09 AM, Barry Leiba <[email-masked]> wrote:
>>
> these definitions are only meaningful if the words are capitalized
>

---

From: Barry Leiba <[email-masked]>
Date: Mon, 28 Mar 2016 16:30:36 -0400

Brian, I think your note goes to how important it is to write clearly
and to get a lot of eyes on it before we publish it.  Well-written
documents, with or without 2119 key words, and with or without
lower-case look-alikes, can still be clear.  Fuzzily written documents
will be fuzzy.

In particular:

> they mean? It can be very unclear. If a node receives a message containing
> an element covered in the spec by "allowed" instead of "OPTIONAL", is the
> receiver supposed to interoperate or to reject the message?

Well, this is where 2119 advises that we *use* the key words when
interoperability is at stake.  It's fine to be fuzzy when it doesn't
matter, though even then, I'd argue for more explanation:

   Every frobotz MUST contain a valid bleeg.  The glorp field in the
   frobotz is an unsigned integer that is normally between 0 and 666,
   inclusive.  Values greater than 666 are allowed, but recipients
   using older software might not be able to handle such values.
...
   When processing a frobotz that does not meet the requirements in
   section 3.1.4, it is permissible to reject the frobotz outright, or to
   attempt to process the parts of it that make sense; the choice is
   an implementation decision.  However, any frobotz that does not
   contain a valid bleeg MUST be rejected.

That sort of thing.

Barry

On Mon, Mar 28, 2016 at 3:58 PM, Brian E Carpenter
<[email-masked]> wrote:
> There are times when I think RFC2119 was a really bad idea, despite it having
> become probably the most frequently cited RFC (inside and outside the IETF).
> It seems to create as much confusion as it avoids.
>
> There are four words whose RFC2119 meaning is different from the dictionary
> meaning: should, recommended, may and optional. Having special typography
> for them is useful, because it signals the RFC2119 meanings. But if a spec
> uses, for example, a mixture of SHOULD and should, who knows what the authors
> intended? To that extent, the proposed clarification is helpful.
>
> The other words (must, shall, required, not) mean what they always mean.
> The only argument for upper-casing them is aesthetic symmetry. If a spec
> uses alternatives like mandatory, necessary or forbidden, they are just as
> powerful.
>
> So
> can be applied to should, recommended, may and optional if we want,
> but strictly doesn't apply to must, shall, required, not, mandatory,
> necessary, forbidden, need, or any other such words.
>
> Where we can get into real trouble is if a spec contains should, recommended,
> may and optional *plus* other non-categorical (fuzzy) words like ought,
> encourage, suggest, can, might, allowed, permit (and I did not pull those
> words out of the air, but out of draft-hansen-nonkeywords-non2119). What do
> they mean? It can be very unclear. If a node receives a message containing
> an element covered in the spec by "allowed" instead of "OPTIONAL", is the
> receiver supposed to interoperate or to reject the message?
>
> If we are issuing guidance, it should probably include a specific warning
> to use any such fuzzy words with extreme care.
>
>    Brian
> On 29/03/2016 03:13, Scott O. Bradner wrote:
>> one minor tweak
>>

---

From: "Scott O. Bradner" <[email-masked]>
Date: Mon, 28 Mar 2016 09:57:58 -0400

> On Mar 28, 2016, at 9:28 AM, John Leslie <[email-masked]> wrote:
> 
> 

well, not quite - it was to make more consistent an existing practice

the use of capitalized words in IETF documents predates RFC 2119 by quite a bit - see,
for example, RFC 1023.  The use became codified by RFC 1122, where the definitions in 
RFC 2119 come from.

As an AD I became frustrated by the number of IDs I was reviewing that used upper case words
but did not include any statement of what the reader was to make of the fact that some words were 
capitalized.  I, and the rest of the IESG at the time, were returning the IDs requesting that the 
authors add some explanation.  The explanations that were added were , to say the least, 
inconsistent. After rather many of these I wrote what became RFC 2119 so that we would at
lets have a consistent explanation of the capitalized words that authors could use if they wanted to.  
There was some interaction on the list that resulted in what is now section 6 of RFC 2119 to
provide guidance on when to use the capitalized words

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 - as I recall some RFCs even after 2119 was published included
their own definitions for the capitalized terms because the authors thought they had better
definitions.

Scott

---

From: "Scott O. Bradner" <[email-masked]>
Date: Mon, 28 Mar 2016 10:13:09 -0400

one minor tweak

---

From: John C Klensin <[email-masked]>
Date: Mon, 28 Mar 2016 14:23:38 -0400

Yes.  +1.  About time and long overdue.

    john

--On Monday, March 28, 2016 10:09 -0400 Barry Leiba
<[email-masked]> wrote:

> Ah.  Then perhaps the clarification needs to go a little
> further and make this clear:
> - These terms are always capitalized when these definitions
> are used. - 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.
> 
> ...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.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Mar 2016 08:58:09 +1300

So

   Brian

---

From: Eric Gray <[email-masked]>
Date: Mon, 28 Mar 2016 20:27:15 +0000

Brian,

	 I agree with most of what you say.  My impression has been that many times the use of some 
of the fuzzier words stems from the fact that the author(s) have occasionally forgotten that they are 
writing a specification, and not a bit of literary prose.

	Using variation in wording does not make a specification more readable, as it might a piece of
literature.  It makes it less readable, even if it might make it a less boring read.

	I am not certain that making a specification exciting enough to keep the average reader awake is 
a goal.

	One area where I do slightly disagree is in your characterization of the use of must verses MUST,
and similar words.  The English usage of the word "must" can vary slightly from the normative use of the 
word "MUST."

	As an example - in the statement "what goes up, must come down" - the word "must" is almost 
certainly meant to reflect a fact of nature, as opposed to an implementation choice that is needed if we
want to have interoperable implementations of a specification. 

	If you could throw a ball into the air, and it just hung there, I'm not sure we should refer to it as
"non-compliant."  :-)

	Also, a statement along the lines of "electronic equipment MUST have a power source of some 
sort" is not particularly useful for interoperability - even though it seems likely to be true.

	Nor do I think we would want an implementation that did not have this limitation to be deemed
non-compliant.

	There are similar uses for "need" for instance.  And - while I cannot think of an example at the 
moment - I am not prepared to bet the farm that there are no such similar uses for "required."  Maybe
this might be the case for a legal requirement that has nothing to do with compatible implementation?

	In any case, it is occasionally necessary to use these terms in an explanatory sense, having not 
very much to do with specification of normative behavior.  The good news is that most of us can tell if
the meaning is explanatory, verses normative.

--
Eric

-----Original Message-----
From: ietf [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Monday, March 28, 2016 3:58 PM
To: Scott O. Bradner; Barry Leiba
Cc: Heather Flanagan (RFC Series Editor); [email-masked]; IETF discussion list; IESG
Subject: Fuzzy words [was Uppercase question for RFC2119 words]

So

   Brian

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 29 Mar 2016 01:07:51 +0000

(Reduce the to line to the relevant WG list ...)

>   requirements meanings only when they appear in ALL CAPITALS,

How about the authors of this document make it clear which of these two conventions they are using in this document and we can avoid the whole debate as it become more or less an editorial nit at that point. 

Personally, I can't imagine while the words from 2119 are in CAP if it did not mean that CAP has special meaning, so I have always read 2119 to line up with alt 1 but really, I don't care. I'd be perfectly happy for the authors to remove all mention of 2119 and use whatever words captured the consensus of the WG. IMHO, there are topics that are much more important that this WG needs to get done - perhaps some other WG could work on an update to 2119 but in the meantime the internet seems to have survived with specs using the possibly under defined meanings in 2119. 

(Cullen with my individual contributor hat on)

---

From: Scott Bradner <[email-masked]>
Date: Tue, 29 Mar 2016 07:27:13 -0400

fwiw - seems to me that the basic idea that MUST and must are the same is wrong and will lead to 
even more confusion

imo - any clarification should (not SHOULD - i.e. the english language) say
	1/ some authors capitalize some words for emphasis and clarity
	2/ there is no requirement to use capitalized words 
	2/ when capitalized words are used RFC 2119 says what the capitalized words mean
	3/ non capitalized words are interpreted using normal English 

Scott

> On Mar 28, 2016, at 4:30 PM, Barry Leiba <[email-masked]> wrote:
>

---

From: Scott Bradner <[email-masked]>
Date: Tue, 29 Mar 2016 08:06:39 -0400

agreed

Scott

> On Mar 29, 2016, at 7:57 AM, John C Klensin <[email-masked]> wrote:
> 
> 
> 
> --On Tuesday, March 29, 2016 07:27 -0400 Scott Bradner
> <[email-masked]> wrote:
> 
>> fwiw - seems to me that the basic idea that MUST and must are
>> the same is wrong and will lead to  even more confusion
>> 
>> 2/ when capitalized words are used RFC
>> 2119 says what the capitalized words mean 
> Agreed, if your second #2 is modified to read "when capitalized
> words are used and RFC 2119 is explicitly and normatively
> referenced, RFC 2119 says what the capitalized words mean".   In
> other words, there is no universal applicability of 2119 -- if I
> write a document that says "where this document says 'MUST', it
> means you should (sic) do it if you find it convenient". that
> might well be editorially dumb, but 2119 has nothing to do with
> it, nor does it prevent such a definition.
> 
>   john
> 
> 
>> 
> 
> 
> 
>

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 29 Mar 2016 08:30:00 -0500

> 	3/ non capitalized words are interpreted using normal English

I agree heartily, especially with 3. As it is, we often get tortured 
language where people try to avoid such words in text. That makes the 
writing hard, and the reading even harder.

Ben.

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Tue, 29 Mar 2016 15:26:23 +0000

I also feel that a modified version of the RFC 2119 statement should be defined and specified in a small RFC.

I like Dave's addition, but also think adding the word "only" is worth doing:

      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 only when capitalised.

Leaving out the "only" still leaves the statement (slightly) ambiguous; it's the same as the difference between "if" and "if and only if".

- Tony Hansen

From: ietf <[email-masked]<mailto:[email-masked]>> on behalf of Dave Cridland <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 29, 2016 at 9:46 AM
To: John C Klensin <[email-masked]<mailto:[email-masked]>>
Cc: IETF discussion list <[email-masked]<mailto:[email-masked]>>, "Heather Flanagan (RFC Series Editor)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, IESG <[email-masked]<mailto:[email-masked]>>, Barry Leiba <[email-masked]<mailto:[email-masked]>>
Subject: Re: Fuzzy words [was Uppercase question for RFC2119 words]

. . .
Agreed, but we should (ought to, probably wish to, etc) consider a replacement for the following:

      RFC 2119.

Perhaps simply:

      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 when capitalised.

---

From: Tony Finch <[email-masked]>
Date: Tue, 29 Mar 2016 11:57:57 +0100

Brian E Carpenter <[email-masked]> wrote:

> But if a spec uses, for example, a mixture of SHOULD and should, who
> knows what the authors intended? To that extent, the proposed
> clarification is helpful.

I think if a document uses RFC 2119 keywords then it ought to avoid
non-capitalized uses of the keywords, e.g. by replacing "should" with
"ought to" or other rephrasings.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Rockall, Malin: Cyclonic 4 or 5, becoming west 5 or 6 later. Moderate or
rough, occasionally very rough in south Rockall. Showers. Good.

---

From: Loa Andersson <[email-masked]>
Date: Tue, 29 Mar 2016 19:29:56 +0800

2nd in motion

/Loa

---

From: Dave Cridland <[email-masked]>
Date: Tue, 29 Mar 2016 14:46:21 +0100

> it, nor does it prevent such a definition.
Agreed, but we should (ought to, probably wish to, etc) consider a
replacement for the following:

Perhaps simply:

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Tue, 29 Mar 2016 07:18:32 -0700

> to use any such fuzzy words with extreme care.

I've been watching this thread and am thrilled to see these
clarifications coming through. Changes to RFC 2219 are a community
decision, not an RFC Editor decision, but the RFC Editor definitely
appreciates consistency and clarity!

-Heather

---

From: Dave Cridland <[email-masked]>
Date: Tue, 29 Mar 2016 17:36:12 +0100

On 29 March 2016 at 16:26, HANSEN, TONY L <[email-masked]> wrote:

> Leaving out the "only" still leaves the statement (slightly) ambiguous;
> it's the same as the difference between "if" and "if and only if".
>
>
I agree that's an improvement.

> - Tony Hansen
>
> From: ietf <[email-masked]> on behalf of Dave Cridland <
> [email-masked]>
> To: John C Klensin <[email-masked]>
> Cc: IETF discussion list <[email-masked]>, "Heather Flanagan (RFC Series
> Editor)" <[email-masked]>, "[email-masked]" <[email-masked]>, IESG <
> [email-masked]>, Barry Leiba <[email-masked]>

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Tue, 29 Mar 2016 18:11:31 +0000

>"ought to" or other rephrasings.

Cue reference to "draft-hansen-nonkeywords-non2119" :-)

	Tony Hansen

---

From: John C Klensin <[email-masked]>
Date: Tue, 29 Mar 2016 16:03:14 -0400

--On Tuesday, March 29, 2016 18:11 +0000 "HANSEN, TONY L"
<[email-masked]> wrote:

> On 3/29/16, 6:57 AM, "ietf on behalf of Tony Finch"
> <[email-masked] on behalf of [email-masked]> wrote:
> 
> 
>>> But if a spec uses, for example, a mixture of SHOULD and
>>> should, who knows what the authors intended? To that extent,
>>> the proposed clarification is helpful.
>> 
>> I think if a document uses RFC 2119 keywords then it ought to
>> avoid non-capitalized uses of the keywords, e.g. by replacing
>> "should" with "ought to" or other rephrasings.
>> 
>> Tony.
> 

Tony (and Tony), it seems to me that raises a fundamental issue
in editorial philosophy and style as well as some human factors
issues... the latter especially for readers who have to
translate (if only in their heads) between English and whatever
language they "think in".  I just don't know whether it is
possible to fix/adjust 2119 without resolving it.

There are, I think, two almost-separate problems.  The first is
that 2119, presumably in the interest of smooth and elegant
writing and phrasing, defined and therefore preempted not only
MUST, SHOULD, MAY, MUST NOT, SHOULD NOT, but several of the
obvious synonyms.  Had it not done that, it would have been
possible to say "for IETF purposes, these are not synonyms,
their meanings are different, and upper-case is just a
convenience for emphasis".  But those obvious synonyms are gone
too, so that avoiding the non-normative versions of the terms
requires some rather awkward circumlocutions as, IMO,  some of
the recommendations of draft-hansen-nonkeywords-non2119 rather
painfully illustrates.  

If you want to understand how painful, pick a non-English
language with with you or one of your colleagues is familiar, a
language that is not closely related to English in vocabulary
and semantics (i.e., not either a Germanic or a Romance
language), and then toss the text of a standard with the terms
recommended in your I-D mechanically substituted for the
normative 2119 terms into the widely-available automatic
translation tool of your choice.  I've tried an experiment or
two like that; the results were, IMO, appalling but YMMD.

So I just don't see that as a viable solution unless you want to
make writing clear I-Ds really difficult (and Heather and the
Production Center are willing to let those awkward constructions
make it into RFCs).

Again, this is partially a philosophical disagreement, so I
recognize that there are other points of view.

best,
    john

---

From: Eliot Lear <[email-masked]>
Date: Tue, 29 Mar 2016 22:43:53 +0200

> receiver supposed to interoperate or to reject the message?

Yes, this.  There seems to be a sort of MUSTSHOULDMAYphobia.  The
contortions some people will go through to avoid the words when that is
what they mean is, at times, hilarious; but at other times harmful to
interoperability.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Mar 2016 12:39:10 +1300

On 30/03/2016 00:27, Scott Bradner wrote:
> fwiw - seems to me that the basic idea that MUST and must are the same is wrong

I disagree, specifically for MUST, SHALL, REQUIRED and NOT. RFC2119
doesn't change their meanings, because their meanings are categorical
anyway. It's absolutely appropriate that RFC 2119 states their meanings,
but they aren't ambiguous.

> and will lead to

That is a change, because 2119 does not say point 3/. I'm not saying
it's a bad change, but it really is a change, affecting SHOULD and MAY
in particular.

Honestly I don't think any of this will change the questions I sometimes
have for authors, basically
"Should that 'should' be 'SHOULD'?"
"Should that 'may/MAY' be 'might'?"

   Brian

---

From: "Scott O. Bradner" <[email-masked]>
Date: Tue, 29 Mar 2016 19:43:01 -0400

yup - it is a change, one that might help against the people that say 2119 MUST be used all the time
but it will not address the examples you cite

Scott

> On Mar 29, 2016, at 7:39 PM, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Mar 2016 12:52:39 +1300

> I agree that's an improvement.

I think it's a significant improvement, despite my other comments. However,
we should also insert "NOT RECOMMENDED" (see the erratum #499 on 2119).

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Mar 2016 12:46:51 +1300

On 30/03/2016 05:34, John C Klensin wrote:
> 
> 
> --On Tuesday, March 29, 2016 08:58 +1300 Brian E Carpenter
>> The other words (must, shall, required, not) mean what they
>> always mean. The only argument for upper-casing them is
>> aesthetic symmetry. If a spec uses alternatives like
>> mandatory, necessary or forbidden, they are just as powerful.
>> ...
> 
> Actually, when 2119 is referenced, Section 6 attaches particular
> interoperability semantics to MUST, SHALL, etc., that are not
> part of the plain-English meaning of those words.  Section 6
> seems to be ignored most of the time but cited when it supports
> an axe someone wants to grind about use of conformance language.

My claim is that even section 6 does *not* change the meanings
of the categorical words in a spec. If it says that something
must or must not happen, either the statement is redundant or
it is essential for interoperability, whether it's written
in upper case Courier New or in runes.

But it doesn't matter. It's the SHOULDs and MAYs that require
precision in their use.

      Brian

---

From: Dave Cridland <[email-masked]>
Date: Wed, 30 Mar 2016 08:24:53 +0100

> in upper case Courier New or in runes.
I should think you must realise that shall not always be the case.

---

From: Adam Roach <[email-masked]>
Date: Wed, 30 Mar 2016 09:09:55 -0500

> - We're defining specific terms that specifications can use.

+1

> - These terms are always capitalized when these definitions are used.

+1

> their meanings are as specified here.

+1

> and they have their normal English meanings; this document has nothing

Yes. This. This, this, this, a million times, this. If we published a 
document that said only this, it would be a huge net win for the community.

> normative text doesn't need to use them, and doesn't use them.

+1

If there's anything I can do to help, Barry, please reach out to me.

/a

---

From: Dave Crocker <[email-masked]>
Date: Wed, 30 Mar 2016 07:34:26 -0700

> document that said only this, it would be a huge net win for the community.

Assuming that merely documenting this explicitly is sufficient, perhaps.

That such a rule differs from natural English -- which does not 
typically alter semantics based on case -- and that most readers of RFCs 
will not have such detailed knowledge of RFC2119 nor read RFCs with the 
care such a rule demands, my question BARRY and adam and EveryOne Else, 
is what makes anyone think that such a rule must (MUST?) ensure proper 
reading of RFCs so as to distinguish between normative portions and 
advisory portions?

It's worth distinguishing between rules that make the writers more 
comfortable, from rules that aid the reading efficacy in practical terms.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Adam Roach <[email-masked]>
Date: Wed, 30 Mar 2016 09:46:27 -0500

> comfortable, from rules that aid the reading efficacy in practical terms. 

Forcing implementors to read through the linguistic contortions authors 
make to avoid using perfectly good English words doesn't do them any 
favors. This odd game of charades -- "one syllable... sounds like... 
desk? wood?" -- does not aid clarity. Much the opposite.

/a

---

From: Eliot Lear <[email-masked]>
Date: Wed, 30 Mar 2016 16:52:47 +0200

On 3/30/16 4:46 PM, Adam Roach wrote:
> Forcing implementors to read through the linguistic contortions
> authors make to avoid using perfectly good English words doesn't do
> them any favors. This odd game of charades -- "one syllable... sounds
> like... desk? wood?" -- does not aid clarity. Much the opposite.

Ok.  But neither should authors and editors be afraid of 2119.  Those
definitions are there to help both the reader and the writer, so that
intent is clear.

Eliot

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 30 Mar 2016 09:55:50 -0500

> like... desk? wood?" -- does not aid clarity. Much the opposite.

+1. Especially having grown up in the border between the US south and 
southwest, where "ought" was a considerably more loaded term than 
"should" (and  was primarily used by grandparents to lecture children).

---

From: Dave Cridland <[email-masked]>
Date: Wed, 30 Mar 2016 17:32:07 +0100

On 30 March 2016 at 15:34, Dave Crocker <[email-masked]> wrote:

> That such a rule differs from natural English -- which does not typically
> alter semantics based on case -- and that most readers of RFCs will not
> have such detailed knowledge of RFC2119 nor read RFCs with the care such a
> rule demands, my question BARRY and adam and EveryOne Else, is what makes
> anyone think that such a rule must (MUST?) ensure proper reading of RFCs so
> as to distinguish between normative portions and advisory portions?
>
>
Sorry, I think that's nonsense. RFC 2119 and its capitalized keywords are
well known to anyone reading any specifications, these days. I think we can
actually assume a priori knowledge of RFC 2119, for the most part. What I
think would be far more surprising is this notion that the keywords, noted
and referenced in capitals, also have the same precise meaning and force
when written normally.

I'd note that in typical technical books, different typefaces are often
used to indicate verbatim commands or code, placeholders, etc - the
practise of using typographical conventions not normally found in written
English in technical literature is not only extremely prevalent, but in
this case in particular this is the assumption of the vast majority of
those likely to read it.

If you don't believe me, go look at a XEP, or a PEP, or a W3C-TR, or any of
hundreds of ad-hoc specifications from community efforts to proprietary
HTTP APIs - they all use RFC 2119 language, often without even bothering to
cite the document.

That's not to say that when reviewing a document, a lower-case "must" might
not be better as a "MUST" - but I don't see it as any different to a
similarly lower case "ought" being phrased better as a "SHOULD" if that's
really what was meant. The keywords exist to enhance clarity - but nothing
more. A mandatory requirement can be expressed without the "M" word. We can
mention that not implementing a feature causes interoperability issues
without using the "S" word. Knowing that we may read such text does not
make it "OPTIONAL".

Finally, I'd note in passing that "bill" and "Bill", "will" and "Will",
"heather" and "Heather", all have different semantics based on case - not
that this is particular relevant.

---

From: Adam Roach <[email-masked]>
Date: Wed, 30 Mar 2016 11:52:17 -0500

On 3/30/16 11:32, Dave Cridland wrote:
> Finally, I'd note in passing that "bill" and "Bill", "will" and 
> "Will", "heather" and "Heather", all have different semantics based on 
> case - not that this is particular relevant.

It's actually quite relevant, since it shows that we already have 
significant cases in which merely changing letter case can alter meaning 
nontrivially. There's a somewhat bawdy example of this that you can find 
by typing "capitalization matters" into Google Image Search. (Probably 
not safe to do in many workplaces).

It kind of takes the wind out of arguments that people will miss the 
difference between letter cases.

/a

---

From: Barry Leiba <[email-masked]>
Date: Wed, 30 Mar 2016 13:59:29 -0400

>> alter semantics based on case -- and that most readers of RFCs will not have
>> such detailed knowledge of RFC2119 nor read RFCs with the care such a rule
>> demands, my question BARRY and adam and EveryOne Else, is what makes anyone
>> think that such a rule must (MUST?) ensure proper reading of RFCs so as to
>> distinguish between normative portions and advisory portions?
>

I agree with the first and third sentences of what Dave Cridland said,
but I think we have to be a little careful about the second.  What I
think we can assume is an a priori knowledge of some of what 2119
says: that there are these capitalized key words that have special
meanings.  But it's quite clear from reviewing a lot of documents (one
of the fun things one gets to do as AD) that many writers do not know
how 2119 actually defines those.  I see significant misunderstandings
about "SHOULD" and "MAY" all the time, examples of which I can give
you if you like.  And one of my favourites is when someone used
"RECOMMENDED", I questioned it in a comment, and the response was,
"Yes, maybe we should switch that to 'SHOULD'."

As a complete side thing, I wonder how this all seems to
German-speakers, as German uses initial caps for all nouns.  I wonder
if anyone even notices if someone fails to do that.  I wonder if it
becomes puzzling, perhaps in some instances.

Barry

---

From: Dave Crocker <[email-masked]>
Date: Wed, 30 Mar 2016 10:03:49 -0700

On 3/30/2016 9:52 AM, Adam Roach wrote:
> nontrivially.

Except that the assertion that case alters meeting is wrong.  The 
examples given were wrong, adam.

d/

-- 

   Dave Crocker

---

From: Pat Thaler <[email-masked]>
Date: Wed, 30 Mar 2016 10:12:36 -0700

"must" has multiple meanings - it can indicate a requirement but it also
can be used to state the inevitable: e.g., "What goes up must come down."

Though in general, I'm not a fan of writing in all caps, "MUST" removes the
ambiguity indicating that it is to be understood as defined, rather than
having its regular English meaning.

All caps for the words also helps the requirement statements stand out when
scanning through a document.

On Wed, Mar 30, 2016 at 9:52 AM, Adam Roach <[email-masked]> wrote:

> nontrivially. There's a somewhat bawdy example of this that you can find by
> typing "capitalization matters" into Google Image Search. (Probably not
> safe to do in many workplaces).
>

---

From: Ole Jacobsen <[email-masked]>
Date: Wed, 30 Mar 2016 10:24:53 -0700 (PDT)

+1

A few years ago I stayed in a B&B in England. The owner asked me: "Do 
you require toast in the morning?" This particular use of "require"
is not commonly used in the US (at least not on the West Coast) unless
toast is some kind of medical substance.

All of which goes to show that words have different meaning and also 
different USAGE, often location-based.

Ole

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 30 Mar 2016 18:47:18 +0000

Hi Barry,

On 3/30/16, 10:59, "ietf on behalf of Barry Leiba" <[email-masked] on behalf of [email-masked]> wrote:
[...]

>becomes puzzling, perhaps in some instances.

German native speaker here.

Indeed, in German the first letter of a noun is capitalized, and indeed there are a very few examples where a noun and a (non-capitalized but otherwise spelled identically) non-noun have meanings that are not intuitively distinguishable.  One example is the plural noun “Spinnen” (spiders), and the verb “spinnen” (to spin/yarn and also to be bonkers :-)

There may even be a handful of cases (in all books of a sizable library) where that situation could lead to confusion when considering the context.  That would typically be slang language.  However, the amount of confusion is probably less than it would be in English, given the examples some folks provided here.

Except for acronyms, all-caps is a no-no in German, even for things like last names.

Stephan

---

From: Dave Cridland <[email-masked]>
Date: Wed, 30 Mar 2016 20:00:37 +0100

On 30 March 2016 at 18:59, Barry Leiba <[email-masked]> wrote:

> typically
> have
For future reference, I tend not to zero-index my sentences. ;-)

I think that MUST/SHOULD/MAY (the former two tempered by NOT) are
well-understood, although the strength of SHOULD is usually underestimated.
OPTIONAL is probably obvious enough (though its implications may not be),
and SHALL/RECOMMENDED are uncommon enough that they're probably not
understood nearly as well.

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Wed, 30 Mar 2016 19:28:39 +0000

This discussion seems to have started because rtcweb produced a document where the status (BCP, informative or standards track) was not clear and I could not even work it out from the use of pseudo normative language.

I would note that the meaning of even lower case “must” has to be clear, and in my view there is frequently an important distinction between “is obliged to” and “is expected to”, and even “should do”, all of which appear to be allowed by the Webster definition. Further, in the Oxford definition, only the first of these seems to be meant, so there is potentially an Atlantic divide here.

Further, when I have questioned in the past what some author has meant by using “must”, we frequently end up understanding that it was not meant at all. Sometimes it is hiding a somewhat differently phrased “MUST” requirement.

I could make similar arguments for other modal auxiliarys.

My other arguments for avoiding lower case versions are that other standards organizations (with one exception) do use lower case versions to explicitly define requirements, and the distinction of a usage within IETF is not necessarily understood, and secondly that it is far too easy for an editor with the misapplication of a single keypress to convert the case of a word.

Regards

Keith

From: rtcweb [mailto:[email-masked]] On Behalf Of EXT Dave Cridland
Sent: 30 March 2016 20:01
To: Barry Leiba
Cc: IETF discussion list; Heather Flanagan (RFC Series Editor); [email-masked]; IESG; Scott O. Bradner; Dave Crocker
Subject: Re: [rtcweb] Uppercase question for RFC2119 words

I think that MUST/SHOULD/MAY (the former two tempered by NOT) are well-understood, although the strength of SHOULD is usually underestimated. OPTIONAL is probably obvious enough (though its implications may not be), and SHALL/RECOMMENDED are uncommon enough that they're probably not understood nearly as well.

Barry

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Wed, 30 Mar 2016 19:37:29 +0000

Irrespective of the rest of this discussion, a reviewer should always address every upper and lower case usage of such verbs and ensure they are appropriate, because that is the place most mistakes are made in being absolutely precise as to meaning.

Keith

From: rtcweb [mailto:[email-masked]] On Behalf Of EXT Dave Cridland
Sent: 30 March 2016 08:25
To: Brian E Carpenter
Cc: IETF discussion list; Heather Flanagan (RFC Series Editor); [email-masked]; IESG; John C Klensin; Barry Leiba; Scott O. Bradner
Subject: Re: [rtcweb] Fuzzy words [was Uppercase question for RFC2119 words]

On 30 March 2016 at 00:46, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:
On 30/03/2016 05:34, John C Klensin wrote:
> <[email-masked]<mailto:[email-masked]>> wrote:
>
>> ...

      Brian

---

From: Mark Andrews <[email-masked]>
Date: Thu, 31 Mar 2016 06:19:26 +1100

> different USAGE, often location-based.

"table" can mean "to put aside" or to "make the focus of discussion"
or can be the actual physical item.

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