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

From: Dave CROCKER <[email-masked]>
Date: Thu, 03 Dec 2009 14:46:40 -0800

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.

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

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

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?

>    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?

>    <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?

>    Implementations SHOULD NOT produce two "To:" header fields in a

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

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

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.

>    resolution.  The character '#' in hfvalues MUST be escaped as %23.

Why isn't this in 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.

> 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?

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

>    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

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

// 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...

>    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

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net