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

Re: Equivalence only in one direction

This message responds to three people (Stephane, Roozbeh, and Martin)
and three threads, but the subject line reflects the topic of the entire

Stephane Bortzmeyer <bortzmeyer@xxxxxx> wrote:

> This is a special case of a more general issue, which is not clearly
> stated in the current draft: equivalence goes from the Left Hand Side
> to the Right Hand Side but not the reverse.

Roozbeh Pournader <roozbeh@xxxxxxxxxx> wrote:

> I was talking about variants that are shared between two different labels
> (that are not variants of each other), which *will* happen in zones, since
> we can't define the equivalence tables to be 'equivalence classes' (in
> mathematical terms).

Now that we're finally starting to understand each other, I'd like to
request that everyone please stop using the word "equivalence" to refer
to relations that are not equivalence relations.  It's confusing.  I
jumped to the conclusion that my approach and Paul's approach were
essentially the same, merely described differently, because Paul's
draft uses the word "equivalent" for the variant relation.  Now I (and
Martin) are starting to see that the two approaches may be fundamentally
different afterall.

An equivalence relation is a relation that is reflexive (X is equivalent
to itself), symmetric (if X is equivalent to Y, then Y is equivalent to
X) and transitive (if X is equivalent to Y, and Y is equivalent to Z,
then X is equivalent to Z).

In the quotations above, Stephane wants to talk about relations that
are not symmetric.  Roozbeh wants to talk about relations that are
not transitive.  That's fine, but we all (myself included) need to be
careful to state our assumptions and choose our terms carefully.

Roozbeh Pournader <roozbeh@xxxxxxxxxx> wrote:

> I am talking about two main labels that are not variants of each
> other, but share a variant.
> 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?

Very good question, illustrating how much more complex the situation
becomes when the relations are not equivalence relations.  More
generally, let's consider various orders of registrations.

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.

scenario 1:
  User1 asks for V.
  User2 asks for X.
  User1 asks for X.

scenario 2:
  User1 asks for X.
  User1 asks for V.
  User2 asks for Y.

scenario 3 (same as 2 but reordered):
  User1 asks for X.
  User2 asks for Y.
  User1 asks for V.

It's not obvious who should get what in each scenario.

> 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).

Presumably it would be okay for the outermost region of one registrant
to overlap the outermost region of another registrant.  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

Martin Duerst <duerst@xxxxxx> wrote:

> I think I agree with Adam that his approach then is easier to
> describe, because it can describe how to map one label to one other
> label, which should make the description a lot simpler.  But of course
> I would like to first see an actual wording from Adam.

Here's one way the groupID function might work:

 1. Apply ToUnicode to the label.
 2. Apply Nameprep to the label.
 3. Initialize an empty string buffer.
 4. While the label is not empty apply a two-column mapping table
    (containing strings in both columns) as follows:
     a. Find the longest prefix match between the label and the first
        column of the table.
     b. If there was no match then remove the first character of the
        label and append it to the buffer, otherwise remove the matching
        prefix from the label and append the corresponding string (from
        the second column of the table) to the buffer.
  5. Apply ToASCII to the buffer.
  6. Apply tolower() to the buffer and return the result.

This serves only to define an equivalence relation.  If we decide we
need some other sort of relation, this sort of function might not be
useful at all.