[rfc-i] Summary: use case for 2119 markup
nico at cryptonector.com
Fri Jun 20 13:56:15 PDT 2014
On Fri, Jun 20, 2014 at 12:32 PM, Heather Flanagan (RFC Series Editor)
<rse at rfc-editor.org> wrote:
> 1. Markup (or lack there of) would create too great an overhead for both
> reviewers and the RFC Editor in terms of checking and cross-checking intent.
I'm willing to worry only about the RFC-Editor's burden, and let you
make that call. I.e., non-RFC-Editor reviewers could be told not to
bother picking nits about this markup; non-marked-up RFC2119
capitalized terms could be OK up to I-D entrance onto the RFC-Editor's
> 2. Even if we regard this as semantic markup, the result would
> (potentially) be a different visual distinction that could in turn be
> interpreted as making specific typography indicative of normative-ness.
Not a new problem: ever since we've had more than one output format
like HTML and PDF we've had this "problem". It's a non-problem
> 3. If we do not require consistency in how we apply markup to RFC 2119
> language, we may see the potential for interop issues.
THIS is a potential problem, and relates to (1) above. Is the
RFC-Editor willing to do the extra work to avoid (3)?
Here's a fourth argument against: this potentially binds us more
strongly to XML as the canonical (or canonical input) format. I don't
care for this argument, but I can't reject it out of hand until XML
indeed becomes the canonical (or canonical input) format.
> Topics outside the boundaries of this discusion
> * markup of entire phrases/sentences/sections as normative or informative
Sure. I can always do what I've done before.
> * creating additional markup to indicate things like "feature", similar
> to "code"
> * revising RFC 2119 to be more clear on use of capitalization
> Anything missing?
Is it possible to ever have a different set of normative terms than
RFC2119's? In theory, "yes". That might have bearing on the design
of the markup.
More information about the rfc-interest