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

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




At 6:55 PM +0430 4/3/03, Roozbeh Pournader wrote:
On Tue, 1 Apr 2003, Paul Hoffman / IMC wrote:

 >2. Clear language about conflict resolution. There needs to be some clear
 >guidelines or recommendations about the times that two registered labels
 >come into an intersection regarding the variant labels associated to them.
 >This will happen with almost any multi-language Arabic-script zone
 >(e.g. U+0649 vs U+064A vs U+06CC).

 I am unclear on how this differs from point #1. If any of those three
 characters are supposed to only be represented by one of them in
 names, then the registry-specific early mapping step will take care
 of them. Or is that not what you are referring to? Please be more
 specific.

I am talking about two main labels that are not variants of each other, but share a variant. For example, a multilanguage zone that support both Arabic and Persian will have something like this in its equivalence data table:

U+0649|U+06CC
U+064A|U+06CC
U+06CC|U+0649;U+064A

The first two characters are only used in the Arabic languages, and the
third is only used in Persian. The above data is necessary if you want
to distinguish the first two (that are distinguished in Arabic), but avoid
security problems (U+06CC looks *identical* to U+0649 in isolated and
final contextual forms, and *identical* to U+064A in medial and initial
forms).

Now, when one registers a label with a U+0649 and someone else goes with a
U+064A, who will own the U+06CC version?

The first person to register either name. I can add (hopefully) "clear language" on this in the next draft.



> - the merging is a policy decision by the registry at the time of
 table-making as to which language "wins" for the overlapping
 characters

Or which character wins, or which registrant wins, or which orthography wins...

Not "registrant"; the policy is in place before the registrants start using it. But "character" and "orthography" are certainly part of the decision that the registry that takes this route much factor in. It is really "which policy-maker at the registry wins". That is not a good position to be in.


> - it is impossible to register without knowing the supposed language
of the registration

 I can add more discussion of that, but the third option is not
 "merging", it is forcing the problem on the registrant (who might be
 sly and use it as a way to make the bundle contain things that the
 registry might not have intended). From my reading of the JET
 document, they call the third option "merging" when in fact it is
 just the opposite: it prevents merging by pointing at one table.

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.

There are many countries outside of Europe that have more than one official languages that by law would have to be represented in the country's ccTLD. There are even countries more that have multiple "unofficial" languages that the registries would catch tremendous grief if the people who spoke that langauge could not register names in the ccTLD.


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.

If you (or anyone!) have suggestions on how to do this with real-world examples, please send them along. I cannot see any, but I am hampered by speaking only one language and by being too close to the current proposal. Such examples might be useful in whatever proposal a multi-lingual zone adopts.


--Paul Hoffman, Director
--Internet Mail Consortium