[Top] [All Lists]

Re: secdir review of draft-ietf-sieve-notify-mailto-07.txt

2008-03-26 10:28:58

Folks, Cyrus and I as chairs need more feedback on whether SHOULDs need to be changed to MUSTs. See my forwarded reply.

Alexey didn't forward my response to Hannes's review, so here's the relevant part of it:

On the SHOULD vs MUST list, Alexey has actually had the same questions. It's a clarification I've recently put in, because the text had said "is" (as in, "If the mailto URI contains a "body" header, the value of that header is used as the body of the notification message.")

I considered it this way: In cases where it seemed that it really matters -- that some sense of interoperability of notifications is affected -- I used MUST. Otherwise, I used SHOULD or MAY. In other words, I tried to avoid using MUST, where MUST wasn't necessary.

Alexey commented to me that it seemed to him that if there was no other reasonable choice, we ought to have MUST. On the other hand, it seems to me that if there's not a *reason* for MUST, we ought to leave the choice to the implementor (or to whoever configures the system, or whatever), rather than being needlessly specific about something that really doesn't matter.

I'm willing to change to MUST (obviously, I will if that's the WG consensus), but my strong sense is that it's wrong to prescribe behaviour that doesn't matter. For Sieve notifications, it seems to me that "interoperability" means that one can move a script to another Sieve implementation and get reasonably consistent results in the notifications, such that the user would have a substantially similar experience. My sense, there, is that what matters most is the subject of the message, so that's the only MUST (apart from Auto-Submitted, which has a functional purpose). The other part that's probably important is the body, but there are various reasons for an implementation to want to control the body -- security configuration, notification infrastructure, whatever. So that's a SHOULD.

In particular, I don't agree with Alexey's thought that if WE can't think of an alternative value for a field, our advice should be MUST. I much prefer the other approach: if there's not a compelling reason for MUST, make it SHOULD and let the implementation determine whether there's a good reason not to comply with that (remember the meaning of SHOULD).

I normally don't like SHOULD in protocols. This is a case where I think SHOULD is entirely appropriate.