Aristotle Pagaltzis's comment on my previous entry prodded me into doing some more thinking about this, and his entry on RFC 2119 usage has persuaded me that there are actually four degrees of requirements that it's useful to put into specifications.

Put simply, I'd say that they are:

• allowed: you can do this, and some people will (so be prepared to cope with it).
• recommended: we think that you should do this.
• should: not doing this causes problems for people and other programs, but we have to admit that they won't actually break if you don't do this.
• must: your program won't work if you don't do this.

The IETF MAY is the first, the IETF MUST is the fourth, and I think that the IETF SHOULD sort of covers both the second and the third. I've now been convinced that there is a real difference between the second and the third cases, and I think it's important to distinguish between them in the name of honesty (if we're honest, we have a better chance of getting people to do should's because we aren't devaluing them; a should is a mark of something fairly important).

(Whether one should use the IETF SHOULD for merely recommended things is one of those debatable issues. The language of RFC 2119 appears to allow it, but there's an argument that a mere recommended practice should just be a MAY if you have to use only the three IETF levels.)

One can argue about recommended versus allowed, but pragmatically I think that it's important to differentiate between what's allowed and what's preferred. I want specifications to be able to steer implementors towards making the right choice as well as warn them about legal things that other implementations will do.

(Possibly I am out on left field on all of this, though. I don't have much experience in trying to write specifications for anyone but myself.)