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

*To*: idn-reg-policy@xxxxxxx*Subject*: Re: Equivalence only in one direction*From*: "Adam M. Costello" <idn-reg-policy.amc+0@xxxxxxxxxxxxxxxxxxxxxxxxxxx>*Date*: Fri, 4 Apr 2003 02:40:39 +0000*In-reply-to*: <> <> <> <> <> <> <>*List-archive*: <http://www.imc.org/idn-reg-policy/mail-archive/>*List-id*: <idn-reg-policy.imc.org>*List-unsubscribe*: <mailto:idn-reg-policy-request@imc.org?body=unsubscribe>*References*: <> <> <> <> <> <> <> <> <> <>*Reply-to*: IDN registration policy list <idn-reg-policy@xxxxxxx>*Sender*: owner-idn-reg-policy@xxxxxxxxxxxx*User-agent*: Mutt/1.4i

This message responds to three people (Stephane, Roozbeh, and Martin) and three threads, but the subject line reflects the topic of the entire message. 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 defined. 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. AMC

**Follow-Ups**:**Re: Equivalence only in one direction***From:*Roozbeh Pournader

**References**:**Re: Comparison of hoffman-idn-reg and jseng-idn-admin***From:*Roozbeh Pournader

**Re: Comparison of hoffman-idn-reg and jseng-idn-admin***From:*Martin Duerst

**Re: Comparison of hoffman-idn-reg and jseng-idn-admin***From:*Paul Hoffman / IMC

**Re: Comparison of hoffman-idn-reg and jseng-idn-admin***From:*Roozbeh Pournader

**Re: Comparison of hoffman-idn-reg and jseng-idn-admin***From:*Paul Hoffman / IMC

**Re: Comparison of hoffman-idn-reg and jseng-idn-admin***From:*Adam M. Costello

**Re: Comparison of hoffman-idn-reg and jseng-idn-admin***From:*Roozbeh Pournader

**Re: New Internet Draft on registering IDNs***From:*Martin Duerst

**Equivalence only in one direction (Was: New Internet Draft on registering IDNs***From:*Stephane Bortzmeyer

- Prev by Date:
**Re: initial thoughts** - Next by Date:
**Re: initial thoughts** - Previous by thread:
**Re: Equivalence only in one direction (Was: New Internet Draft on registering IDNs** - Next by thread:
**Re: Equivalence only in one direction** - Index(es):