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:0123456789(_at_)sms(_dot_)example(_dot_)net?to=evil@master.example.com",
then the
envelope recipient is 0123456789(_at_)sms(_dot_)example(_dot_)net and not
evil(_at_)master(_dot_)example(_dot_)com(_dot_)
I think the text is also trying to say that both To: header and envelope
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:addr1(_at_)an(_dot_)example%2C%20addr2@an.example>
is equivalent to
<mailto:?to=addr1(_at_)an(_dot_)example%2C%20addr2@an.example>
is equivalent to
<mailto:addr1(_at_)an(_dot_)example?to=addr2@an.example>
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.
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 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. ;)
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?
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