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" "knitting.example.com" {
if header :matches "Subject" "[*] *" {
notify :message "From ${1} list: ${2}"
:importance "3"
"mailto:0123456789(_at_)sms(_dot_)example(_dot_)net?to=backup@example.com";
}
}
Notification message:
Received: from mail.example.com by mail.example.org
for <recipient(_at_)example(_dot_)org>; Wed, 7 Dec 2005 05:08:02 -0500
Received: from hobbies.example.com by mail.example.com
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;
owner-email="recipient(_at_)example(_dot_)org"
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
"?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.......