Eszett and IDNAv2 vs IDNA2008
John C Klensin
klensin at jck.com
Sun Mar 15 19:19:16 CET 2009
--On Sunday, March 15, 2009 10:06 AM -0700 Erik van der Poel
<erikv at google.com> wrote:
> I made a couple of mistakes in that email, and it may have been
> confusing, so let me try again.
>
> If HTML implementations start performing multiple lookups, we
> will probably start to see Web sites that take advantage of
> the new xn-- names, and they may not bother with any bundling,
> since the browser is performing multiple lookups.
If names that use the newly-available characters are available
(really not an xn-- issue, but the possibility of using
character, and scripts, that weren't there before), then it is
certain that they will be registered and used (again, people
want these characters). Of those, some will register multiple
names to bundle (because they want accessibility from IDNA2003
client systems that don't look up IDNA2008-dependent strings at
all), others won't (because they consider the new strings
different from the old ones or can't be bothered). And any web
site that is concerned about performance is not going to rely on
bundling if they can help it because "slower" is considered bad
and unnecessary web-level redirections cost performance.
Note that the above comments don't require or depend on any
registry action at all: registry-level bundling is a mechanism
for identifying possibly-confusing sets of names and controlling
who gets access/ownership of them and not for determining which
names are present, unless some of those names are blocked or
automatically registered. Note too that blocking names leads to
multiple lookups too, just ones driven by the user, rather than
by protocol.
> If HTML files containing the old IDNA2003 xn-- labels don't
> disappear completely, the Web site operators may feel
> compelled to keep those domain names, and if those old domain
> names don't disappear completely, HTML implementers may feel
> compelled to continue the multiple lookup, perhaps forever.
See above and my previous note... and remember that I'm not
aware of anything in IDNA2008 that makes an IDNA2003 A-label
invalid. The most IDNA2008 does is to change the number of
different strings that can map onto the old A-label (a mapping
issue generally, not specific to these particular characters)
and, by doing so, make some IDNA2003 A-labels make less
intuitive sense.
> Is this too pessimistic? Or is this realistic, due to the
> nature of the Web?
It seems to me that it is a much stronger argument for either
"IDNA2003, with no changes at all, forever" or for getting rid
of mappings as quickly as we can than it is for any particular
transition strategy.
john
More information about the Idna-update
mailing list