Subject: Comments on draft-ietf-sieve-notify-mailto-07.txt

From: Alexey Melnikov <[email-masked]>
Date: Thu, 03 Apr 2008 11:19:41 +0100

Hi Barry,
Let me try to rephrase my personal objections regarding some specific cases of using SHOULD in the latest draft.

In section 2.7:

   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").

I think there is a problem with this text. Surely the envelope recipient 
is specified in the mailto URI itself, not in the to URI header. (Your 
example in section 3 confirms that.) For example if mailto URI is 
"mailto:[email-masked]?to=[email-masked]", then the 
envelope recipient is [email-masked] and not 
[email-masked].

I think the text is also trying to say that both To: header and envelope 
to should be set to the same value.

So, I suggest the paragraph is split into 2 paragraphs to separately 
specify requirements on To: and envelope recipient.

   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.

I think this SHOULD should be upgraded to a MUST. Reason: I can see use 
cases when :message is never used and Subject is specified in the mailto 
URI itself. So I think

Also, Arnt has raised a good question about whether implementations are 
allowed to strip/alter garbage in :message or subject URI header. I 
think this should be addressed as well.

I also have a new question. It might be a stupid one, but I will ask it 
anyway ;-). How References should be handled? Is the new message allowed 
to reference the original message? Are References: allowed as mailto URI 
headers?

**

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 3 Apr 2008 14:00:54 +0200

Alexey Melnikov writes:
> Also, Arnt has raised a good question about whether implementations 
> are allowed to strip/alter garbage in :message or subject URI header. 
> I think this should be addressed as well.

This text from 2119 describes what we want perfectly, IMO: "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

---

From: Michael Haardt <[email-masked]>
Date: Thu, 03 Apr 2008 14:41:06 +0200

> to should be set to the same value.

To me, the text is correct.  From draft-duerst-mailto-bis-05, section 2.:

   Also note that it is legal to specify both <to> and an <hfname> whose
   value is "to".  That is,

   <mailto:[email-masked][email-masked]>

   is equivalent to

   <mailto:?to=[email-masked][email-masked]>

   is equivalent to

   <mailto:[email-masked]?to=[email-masked]>

The text asks for both header and envelope recipients to be set to
the recipients specified in the URI, and reminds the reader that
URIs may contain recipients as URI headers, too.

> think this should be addressed as well.

I agree on the MUST, because I can't think of reasons not to use the
specified subject.  Concerning garbage: Broken MIME words are not garbage
- they aren't MIME words, but ASCII data.  MIME words that contain odd
characters are not garbage, either.

I don't see what could be a valid URI subject header, but not a valid
mail subject header.  If there is something like that, the mailto URI
draft should be changed.  Or MUST, for that matter. ;)

> to reference the original message? Are References: allowed as mailto URI 

That's two independent questions.  First the easy one, on URI references
headers.  Could additional references hurt? I don't see why.  Say,
I send someone a mail, and later notifications on triggering messages
that refer to this mail - that may actually be useful, as they build
a nice thread below the first mail.  We should allow that.  Should the
triggering message set "In-reply-to:", thus ignoring an URI header of
the same name? To me, it's not a reply, it is a notification.

Not as easy: Should notifications, and that's a general question
beyond the scope of mail, reference to the triggering message, if
the notification method allows to give references? That's an issue of
draft-ietf-sieve-notify, and a good one.  I like the idea.

Ask more questions like that, and nobody will even think of a last call
on notify for quite some time. ;-)

Michael

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 03 Apr 2008 13:51:33 +0100

> weighed before choosing a different course."

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.

Also, image that we update the text to read:

   o  The "Subject:" field of the notification message SHOULD 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.

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.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 03 Apr 2008 09:16:58 -0400

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

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

---

From: Barry Leiba <[email-masked]>
Date: Thu, 03 Apr 2008 09:20:51 -0400

