New version, draft-faltstrom-idnabis-tables-02.txt, available

Gervase Markham gerv at
Fri Jun 15 10:49:26 CEST 2007

>> The JET guidelines actually give some reasonably powerful tools for 
>> specifying which characters a particular registry wants to permit in 
>> domain names it registers, with the possibility to specify some (but 
>> not all) language-specific constraints and adaptions.
>> But they don't specify which characters to permit, and the 
>> specification language used is applied at the codepoint level, not at 
>> the Unicode property level.

Again, forgive me if I've missed something, but my understanding was 
that very early on in this process, there was an agreement that no one 
"level" of the IDN stack could solve all of the problems. Is not your 
concern above a problem of level mixing?

RFC 3743 is the result of a lot of thinking about how to do CJK domain 
names non-confusably. So the IDN standard should permit any CJK 
character that RFC 3743 permits (which may be all of them) in the ALWAYS 
category. Then, registries can apply the wisdom of RFC 3743 to their 
registration processes - as I assume they do now.

I have always seen the solution as working like this:

- The IDN standard excludes every character we know we definitely don't 
want, including ones which are confusable with protocol characters;

- Registry policy excludes characters which are permitted but not used 
in languages they register names for (for most registries, that's most 
of them), and checks for confusables in the remainder using the Unicode 
Consortium list;

- User agents only enable IDN for registries which have such an 
appropriate policy.

Harald said:
> As far as I know, RFC 3743 introduces a couple of tools that are 
> orthogonal to this endeavor. I don't believe that there is a nice way to 
> incorporate those tools into this table building process.

I don't believe we need to - see above.


More information about the Idna-update mailing list