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.