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

["Martin J. Dürst" <[e-mail]>]

On 2011/11/28 1:04, John C Klensin wrote:
> --On Sunday, November 27, 2011 02:11 +0100 Frank Ellermann
> <[e-mail]>  wrote:

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

The IRI WG currently doesn't have such a mandate. The IRI WG charter 
clearly says (see http://datatracker.ietf.org/wg/iri/charter/)

Changes to RFC 3986 ("Uniform Resource Identifier (URI):
Generic Syntax") are explicitly out of scope of this charter,
and may only be considered with a charter update.


> 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

Of course email addresses are not URIs. Domain names are not URIs. Path 
names or file names are not URIs. Query parameters in some requests are 
not URIs. Almost none of the parts of an URI, or the things from which 
URIs are constructed, are by itself URIs.

> and the WG's

Which WG?

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

There is no "internationalization by %-encoding". %-encoding is an 
escaping convention for URIs. With some care, it can be used for 
escaping characters, rather than octets.

Also, it seems that some people are proposing to use %-encoding for mail 
addresses (outside URIs/IRIs, that is). That would definitely be a very 
bad idea. Please stop.


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

It's not a question of which is better, RFC 3986 (URIs) or RFC 3987 
(IRIs). There are some places where only URIs are allowed, e.g. in a 
HTTP GET header. There are some places where (modulo some nasty 
details), IRIs are allowed (HTML, XML,...). Both URIs and IRIs in these 
cases are protocol elements.


> Email addresses may _still_ be irrelevant
> to IRIs and vice versa, but the other question then becomes
> whether the right answer for URIng

By this, you mean putting an email address into an URI, yes?

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

Of course. The same question was and is important when a traditional 
email address is used in a plain old URI mailto:.

And in most cases, it should be pretty easy to answer this question. For 
example, <a href='mailto:[e-mail]'> is obviously an 
URI/IRI. When somebody activates that link, there is some machinery 
involved where the browser calls a designated MUA. Where exactly the 
"mailto" is removed, and where exactly the %-escaping is undone may 
depend on the OS in question. For other situations, this will work in a 
similar way.


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

To Frank: I don't see any MUST here, sorry.

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

So we have an "it depends". That's exactly what RFC 3986 already says. 
And on top of that, I think RFC 3987 somewhere says that you should keep 
an IRI as long as possible. And that's what RFC 6055 says. And in both 
cases, "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).

It doesn't contradict the %-encoding at all. %-encoding is just like the 
escaping that may be needed if you put a string into a string constant 
in a programming language.

It is possible to construct some contradiction between the fact that the 
IRI spec says to use NFC and NFKC (in various different degrees of 
strength in RFC 3987 and in the current draft) and the "never change a 
local part" rule. However, that's not a problem between IRIs and EAI, 
but a problem within EAI itself: How am I supposed to write down an 
email address on a napkin or a side of a bus and key it in later without 
at least some recommendation re. normalization?

If there are other transformations in the IRI spec that you alluded to, 
please tell me which ones.


> For the purposes of this WG, I think we need to concentrate on
> email addresses, not IRIs or URIs.

Yes, please (except where email headers use URIs/IRIs directly, such as 
in many of the List- headers).

> If mailto doesn't work in
> the headers,

In those headers where it's already used (e.g. List-Unsubscribe:), it's 
already working. If it doesn't work for EAI addresses, then that's 
because EAI is new. Make sure that implementers know they have to do a 
bit of work in this area, and it will start work, the same way as the 
rest of EAI will start to work.

In those headers where URIs/IRIs are not used (e.g. From or To), 
definitely don't try to use a mailto:. That would indeed be a bad idea.


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

I very strongly suspect that if you see some huge problems between EAI 
and mailto:, then you have one of the following problems:
a) You are not distinguishing between mail addresses and URIs/IRIs 
containing mail addresses carefully enough.
b) You are asking URIs/IRIs to do something impossible.


Regards,    Martin.


> Just my personal opinion, of course.
>
>      john