[Top] [All Lists]

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

2008-04-03 05:51:39

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 
 then the 
envelope recipient is 0123456789(_at_)sms(_dot_)example(_dot_)net and not 

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,


   is equivalent to


   is equivalent to


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 

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