Re: Character Variant Deployment at VeriSign

["Adam M. Costello" <idn-reg-policy.amc+0@xxxxxxxxxxxxxxxxxxxxxxxxxxx>]

James Seng <jseng@xxxxxxxxxxxx> wrote:

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

Another approach is to have "blocked variants" instead of "reserved
variants".  A "reserved" variant belongs to exactly one package, so
you can activate it without checking for conflicts.  But a "blocked"
variant would not be reserved for just one package, it could be a
blocked variant of multiple packages.  Therefore, before you can
activate a blocked variant of a package, you need to check whether it
is also a blocked variant of any other packages (and check for any
other restrictions on its activation).  When packages are presented
to registrants, the blocked variants would not be shown, because they
don't belong to the registrant.  The registrant will not know whether a
variant can be activated until they try (because inactive variants are
not reserved for just one package).

I think this would be a minor tweak to your draft, and would solve the
problem I described.

I just thought of a related problem.  Suppose W and X are variants, and
X and Y are variants, and Y and Z are variants, but no other pairs are
variants.  Suppose someone registers W, which reserves X, and someone
else registers Z, which reserves Y.  The two registrants can then
activate their reserved labels, and now X and Y (which are variants) are
registered to different people.

If variants are blocked instead of reserved, this problem can be fixed
as follows:  Whenever a variant is activated, all of *its* variants are
added to the blocked set.  The previous example now goes like this:
Someone registers W, which blocks X, and someone else registers Z, which
blocks Y.  The first person then activates X, which blocks Y again.  Now
Y is blocked by two packages, and cannot be activated.

Basically, this would just move some of the checking and variant
construction from the package-creation procedure to the activation
procedure.  The former could invoke the latter, like so:

create_package(label):
  verify the syntactic validity of the label
  activate(self,label) (fail if this fails)
  generate the set of recommended variants of the label
  for each variant activate(self,variant) (ignore failures)

activate(package,label):
  verify that the label is not blocked by any other package
  generate the variants of the label
  verify that none of the variants is an active member of another package
  add the label to the package's active set
  add the variants to the package's blocked set

deactivate(package,label):
  remove the label from the package's active set
  update the package's blocked set (could recompute the blocked set
    from scratch, or regenerate the label's variants and decrement a
    reference count for each one and remove the labels whose count
    becomes zero)

If the variant relation is symmetric, then the second verification step
of activate() will never fail, so it can be eliminated.

AMC