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

Larry Masinter masinter at adobe.com
Sat Jun 21 02:10:17 PDT 2014

I think I left out the use case for 2119 keyword markup, which is:

In more than one case, to generate an initial list of 'features' for interoperability or conformance testing, the group started with a list of every (paragraph containing a) MUST, MAY or SHOULD.  If there were RFC 2119 markup, it would assist with this process.

This isn't a very compelling use case -- unless the RFC is written with this in mind, the results will most likely need clean up -- but it's something I can imagine using with a little XSLT. 

I can't imagine mandating this, though -- what makes a valid interop test or report adequate varies widely. And while I can imagine ALLOWING authors to add this kind of markup, well, if we're allowing optional semantic markup to support informal auxiliary processing, there is lots more that might be useful. 

So maybe the topic for discussion is "additional semantic markup to support auxiliary informal processing", of which 2119 markup is just one example.


-----Original Message-----
From: rfc-interest [mailto:rfc-interest-bounces at rfc-editor.org] On Behalf Of Heather Flanagan (RFC Series Editor)
Sent: Friday, June 20, 2014 7:20 AM
To: rfc-interest at rfc-editor.org
Subject: Re: [rfc-i] Is there a use case for 2119 keyword markup?

On 6/19/14, 10:49 PM, Larry Masinter wrote:
> If I were wishing for a change in how RFCs (and other standards) were
> written, I'd suggest marking up what constituted a 'feature' to allow a
> framework for answering whether there were multiple independent
> interoperable implementations of every feature.   To come to consensus
> on that question does require the kind of agreement.
> Normative text is anything you have to know to decide whether an
> implementation implements the protocol's features correctly.
> http://tools.ietf.org/html/draft-ietf-newtrk-interop-reports-00

Interestingidea , but probably for a different thread in ietf-discuss
rather than here.  I think that type of idea--classifying whole sections
and defining things beyond normative and informative--is something the
IETF as a whole needs to discuss.

Thank you all for your input.  I am going to spend some time today
creating a summary of the discussion so far to make sure nothing was
missed, and then take this to IETF 90 to discuss with the IESG.
Depending on how that discussion goes, I will provide an update to the
community during the RFC Format session (yes, there is one; no, I don't
know what day/time yet).


rfc-interest mailing list
rfc-interest at rfc-editor.org

More information about the rfc-interest mailing list