-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/30/2011 09:11 AM, Keith Moore wrote:
On Aug 30, 2011, at 12:06 PM, Marc Petit-Huguenin wrote:
The meaning of SHOULD is clear for the authors (it "mean[s] that there may
exist
valid reasons in particular circumstances to ignore a particular item, but
the
full implications must be understood and carefully weighed before choosing a
different course."), the problem is that some implementers use a different
meaning (I do not have to implement this if it is inconvenient or difficult
for
me to implement), vendors another one (SHOULD gave us the right to not
implement
it). I even read somewhere, perhaps on this list, about a vendor that
rejected
any bug report against a SHOULD. Conditional MUST, in my opinion, does not
have
this problem.
But conditional MUST has other problems, namely that you have to enumerate the
exceptions for the MUST, and that's not always practical.
Implementors who think that SHOULD gives them a free pass to avoid
implementing
something that's needed to interoperate are misreading 2119. But document
editors should avoid using SHOULD for cases where failure to implement the
requirement will result in interoperability failure.
I could see maybe posting an erratum or a brief update to 2119, but I think
that
reopening that document in general is a Very bad Idea. And for existing
documents that misuse SHOULD, the appropriate thing to do is to update those
documents or post errata to those documents, rather than try to retroactively
change the meaning of the keywords in those documents.
I like your definition a previous email, so perhaps an alternative solution to
updating 2119 is for authors who really care about this subject is to integrate
it in the Terminology section, something like this:
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
"SHOULD", "SHOULD NOT", "RECOMMENDED", and "NOT RECOMMENDED" are
appropriate when valid exceptions to a general requirement are known
to exist or appear to exist, and it is infeasible or impractical to
enumerate all of them. However, they should not be interpreted as
permitting implementors to fail to implement the general requirement
when such failure would result in interoperability failure.
- --
Marc Petit-Huguenin
Personal email: marc(_at_)petit-huguenin(_dot_)org
Professional email: petithug(_at_)acm(_dot_)org
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAk5dDYkACgkQ9RoMZyVa61fA6gCfYTawSM53Uy7okAgidhSyQZzH
8JUAn3AwH0wz96A9K2EfyALIsVkjAFJP
=L35E
-----END PGP SIGNATURE-----
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf