Changing the values of domain names and the need for mapping

John C Klensin klensin at jck.com
Fri Feb 20 20:31:04 CET 2009


Pat,

My thanks for this.  My impression is that most responsible
registries that handle IDNs have, by now, adopted procedures
very similar to the one you describe because the alternatives
just lend themselves to too much possibility of
misunderstandings (or worse), but it is good to hear directly
from you what Verisign is doing.

best,
      john


--On Friday, February 20, 2009 13:37 -0500 "Kane, Pat"
<pkane at verisign.com> wrote:

> 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






More information about the Idna-update mailing list