I also have a more general question here:
How did this (actually, the -06 version) manage to get to the IESG, and into IETF 
Last Call?  I had no idea you were sending it yet, since we'd talked about the 
-07 revision, and we clearly don't have WG consensus on it.  And things that I 
*did* think we had WG consensus are being revisited.

We need to pull it back from the IESG, (re)establish WG consensus (and explain 
why the PROTO writeup was wrong), and then send it back for a fresh IETF Last 
Call.

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 03 Apr 2008 14:36:31 +0100

Barry Leiba wrote:

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

Actually, it is the only thing that matters to me in this case.
I can live with either SHOULD or MUST, but now that I know about Arnt's 
issue, I can't live without its description ;-).

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

Well, if I see SHOULD in the spec *and* there is no explanation why 
SHOULD is there and it is very difficult for my implementation to 
conform to the SHOULD, then I don't feel bad about violating it.

But anyway, let's stop discussing this. It is not that important. And if 
you turn out to be wrong in the future, then I will point this out ;-).

---

From: Michael Haardt <[email-masked]>
Date: Thu, 03 Apr 2008 15:54:50 +0200

> mean that we should forbid it.

I guess the whole question is: Is it important to us to keep the
subject in case no other subject has been specified?

> notifications and sells it to a hospital.
> [privacy issue with passing subjects]

If privacy matters, then don't pass subjects to pagers.

Arnt pointed out that clients may be buggy.  And we all know, some have
a security problem with malware attachments.  If that means an RFC is
well advised to say you SHOULD NOT alter the content in transport, we
SHOULD keep the subject.  If the RFC is fine to ask you MUST NOT alter it,
knowing some sites do nevertheless to let their broken clients be safe,
we can do as well.

Perhaps this analogy helps to decide.

Michael

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 03 Apr 2008 15:00:50 +0100

(Speaking as the document shepherd.)

Barry Leiba wrote:

> How did this (actually, the -06 version) manage to get to the IESG, 
> and into IETF Last Call?  I had no idea you were sending it yet, since 
> we'd talked about the -07 revision, and we clearly don't have WG 
> consensus on it.

Version -06 was accidentally sent to IETF LC, due to a wrong draft state 
in the ID tracker. Oh well.

> And things that I *did* think we had WG consensus are being revisited.

I didn't expect this either.

> We need to pull it back from the IESG, (re)establish WG consensus (and 
> explain why the PROTO writeup was wrong), and then send it back for a 
> fresh IETF Last Call.

I am not entirely sure that we need another IETF LC, but let's make this 
decision when the dust settles and the WG agrees on all changes.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 03 Apr 2008 17:22:17 +0100

>   <mailto:[email-masked]?to=[email-masked]>
Ok. I should have checked this myself.

I think it would be helpful if you/Barry add a clarifying example to 
demonstrate this.

>- they aren't MIME words, but ASCII data.
>
Correct.

>MIME words that contain odd
I was thinking about embedded NULs, CRs and LFs.

>a nice thread below the first mail.  We should allow that.
>
Exactly my thought.

>Should the triggering message set "In-reply-to:", thus ignoring an URI header of
Agreed.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 03 Apr 2008 15:50:49 -0400

--On Thursday, April 03, 2008 09:16:58 AM -0400 Barry Leiba 
<[email-masked]> wrote:

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

Again, this is exactly right.  SHOULD is much stronger than people give it 
credit for, and MUST is properly used very sparingly.  If breaking a 
requirement would cause problems with interoperability, security, 
correctness, uncontrolled congestion on the Internet, etc, then MUST is 
appropriate.  Otherwise, it really is not.

-- Jeff

---

From: Barry Leiba <[email-masked]>
Date: Fri, 18 Apr 2008 17:04:26 -0400

OK, I'm wrapping things up with mailto-07, preparing mailto-08.

Here are the issues that I have to resolve:

1. There was a problem with the IANA Considerations subsection 2, which 
I've fixed.  No WG action needed here.

