[vip] Suggested meta-questions to think about

[Andrew Sullivan]

On Fri, Jun 24, 2011 at 08:31:40PM +0800, Vladimir Shadrunov wrote:
> Are we sure we really need to draw the lines as to what a variant is and
> what a variant isn't?
> 
> Why can't we just say that a variant is whatever the registry wants to be a
> variant? The registry only needs to define a unique way of finding out
> whether String1 is indeed a variant of String2 or not.

Without disagreeing with Cary's remarks elsewhere in this thread, I'd
like to take a different line.

Suppose we assume the above: the registry only needs to define a
unique way of finding out whether string1 is indeed a variant of
string2.

Now, ICANN is in effect the registry (or at least the registry
policy-holder) for the root zone: it is the technical co-ordination
body that publishes the policies for the root zone.  Those policies
are developed in various ways inside the ICANN processes; how is not
that important for our task.  (Please note that this is not a claim of
ICANN authority over the root zone, to impinge on the authority of
sovereigns or the independence of the root operators, or any other
such controversial claim.)

So, if we assume (1) that this is just a matter of registry policy,
and (2) that ICANN needs to have such a policy for the root zone, then
it is clear why this group needs to investigate (and try to develop) a
general rule for what a variant is and what a variant isn't: ICANN
needs an emprical foundation for the development of such a policy
(according to the usual ICANN policy development procedures).
Alternatively, perhaps we will find that "variant" doesn't mean one
thing, but actually means different things -- v1, v2, v3, and so on.

I believe that any ICANN policy could not be "do whatever the
applicant says", because that would just push the problem one step
deeper.  Suppose two applicants requested conflicting things?  What
applicant should be preferred?  What exactly to do is a policy
question and beyond our remit, as far as I understand it.  But surely
our remit is to tease out the principles by which such a policy could
be made.

Now, our answer might well be, "It's something that has to be decided
case by case," or even, "A general description of 'variant', whatever
it is, is impossible."  If that be our conclusion, then we need to
report as much back so that the policy makers can work with that
input.  But I believe we can do better, by working according to our
plan to study the issues under various scripts, and then to draw some
(perhaps tentative) conclusions from that.

One other thing:
 
> On the Second Level the registry might wish to declare that, for example:
> - for Chinese script the variants for traditional characters are
> corresponding simplified charaters
> - for Cyrillic script Е is a variant for Ё with no other variant
> relationships between characters

It need not be the case that a variant policy at the root level
(i.e. for TLDs) would extend all the way down the tree.  It is likely
going to be true, however, that for the simple reasons of user
experience, rules that get adopted at the top level will end up being
used elsewhere in the tree.  (We can draw an analogy with the label
"www", which is used very widely for web servers even though there is
no reason it must be.  Why?  Because everyone expects it to work like
that.)  Speaking only for myself, the reason I supported talking about
other parts of the tree than just the top level is that I think
existing practices elsewhere in the DNS can inform the things we think
are reasonable in the top level.

Best,

Andrew

-- 
Andrew Sullivan
ajs at anvilwalrusden.com