Re: [EAI] I-D Action: draft-ietf-eai-mailinglistbis-00.txt

[John C Klensin <[e-mail]>]

--On Sunday, November 27, 2011 02:11 +0100 Frank Ellermann
<[e-mail]> wrote:

> On 27 November 2011 01:22, "Martin J. Dürst" wrote:
>...
>>>   Note that discussion on whether internationalized domain
>>> names   should be percent-encoded or puny-coded, is
>>> ongoing; see<xref   target="I-D.duerst-iri-bis" />.
> 
>> Why not just point to RFC 3986, last two paragraphs of
>> section 3.2.2
>> (http://tools.ietf.org/html/rfc3986#section-3.2.2)?
> 
>> That's an Internet Standard rather than an "ongoing
>> discussion".
> 
> All those "<reg-name> outside of DNS" considerations in STD 66
> are IMO irrelevant for UTF8SMTPBIS addresses.

Largely concur, especially if the IRI efforts to retroactively
revise the URI spec are relevant.   From my personal point of
view, there are a relatively small number of possibilities here:

(1) RFC3986/STD66 is the controlling spec.  If so, it is
irrelevant to this WG: email addresses are not inherently URIs
and the WG's decision that encoded forms in other than UTF-8
--especially encoded forms that interact with the %-routing
convention-- makes RFC 3986's notion of
internationalization-by-%-encoding inappropriate.

(2) The IRI WG has determined that RFC 3986 has outlived its
usefulness (STD or not) and that IRIs are the new URIs -- a
direct-use (protocol element) form, not user-friendly
presentation of URIs.  Email addresses may _still_ be irrelevant
to IRIs and vice versa, but the other question then becomes
whether the right answer for URIng involves further tuning (or,
depending on one's point of view, piling onto) the IRI spec or
justifies some rethinking.  

If an email address is transmitted via an IRI form (e.g., in an
extended  MAILTO URL), the question of when the string stops
being an IRI (or IRI encoded in a URI) and starts being an email
address becomes pretty important.

>...
  If that's
> correct we end up with the last two sentences in RFC 3986
> 3.2.2:
> 
> | When a non-ASCII registered name represents an
> internationalized | domain name intended for resolution via
> the DNS, the name must be | transformed to the IDNA encoding
> [RFC3490] prior to name lookup. | URI producers should provide
> these registered names in the IDNA | encoding, rather than a
> percent-encoding, if they wish to maximize | interoperability
> with legacy URI resolvers.

> That is an ordinary MUST, and obviously the tool or party
> knowing how it works cannot delegate "punycoding" to another
> tool or party which might not know how it works.

Right.  However, the discussion in the recent IRI WG f2f about
the RFC 6055 implications of that statement take us back to the
question of whether 3986 is still relevant and, more important,
into a possible dilemma: Suppose one "tool or party" knows how
the IDNA encoding works but doesn't know whether the string will
be interpreted in a public DNS environment or so other
environment (one that does not use IDNA encoding).  So it can't
apply the IDNA encoding (especially the IDNA2003 one, which may
lose information) without risking considerable damage if the
string is interpreted and looked up in an non-public-DNS/IDNA
context.  Conversely, if the Unicode string is (as nearly as
possible) preserved until lookup time, the "tool or party" doing
the lookup might, given your implied hypothesis above, not know
how to apply the IDNA encoding.  RFC 6055 effectively argues for
preserving the Unicode form as long as possible, but that may
not always be the right answer (or "as long as possible" may
need careful interpretation) and, more important, %-encoded
UTF-8 is not "the Unicode form", especially since the email
sender or intermediary cannot know what the delivery server does
about normalization (once again, the "no one interprets an email
address (especially a local part) other than the delivery
server" rule comes into effect... and somewhat contradicts all
of the permitted and required transformations in the current and
proposed IRI specs).

For the purposes of this WG, I think we need to concentrate on
email addresses, not IRIs or URIs.  If mailto doesn't work in
the headers, let's figure out what, from an email point of view,
works and is needed and then work backwards to mailto (or
MAILTobis) and whatever _we_ need from URIbis or IRIbis, rather
than taking those specs as given or restrictive.

Just my personal opinion, of course.

    john