2. Do we have a decision about copying Received lines?  I think we've 
reversed ourselves, and no longer want to copy them from the original 
message.  Does that mean:
a. ...the spec should be changed from MAY copy to SHOULD NOT copy or 
MUST NOT copy?  If so, which?
b. ...the spec can remain as it is, with MAY (not SHOULD nor MUST)?
c. ...the spec should say that you can do anything you please?

3. What did we decide for the value on the Auto-Submitted header?  I 
still have it as "Sieve-Notify".  Do we want to change it to 
"Auto-Notification"?  Something else?

4. We currently say MUST NOT notify if an Auto-Submitted header field 
exists (apart from "no").  We had an inconclusive thread going with a 
suggestion to change that.  What's the consensus?  If we're to change 
it, what should we change it to, given that it's critical to our 
loop-prevention story?

5. It seems that we're OK with most of the header handling being SHOULD, 
but we still have to nail down the Subject header.  Note that the text 
that's there, which says MUST for the first bit and SHOULD for the rest 
allows implementations to alter text from user-generated subjects, in 
case they might be problematic.  That's intentional, and if we change to 
MUST there, we have to make exceptions.  Also, the part that says it 
SHOULD fall back to what's in the triggering message is also 
intentional: there are applications where the message subject is 
considered secret, and the implementation will know that it should never 
include it.  We don't want a MUST there.

6. Alexey gummed things up (SLAP!) by bringing up the References header. 
  I don't see a decision on that, so I'll wait for one.

7. Alexey thinks we should have an example that shows more complex use 
of URI headers, in particular one that combines a mailto address with a 
to= URI header.  I see no reason to do that.  Does anyone else think 
it's useful to add such an example?  If so, that person should write one 
and post it here.

I don't have to wait for ALL of these to be resolved before I post -08, 
but I'd like to get at least a few of them resolved first.  So I await 
the WG's swift action.......

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 18 Apr 2008 22:49:22 +0100

Speaking as an individual contributor:

> 1. There was a problem with the IANA Considerations subsection 2, 
> which I've fixed.  No WG action needed here.

Good. But can you tell the WG what has changed?

> b. ...the spec can remain as it is, with MAY (not SHOULD nor MUST)?

I don't care if the specification does a) or b), however it needs to be 
updated in other places to make sure it doesn't mislead the reader that 
copying Received headers is the loop prevention mechanism.
In the case a). the example in section 3 must also be updated not to 
show Received headers copied from the original message.

> "Auto-Notification"?  Something else?

I prefer Auto-Notification, but I don't have a strong opinion.

> it, what should we change it to, given that it's critical to our 

I am weakly in favor of keeping the current logic. I find your argument 
about using redirect in this case to be convincing.

> 5. It seems that we're OK with most of the header handling being 
> SHOULD, but we still have to nail down the Subject header.  Note that 
> the text that's there, which says MUST for the first bit and SHOULD 
> for the rest allows implementations to alter text from user-generated 
> subjects, in case they might be problematic.  That's intentional, and 
> if we change to MUST there, we have to make exceptions.  Also, the 
> part that says it SHOULD fall back to what's in the triggering message 
> is also intentional: there are applications where the message subject 
> is considered secret, and the implementation will know that it should 
> never include it.  We don't want a MUST there.

You lost me here. The text in question is:

According to what you are saying, the first MUST must be changed to 
SHOULD, because it is "user-generated subject". I don't care that much 
about SHOULD versa MUST, but I do care that the first and the second 
SHOULD/MUST are the same, as, IMHO, they are just 2 different forms of 
the same thing.

> 6. Alexey gummed things up (SLAP!) by bringing up the References 
> header.  I don't see a decision on that, so I'll wait for one.

Ok, I can try to think about some suggested text, but don't wait for it 
before posting -08.

> of URI headers, in particular one that combines a mailto address with 
> a to= URI header.  I see no reason to do that.  Does anyone else think 
> it's useful to add such an example?  If so, that person should write 
> one and post it here.

