Re: Why we can go directly to UTF-8 (was: Re: [idn] time to move)

[Keith Moore <moore@cs.utk.edu>]

> 
> Your conclusion
> 
> >we cannot make the jump directly to utf-8 - it is simply not practical.
> 
> isn't really a given. The main point in support of UTF-8 is that
> the main drive for idns is coming from Web usage (http URIs).

the 'main drive' for IDNS is irrelevant.  the major applications do not
exist in isolation; web and email together touch almost everything else.
we can't solve the IDN problem for just the  two and pretend that it will
not do harm to other applications; the boundaries are not that clean.

> Also, I don't buy that once an ACE is deployed, we will come back
> to work on UTF-8. 

I didn't say that we would.  I said that we "might".  But I suspect
that it's at least worthwhile to consider as a followon effort, and I
also suspect that there are enough people who  are willing to do the 
work.  Whether application developers will use it is a different
matter.  But it's hard to see why they wouldn't use it if their protocols
are using UTF-8 internally anyway.

> Also, I don't buy that application protocols
> will do the work to upgrade to UTF-8 internally if they can just
> use ACE. Some might, but most won't. And the result would look
> strangely backwards. 

I didn't say that they would do the work to upgrade to UTF-8, and it's
not even clear that it's desirable overall for them to do so.  I don't 
think this is backwards at all - it is just the way of things.  Old 
interfaces that work tend to get used with few changes for a very long time.  
The POTS telephone interface is ancient and very clunky, and we could
do far better today.  but almost all subscriber equipment still uses it.

> On the other hand, if any particular
> application (e.g. email) really thinks they need ACE, they
> can do that on their own, and bear the consequences.

no they can't, because unless DNS supports queries by ACE from day one,
those applications will not work with ACE names. 

> Also, if one puts together the protocol issues, the user interface
> issues, and the management issues (zone files, scripts, and the like),
> rather than just looking at the protocol issues, ACE is about as
> impractical as anything else.

all of the above issues exist with each of the solution paths.
ACE wins because it has the best backward compabtibility and the
lowest barrier to quick deployment.

Keith