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

Re: New Internet Draft on registering IDNs

At 6:52 PM +0800 3/26/03, Erin Chen wrote:
Thanks Paul for propose draft-hoffman-idn-reg-00.txt  .
I have expressed some of my opinions, and I would like to know others

Yes, it would be great to have more comments here.

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.
<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.

It would be great if you could suggest some wording about how such a registry would work. I can't think of any way it could, but that doesn't mean it is impossible.

The table would look like:
<My opinion>
As the table format describe in the document, the tabel would look like:
Isn't it?

Your second change (to "U+2202|U+0064:U+03B4") is correct. The first one is not, however. The text above said:
- allows the PROPORTION character (U+2237) which has one variant which
  is the string COLON (U+003A) COLON (U+003A)
The way to show a string is to append all the characters together with no delimiters between them.

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.
<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.

We fully agree. The JET document shows a way that it can be implemented. I very purposely tried not to say "it can't be done", just "it will cause the most confusion for users".

 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.

Right. Unfortunately, the current draft of the JET document is silent about these requirements, and from talking to some JET members, I haven't heard any good description of why Chinese needs both. In fact, I remember many long conversations with CNNIC and TWNIC people a few years ago where they all said that just blocking (with no allocating) was fine. Maybe opinions in the Chinese language community have changed since then, but I haven't seen any written down in the JET document yet. Maybe the next version will cover this clearly.

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.
<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.

I never said "impossible" because I am sure it is not impossible. I trust the JET people's analysis that it can be done.

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.

My apologies, but I don't understand that. The fact that it *could* be done does not explain why it is needed. Could you be clearer on the *need*? It would be helpful in this document (and in the JET document) if the actual need is clearly stated.

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.

True, but it would only help a little bit. Telling the users what has been done does not let them predict what will happen. If a registry says "we have mapped these characters to these other ones for this language reason", users will understand that; if a registry says "we have blocked these characters for this language reason", users will understand that. But I don't know how many users will understand "we have mapped some of them but blocked other ones even though the language reason is the same". If there is a good language reason for differentiating the two cases, that would be wonderful.

 $ORIGIN example.com.
 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.

I don't understand your question. Why would there be "serious delegation problems"? Having "too many zone files" is not a problem if the users have the tools to manage them. If the users don't have the tools, then the additional zones would give bad information, but that will be fixed when users complain. This isn't any different than the current DNS when people make mistakes that affect users. The big point is that the effects can only affect the owner of the registration bundle, and that a cybersquatter can't cause the problems.

--Paul Hoffman, Director
--Internet Mail Consortium