About the SHOULD, there is a recent IESG statement trying to clarify the use of BCP14:
https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/
It notably says:
“
The use of “SHOULD” and “RECOMMENDED” (and their corresponding negations) warrants additional guidance:
These key words present a choice to the reader. It improves the document to provide readers with all of the details they need to make an
informed decision. Thus, “You SHOULD do X” is less valuable than “You SHOULD do X because if you don’t, you get Y, which is less preferable because Z”.
Use of these key words is not appropriate when the only reason they are chosen is to avoid committing to a “MUST” or “REQUIRED”. They shouldn’t
be used merely to express a preference. If there are no interoperability implications to the choice being presented, using “MAY” or “OPTIONAL”, or omitting key words entirely, is likely more appropriate.
Sometimes these key words are used as a way to allow for backward compatibility when introducing a change into an existing deployment.
If this is the case, document authors should make it explicit that this is the reason these are used. Additional text explaining that this is the only legitimate reason to deviate from the normative advice is preferred. An alternative approach is to stipulate
“All new implementations MUST do $NEW_WAY but SHOULD also accept $OLD_WAY [for some period of time] for backward compatibility”.
“
-éric
From: Carsten Bormann <cabo@xxxxxxx>
Date: Friday, 29 August 2025 at 06:54
To: John C Klensin <john-ietf@xxxxxxx>
Cc: ietf@xxxxxxxx <ietf@xxxxxxxx>
Subject: Re: Question about BCP 14 / RFC 8174
On Aug 29, 2025, at 04:47, John C Klensin <john-ietf@xxxxxxx> 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
