Hi Daniel, Thanks for your response. Since ICANN has engaged me as a resident technical guy, I'm going to respond with that (somewhat geeky) hat. On Sat, Jun 25, 2011 at 06:47:34AM +0300, Daniel Kalchev wrote:
ICANN is just preparing to enter the "registry business" with the introduction of the new gTLDs.
I want to distinguish between "being a registry" and "the registry business". In the DNS world, where I come from, everyone who operates a zone and performs delegations from it is "a registry". It's possible to be a registry for some.strange.domain.name.example, even though you'll probably never make any money at it. That ICANN is charging amounts of money for entries in the root zone and so on is important from a business/legal/political point of view, but it does not directly impinge on the techno-policy implications of that decision. In my (personal) view, we are charged with providing guidance about that techno-policy only. I have my own views about the wisdom of expanding the TLD space; but given that it is happening, what are the issues that need to be addressed? We are tasked, as I understand it, with addressing one of the latter types of issues. If I am misunderstanding, I'm sure others will correct me.
The DNS is designed in such a way, that uniform technical rules apply to any label at any level in the hierarchy.
That is only sort of true, and it is not much true at all for registration policies. For instance, many people do not realise that there is no strict technical restriction at all of what eight bit octet you can put in your zone. DNS labels are made of octets. If you want, in your zone, to put any series of bits you like in there, you can do so. This means that you could just plop UTF-8 directly into the zone; and some people have done this. But, the RFCs (STD 13) also say that it would be better to stick to the hostname rules ("letter, digit, hyphen"). So, in the TLD space, we have mostly stuck to this, for maximum interoperability on the Internet. The closer you are to the root, the more conservative you need to be, since things will break otherwise. But there are plenty of labels lower in the tree that don't follow that. No TLD of which I am aware, for instance, permits "underscore labels" (_example.example.com). But they're not only legal, they're important for the functioning of things like Apple's Bonjour, DKIM, and so on.
From what we have so far, there seems to be strong opinion, that variants should be considered character based and script specific. I will again voice my opinion, that variants are label (word) based and language specific. Or even go as far to suggest sometimes they are community or region specific.
For the sake of argument, let me grant that variants are label based and language specific. (I've on purpose left aside "word" because it's a disaster: "ns1" is a perfectly viable DNS label, but it is not a word in any language as far as I know. For that matter, "com" is a perfectly viable label, but it's not a word in English, even though people keep insisting it is. And as soon as we start talking about words, we have the problems of neologisms and trademarks -- neither of which are in any dictionary except in very unusual cases -- as well as the problem of which dictionary to pick.) Now, suppose you receive a DNS registration request for "monaco.example". Does it have a variant? Well, if you're Italian targetting a German market, the answer is, "Yes". We don't have an "intention bit" that comes with attempted DNS registrations -- never mind DNS lookups, on which I haven't touched in the above example. This makes the situation terribly complex, and it is why, in the absence of a complete proposal for how a label-wide variant system would work, I have been arguing we shouldn't go down that path. If, however, you have a proposal for how a complete label-based variant system might work, I would be very keen to review it; and I would enthusiastically contribute to its development if it seemed viable. Until I see such a proposal, however, I remain very sceptical that it is possible except in the most constrained environments. And since gTLDs are by definition not constrained environments, I am worried about any suggestion that we ought to work label by label. Best regards, Andrew -- Andrew Sullivan ajs@anvilwalrusden.com