-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf