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

a model for bundles and blocking



I wrote:

> Here's an example of how a registry might decide whether to admit
> a name.  Suppose the zone supports a set L of languages.  For each
> language in L, there is a function Valid(language;label) that checks
> whether the label is valid in that language, and another function
> TooClose(language;label1,label2) that checks whether two labels are
> confusingly similar in that language.
> 
> I suggest that the registration of a new label be allowed if
> 
> (1) Valid(language;label) is true for at least one language in L, and
> 
> (2) TooClose(language;label,existing_label) is never true for any
>     existing label, for any language in L.
> 
> Notice that the language tags of the names never come into play for
> deciding what blocks what.  Language tags might still be used for other
> purposes, though, like pricing and the domain management user interface.

The above example focuses only on blocking, but a full solution needs to
deal with what actually appears in the zone.  Here's a stab at a more
complete model:

A bundle consists of one or more labels, all of which appear in the DNS
zone.  Exactly one of the labels is flagged as the "center" label, and
the bundle is tagged with a language.  Many labels that are not in the
bundle will be blocked by the bundle (which means they cannot be added
to other bundles).  The set of labels blocked by a bundle is simply the
union of the set of labels blocked by each label in the bundle; it does
not depend on the language tag or the center flag.

The labels blocked by a bundle really don't belong to the bundle in any
sense.  To underscore this point, notice that a label might be blocked
by multiple bundles.

The registrant of a bundle is not necessarily able to obtain a list of
all labels blocked by the bundle (it might be a huge list, and might not
be stored anywhere).  But of course anyone can asked whether a single
label is available, and if the answer is no, the inquirer might be told
why the label is unavailable (it is already registered, or it is blocked
by existing bundles, which might be listed).

The zone supports a set L of languages.  For each language in L, there
are functions Valid(language;label), TooClose(language;label1,label2),
and Price(language; center_label, peripheral_label).  When the first
label of a new bundle is being registered, the registration is allowed
if

(1) Valid(language;label) is true for at least one language in L, and
  
(2) TooClose(language; label, existing_label) is never true for any
    existing label in the zone, for any language in L.

Notice that these checks look at the zone as a set of labels, not as a
set of bundles of labels.  These checks look at all the labels in the
zone and at all the variant tables used by the zone but pay no attention
to bundle boundaries, language tags, or center flags.

When the bundle is first created and has only one label, its language
tag can be null, because the language tag is not needed yet.  If the
registrant never wants to add any peripheral labels to the bundle, then
there is no need to ever set the language tag.  In this way, registrants
can get the traditional registration behavior (no language tags, no
variants).  The bundle will still cause other labels to be blocked, but
that's a behavior of the zone, not a behavior of this bundle.

If the registrant wants to add any peripheral labels to the bundle,
they must first choose a language tag for the bundle, which must be
consistent with the single label that already exists in the bundle; that
is, Valid(language_tag; label) must be true.

When a peripheral label is being registered as an addition to an
existing bundle, it is allowed if

(1) Price(language_tag; center_label, peripheral_label) is less than
    infinity, and

(2) TooClose(language; peripheral_label, existing_label) is never true
    for any existing label in the zone, for any language in L.

Step 2 is the same as before, and pays no attention to bundle
boundaries, language tags, or center flags.  Step 1 does, but it deals
entirely with the internal affairs of one bundle, not with issues that
affect the whole zone.

The Price() function could be quite simple, always returning zero or
infinity, or could be more complex, with tiers of prices depending on
the closeness of the peripheral label to the center label.

A registry could optionally allow the registrant to change the language
tag of a bundle, or to recenter it (move the center flag to one of the
current peripheral labels).  Of course these operations would alter all
the prices, and might cause some to become infinity, which means they
would be removed from the bundle.

AMC