On 2/11/22 18:56, John C Klensin wrote:
So, I think that, unless we have reached the stage where we want
and expect our specifications to cover every detail and be exact
about it, SHOULD serves real value... but only if we require
explanations of why it is present rather than using it as "MUST,
but maybe not" or "MUST unless you don't feel like it".
+1
I also think that there is value in having some humility when writing
protocol specifications, and also when implementing them. SHOULD can
be the authors' way of saying "we realize there are probably valid
exceptions to this rule but we're not able to confidently enumerate them
all, particularly given the diversity of the Internet and the
environments in which this must function". But an implementer reading
a SHOULD should also realize that there's probably a good reason for the
SHOULD and that the implementation needs at least that good a reason to
violate the SHOULD. Perhaps we should provide some justifications for
SHOULDs, perhaps in non-normative appendices, when writing specifications.
Also, there's value in having specifications be brief even with some
loss of precision. The longer and more detailed the specification, the
less likely it is that it will be correctly implemented. So specifying
SHOULD can result in a more readable specification, and one more likely
to be correctly implemented, than a specification that detailed all of
the exceptions for a MUST.
Keith
