Subject: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]

From: Alexey Melnikov <[email-masked]>
Date: Wed, 26 Mar 2008 13:07:38 +0000

Subject: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt
From: Alexey Melnikov <[email-masked]>
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked], [email-masked], Cyrus Daboo <[email-masked]>, Lisa Dusseault <[email-masked]>
Date: Wed, 26 Mar 2008 13:04:19 +0000

Hi Hannes,
Below are my opinions as a Sieve WG participant and not as the Sieve WG 
chair:

Hannes Tschofenig wrote:
 [...]

>   o  The "To:" header field and the envelope recipient(s) of the
>      notification message SHOULD be set to the address(es) specified in
>      the URI (including any URI headers where the hname is "to").
>
>This could be a MUST as well. Otherwise you might want to say to what it is set in other cases. 
>  
>
Indeed.

>   o  The "Subject:" field of the notification message MUST contain the
>      value defined by the :message notify tag, as described in
>      [Notify].  If there is no :message tag and there is a "subject"
>      header on the URI, then that value SHOULD be used.  If that is
>      also absent, the subject SHOULD be retained from the triggering
>      message.  Note that Sieve [Variables] can be used to advantage
>      here, as shown in the example in Section 3.
>
>
>Shouldn't the last SHOULD be a MUST? There do not seem to be too many other useful choices. 
>
Agreed. The only other choice I can think of is an implementation 
defined string. I am not sure it is a good choice, but if it is, it 
should be explicitly listed.

Actually I think that both SHOULDs should be MUSTs.
I am just imagining a support person trying to argue with a customer 
about why a particular notification email had wrong subject, when the 
"subject" URI header was specified.

>   o  The "From:" header field of the notification message SHOULD be set
>      to the value of the ":from" parameter to the notify action, if one
>      is specified, has email address syntax and is valid according to
>      the implementation specific security checks (see Section 3.3 of
>      [Notify]).  If ":from" is not specified or is not valid, the
>      "From:" header field of the notification message SHOULD be set
>      either to the envelope "to" field from the triggering message, as
>      used by Sieve, or to a fixed email address (so it "comes from the
>      notification system"), at the discretion of the implementation.
>      This may not be overridden by a "from" URI header, and any such
>      URI header MUST be ignored.
>
>   o  If the envelope sender of the triggering message is empty, the
>      envelope sender of the notification message MUST be empty as well,
>      to avoid message loops.  Otherwise, the envelope sender of the
>      notification message SHOULD be set to the value of the ":from"
>      parameter to the notify action, if one is specified, has email
>      address syntax and is valid according to the implementation
>      specific security checks (see Section 3.3 of [Notify]).  If
>      ":from" is not specified or is not valid, the envelope sender of
>      the notification message SHOULD be set either to the envelope "to"
>      field from the triggering message, as used by Sieve, or to a fixed
>      email address (so it "comes from the notification system"), at the
>      discretion of the implementation.  This may not be overridden by a
>      "from" URI header, and any such URI header MUST be ignored.
>
>
>For these two paragraphs the same question applies; why a SHOULD instead of a MUST
>
I also think the SHOULDs should be MUSTs here.

I think  "address ... is valid according to the implementation specific 
security checks" already provides enough leeway to implementations if 
they want not to use a particular :from value.

The part that reads:

      If ":from" is not specified or is not valid, the envelope sender of
      the notification message SHOULD be set either to the envelope "to"
      field from the triggering message, as used by Sieve, or to a fixed
      email address (so it "comes from the notification system"), at the
      discretion of the implementation.

already list all possible alternatives, so I don't think it is a SHOULD 
either.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 26 Mar 2008 16:02:48 +0000

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

Alexey Melnikov wrote:

> Subject:
> Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt
> From:
> Alexey Melnikov <[email-masked]>
> Date:
> To:
> Hannes Tschofenig <[email-masked]>
>
> To:
> Hannes Tschofenig <[email-masked]>
> CC:
> [email-masked], [email-masked], Cyrus Daboo 
> <[email-masked]>, Lisa Dusseault <[email-masked]>
>
>
> Hi Hannes,
> Below are my opinions as a Sieve WG participant and not as the Sieve 
> WG chair:
>
> Hannes Tschofenig wrote:
> [...]
>
> I think  "address ... is valid according to the implementation 
> specific security checks" already provides enough leeway to 
> implementations if they want not to use a particular :from value.
>
> The part that reads:
>
> already list all possible alternatives, so I don't think it is a 
> SHOULD either.
>

---

From: Barry Leiba <[email-masked]>
Date: Wed, 26 Mar 2008 13:13:33 -0400

> 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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 26 Mar 2008 13:32:19 -0400

--On Wednesday, March 26, 2008 01:13:33 PM -0400 Barry Leiba 
<[email-masked]> wrote:

> 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 agree with Barry here.  This is exactly what SHOULD is for.

-- Jeff

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 26 Mar 2008 18:31:54 +0100

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

I don't mind making these MUST.

Except that I do just a little, but I'd wiggle even in case of MUST. 
Details below.

>>>   o  The "Subject:" field of the notification message MUST
...

If I were to implement notify-mailto, my code might use different RFC 
2047 encoding. If the original subject is invalid in some way I 
wouldn't respond in kind.

>> The part that reads:
>>
>>      If ":from" is not specified or is not valid, the envelope sender 
>>      of the notification message SHOULD be set either to the 
>>      envelope "to" field from the triggering message, as used by 
>>      Sieve, or to a fixed email address (so it "comes from the 

Those aren't all possible alternatives, so although I don't mind MUST I 
rather like keeping SHOULD. (One other alternative is a system address 
with a single-use subaddress.)

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 26 Mar 2008 23:15:26 +0100

> I don't mind making these MUST.

I guess I really mean "I don't mind, but I don't really see the point 
and SHOULD seems strong enough". Quoting 2119:

    ... there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.

Arnt