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