Re: 2119bis - SHOULD Classifications

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]