The Future of IDNA
kenw at sybase.com
Fri Mar 20 02:30:55 CET 2009
> > O.k., I'm a Unicode and language expert on this mailing list. *I*
> > think mapping tonos away in the protocol is a bad idea. That is
> > the kind of equivalencing that *should* be done by bundling
> > (if required).
> Do you have first-hand experience with the difficulty of bundling?
Of course not. What a silly question. I'm not a zone administrator.
But heading down this path of mapping *this* kind of information
in the protocol is a one-way ticket to hell, IMO. It leads
directly to the question of mapping simplified and traditional
forms of Han characters to each other, which is a much, much
bigger and less tractable problem than ignoring a few accents
in Latin, Greek, or Cyrillic.
> By the way, what languages require the separate registration of names
> that differ only in the presence or absence of tonos? And how large
> are those communities?
Well, *Classical* Greek. Or for that matter any use of polytonic
Greek, where the point is to use the accents to make distinctions.
Of course it is pointless to ask how large is the Classical Greek
"community", in one sense, because we are talking about historic
usage, for the most part. But if you map away accent distinctions
for Greek letters by *protocol*, then you preclude the possibility
that someone could want to make a label distinction on that
basis -- just as they might for accented Latin letters.
As Andrew pointed out, you make life easier for some, but you
end up goring somebody else's ox.
And we just haven't got enough time slices left in the decade to
parse all the nuances of one community's preferences against
anothers on a language-by-language and character-by-character
Nor would attempting to do so make the protocol functionally
better, IMO. All it would accomplish would be to make it
more complicated, more subject to arbitrary (and not so
arbitrary) political complaints about X's interests versus
Y's interests, and most of all, would delay its approval
> Yes, it is in the opposite direction, and I have outlined a transition
> strategy for adding or removing mappings. Is the strategy unclear?
I think a transition strategy for adding or removing mappings
is inherently flawed.
Either we go with IDNA 2008 pretty much as currently defined,
take the one-time transition hit, and hope that the Unicode
Consortium (or somebody) can provide a preprocessing for
maximal IDNA 2003 interoperability.
Or we go with Paul's approach and attempt to maximize the
interoperability with IDNA 2003 as the highest priority for
the revised protocol design.
> Should I provide more details?
If you wish, but I'm simply not convinced that the direction
is fruitful at this point.
More information about the Idna-update