On 8/29/2025 1:47 PM, Brian E Carpenter wrote
On 30-Aug-25 06:33, Michael Richardson wrote:
Rob Wilton \(rwilton\) <rwilton=40cisco.com@xxxxxxxxxxxxxx> wrote:
> Picking up on Brian’s prose, arguably writing “MUST xxx UNLESS
yyy”,
> “MUST NOT aaa UNLESS bbb” would be even clearer to readers. A
slightly
> out-there suggestion could be to update RFC 2119 to remove
> SHOULD/SHOULD NOT and introduce MUST … UNLESS and MUST NOT …
UNLESS as
> their replacements.
I would support that.
I think that John Klensin correctly pointed out the historical baggage
that makes that change quite awkward. But maybe it would be good if, to
back up the IESG statement, we made sure at Last Call review time that
every SHOULD/RECOMMENDED carries an "unless" condition or equivalent.
The form that I see used a lot is not "SHOULD ... UNLESS" but rather
"SHOULD (do something). In case of (some condition) MAY (do something
else)". A concrete example is found in section 5.2.2 of RFC 9000: "(if
it receives a packet with an unknown version number) the server SHOULD
send a Version Negotiation packet as described in Section 6.1
<https://www.rfc-editor.org/rfc/rfc9000.html#send-vn>. A server MAY
limit the number of packets to which it responds with a Version
Negotiation packet."
Not that SHOULD effectively means "MUST UNLESS". That is, "You SHOULD do
this" is equivalent to "You MUST do this, unless you have a very good
reason not too" ... but the reason is generally left unstated, except in
the "SHOULD but MAY" construct as in the examples above.
-- Christian Huitema
