IEA Bottom Line (was: Re: FYI: BOF on Internationalized Email Addresses (IEA))

Folks,

I've just spent several hours reading my way through much of 
through the long and fascinating thread caused by the BOF 
announcement.  I should probably just remain silent, but the 
traffic causes me to have a few thoughts.  Some of them have 
been mentioned on the list in one form or another, but let me 
try to draw them together in the hope of separating them from 
the noise.

As a preface, sound bites are a lot of fun, especially among 
politicians and demagogues.  To the extent that our goal is good 
design and engineering, we need to do serious analysis and try 
to read and understand serious analysis.  I am appalled at the 
number of postings on this list that seem to indicate people 
willing to state positions, very strongly, without having read 
any of the relevant drafts.  Whatever is going on in the 
problem-statement list and WG, that may be a much more severe 
threat to the IETF's ability to do good work than anything 
[else] they have gotten fixated on.

First, I am strongly committed to interoperability.  Without it, 
much of what makes the network attractive to many of us 
disappears.  We don't then end up at the "500 one-way channels 
of pointless entertainment" that many of us fear, but every 
significant step taken away from global interoperability --not 
just of the bits, but of user-level applications-- costs us some 
of the properties and potential for an Internet that enables 
human communications.

While me may disagree on many things, including the best way to 
preserve interoperability, I am convinced that Paul, Adam, and 
Martin are also committed to that goal.  I hope the rest of you 
are too --I've singled them out only because their names are on 
documents that represent approaches to the email 
internationalization problem -- if you aren't, these discussions 
are pretty pointless.

Second, it is clear to me that there is a tradeoff between 
completely convenient localization and global interoperability. 
In a completely local environment, I can not only use local 
characters and character codings, but I don't even need to label 
them.  Identifying the codings in use, or even protocol variants 
in use, doesn't require international standards -- they are 
needed only if one wishes to get some (or considerable) 
localization while preserving some (or, I hope, considerable) 
global interoperability.

Third, while it would certainly make global interoperability 
easier, there is no way to prevent people from deciding to use 
local characters, and maybe even local codings, in local 
environments.  They will do it.  They will believe (probably 
correctly) that they have good reasons for doing it.  Our 
choices are between

	* Finding a rational, plausible, global way to let them
	do it while still preserving global interoperability or
	
	* Not doing that and ending up with a potentially large
	number of local solutions that won't interoperate or, at
	best, will require using different protocols for local/
	national/ in-language email and for global
	communication.

There is some superficial appeal to the second choice, i.e., to 
saying "the world will communicate using Roman characters; 
anyone who wants to do something else will need to use local 
systems among people who share the relevant language and 
character sets".  But it won't work, as anyone who has been 
through the age of information-losing gateways among Internet 
mail/ PROFS/ cc:mail/ MSMail/ X.400/ etc., etc., can attest. 
Bad idea.  Doesn't work well and often works very badly. 
Assume it is going to be an internationalization standard or a 
significant drop in interoperability.  No other choices.

Fourth, there was, and is, a case to be made that 
internationalization of domain names is unnecessary and dumb 
because, in that view, domain names are protocol elements that 
need absolutely maximum interoperability and can be hidden from 
users.  Those who advocated that position lost the argument -- 
probably as soon as the first user saw the first web URL.  But 
there is no such case to be made for email addresses except, 
possibly, among those who entertain the fantasy that "The 
Directory" will take over the Internet.   Well, it may be really 
sad, but that plan has been over for years and years.  Hasn't 
happened and, absent some miracle, isn't going to happen.   The 
argument for why one can't get away without internationalization 
(or at least localization) of email addresses is in my draft. 
If you care and haven't done so, go read it.  If you are not 
willing to read that, you probably aren't reading this either.

Finally, the difference between the proposal from Paul and Adam 
and mine hinges on some very fundamental principles about 
architecture and deployability.  One way to oversimplify the 
difference is that mine is better optimized for 
fully-internationalized local environments in the short term, 
and a fully-internationalized world in the longer term (where 
"fully-internationalized" contemplates an environment in which 
English is just another language).  The Paul/Adam proposal is 
much better optimized for environments in which a user who wants 
or needs non-ASCII characters is isolated in a mostly-ASCII 
environment.  And it involves tampering with far few pieces 
that, in my few, we cannot pretend to ignore.

Is it possible to focus on those differences, and on the 
question of what the best way is to accomplish 
internationalization _given_ that it is an issue we need to deal 
with, rather than spending energy debating whether the users 
involved really should want it?

thanks
    john