Subject: Re: [APPS-REVIEW] Request for reviews of draft-duerst-mailto-bis-07.txt

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 08 Mar 2010 16:29:35 +0900

Hello Eliot, others,

Sorry for being so late with this reply.

On 2009/11/30 22:08, Eliot Lear wrote:
> Alexey,
>
> You asked for a review of draft-duerst-mailto-bis-07.txt. I'm taking a
> few moments to comment, but I don't have time for a full review, as your
> document is in front of it ;-)
>
> Overall my only real question is this (not even a concern at this point):
>
> Apart from Bcc, is this change opaque to legacy implementations? It
> seems so, but perhaps I'm not thinking right.

No, it's not. Up to now, only a very restricted subset of US-ASCII 
characters was allowed e.g. in body=...; this has been extended to allow 
percent-encoding and therefore the wide range of Unicode characters. 
Many newer browsers for example already support this, but of course 
there will be old legacy that doesn't support it.

> Nits?:
>
>
> In Section 2, there's a lot of non-normative language that should be
> normative, IMHO. For example:
>
>> 1. A number of characters that can appear in <addr-spec> have to be
>> percent-encoded.
>
> s/have to/MUST/

Done.

> Similarly:
>
>> 2. <obs-local-part> and <NO-WS-CTL> as defined in [RFC5322] are not
>> allowed.
>
> s/are not allowed/MUST NOT be used/.

Done.

> And of course directly below it:
>
>> 3. Whitespace and comments within <local-part> and <domain> are not
>> allowed.
> s/are not allowed/MUST NOT be used/.

Done.

> Martin wrote:
>
>>
>>> Implementations SHOULD NOT produce two "To:" header fields in a
>>> message; the "To:" header field may occur at most once in a message
>>> ([RFC5322], Section 3.6). Also, creators of 'mailto' URIs SHOULD NOT
>>> include other message header fields multiple times if these header
>>> fields can only be used once in a message.
>>>
>>>
>> Any reasons why these SHOULD NOTs are not MUST NOTs?
>>
>> Not being a mail expert, I have no experience on what goes wrong if
>> these restrictions are not met. If you think a MUST is more
>> appropriate, that's fine with me.
>
> IMHO MUST is appropriate. That table is meant to be normative. The usual
> rule "be conservative.. be liberal.." also implies this should be a
> MUST, and I can tell you that spam catching software will prefer
> conservative.

Done.

Regards,    Martin.

> Eliot
> _______________________________________________
> APPS-REVIEW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-review
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 08 Mar 2010 17:27:29 +0900

Hello Dave,

Sorry for being so late to reply to your comments.

On 2009/12/04 7:46, Dave CROCKER wrote:
>
>
> As with Eliot, I'm only claiming a single scan:
>
>
>> This specification does not address the needs of the ongoing Email
>> Address Internationalization effort (see [RFC4952]). In particular,
>
> I am usually a vigorous opponent of references to future work, except in
> the
> most bland and generic fashion, given that the future is entirely
> unknowable and
> almost always develops differently than we expect. This spec seems to be an
> exception, probably because there is such massive of the massive, global
> interest in the enhancements and especially because there is an RFC to
> cite.

On top of that, please note that this 'future work' is referenced with a 
negative connotation.

>> This may be fixed in a future version of this specification.
> ->
> This could be fixed in a future version of this specification.
>
> Particularly given that the next paragraph reserves 'may' to be
> normative...
>
> But in fact, the sentence should be removed. Anything can happen in the
> future. Something might be fixed and it might not. The sentence
> therefore provides no information.

Done.

>
>> to = [ addr-spec *("%2C" addr-spec ) ]
>
> I believe the quotation marks should be removed. If, instead, this is an
> example of characters that must be percent-encoded /in the mailto spec/
> then it's confusing not to see comma mentioned in Note 1, below this.

Very good catch. I think in parallel with 
http://tools.ietf.org/html/rfc5322#section-3.6.3, it should be
     to = [ addr-spec *("," addr-spec ) ]
That would also simplify two examples. RFC 2368 said that all 
URI-reserved characters have to be escaped, which included the comma, 
but at least since RFC 3986, the idea is that escaping is only needed 
for URI characters in a 'payload' role where the same character can have 
a syntactic function. As we don't use the comma, we don't need to escape 
it, although it still can be escaped.

> Note 4:
>> When the internationalized domain name is used to compose a
>> message, the name MUST be transformed to the IDNA encoding where
>> appropriate [RFC3490]. URI producers SHOULD provide these domain
>
> How is the reader supposed to know "where appropriate" applies?

By reading RFC 3490.

>> Within 'mailto' URIs, the characters "?", "=", and "&" are reserved,
>> serving as delimiters. They have to be escaped (as "%3F", "%3D", and
>> "%26", respectively) when not serving as delimiters.
>
> Why isn't this reflected in the ANBF for mailto?

