Re: [idn] WG last call summary

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

> > I doubt we'd reach consensus on that either, since many of us suspect
> > that the following statement is closer to the truth:
> >
> >     The on-the-wire encoding of IDNs is irrelevant; what matters is the
> >     behavior experienced by users.
> 
> Obviously. It's a question of getting there, however.
> 
> The final, ultimate argument in this logic-chain is that native
> representation of the data in the protocol message is the ultimate design
> solution, since it means less implementation work, fewer errors introduced
> by wayward codecs, highest reusability by other services, etc. Managed
> facades are not long-term solutions to anything, and in fact, tend to
> introduce as many problems as they try to fix.

Every single one of the above arguments is highly dubious.

First, it's naive to assume that UTF-8 will be the native 
representation on everybody's platform - it has a number of nice
properties but it's far from clear that everybody is going to
drop what they're doing now to support it.  Second, the portion of
IDNA that does ASCII encoding is such a trivial bit of code that 
the number of failures introduced by that code will pale in 
comparison to those introduced by the other code needed to handle 
10646 (normalization, etc) which would be needed no matter what 
encoding were used.   Third, your statement about "managed facades"
is a gross over-generalization.  Numerous examples demonstrate 
that transition issues are often paramount in determining whether 
a new technology can succeed.

Simplicity is often a virtue, but IDN is inherently complex - it
reflects the tremendous variety in the world's languages and 
writing systems.  And blind faith in some vague notion of 
cleanliness is a poor substitute for engineering analysis.

Having said that, I'm all for having an alternate method to do
UTF-8 queries on-the-wire, provided it produces consistent
results with the IDNA queries, with similar efficiency and
reliability.  But the need to allow incremental upgrade of 
legacy application components strongly compels IDNA, and the 
incremental benefit of a native UTF-8 query interface beyond 
that of IDNA does not appear to justify the additional complexity.  
Nor does it justify delaying approval of IDNA.  Most of the 
problems that are anticipated with IDNA - including the various
kinds of transcription problems - will occur no matter what 
encoding is used for on-the-wire queries.

Keith