[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comparison of hoffman-idn-reg and jseng-idn-admin
At 9:56 PM +0430 3/31/03, Roozbeh Pournader wrote:
A registry MUST NOT blindly combine multiple tables which have
overlapping equivalences. Instead, the registry MUST carefully analyze
every instance in the combined table where a base character has one or
more different variants and select the desired set of variants for the
(But unfortunately doesn't suggest any guidelines when doing so.)
Correct. I think that if I give a few suggestions for guidelines, it
will lead readers to think that the problem is simple, which it is
not. Either we list lots and lots, or none.
I will add a note about why I have done none; see below.
Unfortunately, the list ends here. Specifically, there are fetures that
are *required* for Arabic but are missing in the language of the tables.
And therefore it will be added. (Note to the list: I doubt that
Arabic is the only language that I missed. If you know of others,
please speak up!)
1. Mandatory equivalences as opposed to secondary/variant equivalences.
This feature is necessary for defining equivalences between European and
Arabic-Indic digit shapes in Arabic labels, for example.
Very good point! This is a registry-specific early mapping step that
must be done. I think it should be done before the variants are
checked in the table; do folks here agree?
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
3. Clear language with specific guidelines and real-life examples for
merging tables for different languages/locales.
Currently, I believe that there are three possibilities:
- the merging is trivially easy because there is no overlap
- the merging is a policy decision by the registry at the time of
table-making as to which language "wins" for the overlapping
- 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.
4. Better syntax for the table. Don't you agree that a U+ABCDU+BCDAU+CDAB
syntax is unreadable? Why can't one use a space?
Spaces as separators in tables cause problems going through gateway
programs. I'm happy to add an inter-character separator of "-".
--Paul Hoffman, Director
--Internet Mail Consortium