New version, draft-faltstrom-idnabis-tables-02.txt, available
Gervase Markham
gerv at mozilla.org
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.
Gerv
More information about the Idna-update
mailing list