Barry Leiba wrote:
Just responding to a small part, here:
� B) RFC2119 states SHOULD is the same as the adjective "RECOMMENDED."
As far I am concern, a recommendation is not a mandate nor obligation.
..
But don't make the mistake of thinking that, in the context of RFC
2119, one can use one's own English sense of what the meanings of
these terms are.
Agree, that is why the final part of my email I suggested the
consideration to remove the last sentence of the text be removed; The
term "RECOMMENDED" is equivalent to "SHOULD".
Personally, it benefit us if we state SHOULD under different
classifications. I'm just winging it, but perhaps:
NEW ITEM
IMPROVEMENT
SECURITY (VERY IMPORTANT)
A context of which the SHOULD offers has a lot of weight in the
decision making process.
Example:
If the SHOULD is related to security,
then all efforts MUST be to made to support it.
If the SHOULD item is an improvement not related to security,
then all efforts SHOULD be to made to support it.
If the SHOULD item is a new item not related to security,
then all efforts MAY be to made to support it.
Of course, there is the interesting nature of recursion here and the
last two can possibly be folded, but I think stating SHOULD compliance
classified under new, improvement and the level of importance context
will help rather than trying to state it as a generalize, ambiguous
rule of thumb - "A MUST BUT OPTIONAL IFF YOU KNOW WHAT YOU ARE DOING."
The basic idea is that when is something is NEW there is lesser
obligation to support it until its becomes widely adopted. If its
really an important feature, like security, then it ought to be stated
with a heavy obligatory emphasis.
Also, we may consider other general guidelines text like:
New protocol enhancements with SHOULD key words MUST NOT be used
a non-compliance
measurement tool of existing compliant implementations. i.e.
current implementator
are not "broken" because they are not currently supporting a SHOULD.
A new protocol that has a OPTIONAL dependency on an existing
optional protocol
MUST NOT use MUST|SHOULD as an enforcement tool for make
implementator to
support the optional protocol.
The last one I had trouble writing it, but I think you get the gist of it.
Overall, I believe the "system" has worked - we got this far because
we gave implementators the benefit of the doubt that valid reasons to
ignore was done responsibly and the protocols still worked.
The problem, in my view, has been an agenda of enforcing protocol
behavior from a "Throw the book" non-compliance mindset, worst when
dealing with integrated of optional protocols, yet not equally
applied. e.g., "I don't wish to honor that other protocol SHOULD but
you MUST follow my protocol SHOULD."
--
Sincerely
Hector Santos
http://www.santronics.com
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf