[vip] [arabic-vip] The "Invisible Separator Characters" Issue

[Andrew Sullivan]

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