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

Barry Leiba wrote:

> > 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:
Mea culpa.

> --------------------------------------------------------
> 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.
Agreed.

> 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).
That make sense.

I would also add SMTP MAIL FROM to this category, as it is frequently 
used for Sieve filtering.
> 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.
Ok. I wish you added some text to the document stating that. This would 
remove any further questions why it is only a SHOULD.
I wasn't entirely clear of why you chose SHOULD in various places, so 
thanks for clarifying.
> 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 would slightly reword this: when using SHOULD one should have an 
example or at least gut feeling of when it can't be violated.
> 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).
It is a bit silly to argue this in general case. I would rephrase my 
objections based on the guiding principal you've specified above.
> I normally don't like SHOULD in protocols.  This is a case where I 
> think SHOULD is entirely appropriate.