New version, draft-faltstrom-idnabis-tables-02.txt, available
Harald Alvestrand
harald at alvestrand.no
Mon Jun 18 07:21:43 CEST 2007
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
More information about the Idna-update
mailing list