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@anvilwalrusden.com