Here (replace 2/3rds of the existing example in section 3):

    Sieve script (run on behalf of [email-masked]):

      require ["notify", "variables"];

      if header :contains "list-id" "knitting.example.com" {
        if header :matches "Subject" "[*] *" {
          notify :message "From ${1} list: ${2}"
                 :importance "3"
                 "mailto:[email-masked]?to=[email-masked]";
        }
      }

   Notification message:

      Received: from mail.example.com by mail.example.org
        for <[email-masked]>; Wed, 7 Dec 2005 05:08:02 -0500
      Received: from hobbies.example.com by mail.example.com
        for <[email-masked]>; Wed, 7 Dec 2005 02:00:26 -0800
      Date: Wed, 7 Dec 2005 05:08:55 -0500
      Message-ID: <[email-masked]>
      Auto-Submitted: sieve-notify; owner-email="[email-masked]"
      From: [email-masked]
      To: [email-masked]
      To: [email-masked]
      Subject: From Knitting list: A new sweater

Which reminded me of another question: should we describe how to handle "?cc=..."?

> I don't have to wait for ALL of these to be resolved before I post 
> -08, but I'd like to get at least a few of them resolved first.  So I 
> await the WG's swift action.......

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Sun, 20 Apr 2008 02:03:43 +0200

> > b. ...the spec can remain as it is, with MAY (not SHOULD nor MUST)?

Mark's example of wanting to receive notification about automatically
generated alarms makes me wonder if we shouldn't use Received as the
loop prevention mechanism after all.  it's definitely the safest method
of prevention.  the risk is that users will run into hop count limits,
but I think most messages should be well clear of that.

> about using redirect in this case to be convincing.

yes, but even if the Right Thing is to use redirect, it's quite likely
that a non-trivial amount of people will use notify instead.

>       Subject: From Knitting list: A new sweater

note, multiple To-headers is not allowed by 2822.

-- 
Kjetil T.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 20 Apr 2008 11:32:27 +0200

> that a non-trivial amount of people will use notify instead.

There is always the option of sprinking magic DWIM powder over notify-mailto...

     If the message being notified about has an Auto-Submitted
     field, the sieve SHOULD execute a redirect action instead of
     the notify action.

People who write good user interfaces are used to doing such things, but 
I'm not so sure it's a good idea in a specification like this.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 20 Apr 2008 22:42:39 +0100

>note, multiple To-headers is not allowed by 2822.
Fine :-). Make it:

      To: [email-masked], [email-masked]

---

From: Michael Haardt <[email-masked]>
Date: Tue, 22 Apr 2008 10:08:25 +0200

> c. ...the spec should say that you can do anything you please?

By now, I suggest not to say anything about "Received:" at all and I am
sorry about having had that idea in the beginning.  The notification
message simply did not originate at the described path at the given
time, and spam filters could drop it for forged headers.

> "Auto-Notification"?  Something else?

I suggest "auto-notified", like "auto-generated" and "auto-replied".

Michael

---

From: Michael Haardt <[email-masked]>
Date: Tue, 22 Apr 2008 10:29:16 +0200

> about using redirect in this case to be convincing.

I like the current logic, too.  It is possible to write a Sieve rule that
redirects messages with "Auto-Submitted:" (not containing "no"), should
that really be desired.  Should anybody suggest to to do automatically,
please add an option to disable that behaviour in your suggestion.

> Which reminded me of another question: should we describe how to handle "?cc=..."?

Yes. I suggest to add this right after the section about the envelope
sender:

  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" or "cc")

Additionally, change:

  The "To:" header field SHOULD be set to the address(es) specified in
  the URI (including any URI headers where the hname is "to").

Michael

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 23 Apr 2008 09:32:26 +0100

Michael Haardt wrote:

>that really be desired.  Should anybody suggest to do so automatically,
I was thinking about this as well.

>  the URI (including any URI headers where the hname is "to").
I like that.