> -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Keith Moore > Sent: Wednesday, August 31, 2011 9:03 AM > To: Hector > Cc: IETF discussion list > Subject: Re: 2119bis > > Because of long experience that indicates that implementors often fail > to read base specifications thoroughly, much less the referenced > specifications. I absolutely agree, and also with your earlier point that a lot of people apparently either don't bother to read RFC2119 at all, or (in my experience) read it selectively. If there is an RFC2119bis, I would like to see it illustrate the cases where a MUST would be preferred over a SHOULD, and vice-versa, such that the implications to both the spec author and the reader are clarified. It already seems to start down that road, which is fine. But I don't think there's anything wrong with the definitions as we have them; I think they've served us well for the last fourteen years. I don't agree at all with the interpretation of SHOULD as an optional protocol feature in all cases. RFC2119 makes it clear what SHOULD and RECOMMENDED mean beyond the dictionary definition. They are not an invitation to disregard those requirements merely because they are hard to implement or would confuse end users if exposed. It seems clear to me that SHOULD is the same as "MUST... UNLESS", and the "unless" part has to be carefully considered in terms of how interoperability will be affected, not how your source code or user interface will become more complicated. It's certainly the case that there are some documents that got use of SHOULD wrong, but that doesn't mean RFC2119 is broken. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf