Updating RFC 5890-5893 (IDNA 2008) to Full Standard (was: Re: Lookup for reserved LDH labels)

[John C Klensin]

--On Thursday, 08 November, 2012 13:18 +0900 "\"Martin J.
Dürst\"" <duerst at it.aoyama.ac.jp> wrote:

>... 
>> RFC 5890-5893 were published over two years ago.  Is there
>> interest in reviewing them and trying to advance them to Full
>> Standard (I assume that 5894 and 5895 would have to be updated
>> as well, but haven't studied that issue)?  Doing so would
>...

> I think this should happen sooner or later. However, Anne van
> Kesteren recently pointed out that the major browsers haven't
> yet done too much with respect to implementing UTR 46, which
> I'd guess implies that they haven't yet implemented much of
> IDNA 2008, either (Anne, can you confirm or clarify?). Given
> that browsers are an important part of IDNA users, it might be
> prudent to wait for some more time and see what issues might
> come up from that side.

Fine with me to wait.
However, as you know but Anne may not, I still consider UTR 46
to represent a tradeoff between a possibly-useful short term
patch and a long-term interoperability problem.  Two years
later, my key question about UTF 46 is "if one starts down that
path, when and how does one stop".    Some of the responsibility
lies (as it always has) on registries (at all relevant levels of
the DNS) to get rid of strings that IDNA2008 invalidates.   Some
have been very good about that in the last two years; others
have done nothing or, worse, continued to register invalid
strings (presumably to collect a bit of extra revenue).  The
question we haven't asked Marcos is what legitimate use he, or
his registrants, see for labels with odd prefixes and, if the
answer is "transitional", what to do about transitioning out.
If a browser vendor hasn't implemented specific support for
those prefixes, they aren't going to be rendered as anything but
themselves... and I can't imagine they have more mnemonic value
than A-labels do.

So, if browser vendors haven't implemented UTR 46 yet, maybe its
time has passed.

> (That was also why I asked Marcos about deployment of "ß";
> the story was that registries would first deploy these with
> the respective bundlings or restrictions, and then browsers
> could move ahead and resolve them directly.)

Understood.   However, the specific problem with "ß" is that
the community that really wants it as a character doesn't want
it bundled with "ss", much less to have either prohibited.  So
there is a very fundamental policy question --one that certainly
cannot be resolved as part of IDNA2008 and that almost certainly
should not be preempted in browsers--- as to what "the
respective bundlings or restrictions" might be.  

best, 
   john