Re: Question about BCP 14 / RFC 8174

[Carsten Bormann <[e-mail]>]

On Aug 29, 2025, at 04:47, John C Klensin <[e-mail]> wrote:
> 
> if we more often
> insisted on "SHOULD ... unless" discussions where they are possible
> -- e.g., "You SHOULD look both ways before crossing the road unless
> you are being chased by a dangerous animal" -- we'd probably have
> fewer misunderstandings of what SHOULD implies, 

I’d say the IESG is already doing a good job here in its reviews (definitely helped by the various area/directorate reviewers), at least for the last few couple of years.

We could of course point out the need for this review more prominently (I can’t find the “manual” id-nits statement right now, but it should be there, or maybe even in the directorate-specific review guidelines, e.g., for GENART).

The idnits tool can’t really check this.

An LLM can render at least some assistance, see below.
(Some prompt engineering may be required to focus this on BCP14 usage.)

Grüße, Carsten


Comments on the below LLM answer:
(Ugh, fragment identifiers… I need to find someone to tell us how to do this right.)
The comment on 3.4 is interesting, as I believe the usage of NOT RECOMMENDED here is fully justified even without an unspecific “unless a bear chases you” clause, as in “unless the benefits significantly exceed the drawbacks of depending on the serialization order”.
Maybe these two instances reflect that using BCP 14 for aspects of registration actions possibly involving designated experts has its own characteristics we haven’t fully captured yet.


# In rfc8949, are there any statements of the form SHOULD or RECOMMENDED (BCP14) that do not explain the exceptional conditions that must be fulfilled before the statement does not need to be heeded?

Yes. RFC 8949 contains BCP 14 SHOULD/RECOMMENDED usages without stated exception conditions.

Two clear examples:
    • Section 3.4 (Tagging of Items): After noting a few tags whose semantics depend on serialization order, the text says “The definition of new tags with this property is NOT RECOMMENDED.” It provides rationale but does not enumerate conditions under which ignoring that guidance would be acceptable. ​⁠https://datatracker.ietf.org/doc/html/rfc8949
    • Section 9.5 (Structured Syntax Suffix Registry):
        • “The syntax and semantics of fragment identifiers specified for +cbor SHOULD be as specified for ‘application/cbor’.”
        • “The syntax and semantics for fragment identifiers for a specific ‘xxx/yyy+cbor’ SHOULD be processed as follows: …”
These establish recommended behavior but do not spell out exceptional circumstances for deviating. The parenthetical note about there being no fragment identifier syntax for application/cbor at publication time is contextual information, not an exception clause. ​⁠https://datatracker.ietf.org/doc/html/rfc8949

In short, while the document generally uses BCP 14 precisely, it does include SHOULD/NOT RECOMMENDED statements that lack an explicit “unless…” or enumerated exceptional conditions. ​⁠https://datatracker.ietf.org/doc/html/rfc8949