ietf-mta-filters
[Top] [All Lists]

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

2008-04-18 14:14:21

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