Subject: [provreg] Perhaps out of scope, but valuable: IDN Codepoint

From: Jothan Frakes <[email-masked]>
Date: Fri, 27 May 2011 10:56:30 -0700

Hi-

I am spending a bit of time with the Universal Acceptance aspect of
the new TLD launches, as well as spending a fair amount of time in my
volunteer role with the Mozilla Foundation on the IDN White-list and
the curation efforts for the Public Suffix List ( PublicSuffix.org is
the URL ).

I am noticing something that might be a worthwhile standardization in
and around having some means to identify to the registrars what are
and are not legal characters to receive registrations on for a given
TLD.  I wonder if a call that could pull down the Unicode code points
and/or any registry specific normalization, case folding, or homonym
replacement mapping  might be important to have.

Each registry seems to have strong opinions about how their solution
is the best, there are numerous cultural-linguistic elements and
sensitivities that a registry might make for having their own specific
mappings, or other things that make the character set code points
distinct to a TLD.

Mileage varies in current IDN implementations, though there are some
standardizations (ie the JET Guidelines).

The status quo in registry launches is that there is a
sunrise[1..x]->landrush->general availability cycle that happens in
the legal roman characters, followed by later launches for IDN.  What
I want to make sure of is that registries that wish to start day 1
with IDN inclusive have the ability to do so in a clean and sane
manner that is unified so that registrars can assimilate them.

Is this obtuse to our focus?

-Jothan

Jothan Frakes
+1.206-355-0230 tel
+1.206-201-6881 fax

---

From: Gavin Brown <[email-masked]>
Date: Tue, 31 May 2011 11:53:36 +0100

> [snip]

I don't think it has any relevance to the LaunchPhase extension.

EPP currently has no way to signal any metadata relating to IDNs. There
was a draft for an extension but it expired some time ago.

EPP is strictly a provisioning protocol, and therefore signalling of
policy (such as what code points are permitted) is out of scope. The
current best practice is for registries to submit their IDN tables to
IANA for publication. These can then be used by registrars to
pre-validate domains before attempting to register them.

Having said that, an EPP extension that extended the semantics of
<check> might be useful - something like this:

  <?xml version="1.0" encoding="utf-8" standalone="no"?>
  <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
    <command>
      <check>
        <domain:check xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
          <domain:name>xn--eqrt2g.xn--fiqs8s</domain:name>
        </domain:check>
      </check>
    </command>
    <extension>
      <validate:check xmlns="urn:centralnic:params:xml:ns:validate-1.0">
        <validate:language>zh</validate:language>
      </validate:check>
    </extension>
  </epp>

We implemented a function in our HTTP Toolkit [1] to do something very
similar.

G.

1: https://www.centralnic.com/registrars/toolkit/doc/validate_domain

-- 
Gavin Brown
Chief Technology Officer
CentralNic Ltd
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Ltd is a company registered in England and Wales with company
number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 31 May 2011 07:23:01 -0700

And not even that,

Since you're using XML to exchange the request, if you specify the appropriate character encoding and pass the document with entities such as:

<?xml version="1.0" encoding="utf-8" standalone="no"?>
 <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   <command>
     <check>
       <domain:check xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
         <domain:name>espa&#241;ol.com</domain:name>
       </domain:check>
     </check>
   </command>
 </epp>

On the registry side, you should be able to decode it properly and generate a UTF-8 string with: español.com

Which can be validated in the registry.

IDNs should be obscured to the client as much as possible. There's no need for them to know at this level that this domain name translates into xn--espaol-zwa.com since that's something that the registry must handle internally. 

Francisco

On May 31, 2011, at 3:53 AM, Gavin Brown wrote:

> _______________________________________________
> provreg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/provreg

Francisco Obispo 
Hosted@ Programme Manager
email: [email-masked]
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
Key fingerprint = 532F 84EB 06B4 3806 D5FA  09C6 463E 614E B38D B1BE

---

From: Patrick Mevzek <[email-masked]>
Date: Tue, 31 May 2011 20:08:12 +0200

Gavin Brown <[email-masked]> 2011-05-31 12:54
> I don't think it has any relevance to the LaunchPhase extension.
 
Agreed, not related strictly to launchphase, but since we are on the
provreg mailing-list the question is indeed a valid one for EPP.

[..]

> We implemented a function in our HTTP Toolkit [1] to do something very

There are *a lot* of registry extensions (each doing it its own way)
covering this case.

I count at least 4 of them in my client EPP implementation.

In my previous draft on EPP experiences, consolidating the way IDNs
are handled was a specific point worth working on in my view, 
since one could imagine a not
too distant future where most (or even all) of the TLDs will do IDNs.

-- 
Patrick Mevzek