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
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
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 them.
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).
Indeed,
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.
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
--On Sunday, May 20, 2012 07:53 +0100 Brian E Carpenter
brian.e.carpen...@gmail.com 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
On 2012-05-20 17:29, John C Klensin wrote:
--On Sunday, May 20, 2012 07:53 +0100 Brian E Carpenter
brian.e.carpen...@gmail.com 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
On Wed, May 16, 2012 at 11:06:25AM -0400,
Simon Perreault simon.perrea...@viagenie.ca 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
-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
simon.perrea...@viagenie.ca wrote a message of 12 lines which said:
One dreams of a period in which precision and elegance were not
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
simon.perrea...@viagenie.ca wrote a message of 12 lines which said:
One
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 removing
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, MAY, and
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
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
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?
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 practical
On Fri, May 18, 2012 at 1:06 AM, Hector Santos hsan...@isdg.net 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.
An octet might
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, MAY, and OPTIONAL in
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
document are to be interpreted as
On Fri, May 18, 2012 at 12:41 PM, Ralph Droms rdroms.i...@gmail.com 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 NOT,
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 be
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
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
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 have
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: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 rofl. thanks.
my wife says the purpose of tourists (we in japan) is to amuse the
natives
randy
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
- Original Message -
From: Doug Barton do...@dougbarton.us
To: ietf@ietf.org
Cc: Barry Leiba barryle...@computer.org
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
Andrew Sullivan a...@anvilwalrusden.com 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
Randy Bush ra...@psg.com 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.finch d...@dotat.at http://dotat.at/
FitzRoy:
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
-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 inclusive; that is,
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
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 usage,
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
can != may
one is ability, the other permission
randy
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
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 distinction has
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
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.
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).
yep. let's
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
lower case as plain
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 in
lower case
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 also appear in
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
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
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
Adrian == Adrian Farrel adr...@olddog.co.uk 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] when they
+1
Randy Bush wrote:
can != may
one is ability, the other permission
randy
--
HLS
On 5/16/12 9:58 AM, Sam Hartman wrote:
Adrian == Adrian Farrel adr...@olddog.co.uk 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
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 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-art
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
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, I
...@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 slightly richer publication format we could
use
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
--On Wednesday, May 16, 2012 19:45 +0100 Adrian Farrel
adr...@olddog.co.uk 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
Authors must be fastidious about this.
s/this/documents/
It may rain today is fine
iff you are talaya
randy
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 try to remember
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
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
to a slightly more
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
lower case as plain
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
appear in ALL CAPS. These
+1
and for the current thread, case is format...
Peter Saint-Andre stpe...@stpeter.im 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
I'm looking forward to the normative use of BLINK.../BLINK.
Proper use should be NORMATIVE/NORMATIVE, how that is revealed to
the user is decided by the display system.
jaap
+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.
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
appear in ALL CAPS.
69 matches
Mail list logo
