Changing the values of domain names and the need for mapping

[Kane, Pat]

All,

As a followup to the post from last week there are currently no registrations contained within the com/net registration base that contain the Eszett or the Final Sigma.  Good news.  Name/string prep implemented correctly and no defects introduced.   

However, I may have answered the wrong question.  While we can be certain that there will be no authoritative name space collisions between existing registrations and new registrations that may appropriately contain code points 00DF and 03C2, there were anecdotal reports from registrars where registrants intended to register those code points as part of domain labels within com and net.  These registrant stories ranged from at best surprise and in some cases very angry phone calls Customer Service staff.

Hope this helps.

Pat

Patrick S. Kane
Vice President
VeriSign Naming Services


-----Original Message-----
From: idna-update-bounces at alvestrand.no [mailto:idna-update-bounces at alvestrand.no] On Behalf Of Kane, Pat
Sent: Friday, February 20, 2009 1:38 PM
To: Paul Hoffman; Cary Karp
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

-----Original Message-----
From: idna-update-bounces at alvestrand.no [mailto:idna-update-bounces at alvestrand.no] On Behalf Of Paul Hoffman
Sent: Friday, February 20, 2009 12:24 PM
To: Cary Karp
Cc: idna-update at alvestrand.no
Subject: Re: Changing the values of domain names and the need for mapping

At 5:57 PM +0100 2/20/09, Cary Karp wrote:
> > The main question for this group is what those actions are. Some
>> actions would cause lack of interoperability with current names, 
>> others would cause new requirements on current domain name owners, 
>> and others would be just fine. Without knowing what these registries 
>> plan, this WG cannot decide the stability effects of our decisions 
>> here.
>
>Have I really understood this correctly? 

No.

>In order for us to be able to
>articulate constraints that the registries will need to implement, the 
>registries first need to tell us how they intend to implement those 
>constraints. ??

We are proposing changes that will change the DNS operations of registries and registrants. We can

a) demand they operate in one particular fashion

b) list some acceptable operational changes (and possibly some unacceptable ones as well)

c) let them guess what they should do

Right now, we are at (c).

In the IETF, making protocol changes that affect operations of something as valuable as the DNS and not giving any operational advice is rare. If we want to do either (a) or (b), we either need to come up with the operational changes ourselves or hear from the affected parties about what they are thinking. I believe the latter is better.

> > Well, we can take this discussion to the DNSOP WG, but I think this
>> list is certainly more appropriate. The operational affects of our 
>> decisions is indeed something we need to consider, so it is 
>> reasonable to expect details of operational plans to appear here.
>
>The largest part of those plans involve marketing and client relations 
>issues that cannot possibly be of concern here.

We fully disagree here. The largest part of the plans is how to operationally handle the mapping / bundling / binding of the names.

>Any time a new
>character is made available for registration, a registry that decides 
>to support it is going to need to deal (often via registrars) with 
>people who would have preferred to include it in names they had 
>previously registered, and who are now concerned about somebody else 
>getting the form initially desired.

That may be true, but it is not what we are talking about. We are talking about how, operationally, a registry can give a new name to a registrant that already registered a previous name, and how, operationally, that registrant will have to handle two names that are supposed to act in an identical fashion.

If you think this is really just about marketing, maybe we should take this discussion to the DNSOP WG.

>How on earth can we know that nothing is ever going to become available 
>in that process that will trigger issues such as those presently 
>attaching to the Eszett and the final form sigma?

See my proposal for IDNAv2 (the straight upgrade to IDNA2003). It explicitly prohibits this kind of "sorry that you trusted us on stability the last time" change.
_______________________________________________
Idna-update mailing list
Idna-update at alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update
_______________________________________________
Idna-update mailing list
Idna-update at alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update