Stability of valid IDN labels

Mark Davis mark.davis at icu-project.org
Tue Apr 22 22:40:17 CEST 2008


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

> On 22 apr 2008, at 20.33, Mark Davis wrote:
>
>  Patrick, I don't understand your reasoning.
> >
> > 1. Why must we guarantee to developers that DISALLOWED never changes?
> >
>
> The other way around.
>
> We tell developers what codepoints are disallowed. They add those
> codepoints to be banned in their user interface. If then later we allow
> registration, we will have tons of applications out there that can not be
> used to access domain names that include that codepoint.


That's circular. Banning codepoints in the UI because they are in DISALLOWED
-- in a product that isn't updated very often -- would only be a reasonable
thing to do IF we disallow changes in DISALLOWED. If we don't, then it's a
bad thing to do.

But if a product isn't updated very often, then *also* it won't pick up
changes in UNASSIGNED characters moving to PVALID or DISALLOWED. And it also
isn't going to catch changes in CONTEXT rules, and so on. In any event we'd
have your "applications out there that can not be used to access domain
names that include that codepoint". If a product is out of date -- and has
no mechanism for getting the up-to-date tables -- it will only accept as
valid those identifiers that qualify under whatever version of Unicode/IDN
at the date it was released.


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.
> >
> I agree that it is important for DISALLOWED to not have any but
> exceptional
>
> People use software without upgrading until their computers stop working.
> And that is 10+ years.


Understood. But as above, their program just won't let them access labels
that incorporate any changes in the tables, not just exceptional changes
from DISALLOWED to PVALID.

> obsoleting IDNA200x and moving one character from DISALLOWED to PVALID?
> >
> 2. How can such a promise be guaranteed? What is to prevent IDNA2012 from
>
> Absolutely nothing of course. But when that choice is made, the people
> that make that decision must know that there will be software out there
> deployed until maybe 2022 or even longer that will not allow that codepoint
> in domain names.


And some programs won't work with IDNA200x until then either, because they
are stuck on IDNA2003.


>
>   Patrik
>
>
>  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
> >
>
>


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


More information about the Idna-update mailing list