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

Re: Equivalence only in one direction

On Fri, 4 Apr 2003, Adam M. Costello wrote:

> Let's call these three labels X, Y, and V, where V is the common
> variant of X and Y, and X and Y are not variants of each other.

Which of the following tables do you mean?





> > 1. Required: Always resolving. Example: different digit forms
> > (U+0030->U+0660).
> >
> > 2. Variant: Optionally resolving. The current variant.
> >
> > 3. Blocking: Reserved forever. Example: Arabic vs Persian Yehs
> > (U+0649->U+06CC).
> I think I'm starting to understand your vision.  Let's me try to explain
> it back to you to check..  The name(s) that the registrant requests
> is(are) the center(s) of three nested regions of the namespace.  The
> innermost region contains all the labels that are automatically active
> and delegated to the registrant.


> The next larger region contains all the labels that the registrant
> controls (including both the automatically active labels and the labels
> that the registrant may activate at any time with no further collision
> checking).


> The largest region contains all the names that cannot be delegated to
> any other registrant (some of them cannot be delegated to anyone at
> all).

Correct. (But I will emphasize the part in the parentheses.)

> Presumably it would be okay for the outermost region of one registrant
> to overlap the outermost region of another registrant.

Not only it would be okay, but it would be unavoidable because of language
requirements. (Well, actually this is Unicode requirements, it is the way
Unicode model that makes this unavoidable. You can usually design a
character set for your zone that doesn't have some of these requirements.)

> But it would not be okay for the outermost region of one registrant to
> overlap the middle region of another registrant.


> I have not begun to think about how these regions might be formally
> defined.

I suggest using three levels of variants (U+AAAA|U+BBBB|U+CCCC|U+DDDD),
with some specified restrictions (TBD) on the data to make sure certain
overlaps don't happen in the data. 'jseng-idn-admin' already specifies two