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

Re: Character Variant Deployment at VeriSign

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?

Yep, that is how it suppose to work.

We could probably design the system such that X is deleted and Y will become part of package2 when package1 is deleted, but such operation become "expensive" as you need to check thru all the packages. It also violate the "atomicity" principle (content of the package are not supposed to be changed after creation) and "least astonishmnent" (i dont remember getting Y when I register for Z).

The goal is to "reduce dispute" not "no dispute". In fact, I dont the the latter is possible.

-James Seng