[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
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
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
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
Or which character wins, or which registrant wins, or which orthography
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
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