[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
The following message was originally sent last Friday, but never made it
to the list.
Registration policy was on my mind today, so I wrote up my thoughts,
then looked at the list archive and Paul's draft for the first time.
Apparently Paul and I think very much alike on this topic (probably
because we'd seen the same earlier documents). Here's what I wrote:
What policies ought a registry have before it starts admitting IDNs?
1. A policy defining what labels are admissible. This could be a set
of allowed characters, or could be more complicated (for example, it
could involve sequences of characters). The policy should allow only
those strings for which the registry has sufficient expertise to define
a sensible grouping policy (see below). The set of admissible labels
can start small and gradually be expanded as the registry develops (or
2. A policy defining how labels are grouped. With traditional ASCII
domain names, you register one name, and you get one name. If you
register color.com, that doesn't prevent someone else from registering
c010r.com or colour.com. For IDNs, it may be prudent to partition the
set of admissible labels into groups (every admissible label belongs to
exactly one group), where the group is the unit of registration; that
is, registering any label in the group allocates the entire group, so
that no one else may register any label in the same group. This policy
could be implemented by defining a function that maps a label to a
group identifier, which could be a canonical member of the group. The
function might work by applying ToUnicode, then Nameprep, then some
custom mappings of individual characters or sequences of characters,
3. A policy defining how lookups behave with respect to groups. Does a
lookup return the same resource records no matter which member of the
group is queried? Or does the lookup fail except for particular members
of the group chosen by the registrant (or by the registry)?
All of the above policies need to be unambiguously specified and
publicly available, so that registrants know what they're buying.
I think those three things are all that is needed. In particular, I
don't think it would be helpful to associate a language tag (or tags)
with a registration; I think that would just raise unnecessary questions
That's very close to Paul's draft, but there are a few slight
Paul's draft assumes that the policies can focus on single characters,
and disregard sequences of characters. I wonder if that might not be
powerful enough for some registries.
We both propose partitioning the set of admissible labels into groups
(bundles). Paul imagines a function that constructs the entire group
given any member of the group, while I imagine a function that computes
a group identifier given any member of the group, where the group
identifier could be a single member of the group arbitrarily chosen to
stand for the whole group. Either kind of function implies the same
partition of the space, and both functions would use the same tables,
but I think the group-id function might be easier to describe and
understand. The group-construction function might be useful internally
by the registry, if the registry needed to enumerate the group, but that
doesn't really scale.
That brings us to an issue I neglected to address: If the registry (or
the registrant) decides that all members of the group should be visible,
how will that work? Will it scale? The combinatorics are exponential.
I think the only way it would work well is if the authoritative DNS
servers (both the registry's servers that delegate the name, and the
registrant's servers that provide the data for the name) include support
for the grouping. I guess you would supply the tables to the DNS
server, and it would perform the group-id computation whenever a request
comes in, then look for the group-id in the zone database. This would
require a standard machine-readable format for describing the grouping
policy for a zone.
Without that support in the DNS server, I think the sensible approach
is for the registrant to choose individual member(s) of the group to be
visible, and let the others be invisible (blocked). Registries could
come up with a pricing plan, maybe the normal registration fee for a
group with one visible member, and a small additional fee for each
additional visible member.
You could also imagine that the registry, rather than the registrant,
chooses which member(s) will be visible, but I think it would be
difficult for registries to come up with rules that would please
everyone; it would probably be easier to let the registrant choose, and
simply store the list.