[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
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.
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.
The table would look like:
As the table format describe in the document, the tabel would look like:
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.
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.
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.
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
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
been blocked, that would be improve the user experience.
pale IN NS x.example.com.
pale IN NS y.example.com.
pa1e IN DNAME pale.example.com.
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