Tables: BackwardCompatible Maintanence

Erik van der Poel erikv at google.com
Wed Dec 10 18:58:10 CET 2008


On Wed, Dec 10, 2008 at 9:23 AM, Mark Davis <mark at macchiato.com> wrote:
> For the X/Y characters, the choices are:
>
> BackwardCompatible automatic - stability is the norm, IETF can write RFC if
> it wants to change to follow Unicode.
>
> BackwardCompatible not automatic - instability is the norm, IETF can write
> RFC if it wants to maintain stability.
>
> Either of these two models can work - the first would be safer from a
> stability point of view.

There is a 3rd model:

BackwardCompatible semi-automatic - implementors are encouraged not to
implement new versions of Unicode in IDNA until the IETF (or some
group of experts) has declared the chosen action (i.e. addition to
BackwardCompatible or addition to Exceptions).

> The situation on eszett was not an oversight in IDNA2003. It was discussed
> at great length. And it is not a clear-cut case. There are a handful of
> problematic cases:  eszett, final sigma, and the Turkish i's. These were all
> ugly problems before Unicode; there wasn't much of a way around them. Had
> the Germans had an uppercase eszett, the Greeks a final capital sigma, and
> the Turks chosen a different accent on the i rather than have their casing
> be inconsistent with every other Latin alphabet, it would have been far, far
> easier for software. But Unicode has to recognize existing usage.

I'm sorry, but this is not very persuasive. There is really nothing
you can say to convince me that eszett was not botched. Either the
Unicode case-mappings were recommended too forcefully, or the IETF
accepted them too easily, or the German registry was not present, or
the German registry changed their mind in 2008, or some combo of the
above. Either way, at the end of the day, it's botched.

We can deal with it.

Erik


More information about the Idna-update mailing list