2009-08-29
MUST versus SHOULD in your specifications
Something I've been mulling over lately is the the effects of A rule for Internet software on specifications and how strong you make requirements in them.
To put it one way: a 'MUST' in a specification makes a handy club to beat people with, but perhaps they are best reserved for things that are absolutely required in order to make the protocol work, because in practice that is what is going to happen anyways.
(Note that a MUST often does not make an effective club, because if it doesn't break things the people who got it wrong rarely care about it. This is the world of 'technical' violations of standards, as in 'technically we don't comply with ...'.)
Given that people screw things up, sooner or later someone is going to write software that disobeys every MUST in your specification (maybe not all at once, though). Some of these violations will cause their software to not work, and they will get fixed. Some of them will not, and generally those violations will then live on in the software. At this point, the only thing that those MUSTs in your specification are doing is giving people an excuse to lecture the author (and sometimes the users) of the software, and perhaps to feel smug when they do things that make it not work.
This gets stronger when you are talking about user visible behavior, because sooner or later people will disagree with you about the right thing to do (sometimes they will even be right in practice). At this point, all of these MUSTs are pointless, and should be SHOULDs all the way through.
(If you have a 'how things are presented to users' MUST that really is a MUST, for example because it's necessary to preserve security properties, you have a serious problem, because sooner or later that MUST will be violated.)
I don't particularly like this conclusion; in some ways I'm a fairly strong protocol purist (which makes me an asshole). But I think that it's inescapable in the real world, and certainly I think this is how it's played out repeatedly in practice with things like SMTP.
Note that I'm talking about, essentially, protocol specifications here, ones that involve multiple computer parties that actively interact with each other. ESMTP is a protocol specification, but HTML is not. I'm not sure what MUSTs in HTML-like specifications do in practice; possibly their only real use is making it so that people can't trivially claim compliance with your specification.
(All of this is similar to the IETF usage of MUST and SHOULD, but not quite the same. I think that the IETF would have people use MUST in places that I would wince, hold my nose, and suggest SHOULD.)