Dear colleagues, On Fri, Jul 29, 2011 at 10:22:26AM +0100, Nicholas Ostler wrote:
On 29/07/2011 07:37, Patrik Fältström wrote:
The DNS only have three parameters in a query: {owner, type, class}. In fact, this may not be an impossible probem. The rules given by Unicode and RFC 5892 refer to properties of characters (e.g. Canonical_Combining_Class, Joining_Type:{L,D}, Joining_Type:{R,D} not to languages as such. So, in principle, the rules would apply universally, regardless of local registries' languages.
While this is true, it misses the core of Patrik's point. There is no practical way to perform these checks at lookup time in all but the most specialized zones (and certainly, they can't be performed at the root). Recall that the actual lookup is not for a U-label, but for an A-label. In order to perform the necessary context checks, a DNS server would need to perform the A-label/U-label transformation, and then perform the context check. Now, DNS lookups need to happen in milliseconds. These days, in order to deal with things like IPv6 transition mechanisms (the so-called "happy eyeballs" approach), DNS timeouts by clients have been scaled back practically to nothing. The old one or two second long timeout is a thing of the past. So the overhead would be too great for clients to wait for it. In addition, in order to get this benefit, any DNS authority server (and maybe any cache, but let's say not) that was serving a zone with these joiners would also need to be upgraded (either with a shim in front or else as part of the software itself) in order to perform this transform-and-check step. But the whole point of IDNA is supposed to be that we can do the job without touching the DNS servers or protocol. If we can open that can of worms, we could surely come up with something better than IDNA. Regardless, it would be asking far too much that the root server infrastructure be modified in this way, at least in the near term. So, in short, resolution-time checks will not be possible. This leaves only strong rules restricting registration of labels with the joiner code points. In respect of registration rules, in large, delegation-only or delegation-mostly zones (like the root and most TLDs), it is always preferable to start with the most conservative policy and gradually relax the rule. This is because it is very hard to remove a working delegation, but it is always easy to add a new one. Consider that removal of delegation from the root is incredibly rare. Consider, too, that the ICANN-agreement gTLDs all have a large number of grace policies designed to ensure the maximal probabilty of a registration being made correct (and properly paid for) instead of having the delegation get lost. These are both evidence for the proposition that it is easier to add a new delegation than to remove an existing one, and therefore reasons for caution in expanding registration rules at the root (or indeed, in any TLD). Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com