[Top] [All Lists]

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

2008-04-18 14:59:48

Barry Leiba wrote:

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

Speaking as an individual contributor:

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.

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

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)?

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.

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?

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

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?

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:

  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.

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.

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.

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

   Sieve script (run on behalf of recipient(_at_)example(_dot_)org):

     require ["notify", "variables"];

     if header :contains "list-id" "" {
       if header :matches "Subject" "[*] *" {
         notify :message "From ${1} list: ${2}"
                :importance "3"

  Notification message:

     Received: from by
       for <recipient(_at_)example(_dot_)org>; Wed, 7 Dec 2005 05:08:02 -0500
     Received: from by
       for <knitting(_at_)example(_dot_)com>; Wed, 7 Dec 2005 02:00:26 -0800
     Date: Wed, 7 Dec 2005 05:08:55 -0500
     Message-ID: <A2299BB(_dot_)FF7788(_at_)example(_dot_)org>
     Auto-Submitted: sieve-notify; 
     From: recipient(_at_)example(_dot_)org
     To: 0123456789(_at_)sms(_dot_)example(_dot_)net
     To: backup(_at_)example(_dot_)com
     Subject: From Knitting list: A new sweater

Which reminded me of another question: should we describe how to handle 

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