Not changing the prefix

[Mark Davis]

John presented some very good points about not changing the prefix. There
are more.

Suppose that we do change the prefix. The registries won't recognize that
the A-Labels are the same, without bundling. What do clients do with
http://ÖBB.at <http://%c3%96bb.at/>? Do they use the xn-- prefix? The new
prefix? Make two DNS calls?

What about a series of communicating systems? If I convert to an A-Label (
http://xn--bb-eka.at <http://%c3%b6bb.at/>) with one of the prefixes and
send on to you, should you always convert back to a U-Label, then convert to
one or the other prefix? Or try both?

And as for incorporating native language in IDNs, I share John's misgivings
-- and more, along the lines above. If I as a client see
http://ÖBB.at<http://%c3%96bb.at/>,
which languages do I convert to? The DNS servers are presumably not going to
bundle them all together, so I have to pick among them. All possible
languages (a huge list, once we also count script and regional variants)? All
those that could have umlauts? (So then
häagen-dazs.com<http://xn--hagen-dazs-q5a.com>(an English name)
wouldn't match.) And so on...

I think any serious look at changing prefixes would find that the problems
form a big, nasty, hairball. The goal should be to interoperate between
IDNA2003 and IDNA2008 as much as possible -- and avoid the need for a new
prefix.

Mark


On Thu, Feb 26, 2009 at 10:56, Paul Hoffman <phoffman at imc.org> wrote:

> At 11:32 PM -0500 2/25/09, Vint Cerf wrote:
> >Before we go down the path of introducing a collection of prefixes, I
> >think we have a lot to get done with the xn-- version first.
>
> At what point does this WG consider changing the prefix? We are currently
> discussing breaking the stability of names that any reasonable implementer
> of IDNA2003 would have expected under the current prefix. We are also
> discussing greatly reducing the expected interoperability in exchange for
> not having to do another revision later.
>
> Are these acceptable to do without changing the version identifier (which
> in this case is the prefix)?
>
> I do not want to change the prefix, but I also don't want to do things that
> would normally cause us to change it but then not change it anyhow. That
> kind of cheating has always led to bad protocols in the IETF; we can do
> better.
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20090226/c0f909b9/attachment.htm