Not to pick on Eric; others have said things along the lines of:
At 12:59 PM +1000 4/4/05, Eric Scheid wrote:
I'll be happy with:
self: MAY alternate: MAY id: SHOULD
or possibly even:
self: SHOULD alternate: SHOULD id: MUST
This isn't a negotiating game. We have to have technical reasons for our assigning requirements levels.
To repeat the relevant section from RFC 2119 (which is only two pages long, really):
6. Guidance in the use of these Imperatives
Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability.
What is the technical reasons for the SHOULDs and MUSTs? Where is the interoperability issues within the protocol (not with readers that don't know what the protocol looks like)? What are the potentials for causing harm? I'm not saying there are none; I'm saying let's choose our levels based on what we are supposed to be choosing from.
--Paul Hoffman, Director --Internet Mail Consortium
