Implementation questions (digressing from...)

[Andrew Sullivan]

On Tue, Dec 23, 2008 at 02:51:05PM -0800, Mark Davis wrote:
> Half of what the protocol does is impose requirements on registries.
> Are you saying that we should remove those?

I don't think I fully understand that claim.  In some trivial sense,
of course it imposes requirements on registries.  But the protocol
goes out of its way so far to avoid making any policy decisions for
registries about which code points they should permit from the entire
set of allowable ones, and from making any policy decisions about
which things must be treated as equivalent.

I think it would be entirely unwise to tell registries, for instance,
that if they currently have registrations that might have had ß in
them in the past but that were instead mapped to "ss", then they must
treat them as equivalent.  In at least one instance with which I am
personally familiar, the registry simply doesn't have that
information.  There'd be no way to tell.  And in the registry of which
I'm thinking, you couldn't trivially go through and look for "ss"
and make assumptions, because it's a gTLD.

These backward compatibility issues are a problem that will need to be
handled differently by different registries.  They will need to come
up with careful and tricky answers that meet their local conditions.
That is the cost of pushing this sort of mapping out to the ends of
the network.  If we don't like that, we should give up on the new
protocol effort and stick with the (admittedly flawed) one we have.
Alternatively, we should decide that we have a new protocol and
replace the xn-- ACE indicator with a new one, to signal the
incompatibility.  That's not too popular with registries either.  But
if I were still in charge of wrangling data at a TLD, I'd darn sure
prefer that to "figure out which of these ought to have had a variant,
and magically create it".  The former's a large PITA.  The latter's
impossible, because it involves knowing something about the intention
of the registrant some time in the past.

A

-- 
Andrew Sullivan
ajs at shinkuro.com
Shinkuro, Inc.