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