Re: Question about BCP 14 / RFC 8174

[Christian Huitema <[e-mail]>]

On 8/29/2025 1:47 PM, Brian E Carpenter wrote
>
> On 30-Aug-25 06:33, Michael Richardson wrote:
>>
>> Rob Wilton \(rwilton\) <rwilton=[e-mail]> 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