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

Re: Character Variant Deployment at VeriSign



James Seng <jseng@xxxxxxxxxxxx> wrote:

> > But is it possible for a label to be blocked by multiple bundles,
> > so that no one can register/activate it?  This is important if the
> > variant relation is not transitive, as some people (like Roozbeh)
> > have argued that it needs to be.
>
> Yes, it is possible.  It is also dealt with in the JET IDN Admin.
>
> Basically, we deal with it on FCFS (or whichever dispute policy is in
> place for the zone).

I have now read draft-jseng-idn-admin-02, and I don't see how it can
accomodate the non-transitive variant situation I described, especially
if first-come-first-serve is the conflict policy.

Let's walk through it.  Recall that X and Y are variants, and Y and Z
are variants, but X and Z are not variants.

Someone registers X, causing the creation of package1 containing X (in
the zone) and Y (reserved).

Someone else registers Z, causing the creation of package2, containing
Z (in the zone).  Package2 would like to contain Y (reserved), but this
conflicts with package1, so the FCFS conflict policy is invoked, which
leaves Y in package1, and allows package2 to be created without Y.

Now the first person deletes package1.  Section 3.3 is very explicit
about what happens:

    When an IDL Package is deleted, all the active and reserved variants
    would be available again.  IDL Package deletion does not change any
    other IDL Packages, including IDL Packages that have variants that
    conflict with the variants in the deleted IDL Package.

So now package2 is unaffected, and Y is available.  Now a third person
can come along and register Y.  Now Y and Z are registered to different
people.  But a primary purpose of the whole system is to prevent two
variants from being registered to different people, right?

AMC