Subject: Sending the original (Unicode) domain name as well as the ACE?

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 6 Aug 2002 09:03:50 +0200

This issue was raised on the Crisp mailing list
<URL:http://www.ietf.org/html.charters/crisp-charter.html>. It seems
it could be a good idea, for the registry, to store the original
(Unicode) form of an IDN, as well as its ACE (ASCII-encoded) form. 

It would allow more searches (Crisp protocols do not perform only
exact-match searches but also partial-name searches, which are not
possible on the ACE form).

Am I correct when reading draft-ietf-provreg-epp-domain-04.txt that it
contains nothing about transmitting the original form from the
registrar, which knows it, to the registry?

And that <domain:name> is only the ACE form? Shouldn't we add an
optional element <domain:original_name>?

---

From: Rick Wesson <[email-masked]>
Date: Tue, 6 Aug 2002 00:16:01 -0700 (PDT)

> optional element <domain:original_name>?

since epp's char set is utf8 i see no reason why a native utf name
cound't be enclosed in <domain:name> insted of the ace name.

-rick (who is guessing)

---

From: Dave Crocker <[email-masked]>
Date: Tue, 06 Aug 2002 00:19:50 -0700

>possible on the ACE form).

ace is an encoding form.  so is utf-8.  so is utf-16.  all of them are unicode.

so ace is just as much "original (Unicode)" as utf-8 or utf-16.

There is no informational benefit in having the string stored in two 
different encodings.  There also is not computational benefit, given that 
the strings are so short.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.850.1850

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 6 Aug 2002 09:27:19 +0200

On Tue, Aug 06, 2002 at 12:16:01AM -0700,
 Rick Wesson <[email-masked]> wrote 

> cound't be enclosed in <domain:name> insted of the ace name.

It is a matter of registrar-registry policy. I assume that a IDN
registry will require its registrars to create domain with
<domain:name> set to the original form OR the ACE form. And that this
choice will be uniform among all the registrars.

For instance, if the registry decides it will accept the original
form, it will have to perform nameprep before deciding if the domain
is already registered.

But, if the registry decides to let the registrars encode the IDN in
ACE, it could be useful to accept the original name as well (remember
also that the mapping between the IDN and its ACE form is N->1 and
1->1 in reverse so the registry cannot compute the original form
itself).

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 6 Aug 2002 09:29:50 +0200

On Tue, Aug 06, 2002 at 12:19:50AM -0700,
 Dave Crocker <[email-masked]> wrote 

> ace is an encoding form.  so is utf-8.  so is utf-16.  all of them are 

Big difference: you can go from UTF-8 to UTF-16 (and back) without
losing information. You CANNOT go from UTF-8 (or 16) to ACE without
losing information (because of nameprep).
 
> so ace is just as much "original (Unicode)" as utf-8 or utf-16.

I slightly disagree.

> different encodings. 

I do not regard ACE as an encoding of Unicode.

---

From: Patrick <[email-masked]>
Date: Tue, 6 Aug 2002 12:47:56 +0200

> > cound't be enclosed in <domain:name> insted of the ace name.

I totally agree with Rick's comments.

> choice will be uniform among all the registrars.

My opinion is that Registry should accept the UTF-8 version and do
the ACE things by themselves. Of course this is a matter of policy.

> form, it will have to perform nameprep before deciding if the domain

This is not a problem, I think.

> ACE, it could be useful to accept the original name as well (remember

See http://www.verisign-grs.com/idn/techpaper.pdf for an example.
The Registry takes the ACE version, translates it to ISO10646,
do again the nameprep+ACE stuff on it, and compare its result with
what was given by the Registrar.

Patrick.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 6 Aug 2002 14:06:32 +0200

On Tue, Aug 06, 2002 at 12:47:56PM +0200,
 Patrick <[email-masked]> wrote 

> I totally agree with Rick's comments.

In theory, yes. In practice, it is probably fair to assume that few
EPP servers will be happy with Unicode. I just tried on LibertyRMS
testbed and I got:

Executing domain create [aÃ¨Ã§Ã .epp]
    Code: 2005
    Message: Parameter value syntax error
     2005:Parameter value syntax error (Value contains invalid character: -1(ã))

It is not a message for a policy violation :-)

---

From: Patrick <[email-masked]>
Date: Tue, 6 Aug 2002 17:31:18 +0200

> EPP servers will be happy with Unicode. I just tried on LibertyRMS

The fact that it is already now possible with the EPP protocol, does
not mean necessarily that
1) there are EPP implementations out there that support it
2) there are policies that accept it.

It is just possible.

I suspect that when the idn IETG wg will finish its work, new
Registries will start accepting IDN registrations, and thus make sure
that their EPP software and that their policies are ok with that.

Patrick.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 7 Aug 2002 15:42:36 +0200

On Tue, Aug 06, 2002 at 09:03:50AM +0200,
 Stephane Bortzmeyer <[email-masked]> wrote 

> (Unicode) form of an IDN, as well as its ACE (ASCII-encoded) form. 
...
> registrar, which knows it, to the registry?

Funny, but I did not notice yet that
draft-ietf-provreg-epp-contact-04.txt (which does not deal with IDN at
all) suggests exactly that for contact information.

  - One or two <contact:postalInfo> elements that contain postal address
  information.  Two elements are provided so that address information
  can be provided in both internationalized and localized forms.  If an
  internationalized form is provided, it MUST be listed first and
  element content MUST be represented in a subset of UTF-8 that can be
  represented in the 7-bit US-ASCII character set.  If a localized form
  is provided, element content MAY be represented in unrestricted UTF-8.
  The <contact:postalInfo> element contains the following child
  elements:

I'm curious about the rationale. Why not just accepting Unicode and
translating it to ASCII when necessary? Is it because automatic
transliteration of Unicode to ASCII is quite difficult so we prefer
that the registrar does it?

---

From: Patrick <[email-masked]>
Date: Wed, 7 Aug 2002 16:09:48 +0200

> translating it to ASCII when necessary? Is it because automatic

How do you translate Chinese and Japanese and many other characters
available in Unicode to ASCII ?

> that the registrar does it?

There were threads about this in the past.
I remember vaguely that there was something about putting only ASCII
in whois, since Unicode in that would probably break many clients.

Patrick.