Subject: [EAI] i18n Addressing and Fragmentation of the email infrastructure

From: John C Klensin <[email-masked]>
Date: Sun, 19 Mar 2006 09:15:51 -0500

Dave,

I've been trying to figure out how to address your concern, 
voiced  several times and in different ways, that the approach 
being contemplated in this WG inherently breaks the 
infrastructure, that it fragments the email network, and that I, 
and others, are insensitive or indifferent to those issues.  If 
that is not a correct summary of your position and concern, I 
apologize -- it is, at least,  the impression I'm left with 
after several readings of a number of your notes.

To get the other issue on the table in the hope that, once 
exposed, we and the community generally can move beyond it, I 
personally take the issue seriously enough that I've been trying 
for some years to engage the question of ways to get full 
internationalization without giving non-ASCII users less 
functionality than those who operate entirely within an ASCII 
environment.  I've been involved in innumerable discussions on 
the subject and large numbers of explorations of how it might be 
done.   I haven't avoided any discussion on that topic that has 
been able to be conducted among parties who appear to be willing 
to work together to find solutions.   I wish there were a magic 
solution that would install seamlessly without changes in the 
existing mail system, but such a solution appears to require a 
quantity of pixie dust that just is not available.

This leaves us with a classic engineering problem in which, 
rather than find a perfect solution, we need to look at the 
intersection of possible constraint spaces and solutions spaces, 
analyze and balance the tradeoffs, and then try to find 
something that works.

If, for example, we apply the constraints that (i) no i18n email 
approach is acceptable if it could result in a situation in 
which someone who has only an address in one script will be 
unable to communicate with someone who has an address only in a 
different non-ASCII script and (ii) users of non-ASCII addresses 
must have all of the functionality available to them that is 
traditional for users of all-ASCII addresses, then it is 
basically over: the only "solution" is to retain ASCII-only 
addressing forever, relying on encoded words or the equivalent 
to express names or terms that cannot be accurately rendered in 
ASCII characters.  While it has gotten more refined over time, 
the reasoning behind that startling conclusion appears in my 
early internationalized addressing I-Ds, now well over two years 
old.  An overview of it appears in draft-klensin-ima-framework 
and a different perspective on it, in far more depth than I 
intend to repeat in this note, appears in the more recent 
draft-klensin-ima-constraints.    As I indicated above, we've 
certainly been looking at the issues and doing so carefully and 
for a fairly extended time.

Viewed on way, that conclusion gives us a choice of options that 
could create islands within the email environment that can't 
communicate.  Clearly, that is not a desirable state of affairs, 
but, again, it appears that the choice is among types and 
sources of islands, not whether islands will exist.

One sort of island-development occurs if we simply do nothing. 
There is considerable demand for internationalized email 
addresses.  The level of that demand is likely to become much 
higher than the demand was for IDNs and is, IMO, far more 
legitimate (see the drafts cited above for more details on that 
claim).  With the right selection of MTAs, MUAs, and 
mail-accessing protocol implementations --ones that depart "only 
a little bit" from the standards and that are trivially modified 
to do so-- approaches analogous to the "just send 8" approaches 
we needed to overcome with MIME are quite plausible.  In some 
ways, those approaches are more plausible now then they were a 
decade ago because one can say "just send UTF-8" and hope for 
universal acceptance, rather than having a nasty problem with 
choices of character sets and labels.  If we do nothing, we will 
almost certainly see deployment of solutions along those lines. 
And, as with "just send 8", they will certainly cause serious 
interoperability problems as subtly different i18n address and 
header forms hit MTAs and MUAs that are not prepared to deal 
with them and do so without agreement or even warning.  "Just 
say no" is not a realistic option here, any more than it was a 
realistic option with IDNs or, for that matter, the basic 
multiple-script and multimedia functionality that MIME enabled. 
Our advantage over IDN is that a larger fraction of the 
community has come to understand that "any solution, as long as 
it is quick" is not a good way to do protocol design: we 
actually have the option of examining and balancing tradeoffs 
here... and I suggest we are obligated to do just that.

A second type of island-building involves, from at least one 
perspective, exactly what we did with MIME, only moved out to 
the  transport level (of necessity).  From that perspective, 
MIME doesn't provide global interoperability.  Instead, it 
provides a safe and controlled form of non-interoperability. 
None of us who advocate and support MIME like to think about it 
that way but, if I send you a body part that is identified with 
a content type that you, and the tools you have available, have 
never heard of, then we just are not going to interoperate. 
MIME gives us the considerable advantage of knowing that a 
particular body part cannot be processed but it doesn't 
intrinsically provide any mechanisms for ensuring that it can be 
processed.   In practice, if one looks at both the MIME-aware 
and non-MIME-aware implementations out there, there is only one 
content-type that is substantially guaranteed to be implemented 
and supported globally and that is plain, ordinary, legacy, 
ASCII text with relatively short lines.  For everything else, 
maybe it is supported and maybe it is not supported, but what 
MIME provides is only a clear indication of the type so that an 
unambiguous decision can be made about whether support is 
available (I note that we have compromised even that principle 
in recent years, but that is a different discussion).

If we take that logic and the constraint set it implies, back to 
the i18n email solution space, the conclusion we (the design 
team that put the framework for this WG together) have reached 
is that, absent a desire on the part of all users of i18n email 
to interoperate with traditional, all-ASCII, email users --a 
desire that extends to accepting a certain amount of 
inconvenience-- there will be islands.  Our task then becomes to 
make the islands acceptable: to be sure that having i18n 
addresses or headers on the Internet doesn't blow up 
unsuspecting older systems and to be sure that "downgrading" 
mechanisms or arrangements are available at appropriate points 
in the infrastructure for those who are willing to go to the 
trouble.   Note here that, as far as we have been able to tell, 
even encapsulation doesn't give us clean, easy, and universal 
in-flight downgrades:  the message/rfc822 is limited to ASCII 
and the double-encoding rule prevents encapsulating something 
that might already be encapsulated, so we will almost certainly 
need a new content-type and body part to accomplish the 
encapsulation.  Because non-upgraded receiving programs will 
presumably not understand that new type, it will provide, in 
essence, a tunnel to nowhere for those cases ... a different way 
to have two systems on the Internet not communicate with each 
other, but a way nonetheless.

This isn't easy.  All of us who have been trying to find an 
approach that works with minimal risk of damage or unanticipated 
side effects know it isn't easy.   I hope, I think we all hope, 
that the IETF community, especially the community of experts on 
email, will work with us to identify the tradeoffs and risks and 
to find a good balance among them rather than getting diverted 
into arguments about which approaches can be labeled as 
"fragmenting" or "creating a new infrastructure".

    john

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima