[rfc-i] Is there a use case for 2119 keyword markup?

Nico Williams nico at cryptonector.com
Wed Jun 18 15:20:01 PDT 2014


On Wed, Jun 18, 2014 at 5:03 PM, Andrew Sullivan <ajs at anvilwalrusden.com> wrote:
> On Wed, Jun 18, 2014 at 01:50:37PM -0700, Heather Flanagan (RFC Series Editor) wrote:
>> For this to happen, we need to add something to the XML vocabulary as
>> well.  Does anyone have a use case where this kind of markup would be
>> useful, or is it just a "nice to have, because we can, but not if it
>> increases the overall cost of creating RFCs"?
>
> It seems to me that, if we're using semantic mark up and don't use it
> in any way to deal with perhaps the most important semantic
> distinction we have in the entire RFC series, then we're doing it wrong.

Which distinction is...?

>> Note: Whether or not we decide to add markup around the keywords, the
>> current guidance around capitalization, etc, as described in RFC 2119
>> will still apply.
>
> This also seems like a mistake, at least in the long term.  That is,

ISTM that semantic markup and rendering of the same are separable
things.  In fact, that seems like the point of such markup.

In any case, as long as we use "must", "should" and so on -- every day
English language words (what an understatement) for normative
purposes, then we definitely need to distinguish them from informative
uses.  That distinction needs to be clear to _readers_, therefore the
use of capitalization in rendering is one possible (and to date very
useful) manner of rendering that distinction.

> if you alter the XML vocabulary, then at some future date you can stop
> the incredibly stupid arguments about whether MUST and must are
> [...]

I don't agree that such arguments are stupid.  The are the crux of
what we do in standards track RFCs!

Having such semantic markup does mean not having to capitalize these
words in the source.  More than that, and assuming generalized
rendering options: we could even extend semantic normative/informative
markup to many other words/phrases.

Nico
--


More information about the rfc-interest mailing list