Stability of valid IDN labels

Mark Davis mark.davis at icu-project.org
Tue Apr 22 20:33:30 CEST 2008


Patrick, I don't understand your reasoning.

1. Why must we guarantee to developers that DISALLOWED never changes?

I agree that it is important for DISALLOWED to not have any but exceptional
changes, but why is it important for developers to be able to depend on it
never changing? They can't depend on various changes over time: they can't
depend on it not growing; they can't depend on UNASSIGNED not shrinking; and
so on.

For example, as an exception, suppose that
U+02DE<http://unicode.org/cldr/utility/character.jsp?a=02DE>( ˞ )
MODIFIER LETTER RHOTIC HOOK were to to be added in some future version
to the exception list, because it was found to be needed for a particular
African language. This would involve changing from DISALLOWED to ALLOWED.
What would be the practical problem that this causes?

We at Google, and I'm sure others, have lots of code that depends on
backward compatibility -- that once an identifier is valid, it stays valid.
That allows us to always update to the latest validity checks on all
identifiers, whether they are currently found or stored in databases. (A
one-time hit is containable for IDNA2003, but ongoing changes would be
untenable.)

But anyone who stays current with the IDNA2003 specs always be expanding the
valid identifiers.


2. How can such a promise be guaranteed? What is to prevent IDNA2012 from
obsoleting IDNA200x and moving one character from DISALLOWED to PVALID?

On Tue, Apr 22, 2008 at 12:38 AM, Patrik Fältström <patrik at frobbit.se>
wrote:

> On 22 apr 2008, at 03.49, Martin Duerst wrote:
>
>  What may happen
> > is that DISALLOWED is treated more closely to the way it is in
> > IDNA2003: okay to query, but forbidden to register.
> >
>
> I object to any kind of idea like this.
>
> This makes it impossible for application developers to filter, and there
> is no way it is possible to control "registration" of DISALLOWED codepoints,
> and the latter is the reason why application developers have to filter out
> DISALLOWED codepoints completely.
>
> DISALLOWED is DISALLOWED. Forever. Period.
>
>   Patrik
>
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>



-- 
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20080422/3ed316bf/attachment.html


More information about the Idna-update mailing list