Alan Barrett wrote:
On Tue, 30 Aug 2011, Martin Sustrik wrote:
For an implementor it's often pretty hard to decide whether to
implement functionality marked as SHOULD given that he has zero
context and no idea whether the reason he has for not implementing the
feature is at all in line with RFC authors' intentions.
The likelyhood of a SHOULD getting implemented is directly related
to its implementation complexity. There are extremely complex protocols
(such as PKIX/rfc5280) where implementing all SHOULDs is economically
infeasible for many implementations (there are even some MUSTs in the
spec that are regularly ignored--and one can hardly blame implementations
for it).
It's really simple. If an interoperability problem arises
from your failure to implement a SHOULD, then it's your fault.
Hardly. A protocol spec ought to be architected so that two implementations
of only the MUST requirements will still be interoperable, otherwise
it is calling for troubles. A should requirement for a communications
protocol means that the _other_ end must sensibly (which in many cases
implies "gracefully") deal with peers that do not implement SHOULDs.
-Martin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf