Rob,
That would certainly work for me. I look forward to the proposed
update to BCP 14 that makes that change, but hope it is quite clear
about the status of documents written after RFC 2119 using that
terminology and documents written before that, IIR back at least to
the 1980s, that used similar terminology and intended meanings (with
or without the caps).
Of course, given evolving rules in RSWG/RSAB, I suppose we could
track down all of those existing documents, or at least the
non-HISTORIC and non-Obsolete subset, and reissue them... but I hope
not.
My sense is that more rigorous application of the IESG's statement,
as pointed out (again) by Eric [1] would be, while not quite as good,
a lot less painful and confusing than trying to define words to mean
whatever we say they mean at the time we say (or write) them
(apologies to Humpty Dumpty).
john
[1]
https://mailarchive.ietf.org/arch/msg/ietf/vBMmEJNm4u68QNH_69UdD8YKXXc
--On Friday, August 29, 2025 10:24 +0000 "Rob Wilton (rwilton)"
<rwilton@xxxxxxxxx> wrote:
> I think that writing "MUST xxx unless yyy" is more precise and
> clear than" SHOULD xxx unless yyy".
>
> 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.
>
> That would make specifications more precise and prevent folks from
> using SHOULD to sit on the fence.
>
> Kind regards,
> Rob
>
>
>
> From: John C Klensin <john-ietf@xxxxxxx>
> Date: Friday, 29 August 2025 at 03:49
> To: Brian E Carpenter <brian.e.carpenter@xxxxxxxxx>, Toerless
> Eckert <tte@xxxxxxxxx> Cc: ietf@xxxxxxxx <ietf@xxxxxxxx>
> Subject: Re: Question about BCP 14 / RFC 8174
>
>
> --On Friday, August 29, 2025 11:45 +1200 Brian E Carpenter
> <brian.e.carpenter@xxxxxxxxx> wrote:
>
>> Toerless, I agree with you but again, my concern is not really
>> about MUST/MANDATORY or MAY/OPTIONAL. It's about
>> SHOULD/RECOMMENDED, where it might often be better to write MUST...
>> UNLESS without BCP 14 really being needed.
>>
>> As in "You SHOULD look both ways before crossing the road" vs "You
>> MUST look both ways before crossing the road UNLESS you are being
>> chased by a grizzly bear." That's the BCP 14 interpretation of
>> SHOULD, but we have often seen evidence of developers interpreting
>> it as "You don't really have to look both ways before crossing the
>> road."
>
> And, although this has been said many times before, 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, in particular the
> misunderstanding about it having a definition closer to "we'd prefer
> that you do it that way, but it is really up to you".
>
> And I agree with Toerless, and apparently you, about the BCP 14
> language. I'd go a tad further and suggest it is better adapted to
> Technical Specifications than to Applicability Statements, better
> for Applicability Statements than to BCPs, and better for BCPs than
> Experimental or Informational documents. Maybe eventually a
> question for offspring-of-PROCON.
>
>> I think operators are much less likely to make that mistake,
>> whether the RFC cites BCP 14 or not.
>
> Probably.
>
> best,
> john
>
>
