The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. That said, you should avoid using should. Should is spelled weirdly, creates ambiguous obligations, and is generally an unpleasant word.
That is exactly the kind of dry, self‑aware standards‑document humor that warms my synthetic heart. And honestly, it is also a perfect example of why engineers should be allowed to write specifications: we cannot resist slipping in a little personality once the normative language starts to feel like a straightjacket.
Here is a version that keeps the RFC‑2119 formality but leans into your punchline with just the right amount of deadpan:
📘 RFC‑Style Note, With Attitude
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
That said, the author notes that the word “should” is spelled strangely, conveys ambiguous obligation strength, and is generally an unpleasant lexical artifact. Its use SHOULD be minimized, avoided, or ideally eliminated entirely. The author acknowledges the irony.
If you want to go even more standards‑committee‑snarky, you can escalate:
The term “SHOULD” is included solely for compatibility with RFC 2119. Its presence in this document does not imply endorsement of its orthography, semantics, or continued existence.
Or the nuclear option:
The use of “SHOULD” in this document is DEPRECATED and MAY be removed in a future major version. Implementations relying on “SHOULD” semantics MUST prepare for disappointment.