Q3: What characters should be allowed in a revised IDNA2008 specification?

[John C Klensin]

Gerv,

Thanks.   A bit more below.

--On Wednesday, April 01, 2009 11:08 +0100 Gervase Markham
<gerv at mozilla.org> wrote:

> As a point of information, given that such "spoofing"
> characters can  appear at any level in a domain name, these
> characters have to be  "banned" outright by browsers anyway -
> which is what we do in Firefox:
> http://mxr.mozilla.org/mozilla-central/source/modules/libpref/
> src/init/all.js#744
> 
> It's not the most easily understandable format, but I'm sure
> you can all  cope with that :-) If people have suggested
> additions, please do let me  know.

This is, of course, the other (and, IMO, very strong) argument
for banning non-language (i.e., other than an extended form of
LDH) characters  in the protocol and specifically in lookup.  If
we specify the characters that are rejected on lookup and do a
competent job of it, then all conforming browsers (and other
applications supporting looking up IDNA labels) will ban the
same bogus labels.   If we don't, we leave it up to individual
interpretation.  Such interpretations have all of the issues of
inconsistency for users that have been raised for local mappings
-- some strings work in some application contexts and not others.

>> The period in which IDNA2003 lookup implementations are
>> gradually replaced by IDNA2008 ones should provide a more than
>> adequate transition period without taking any special
>> measures. Registries and zones that have created and
>> installed such labels should certainly work out transition
>> strategies, but the exact nature of those strategies is
>> beyond the scope of this WG.
> 
> I agree that the protocol does not need to define a transition
> strategy.

That makes at least two of us :-;

    john