[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New Internet Draft on registering IDNs




Hi! Paul and dear all,


Thanks Paul for propose draft-hoffman-idn-reg-00.txt  .
I have expressed some of my opinions, and I would like to know others
comments.

----------cut-------------
2.3 Table for a zone that has no language restrictions

A registry that does not restrict the number of languages will probably
allow a much wider range of characters to be used in names. At the same
time, that registry cannot easily use character variants because
variants for one language will be different from the variants used in a
different language. To handle conflicting variants among languages, the
registry can choose to have no variants for any base characters, or can
choose to have variants for a subset of the languages that are
expressible in the characters allowed.
-----------cut------------
<My opinion>
A registry that does not restrict the number of languages here means the
registry would possible offer the registration service for the languages
which have overlapped variants. For the purpose of decrease confusion,
cybersquating and DRP, so, how to let such registration result consist with
the principle described in  2.2 is very important.


---------cut-------------- The table would look like: U+2200 U+2201|U+0043 U+2237|U+003AU+003A U+2202|U+0064;U+03B4 ---------cut-------------- <My opinion> As the table format describe in the document, the tabel would look like: U+2200 U+2201|U+0043 U+2237|U+003A:U+003A U+2202|U+0064:U+03B4 Isn't it?


--------cut------------ Option 3 is likely to cause the most confusion with users because including some variants will cause a name to be found, bout using other variants will cause the name to be not found. ---------cut----------- <My opinion> I think the option 3 is a combination case of option 1 and option 2. If option 1 and option 2 is possible for implement. So implement option 3 would also possible for implement. The result would be the combination result of option 1 and option2. The key point has to consider is whether and which language has the requirements of allocate some variant labels for resolution and block other variant labels for prevent later registration at the same time.


---------cut--------- If the registry chose option 3, it must use an unspecified method to keep the elements in the registration bundle cohesive. This option SHOULD NOT be used except under carefully-controlled circumstances. ---------cut---------- <My opinion> I know the intention of this document is for the generic purpose not like IDN Admin Guideline just forcus on CJK characters.

So, I suppose that, it is natural that a generic principle should comprise
the specific language requirement like CJK Guideline has explain. At least
does not just mention how impossible/difficult for registry choice option 3.

Why need "Allocate some labels and block some other labels" ? That's
because the variants could be seperate into 2 categories. One for allocate
and one for block with a base domain name label.

The allocated labels would put in the zone file for the same destination
resolution with the base domain name. However the blocked labels
would prevent the latter registration from others.

So, if th registry make more explain to the public about his registration policy
regard the variant table very clearly, and when user register a domain name
let user recognize about what labels have been allocated and what labels have
been blocked, that would be improve the user experience.



----------cut------------ $ORIGIN example.com. pale IN NS x.example.com. pale IN NS y.example.com. pa1e IN DNAME pale.example.com. ----------cut------------- As I know DNAME is support by BIND9 not BIND8, is it possible to let the users know if do not use DNAME the would have possible serious delegation problem? Such as there might be too much zone file have to maintain bye users, user has to keep the variant labels setting consistent.

Erin Chen, TWNIC

Paul Hoffman / IMC wrote:


Greetings. I have just submitted a new Internet Draft that gives suggestions on how to register IDNs. You can find a link to the draft at the web site for this mailing list at <http://www.imc.org/idn-reg-policy/>. Comments are, of course, welcome.


This document is different than the JET document in many ways. It is meant to be generic and usable by anyone, not just registries using CJK characters. It also attempts to make the registry policy easier and more predictable from the outside. I have heard that other folks will also be preparing Internet Drafts on this issue, so it will be good to see what the differences are.

--Paul Hoffman, Director
--Internet Mail Consortium