Making progress on the mapping question

Shawn Steele (???) Shawn.Steele at microsoft.com
Mon Mar 30 21:35:10 CEST 2009


-----Original Message-----
From: idna-update-bounces at alvestrand.no [mailto:idna-update-bounces at alvestrand.no] On Behalf Of John C Klensin
Sent: Pōʻakahi, Malaki 30, 2009 8:20 AM
To: Vint Cerf; idna-update at alvestrand.no
Subject: Re: Making progress on the mapping question

> (c) The above would imply that we apply _all_ IDNA2003 mappings
> and lookups if the IDNA2008 lookup of (1) fails.  I do not
> believe that is actually our intent.   Consider the string
> "┌┐└┘" (U+250C U+2510 U+2514 U+2518).  An IDNA2008
> conversion fails completely because all four characters are
> DISALLOWED.  If we then apply the IDNA2003 mappings and Punycode
> conversion, we get "xn--lwhimq", which could be looked up.    An
> example that is graphically even more interesting would be
> "□□□" (U+25A1 U+25A1 U+25A1), which looks suspiciously
> like the "no available font/graphic" indicator in many systems.
> It, too, is DISALLOWED by IDNA2008 but, for IDNA2003, is
> successfully converted by ToASCII to "xn--u0haa".

I think this scenario is where there is where some thought is needed.  What will it cost?  Is the cost worth the benefit?

Consider http://xn--iblogging-0g3f.blogspot.com/ ("http://i♥blogging.blogspot.com"), which works right now.  My problem is that if this stops working, then:
A) Microsoft is going to get a bug because Internet Explore is "broken."
B) Firefox, etc. are going to get bugs because they're "broken."
C) Several ISPs are going to get bugs because their DNS is "broken."
D) Blogspot's going to get a bug because the blog's going to need a new name, and, AFAICT, there's no way to easily change the blog's name.

And this is the BEST CASE!

Lots of these types of things (blogs, photo sharing accounts, message boards, etc) have dashboards that are like http://i♥blogging.blogspot.com/dashboard.html, in which case the user can't even get to their settings.  Many of them make you look at your profile before contacting customer service.  (Eg: you have to be logged in to a valid account before they'll spend customer support time on you).  In that case you won't even be able to file a bug if your browser won't let you go to the URL because it's illegal punycode2008.

This isn't completely hypothetical.  I'm not sure about blogspot, but other applications already permit registration of illegal xn-- names, so it's pretty simple to see how badly behaved they get in the event of a hypothetical change.

I could concede that maybe symbols are really unnecessary, and useless, overly cute, or whatever, but the customer support tail for this change is going to be inordinately expensive.  So I suspect that clients will want to continue to provide IDNA2003 support even if the registrars prohibit new registrations.  I also don't think that it is reasonable to expect that IDNA2003 registrations can easily be prohibited at all levels of the DNS.

I'm NOT objecting to specific, targeted changes, it’s the huge changes that disconcert me.  I don't want to pick on each case individually, but for ZWJ/ZWNJ, I could see needing to make a fix, because:

* Some languages have issues with code point(s) that just don't work for that language in IDNA2003.  For ZWJ/ZWNJ, you can't correctly display strings without them, so they are required for some languages.

* For ZWJ/ZWNJ, we're a bit "lucky" because the mappings were dropped.  This means that 2008 resolution will go somewhere else, but at least dropping them by hand would get you to the old URL.  (so it won't just disappear like i♥blogging would).

Just because a few specific changes are needed to mappings to support certain languages doesn't mean that a larger set of changes is a good idea.

As always in the IETF, I am representing my own concerns :)  Microsoft, Windows Live, IE, etc. haven't decided what kind of fallback will be used for IDNA2008 to IDNA2003.  Obviously that'll depend on the mappings the end up being in 2008 and how they break existing users.  "I" would like the RFC for IDNA2008 to be clear enough that client apps (whether Microsoft or not) won't feel like they need to add an extra lookup for backwards compatibility.  (Or even worse, "fix" the mappings themselves).

- Shawn

P.S:  I'm not trying to pick on Blogspot or Google.  "Microsoft" products have similar (or worse) behavior, but I didn't want this to be derail into a "fix your bug" discussion.





More information about the Idna-update mailing list