Looks good, but needs some smitthing.
I think that the sense that I would want is:
* Whenever the keywords are used they are to be considered normative
* Whenever the keywords are used they SHOULD be capitalized
* Editors SHOULD avoid use of normative keywords for non-normative language,
even in drafts.
The reason for the last is that it is very common for folk to go through a
doucument 'to make sure all the keywords are capitalized as they should be'.
This is particularly so where older RFCs are being revised. A standards
document should be robust in the face of search and replace changes to the text.
I would ideally like to see a normative keyword tag added to the XML2RFC markup
to make it easy to construct tables of normative requirements as are required
for interop testing and are beginning to appear in some specs.
So the marku would be something like:
<t>Normative keywords <normative key="should">Only use normative keywords to
specify normative language</normative> only be used to specify normative
language.</t>
And this would allow a table such as the following to be created:
NORMATIVE REQUIREMENTS
SHOULD
Section 2.1 p 3: Only use normative keywords to specify normative language
________________________________
From: ietf-bounces(_at_)ietf(_dot_)org on behalf of Ralph Droms
Sent: Mon 6/30/2008 10:11 AM
To: Spencer Dawkins
Cc: Randy Presuhn; IETF Discussion
Subject: Re: SHOULD vs MUST case sensitivity
Would a reasonable BCP for future docs looks something like:
terms defined in RFC 2119 are to be capitalized for clarity;
alternatives for RFC 2119 terms, such as "ought" and "can" are to be
used in
non-normative text to avoid confusion
- Ralph
On Jun 30, 2008, at Jun 30, 2008,10:08 AM, Spencer Dawkins wrote:
Without reference to other points that have been made in this
thread, it's also worth noting that Gen-ART reviewers have been
challenging 2119-ish statements in drafts under review for several
years, assuming that capitalization is significant, and discouraging
upper-casing for emphasis.
It would be lovely to have the current practice written down
clearly, so authors and editors aren't surprised when this happens
(and we never have to revisit the topic).
Thanks,
Spencer
However, there is abundant evidence to support argument
that prospective RFC authors should use the ALL-CAPS version of
these words - if for no other reason than because it removes any
possibility of doubt. The evidence to support this is based at
least partly on current usage - such as a BCP like RFC 2119 is
meant to reflect. It is also based at least in part on the the
arguments put forward in this thread. And finally, it is based
at least in part on the common-sense proposition that anything
that adds clarity to a specification is generally a good thing.
Hence I believe the one thing we should take away from
this discussion is that - while use of the ALL-CAPS version of
the requriements level terminology in RFC 2119 is probably not
technically required to indicate the intended usage - it is a
very good idea to do this. Further, if we assume that is the
case (and I think reasonable people will agree that it is),
then continuing the argument about the semantics in this case
is merely a distraction from useful discussion and clarity in
the work we all want to be doing.
--
Eric Gray
Principal Engineer
Ericsson
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On
Behalf Of Dave Crocker
Sent: Sunday, June 29, 2008 10:32 PM
To: Randy Presuhn
Cc: IETF Discussion
Subject: Re: SHOULD vs MUST case sensitivity
Randy Presuhn wrote:
English is not case sensitive.
Not so. Case has long been used for emphasis in environments
lacking other typographical means, such as bolding, underlining,
or italicization.
Emphasis is not semantics.
Normative intent is semantic.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf