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