Mapping and Variants

Mark Davis mark at
Tue Mar 10 21:15:03 CET 2009

Actually, in this particular case I think we've learned quite a bit. Reading
Marcos's message, DENIC's position is quite a bit more nuanced than many of
use have realized for the past year. In particular:

"c) IDNA2003 is now well established and widespread. *With a new version of*
* IDNA we would like and would expect the situation to be backwards*
* compatible with IDNA2003. *That is, for all practical effects: eszett
*works* for the users and is mapped to ss." [My bolding.]

It is also not at all clear what the Greek NIC position is on sigma, based
on the email. It appears that the tonos is more of an issue for them, and
that for final sigma they may be more in line with the DENIC position.

This has not at all been a waste of time; the 4 special cases are very
problematic for compatibility and security, and winnowing them down would be
a very good thing.

Nor has the discussion around mapping been a waste of time either. Frankly,
unless IDNA2008 makes changes for interoperability in lookup with IDNA2003,
at this point it may very well be better to go in the direction of the
IDNAv2 proposal instead. It'd be a shame to not keep the many improvements
developed in IDNA2008, but the level of breakage between the old version of
IDNA and new would be pretty serious.


> To take one painful example, I don't believe that I've learned
> anything significant to the WG in the recent revisiting of
> Eszett and Final Sigma.   I've gotten a much better
> understanding of the details of the perspectives of some of the
> registries involved, which I appreciate, but the bottom line
> appears to me to be the same as it was over a year ago: the
> interactions between desires for proper orthography,
> preservation of information about characters that is sometimes
> important, compatibility with IDNA2003 (whether one believes the
> decisions made there were correct or not), etc., add up to a
> very complex set of tradeoffs and to a situation in which
> nothing that we could possibly do will make everyone happy all
> of the time.  In those situations, we just have to figure out
> how to decide and move on (as I assume Unicode did, mostly in a
> matching rather than mapping context, with CaseFold itself).
> Instead, we keep looping, proving the wisdom of the original
> IDNA assumption that the WG would avoid dealing with individual
> code points... only, here, I just don't see how to avoid it
> given the observation that eliminating mapping forces
> transitions either way.
>     john
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Idna-update mailing list