On Thu, 19 Jan 2023 at 09:17, Maxime Buquet <p...@bouah.net> wrote:
> On 2023/01/18, Peter Saint-Andre wrote:
> > On 1/18/23 9:26 AM, Thilo Molitor wrote:
> > > In Appendix F: Requirements Conformance all our XEPs refer to RFC 2119
> defining
> > > "MUST", "SHALL" etc.
> > > But since RFC 2119 does not specify which case should be used for these
> > > keywords, a XEP using "shall" or even "sHaLl" uses normative keywords,
> no?
> >
> > My personal practice in writing RFCs has been to studiously avoid
> lowercase
> > conformance terms. It's quite easy and natural in English to use other
> > words: might instead of MAY, ought instead of SHOULD, etc. But it seems
> that
> > most authors are too lazy to do this, which is why we ended up with RFC
> > 8174.
>
> I'd like to nuance this here.
>
> Not everybody has english as their native language and many contribute
> to standardization nonetheless. Maybe standardization should be made
> more accessible, and I think 8174 is an ok step towards this, rather
> than having to be careful about subtle nuances of the language.
Additional Nuance:
The original keywords come from the RFC 1122 and RFC 1123 effort, which was
intended to tighten a lot of the early standards. These derive from a
series of campaigns of various implementors of early commercial Internet
offerings who claimed full conformance because the specifications had
sufficient wiggle-room to allow it. RFC 1123 stipulates that the "words"
are capitalized.
Many people thought these were great, and would reuse them - but often
without restating the definition. An example is RFC 2821 (published,
eventually, a full four years after RFC 2119) - I think Klensin kept his
own definition intentionally, actually, but I can't spot a difference.
Scott Bradner ("sob") would put in a formal appeal every time someone
attempted to use MUST/SHOULD/MAY without a definition, and then produced
his own. RFC 2119 does not stipulate that the keywords are to be
capitalized, but also always uses them in upper case, and does not say they
can be anything else, and stipulates "keywords", which are not the same
thing as words. He has stated on a number of occasions that he didn't
intent the keywords to be case insensitive, either.
Some people thought that a lowercase "must" used as ordinary English rather
than a keyword had the same meaning and weight as an RFC 2119 keyword
because it hadn't been specified not to. Although this was never the
intent, this is made more complicated because it often does... You need not
use RFC 2119 keywords to define a requirement in a specification (RFC 4469
is an example of a specification that eschews RFC 2119 entirely), and this
is often easily performed by words that - if capitalized - would have a
similar meaning. If my specification says "Servers must always ensure a
valid key is used", then capitalizing the MUST makes no difference. But the
meaning of "should" varies enormously from vague encouragement to the same
as saying you must. If I say that implementors should consider ... - is
that MUST consider? SHOULD consider? OUGHT to consider? Or is it none of
those, really?
It is often possible to jump through linguistic hoops to avoid the use of
words also used as RFC 2119 keywords, but that can change the meaning
subtly. Or not so subtly:
Servers may rely on a conformant client providing only...
Servers might rely on a conformant client providing only...
This is made worse when authors decide they MUST capitalize the words,
turning them into formal requirements, even if they MAY NOT [sic] need to.
Especially since this ends up changing the meaning rather dramatically in
cases where someone blindly uppercases a "should" or "may" in "should/may
not" - the English meaning of "SHOULD NOT" and "MAY NOT" is a mandatory
imperative, not a strong encouragement or an optional suggestion. Well,
depending on context... In any case, I would strongly agree this isn't a
matter of laziness.
I find it's hard enough to remind people that "SHOULD" requirements aren't
in any way optional and ignoring them may break interop.
Anyway, all this came to a head a few years back and RFC 8174 was produced
to quench this whole argument to the satisfaction of both sides. We should
use it.
Sorry.
We MUST use it.
Dave.
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
