[EAI] [Fwd: AD review of draft-duerst-mailto-bis-06.txt]

[Alexey Melnikov <[e-mail]>]

I believe I completed the todo item assigned to me during the Stockholm 
meeting.

--- Begin Message ---

Hi,
The EAI WG tasked me to review this document, as it seems to be blocking 
some EAI drafts.

In Section 2:

      addr-spec   = local-part "@" domain
      local-part  = dot-atom / quoted-string

I don't think this change goes all the way to clarify that obsolete RFC 
5322 syntax and comments are disallowed.
RFC 5322:
   domain          =   dot-atom / domain-literal / obs-domain

   domain-literal  =   [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]

   dot-atom-text   =   1*atext *("." 1*atext)

   dot-atom        =   [CFWS] dot-atom-text [CFWS]

   atom            =   [CFWS] 1*atext [CFWS]

   obs-domain      =   atom *("." atom)

I think "obs-domain" and "domain-literal" definitions are problematic 
(at least).


   Within 'mailto' URIs, the characters "?", "=", and "&" are reserved.

"Reserved" in URI sense? If yes, I think this can be made clearer.

   4.  Percent-encoding can be used in the <domain> part of an <addr-
       spec>, in order to denote an internationalized domain name.  The
       considerations for <reg-name> in [STD66] apply.  In particular,
       non-ASCII characters must

s/must/MUST ?

       first be encoded according to UTF-8
       [STD63], and then each octet of the corresponding UTF-8 sequence
       must

s/must/MUST ?

       be percent-encoded to be represented as URI characters.  URI
       producing applications must not

s/must not/MUST NOT ?

       use percent-encoding in domain
       names unless it is used to represent a UTF-8 character sequence.
       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
       names in the IDNA encoding, rather than percent-encoded, if they
       wish to maximize interoperability with legacy 'mailto' URI
       interpreters.

As per IRI bar BOF in Stockholm: this needs to be aligned with any 
[potential] changes to the IRI spec.

   5.  Percent-encoding of non-ASCII octets in the <local-part> of an
       <addr-spec> is reserved for the internationalization of the
       <local-part>.  Non-ASCII characters must

s/must/MUST ?

       first be encoded
       according to UTF-8 [STD63], and then each octet of the
       corresponding UTF-8 sequence must

s/must/MUST ?

       be percent-encoded to be
       represented as URI characters.  Any other percent-encoding of
       non-ASCII characters is prohibited.  When a <local-part>
       containing non-ASCII characters will be used to compose a
       message, the <local-part> must

s/must/MUST ?

       be transformed to conform to
       whatever encoding may be defined in a future specification for
       the internationalization of email addresses.

 [...]

   Non-ASCII characters can be encoded in hfvalue as follows:
 [...]

   2.  Non-ASCII characters can be encoded according to UTF-8 [STD63],
       and then each octet of the corresponding UTF-8 sequence is
       percent-encoded to be represented as URI characters.  When header
       field values encoded in this way are used to compose a message,
       the <hfvalue> must

s/must/MUST ?

       be transformed into MIME encoded words
       [RFC2047], except for an <hfvalue> of a "body" <hfname>, which
       has to be encoded according to [RFC2045].  Please note that for
       MIME encoded words and for bodies in composed email messages,
       encodings other than UTF-8 MAY be used as long as the characters
       are properly transcoded.

 [...]

   MIME encoded words and UTF-8-based percent-encoding SHOULD NOT both
   be used sequentially in the same <hfvalue>, and MUST NOT be combined.

Can you clarify what you are trying to say here?
In particular I am not clear on the meaning of "sequentially" here.

In Section 3:

   In current practice, resolving URIs such as those in the 'http' URI
   scheme causes an immediate interaction between client software and a
   host running an interactive server.  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 unedited, or choose not to send
   the message.  The operation of how any URI scheme is resolved is not
   mandated by the URI specifications.

The last sentence doesn't seem to be related to the rest of the 
paragraph. Should it be deleted or moved to a separate paragraph?


In Section 4:

   The creator of a 'mailto' URI cannot expect the resolver of a URI to
   understand more than the "subject" header field and "body".

What about the "To" header field?

   Clients
   that resolve 'mailto' URIs into mail messages MUST be able to
   correctly create [RFC5322]-compliant mail messages using the
   "subject" header field and "body".

In Section 8:

   A 'mailto' URI gives a template for a message that can be sent by
   mail client software.  The contents of that template may be opaque or
   difficult to read by the user at the time of specifying the URI.
   Thus, a mail client should never send a message based on a 'mailto'

s/should/SHOULD ?

   URI without first showing the full message that will be sent to the
   user (including all header fields that were specified by the 'mailto'
   URI), fully decoded, and asking the user for approval to send the
   message as electronic mail.  The mail client should also make it

s/should/SHOULD

   clear that the user is about to send an electronic mail message,
   since the user may not be aware that this is the result of a 'mailto'
   URI.

   A mail client should never send anything without complete disclosure

s/should/SHOULD

   to the user of what will be sent; it should disclose not only the

s/should/SHOULD

   message destination, but also any header fields.  Unrecognized header
   fields, or header fields with values inconsistent with those the mail
   client would normally send should be especially suspect.  MIME header
   fields (MIME- Version, Content-*) are most likely inappropriate,
   except when added by the MUA to correctly encode the text(s) being
   sent, as are those relating to routing (From, Apparently-To, etc.)


9.  IANA Considerations

   This document changes the definition of the 'mailto' URI scheme; the
   registry of URI schemes needs to be updated to refer to this document
   rather than its predecessor, [RFC2368].

It doesn't look like the proper URI registration template was ever 
specified in this document or its predecessor.

--- End Message ---