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

Re: Comparison of hoffman-idn-reg and jseng-idn-admin




On 16:25 03/04/03, Roozbeh Pournader said:
a multilanguage zone that support both Arabic and Persian

From what I gather, IDNA created only two language zones:
- ACE label for non-WASP languages
- non-ACE label for WASP languages.
This second left to right limited DNS cross-hierarchy seems to create many problems together with the choice of "xn--" for the ACE label instead of "x--n" (meanings of "xn" and babelsquatting).


One proposed response is the variant system to patch the 5000 languages of the world in a way which may upset the registrants and the judges. Fist US tries (to support 3/4LDs employee names in California, Louisiana etc. and foreign subsisidary locations) show the problem.

Another response could be to use virtual language zones as per RFC 3066. These virtual zoning will be managed outside of the DNS through 368 registration systems. Each could use a prefered language IANA registered zone character sets. This would be an unique PHP registration system with an RFC 3066 compliant parameter system and language pages.

Registrant should then register in using the IANA virtual zone language character set. They could be permited to use foreign characters, should they take responsiblity for the possible conflicts and pay an extra fee (to prevent abuse, and to pay for the cost of a cheap conflict management procedure : an apointed expert - or far better - an on-line user panel - call on your @larges). This would only modify the rule into "first context consistent, first served".

No one will ever know which UTF8 chararacter they used. They will only know they have registered a name in Arabic or in Persian and that if they tried to use several character sets, they may lose.

Is there a conflict possibility? Yes. Only if the other characters used in the registered name are do not permit the users to determine the scripting context ( what the user panel will see quick ).

Is this a problem? No. Because this is true for every usage of such scriptings, as a title of a book, as a TM, etc. This will most probably be why the registrant will register it. His interest will be to register all the variants if he is in his own right, or to pay a good lawyer if he is not. No difference with "IBM" and "1BM" (that IBM may want to register to communicate as a leader).

The day eventually ICANN understands the reality of the world, you will just transfer the registrants from you Arabic and from your Persian vitual zones into the DNS zones of your now permitted Arabic and Persian TLDs - transcoding in Arabic and in Persian your ".TLD-ISO 369 code" (exemple: ".cn--fre" for French registered DNs by CNNIC. Without any conflict, at no cost and with no sunrise period.

What is of interest is that registry and registrar programs seem to already exist, off-the-shelves. They should be added a user-panel support.

I like to see a standard that limits each zone to a specific *language*,
but I guess that can't happen in situations like a Swiss or European zone.

The rules are exactly the same. The language virtual zones share the same DNS. Again the rule ("first context consistent, first serve").

But also, I like to see a nice mechanism or some guideline for a Swiss
registry: "Grab the Italian, French, and German and merge them
according to the following guidelines." The guidelines may require a
language priority list or whatever, but it should be usable in a semi-automatic way.

No need. For 7000 years we have used scriptings in many languages and survived. Without any automatic system nor world constable prioritizing cultures and languages. The Babel Tower is a symbol of liberty: not to be bound into bricks by an unique mortar for some to build an offense to God, but to become flow as the sand with many languages.


IMHO we will even survive  IDNA.
jfc