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