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

[Harald Alvestrand]

Gervase Markham wrote:
>>> 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.
That's the model I think is the right one (modulo some quibbles on the 
formulation of the last point - separate debate).

3743 fits completely and totally into the second tier, but I can't see 
that as a statement that the first tier can claim the whole CJK group of 
characters as "ALWAYS".

                    Harald