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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >>> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
