[rfc-i] Is there a use case for 2119 keyword markup?
Brian E Carpenter
brian.e.carpenter at gmail.com
Sat Jun 21 13:01:22 PDT 2014
On 21/06/2014 23:03, Paul Hoffman wrote:
> On Jun 21, 2014, at 10:10 AM, Larry Masinter <masinter at adobe.com> wrote:
>> 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.
> As someone who is doing this exercise right now (on the ~100 documents that define the DNS), I fully disagree with that last sentence. I can just as easily search for "MUST" using a text editor as I can search for an XML entity using some XML tool. I can visually see all-caps as well as I can bold.
> More significantly, however, I cannot rely on the XML entities to be applied correctly. Authors will get this wrong, and the RFC Production Center will get this wrong. That's just a fact of life. I need to actually read the text to see what is and is not a feature for interoperability and conformance.
> Given that, the utility of the entities reduces to zero, but their presence will give a false sense of security.
How is that different from the false sense of security that you might
get from the current approach?
I tend to to think that having dedicated markup will make people
more careful than they are now when all they need is the shift key,
but that's psychological speculation.
(Since the absence of normative keywords does not imply the absence
of normative text, any attempt to rely on the presence of normative
keywords for interoperability criteria is doomed anyway.)
More information about the rfc-interest