To avoid copying more and more of RFC 5322 over to this document.

>> <mailto:[email-masked][email-masked]>
>> is equivalent to
>> <mailto:?to=[email-masked][email-masked]>
>> is equivalent to
>> <mailto:[email-masked]?to=[email-masked]>
>> However, the latter form is NOT RECOMMENDED.
>
> Why isn't "to=" simply prohibited, so that there is one, fixed way to do
> addressing?

Because "to=" was allowed already in RFC 2368, and we can't simply 
disallow it.

> This provides a nice example of the reason "to=" should be disallowed.

The SHOULD NOT above was changed to a MUST NOT. Unfortunately, I don't 
think we can do much more at this point.

>> Creators of 'mailto' URIs SHOULD avoid using the same <hfname>
>> multiple times in the same URI to avoid interoperability problems.
>> If the same <hfname> appears multiple times in an URI, behavior
>> varies widely for different user agents, and for each <hfname>.
>> Examples include only using the first or last <hfname>/<hfvalue>
>> pair, combining each <hfvalue> by simple concatenation, or in a way
>> appropriate for the corresponding header field, or creating multiple
>> header fields.
>
> At a minimum, "SHOULD avoid using" -> "SHOULD NOT use", to make the
> language match the usual RFC specification form.

Done.

> More substantively, why not simply prohibit multiple, identical hfnames?
> Interoperability is about simplicity, which is largely the message of
> this text in the document, except that it does not them follow through
> on the point.

That might have been a valid choice earlier in the drafting process.

>> resolution. The character '#' in hfvalues MUST be escaped as %23.
>
> Why isn't this in the ABNF?

It is mentioned immediately below the ABNF.

>> A 'mailto' URI designates an "internet resource", which is the
>> mailbox specified in the address. When additional header fields are
>> supplied, the resource designated is the same address, but with an
>> additional profile for accessing the resource.
>
> I found this confusing. I think it is trying to say:
>
> A 'mailto' that consists only of an address refers to the mailbox
> associated with that address. A 'mailto' that consists of an address and
> additional header fields specifies a message that is to be sent to the
> references mailbox.
>
> At the least, I don't know what "an additional profile for accessing the
> resource" means.

This is more or less philosophic text that has been argued about quite a 
bit. I don't want to change it at this stage in the process.

>> While there are
>> Internet resources that can only be accessed via electronic mail, the
>> 'mailto' URI is not intended as a way of retrieving such objects
>> automatically.
>
>
> Retrieving??? mailto isn't for retrieving, is it?

That's exactly that the text above says ("is not intended").

>> The 'mailto' URI has unusual semantics because resolving such a URI
>> does not cause an immediate interaction. Instead, the client creates
>> a message to the designated address with the various header fields
>> set as default. The user can edit the message, send this message
>>
>
> "creates a message" sounds like interaction to me. (and of course, it
> isn't the user creating the message, it's an MUA or pre-MUA agent
> working on the user's behalf, when they click the mailto...

You have to read this in context. The paragraph starts talking about 
interaction between clients and servers, and then says that mailto: 
doesn't produce such an interaction immediately. I added "with a server" 
to make it easier to read.

>> The user agent interpreting a 'mailto' URI SHOULD choose not to
>> create a message if any of the header fields are considered
>
>
> SHOULD choose not to create -> SHOULD NOT create

Done.

>> The creator of a 'mailto' URI cannot expect the resolver of a URI to
>> understand more than the "subject" header field and "body".
>
> -> Creators and resolvers of a 'mailto' URI MUST support correct process
> of "subject" and "body" hfnames (and their hfields.)

It says so later in the same paragraph: "Clients that
    resolve 'mailto' URIs into mail messages MUST be able to correctly
    create <xref target="RFC5322"/>-compliant mail messages using the
    "subject" header field and "body"."
(for resolvers, not for creators, because creators in my view do not 
process).

> They MAY support
> additional hfnames.
>
> I suspect this paragraph belongs earlier in the document. I understand
> the safety motivation for placing it here, but the normative impact is
> much more basic.

Putting it earlier would be a possibility indeed. But then this section 
would look way too short.

> // sorry, but i skipped the examples, due to time limits /d //
>
>
>> Programs that interpret 'mailto' URIs SHOULD ensure that the SMTP
>> "From" address (the SMTP envelope return path given as an argument to
>
> "From" -> "Mail From"
>
> although it might be simpler to have the sentence say:
>
> ... ensure that the SMTP envelope return path address, that is given as an
> argument to the SMTP MAIL FROM command)...
>
> This avoid any possibility of confusing the reference with an actual
> From: address...

Done (with "that is given" -> "which is given").

>
>> harvesting. This applies to all mail addresses included in the
>
> included in the -> that are part of the
>
> to avoid the 'include' twice in the same sentence

fixed.

Regards,    Martin.