Hi
It is preferable to update RFC2119 to be more suitable for IETF RFCs
in the future, IMO importance of using CAPS is understood, but when to
use lower case (e.g. must, should, etc.) is not clear. Some use their
sensibility to determine when to use lower case. In the end we can
leave it for the e
On May 20, 2012, at 11:36 PM, Marc Petit-Huguenin wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 05/20/2012 12:41 PM, Stephane Bortzmeyer wrote:
>> On Wed, May 16, 2012 at 11:06:25AM -0400, Simon Perreault
>> wrote a message of 12 lines which said:
>>
One dreams of a pe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/20/2012 12:41 PM, Stephane Bortzmeyer wrote:
> On Wed, May 16, 2012 at 11:06:25AM -0400, Simon Perreault
> wrote a message of 12 lines which said:
>
>>> One dreams of a period in which precision and elegance were not
>>> mutually exclusive p
On Wed, May 16, 2012 at 11:06:25AM -0400,
Simon Perreault wrote
a message of 12 lines which said:
> >One dreams of a period in which precision and elegance were not
> >mutually exclusive properties.
>
> You mean when French was the dominant language?
Nice troll. Let me amend it: we now have
On 2012-05-20 17:29, John C Klensin wrote:
>
> --On Sunday, May 20, 2012 07:53 +0100 Brian E Carpenter
> wrote:
>
>> On 2012-05-19 20:39, Ofer Inbar wrote:
>> ...
>>
>>> But don't change the rules. 2119 works well as is IMO.
>> Just to be clear about the current rules, 2119 makes it clear
>> t
--On Sunday, May 20, 2012 07:53 +0100 Brian E Carpenter
wrote:
> On 2012-05-19 20:39, Ofer Inbar wrote:
> ...
>
>> But don't change the rules. 2119 works well as is IMO.
>
> Just to be clear about the current rules, 2119 makes it clear
> that upper case keywords are optional ("These words a
Brian E Carpenter wrote:
On 2012-05-19 20:39, Ofer Inbar wrote:
...
But don't change the rules. 2119 works well as is IMO.
Just to be clear about the current rules, 2119 makes it clear that
upper case keywords are optional ("These words are often capitalized").
Indeed, numerous standards tr
On 05/20/2012 07:25 AM, Yaakov Stein wrote:
> But the IETF is still living in Roman times.
If you want a discussion as to whether we should live
in Times Roman, that'd be best on the rfc editor list.
(Sorry, couldn't resist;-)
S.
On Sat, 2012-05-19, Brian E Carpenter wrote:
> On 2012-05-19 20:39, Ofer Inbar wrote:
> ...
>> But don't change the rules. 2119 works well as is IMO.
> Just to be clear about the current rules, 2119 makes it clear that
> upper case keywords are optional ("These words are often capitalized").
>
On 2012-05-19 20:39, Ofer Inbar wrote:
...
> But don't change the rules. 2119 works well as is IMO.
Just to be clear about the current rules, 2119 makes it clear that
upper case keywords are optional ("These words are often capitalized").
Indeed, numerous standards track documents don't use the
> And of course if we had a slightly richer publication format we could
> use, oh, say, underline, bold, italics and maybe even a special font
> for normative terms, but I guess I am dreaming decades ahead...
I was waiting to see if someone was going to bring this up.
In Roman law, the way you
> So perhaps if Randy's new suggested boilerplate could be added as
> an erratum to 2119
yikes! i did not intend that. and i think folk need to look up
'erratum', think trivial bug fix. this would be a change. and i do
not have the hubris to change sob's immortal words :)
i think the practica
On 5/16/12 3:59 PM, Barry Leiba wrote:
>
> It's probably worth having a discussion of all of that
Did you envision THIS much discussion?
As a reader of RFCs, I've come to expect that 2119 words are always
capitalized, and that when the same words appear in lowercase or mixed
case they're not being used in the 2119 sense. This seems to be a de
facto standard, even though 2119 doesn't require it. I'm in favor of
continuing with this
On May 19, 2012, at 08:48, Brian E Carpenter wrote:
> Very seriously - after all that has been said on this thread, I see
> no reason to change anything.
+1
This is one of those issues that is best addressed by *awareness*, not by new
rules.
Grüße, Carsten
> Very seriously - after all that has been said on this thread, I see
> no reason to change anything.
the discussion has incited me to change the boiler plate which i will
use henceforth
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED
On 2012-05-18 19:27, Randy Bush wrote:
>> I recommend an errata to RFC 2119: "These words MUST NOT appear in a
>> document in lower case."
>
> first, that is not an erratum, it is a non-trivial semantic change.
>
> second, do we not already have enough problems being clear and concise
> without r
my wife says the purpose of tourists (we in japan) is to amuse the
natives
randy
On May 18, 2012, at 2:40 PM 5/18/12, Randy Bush wrote:
>> Dave Crocker's suggestion would minimize the number of words taken out
>> of our vocabulary:
>
> for a language other than english.
>
>> In addition to "clear and concise" we need precision and avoidance of
>> ambiguity.
>
> wonderful r
> Dave Crocker's suggestion would minimize the number of words taken out
> of our vocabulary:
for a language other than english.
> In addition to "clear and concise" we need precision and avoidance of
> ambiguity.
wonderful rofl. thanks. mind if i put that in my public quotes file?
randy
On May 18, 2012, at 2:27 PM 5/18/12, Randy Bush wrote:
>> I recommend an errata to RFC 2119: "These words MUST NOT appear in a
>> document in lower case."
>
> first, that is not an erratum, it is a non-trivial semantic change.
You are correct and point taken.
>
> second, do we not already h
> > I recommend an errata to RFC 2119: "These words MUST NOT appear in a
> > document in lower case."
> first, that is not an erratum, it is a non-trivial semantic change.
And therefore explicitly disallowed by the erratum process.
> second, do we not already have enough problems being clear and
> I recommend an errata to RFC 2119: "These words MUST NOT appear in a
> document in lower case."
first, that is not an erratum, it is a non-trivial semantic change.
second, do we not already have enough problems being clear and concise
without removing common words from our language?
randy
> So, I recommend an errata to RFC 2119: "These words MUST NOT appear in a
> document in lower case."
I'm glad you said "I recommend" instead of "I have recommended", as the
latter would violate the recommended (oh dear) rule.
This RECOMMENDED rule would also imply that documents can no longer b
On Fri, May 18, 2012 at 12:41 PM, Ralph Droms wrote:
>
> On May 16, 2012, at 10:22 PM 5/16/12, Ned Freed wrote:
>
>>
>>> On May 16, 2012, at 5:22 PM 5/16/12, ned+i...@mauve.mrochek.com wrote:
>>
>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>> "SHOULD", "SHOULD N
On May 16, 2012, at 10:22 PM 5/16/12, Ned Freed wrote:
>
>> On May 16, 2012, at 5:22 PM 5/16/12, ned+i...@mauve.mrochek.com wrote:
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> docu
> I find this morning a message on the URN WG list
> by Alfred Hines on RFC 6329, which has a new (AFAIK) convention on
> normative language
> 3. Conventions Used in This Document
>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>"SHOULD", "SHOULD NOT", "RECOMMENDED",
On Fri, May 18, 2012 at 1:06 AM, Hector Santos wrote:
> Lee Howard wrote:
>>
>>
>>> -Original Message-
>>> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
>>
>> Dave Cridland
>>>
>>> Consider:
>>>
>>> "An octet may contain 0-255".
>>> "An octet contains 0-255".
>>>
Lee Howard wrote:
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Dave Cridland
Consider:
"An octet may contain 0-255".
"An octet contains 0-255".
"An octet might contain 0-255" - or it might not?
"The Foo octet MUST lie between 0 and 127 in
> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Dave Cridland
> Consider:
>
> "An octet may contain 0-255".
> "An octet contains 0-255".
> "An octet might contain 0-255" - or it might not?
> "The Foo octet MUST lie between 0 and 127 inclusiv
On 2012-05-16 22:29, Dave Cridland wrote:
On Wed May 16 21:10:02 2012, Randy Bush wrote:
> Authors must be fastidious about this.
s/this/documents/
RFC 2119 §6 says:
Imperatives of the type defined in this memo must be used with care
and sparingly. In particular, they MUST only be used where
Randy Bush wrote:
> can != may
>
> one is ability, the other permission
Right, and if you are giving some entity permission to do something in a
protocol spec, surely that ought to be written in normative terms.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
FitzRoy: Cyclonic at times in far n
Andrew Sullivan wrote:
> On Wed, May 16, 2012 at 07:17:04AM -0700, Dave Crocker wrote:
> > Case does not define meaning in normal language, why should it here?
>
> That is false. Consider these two passages:
>
> The King asked the Queen,
> and the Queen asked the dairy-maid …
>
> vs
>
>
- Original Message -
From: "Doug Barton"
To:
Cc: "Barry Leiba"
Sent: Thursday, May 17, 2012 7:18 AM
> On 05/16/2012 06:59, Barry Leiba wrote:
> > In fact, RFC 2119 says that the normative keywords are "often
> > capitalized", but doesn't require that they be.
>
> Standards should be writ
On 05/16/2012 06:59, Barry Leiba wrote:
> In fact, RFC 2119 says that the normative keywords are "often
> capitalized", but doesn't require that they be.
Standards should be written in such a way as to remove as much ambiguity
as possible, not show how clever we are. That allowance in 2119 was a
m
> On May 16, 2012, at 5:22 PM 5/16/12, ned+i...@mauve.mrochek.com wrote:
> >>> 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 [RFC2119] when t
+1
My view that this is more about the specific issues of documents and
not just RFC2119 itself. Sometimes it falls through the cracks.
Sometimes a justification or argument is found to show the contrary of
what is stated, especially when its uses lower cases or even terms
like "choose." So
I'm looking forward to the normative use of
Proper use should be , how that is revealed to
the user is decided by the display system.
jaap
+1
and for the current thread, case is format...
Peter Saint-Andre wrote:
>On 5/16/12 12:26 PM, Ole Jacobsen wrote:
>>
>> And of course if we had a slightly richer publication format we could
>
>> use, oh, say, underline, bold, italics and maybe even a special font
>> for normative terms, but
On May 16, 2012, at 5:22 PM 5/16/12, ned+i...@mauve.mrochek.com wrote:
>>> 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 [RFC2119] when they
>>>
> >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 [RFC2119] when they
> >appear in ALL CAPS. These words may also appear in this document i
On May 16, 2012, at 4:10 PM, Worley, Dale R (Dale) wrote:
>> From: John C Klensin [john-i...@jck.com]
>>
>>> Remind me:
>>> Is bold must more or less compelling that underlined must. And
>>> where does uppercase MUST fit in?
>>>
>>> I fear the slightly richer publication format will give rise
>
On Wed May 16 21:10:02 2012, Randy Bush wrote:
> Authors must be fastidious about this.
s/this/documents/
RFC 2119 §6 says:
Imperatives of the type defined in this memo must be used with care
and sparingly. In particular, they MUST only be used where it is
actually required for interop
> From: John C Klensin [john-i...@jck.com]
>
> > Remind me:
> > Is bold must more or less compelling that underlined must. And
> > where does uppercase MUST fit in?
> >
> > I fear the slightly richer publication format will give rise
> > to a slightly more complex revision of RFC 2119.
>
> Let's
> Authors must be fastidious about this.
s/this/documents/
> "It may rain today" is fine
iff you are talaya
randy
--On Wednesday, May 16, 2012 19:45 +0100 Adrian Farrel
wrote:
> Remind me:
> Is bold must more or less compelling that underlined must. And
> where does uppercase MUST fit in?
>
> I fear the slightly richer publication format will give rise
> to a slightly more complex revision of RFC 2119.
L
Yeah, that's probably a safer approach. One could of course
imagine some kind of hybrid and parsing in the form of *very*
or /very/ explicit terms. Maybe this is orthogonal to the
other discussion we are having...
Ole
Ole J. Jacobsen
Editor and Publisher, The Internet Protocol Journal
Cisco Sy
o:stpe...@stpeter.im]
> Sent: 16 May 2012 19:43
> To: Ole Jacobsen
> Cc: Mary Barnes; adr...@olddog.co.uk; Sam Hartman; ietf@ietf.org
> Subject: Re: RFC 2119 terms, ALL CAPS vs lower case
>
> On 5/16/12 12:26 PM, Ole Jacobsen wrote:
> >
> > And of course if we had a s
On 5/16/12 12:26 PM, Ole Jacobsen wrote:
>
> And of course if we had a slightly richer publication format we could
> use, oh, say, underline, bold, italics and maybe even a special font
> for normative terms, but I guess I am dreaming decades ahead...
Although I too dream the impossible dream,
And of course if we had a slightly richer publication format we could
use, oh, say, underline, bold, italics and maybe even a special font
for normative terms, but I guess I am dreaming decades ahead...
Ole
Ole J. Jacobsen
Editor and Publisher, The Internet Protocol Journal
Cisco Systems
Tel
On 2012-05-16 18:53, Peter Saint-Andre wrote:
> On 5/16/12 9:58 AM, Sam Hartman wrote:
...
>> I'll note that in my normal reading mode I do not distinguish case,
>> but even so I find the ability to use may and should in RFC text without
>> the 2119 implications valuable.
Agreed. But as a gen-a
Peter,
I also try to follow the same practice after I got the suggestion for one
of my documents. The issue I see with the suggestion that "may" is not
normative whereas MAY is, is that it is not at all uncommon for folks to
typo and forget to make the "may" uppercase - that puts the burden on the
On 5/16/12 9:58 AM, Sam Hartman wrote:
>> "Adrian" == Adrian Farrel writes:
>
> Adrian> How about... The key words "MUST", "MUST NOT", "REQUIRED",
> Adrian> "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
> Adrian> "MAY", and "OPTIONAL" in this document are to be int
+1
Randy Bush wrote:
can != may
one is ability, the other permission
randy
--
HLS
> "Adrian" == Adrian Farrel writes:
Adrian> How about... The key words "MUST", "MUST NOT", "REQUIRED",
Adrian> "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
Adrian> "MAY", and "OPTIONAL" in this document are to be interpreted
Adrian> as described in [RFC2119] w
On 5/16/2012 7:56 AM, Andrew Sullivan wrote:
But your claim is actually a symptom of the disease you've diagnosed:
computers obliterated distinctions that are important in the writing
of natural languages, mostly because case transformation for ASCII was
a trivial task and treating these differ
On 2012-05-16 10:56, Andrew Sullivan wrote:
Because, after all, technical specification language is already such
elegant prose, maintaining that elegance is more important than
robustly encoding the semantic of being normative in a way that
avoids ambiguity?
One dreams of a period in which prec
On Wed, May 16, 2012 at 07:17:04AM -0700, Dave Crocker wrote:
> Case does not define meaning in normal language, why should it here?
That is false. Consider these two passages:
The King asked the Queen,
and the Queen asked the dairy-maid …
vs
The king asked the queen,
and the q
On 5/16/2012 7:39 AM, Randy Bush wrote:
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 [RFC2119] when they
appear in ALL CAPS. These words may
How about...
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 [RFC2119] when they
appear in ALL CAPS. These words may also appear in this document
>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 [RFC2119] when they
>appear in ALL CAPS. These words may also appear in this document in
>l
>>> can != may
>>> one is ability, the other permission
>> When we were first taught English grammar, yes. Today, not so much.
>> Actually pretty much never. In modern usage, the distinction has been lost.
> I must be ancient then as I still use this distinction (and similarly
> would/could).
y
On 5/16/2012 7:34 AM, Scott Kitterman wrote:
On Wednesday, May 16, 2012 07:31:53 AM Dave Crocker wrote:
On 5/16/2012 7:28 AM, Randy Bush wrote:
can != may
one is ability, the other permission
When we were first taught English grammar, yes. Today, not so much.
Actually pretty much never.
At 9:59 -0400 5/16/12, Barry Leiba wrote:
It's probably worth having a discussion of all of that, and seeing
whether there's some possibility of developing a rough community consensus
on what we might-could-maybe-oughta-should do.
What I've run into, a couple of times, in the past few years ar
On Wednesday, May 16, 2012 07:31:53 AM Dave Crocker wrote:
> On 5/16/2012 7:28 AM, Randy Bush wrote:
> > can != may
> >
> > one is ability, the other permission
>
> When we were first taught English grammar, yes. Today, not so much.
>
> Actually pretty much never. In modern usage, the distinct
On 5/16/2012 7:28 AM, Randy Bush wrote:
can != may
one is ability, the other permission
When we were first taught English grammar, yes. Today, not so much.
Actually pretty much never. In modern usage, the distinction has been lost.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.
can != may
one is ability, the other permission
randy
On 5/16/2012 6:59 AM, Barry Leiba wrote:
This passes all nit checks, including those involving the eyes of the
IESG,
Computer Science has a long history of being quaint about the role of
upper/lower case and then ignoring the problems caused by the
distinctive interpretation it imposes. It
Some snippets from another discussion thread, in a galaxy far, far away:
Murray:
Sections 1, 3-7: The "may" in a document citing RFC2119 ought to be
"can" or such.
Ned:
This seems pretty silly to me. The entire point of capitalizing these
terms is so they aren't confused with conventional usa
69 matches
Mail list logo
