Fw: Changing the values of domain names and the need for mapping

[Cary Karp]

I am forwarding this at Pat's request, as it does not seem to have been
distributed in normal order.

 - - - - - - - - - - 

Original message:

Date: Fri, 20 Feb 2009 13:37:32 -0500
From: "Kane, Pat" <pkane at verisign.com>
To: "Paul Hoffman" <phoffman at imc.org>, "Cary Karp" <ck at nic.museum>
Cc: <idna-update at alvestrand.no>
Subject: RE: Changing the values of domain names and the need for
mapping


Paul,

Of the items that you are discussing in this thread, assuming I
understand the question posed to VeriSign, I believe that I can discuss
the implementation at VeriSign around the Eszett and Final Sigma.

I believe that the assumption that there are domain registrations in
com and net (and for registrations made in org prior to the transition
to PIR) that contain code points 00DF and 03C2 is false.  I am having
my team confirm that.  

When we implemented IDNA 2003, we had the registrars take
responsibility for encoding the string of non-ASCII characters using
punycode.  When this encoded string is received by VeriSign from the
registrar, VeriSign unwinds the encoded string to a set of code points,
re-encodes those code points back to punycode and does a comparison
against what was received from the registrar.  If these encoded strings
match, the registration is applied to the registry.  This assumes that
there is not a variant of that string already registered, but that is
an entirely different converstaion.  If the strings do not match, we
reject the registration.

If a registrar were to send a raw encoded string, or a string of
characters that has not been processed via stringprep and nameprep, to
VeriSign, the encoded strings would not match per the process above.
Fußball would come in with a prefix xn--<encoding here> get unwound and
re-encoded to "fussball" and subsequently fail as a registration.
Error codes would be returned to the registar indicating such.

Essentially, if these changes were made in the IDNA 200x protocol,
there would be no collision in the space as those encodings should
still be available. The issue for the registrars will be registrants
who say "I registered FUSSBALL because I had to.  What I really wanted
was Fußball."  The issue for gTLD registries will be ensuring
equivalent access to these characters upon implementation of IDNA 200x.

Hope this helps.

Regards,

Pat


Patrick S. Kane
Vice President
VeriSign Naming Services
 

"In preparing for battle I have always found that plans are useless,
but planning is indispensable."

  -- Dwight D. Eisenhower