While using SHOULD here might be fine, not describing valid reasons for
violating the SHOULD when they are known in advance is a very bad thing. I
always prefer documents that explain background/motivation.
...
I read this as allowing an implementation to ignore :message and/or the Subject
URI header unconditionally. Is this something we actually want to encourage? I
certainly wouldn't want to.
A much better approach is to at least explain what are valid reasons for
violating the SHOULD and optionally use MUSTs.
No, no, no, no!
Yes, if we know a reason why you might want to vary from what we recommend, it's
always a good idea to explain that. But that's a side issue, and it doesn't
really matter. The fact that we can't think of why you might want to... doesn't
mean that we should forbid it.
Second, using SHOULD is *not* "encouraging" contrary behaviour. Quite the
opposite: it's saying that if you don't have a damned good reason for doing
otherwise, this is the course you'd better take.
Suppose (I'm groping, here, but bear with me) someone implements Sieve
notifications and sells it to a hospital. And suppose the doctors use the
notifications and start complaining that they get notifications with subjects
like "Viagra Rx for Joe Jenkins", and they consider that a privacy problem
because they have to leave their pagers at the door when they go to the ballet,
and the ushers can see their notification messages. But the Sieve implementors
say, "But we have to do it that way because the notification spec says that we
MUST use the subject from the original message."
Don't pick at that -- it's just an example. The point is that we can't
anticipate all the issues that might arise. We can just say MUST when we're
defining something that will break interoperability if it's not followed, and
SHOULD or MAY otherwise. For most of these fields, there's NO GOOD REASON to use
MUST. There just isn't.
So we SHOULDN'T.
Barry