Subject: [ietf-provreg] EPP Extensions for IDN

From: "Dan Maharry" <[email-masked]>
Date: Wed, 4 Apr 2007 14:54:29 +0100

Hi,

Is there an rfc or a draft of EPP extensions for supporting IDNs at all?
If so, where can I find it. There's a draft 1 of a doc about this
floating about but its from a while ago and I notice that PIR are
running IDNs for .org so am I right in thinking there's been progress on
this that I can't find?

Please advise,

Dan

Dan Maharry
Technical Manager
Midcounties Co-operative Domains Ltd 

The Midcounties Co-operative is an innovative co-operative business, owned by its customers and staff in the 9 counties it spans. We trade in a
number of retail sectors including food, travel, funerals, motors, childcare, pharmacy, post offices and IT. We are proud to be a successful
co-operative, founded on co-operative values and principles that co-ops share throughout the world.

This e-mail is confidential and is for the named recipient(s) only. If you are not the named recipient(s) please do not disseminate or copy this
e-mail, but please delete it and any copies from your computer. The Midcounties Co-operative has taken reasonable precautions to ensure that
any attachment to this e-mail has been checked for viruses. However, we cannot accept liability for any damage sustained as a result of
any such viruses and advise you to carry out your own virus checks before opening any attachment. Furthermore, we do not accept responsibility for any
change made to this message after it was sent by the sender. 

*** The Midcounties Co-operative works to protect our environment ***  
*** Please don't print this e-mail unless you really need to ***

This Message has been Scanned by SurfControl(c) Email Filter

---

From: "Michael Young" <[email-masked]>
Date: Wed, 4 Apr 2007 10:08:13 -0400

Hi Dan 

Edmon Chung (supported by Scott Hollenbeck and Ted Hardie) floated the idea
of this at a BOF a couple of years ago.  It was shot down by the community
due to the many external policy influences and lack of a central language
authority. In the archives you will find at least two submissions regarding
IDNs and EPP.  One is a discussion document and one is an actual extension
implemented by Afilias (that sounds like the one you have in hand).  I don't
think any others have since been submitted - following that BOF.

We are happy to update the original document (yes there's been progress) and
resubmit if there's an interest in doing so.  A lot has changed since then
on the policy side of things,.....maybe its time to revisit this.

Michael Young 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dan Maharry
Sent: Wednesday, April 04, 2007 9:54 AM
To: [email-masked]
Subject: [ietf-provreg] EPP Extensions for IDN

Hi,

Is there an rfc or a draft of EPP extensions for supporting IDNs at all?
If so, where can I find it. There's a draft 1 of a doc about this floating
about but its from a while ago and I notice that PIR are running IDNs for
.org so am I right in thinking there's been progress on this that I can't
find?

Please advise,

Dan

Dan Maharry
Technical Manager

The Midcounties Co-operative is an innovative co-operative business, owned
by its customers and staff in the 9 counties it spans. We trade in a number
of retail sectors including food, travel, funerals, motors, childcare,
pharmacy, post offices and IT. We are proud to be a successful co-operative,
founded on co-operative values and principles that co-ops share throughout
the world.

This e-mail is confidential and is for the named recipient(s) only. If you
are not the named recipient(s) please do not disseminate or copy this
e-mail, but please delete it and any copies from your computer. The
Midcounties Co-operative has taken reasonable precautions to ensure that any
attachment to this e-mail has been checked for viruses. However, we cannot
accept liability for any damage sustained as a result of any such viruses
and advise you to carry out your own virus checks before opening any
attachment. Furthermore, we do not accept responsibility for any change made
to this message after it was sent by the sender.

---

From: "Dan Maharry" <[email-masked]>
Date: Wed, 4 Apr 2007 15:12:39 +0100

Michael,

Now would seem appropriate with EPP basically a standard now and most of
the main registries now using it. 

Is there a spec online of the way you implemented it or did you use
Chung's document as the base for your implementation?

Dan

-----Original Message-----
From: Michael Young [mailto:[email-masked]] 
Sent: 04 April 2007 15:08
To: Dan Maharry; [email-masked]
Subject: RE: [ietf-provreg] EPP Extensions for IDN

Hi Dan 

Edmon Chung (supported by Scott Hollenbeck and Ted Hardie) floated the
idea
of this at a BOF a couple of years ago.  It was shot down by the
community
due to the many external policy influences and lack of a central
language
authority. In the archives you will find at least two submissions
regarding
IDNs and EPP.  One is a discussion document and one is an actual
extension
implemented by Afilias (that sounds like the one you have in hand).  I
don't
think any others have since been submitted - following that BOF.

We are happy to update the original document (yes there's been progress)
and
resubmit if there's an interest in doing so.  A lot has changed since
then
on the policy side of things,.....maybe its time to revisit this.

Michael Young 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On
Behalf Of Dan Maharry
Sent: Wednesday, April 04, 2007 9:54 AM
To: [email-masked]
Subject: [ietf-provreg] EPP Extensions for IDN

Hi,

Is there an rfc or a draft of EPP extensions for supporting IDNs at all?
If so, where can I find it. There's a draft 1 of a doc about this
floating
about but its from a while ago and I notice that PIR are running IDNs
for
.org so am I right in thinking there's been progress on this that I
can't
find?

Please advise,

Dan

Dan Maharry
Technical Manager

The Midcounties Co-operative is an innovative co-operative business,
owned
by its customers and staff in the 9 counties it spans. We trade in a
number
of retail sectors including food, travel, funerals, motors, childcare,
pharmacy, post offices and IT. We are proud to be a successful
co-operative,
founded on co-operative values and principles that co-ops share
throughout
the world.

This e-mail is confidential and is for the named recipient(s) only. If
you
are not the named recipient(s) please do not disseminate or copy this
e-mail, but please delete it and any copies from your computer. The
Midcounties Co-operative has taken reasonable precautions to ensure that
any
attachment to this e-mail has been checked for viruses. However, we
cannot
accept liability for any damage sustained as a result of any such
viruses
and advise you to carry out your own virus checks before opening any
attachment. Furthermore, we do not accept responsibility for any change
made
to this message after it was sent by the sender. 

 

------------------------------------------------------------------------
--------
This Message has been Scanned by SurfControl(c) Email Filter
------------------------------------------------------------------------
--------

---

From: Francisco Obispo <[email-masked]>
Date: Wed, 4 Apr 2007 10:14:39 -0400

Dear Dan,

I'm not sure if you need additional extensions for IDNs..

We just encoded the domain name at the client into XML compatible  
form (i.e: español.com.ve -> espa&#241;ol.com.ve),
and later, on the server we will convert it to ACE if needed.

regards.

_____________________________
Francisco Obispo
Jefe de Oficina de NIC-VE
Centro Nacional de Tecnologías de Información

On 04/04/2007, at 09:54 AM, Dan Maharry wrote:

> The Midcounties Co-operative is an innovative co-operative  
> business, owned by its customers and staff in the 9 counties it  
> spans. We trade in a
> number of retail sectors including food, travel, funerals, motors,  
> childcare, pharmacy, post offices and IT. We are proud to be a  
> successful
> This e-mail is confidential and is for the named recipient(s) only.  
> If you are not the named recipient(s) please do not disseminate or  
> copy this
> any attachment to this e-mail has been checked for viruses.  
> However, we cannot accept liability for any damage sustained as a  
> result of
> any such viruses and advise you to carry out your own virus checks  
> before opening any attachment. Furthermore, we do not accept  
> responsibility for any

---

From: Patrik Wallstrom <[email-masked]>
Date: Wed, 4 Apr 2007 16:23:49 +0200

> and later, on the server we will convert it to ACE if needed.

Interesting. We, .SE, only accepts the ACE-coded versions. Our domain
name validator does a roundtrip coding to see if we allow the
characters used if the name starts with xn--.

-- 
patrik_wallstrom->foodfight->[email-masked]>+46-733173956

---

From: "Michael Young" <[email-masked]>
Date: Wed, 4 Apr 2007 10:26:12 -0400

No Edmon's discussion doc was the first submission, the second doc I
referred to was a spec, although it does relate to Edmon's doc.  Its not
that far off from current implementations in .Org, .Info, .Mobi, and .IN.
So there's at least five registry operators that are using the same
implementation.

Given your statements we can update that original spec and do an individual
submission on the standards track (much like Scott did with ENUM, DNSSEC,
RGP).

It would help the argument with the current ADs if others still tuned on
this list would support such an effort.   I will take silence as consent
though.

Michael Young 
-----Original Message-----
From: Dan Maharry [mailto:[email-masked]] 
Sent: Wednesday, April 04, 2007 10:13 AM
To: Michael Young; [email-masked]
Subject: RE: [ietf-provreg] EPP Extensions for IDN

Michael,

Now would seem appropriate with EPP basically a standard now and most of the
main registries now using it. 

Is there a spec online of the way you implemented it or did you use Chung's
document as the base for your implementation?

Dan

-----Original Message-----
From: Michael Young [mailto:[email-masked]]
Sent: 04 April 2007 15:08
To: Dan Maharry; [email-masked]
Subject: RE: [ietf-provreg] EPP Extensions for IDN

Hi Dan 

Michael Young
-----Original Message-----

Hi,

Please advise,

Dan

Dan Maharry
Technical Manager

---

From: "Dan Maharry" <[email-masked]>
Date: Wed, 4 Apr 2007 15:31:27 +0100

Interesting. 
I guessed that you needed three pieces of information for a IDN which should be stored in the extension.

- the Unicode version of the domain 
- the punycode ascii version of the domain
- the language code for the domain name 

Maybe you need some more. 

Francisco, is espa&#241;ol.com.ve a valid whois query? 
If ICANN ever started asking for an IRIS server, holding both versions of the domain would make a lot of sense at this point - much in the same way that there are i18n'd and l10n'd versions of a contact's postal information in EPP as standard.

Dan

-----Original Message-----
From: Patrik Wallstrom [mailto:[email-masked]] 
Sent: 04 April 2007 15:24
To: Francisco Obispo
Cc: Dan Maharry; [email-masked]
Subject: Re: [ietf-provreg] EPP Extensions for IDN

--------------------------------------------------------------------------------
This Message has been Scanned by SurfControl(c) Email Filter
--------------------------------------------------------------------------------

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 4 Apr 2007 10:55:56 -0400

> - the language code for the domain name 

It seems to me that the "Punycode ASCII version" (what John Klensin is
now calling an A-label, I think) is just what you put as the domain
name in the command.  But I agree that you probably actually want the
U-label as well.

Most important, at least under any policy regime where you intend to
map characters into language (as the ICANN policy requires) is that
language code bit.  That's even more important when variants come into
play.

The Internationalization discussion during the technical plenary at
the Prague meeting was awfully interesting on this topic.  Anyone
working on documents proposing to offer a way to implement IDNA for
EPP ought to keep a pretty close eye on the Internationalization
dicussions, because it'd be awful to settle on an approach that made
moving to IDNA200x harder.  (In that context, John's
draft-klensin-idnabis-issues is obviously something to watch.)

A

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
jabber: [email-masked]                 +1 416 646 3304 x4110

---

From: James Gould <[email-masked]>
Date: Wed, 04 Apr 2007 11:07:17 -0400

We created a custom IDN extension that takes the language tag with the
assumption that the domain:name is being passed in punycode.  The following
is the XML schema for out extension:

<?xml version="1.0" encoding="UTF-8"?>
 
   <schema targetNamespace="http://www.verisign.com/epp/idnLang-1.0"
          xmlns:idnLang="http://www.verisign.com/epp/idnLang-1.0"
          xmlns="http://www.w3.org/2001/XMLSchema"
          elementFormDefault="qualified">
 
    <annotation>
      <documentation>
         Extensible Provisioning Protocol v1.0 domain name
         extension schema for IDN Lang Tag.
      </documentation>
    </annotation>
 
   <!--
   Child elements found in EPP commands.
   -->
     <element name="tag" type="language"/>

   <!--
   End of schema.
   -->
</schema>

JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Information Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, proprietary and/or
Registry  Sensitive information intended solely for the recipient and, thus
may not be  retransmitted, reproduced or disclosed without the prior written
consent of  VeriSign Naming and Directory Services.  If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy.  Thank you.

> From: Michael Young <[email-masked]>
> Date: Wed, 4 Apr 2007 10:26:12 -0400
> To: 'Dan Maharry' <[email-masked]>, <[email-masked]>

---

From: Francisco Obispo <[email-masked]>
Date: Wed, 4 Apr 2007 12:51:17 -0400

Internally, we register the domain as: xn--espaol-zwa.com.ve,
the WHOIS server accepts the ACE string and UNICODE string,

The whois server does not allow &#241; because it does not expect
the input to be in XML ;-), although support for that can be added.

We have a restricted list of characters that can be used in the  
registry,
so if its not on that list, the domain registration gets rejected.

In the whois response we provide both UNICODE and ACE string conversion
of the domain name:

    Nombre de Dominio: español.com.ve
    Dominio en Codificacion Compatible ASCII (ACE): xn--espaol- 
zwa.com.ve

This way, we only deal with IDN at the moment of registration and  
anytime
it needs interaction with the user of the service (it gets  
transformed from ACE to UNICODE), keeping the XN-- conversion hidden  
from the user interface .

Maybe in our case is fairly simple, because we only need support for  
7 extra characters, (á,é,í,ó,ú,ü and ñ), it would be interesting
to see other implementations ...

regards

On 04/04/2007, at 10:31 AM, Dan Maharry wrote:

> If ICANN ever started asking for an IRIS server, holding both  
> versions of the domain would make a lot of sense at this point -  
> much in the same way that there are i18n'd and l10n'd versions of a  
> contact's postal information in EPP as standard.
>
> Dan
>
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 5 Apr 2007 18:21:35 +0200

On Wed, Apr 04, 2007 at 03:31:27PM +0100,
 Dan Maharry <[email-masked]> wrote 

> - the language code for the domain name 

No, IDN is about scripts, not about languages, so there is no reason
to transmit the language.

What is the language of "coca-cola", anyway? English?

---

From: Edward Lewis <[email-masked]>
Date: Thu, 5 Apr 2007 13:37:21 -0400

>to transmit the language.

I agree with Stephane.  I was about to reply the opposite way 
yesterday but then I consulted our in-house expert on such matters.

E.g., If you are in Taiwan and write "east capital" in the local 
written language you get two Han characters.  If you are in Japan and 
write "east capital" in the local written language you get the same 
exact looking pair of Kanji/Han characters.  Never mind that one is 
Chinese and the other Japanese and thus differ when read aloud, they 
mean the same thing and look the same on paper.

Now shift to the People's Republic of China.  You will get a 
different first character but when read aloud get the same sound as 
in Taiwan.  That's because the mainland has "simplified" (reduced the 
strokes) of the Han for "east."

Let's shift to transliterating the Han to Latin characters.  You 
might get at least two different and possibly three different strings 
of Latin characters and marks corresponding to the same concept. 
(BTW, "east capital" is most commonly known around the world as 
Tokyo.)  E.g., "Middle mountain" is written as Zhongshan in the PRC 
and Cheongshan in Taiwan.  I don't know "Middle" in Japanese romaji.

At this point my expert said - for IDN policies we stick to just what 
are the equivalent looking characters.  The two native script forms 
(the Taiwan/Japan and the PRC) are considered equivalent, but not 
other semantic, homonyms, or transliterated forms.  IDN cares about 
the look (the script) and not the language meaning.  I.e., if I 
register "tokyo.biz" I do not consider "dongjing.biz" or 
"dong1jing1.biz" or "$1$2.biz as variants - where the $1 and $2 are 
the appropriate characters.  I don't get "activity.biz" (based on 
dong4jing4 meaning (n)activity) either.  (To an untrained ear, the 
tones of the Chinese language are lost making dong1jing1 sound like 
dong4jing4.)

My new understanding is that EPP is already suitable for IDN.  I 
realized this after my headache evaporated.

PS - My mail would be a lot clearer if my mail reader was capable of 
more than just ASCII. ;)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Sarcasm doesn't scale.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 5 Apr 2007 13:50:42 -0400

> mean the same thing and look the same on paper.

This is actually, under the current ICANN guidelines, up to the
implementor:

        3. (a) In implementing the IDN standards, top-level domain
           registries will associate each label in a registered
           internationalized domain name, as it appears in their
           registry with a single script This restriction is intended
           to limit the set of permitted characters within a label. If
           greater specificity is needed, the association may be made
           by combining descriptors for both language and
           script. Alternatively, a label may be associated with a set
           of languages, or with more than one designator under the
           conditions described below.

(that's from http://www.icann.org/general/idn-guidelines-22feb06.htm)

So maybe we need both script and language.

A

---

From: Edward Lewis <[email-masked]>
Date: Thu, 5 Apr 2007 14:27:40 -0400

>This is actually, under the current ICANN guidelines, up to the
...
>So maybe we need both script and language.

Pluralize that (language[s]).

If it is left to the implementor then the protocol ought to have it 
(as optional) so that the option remains open.

Sarcasm doesn't scale.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 5 Apr 2007 11:41:46 -0700

>>to transmit the language.

You know, this stuff is pretty hard.  There are several things just mildy
wrong with the text below.  I'll try to correct them, but the key
thing to remember is probably this:  for registrations within a domain,
a policy needs to set out which code points may be registered,
which may not be *at all*, and which code points will be considered
equivalent (and so may not be registered independently of their
equivalent brethren).    RFC 3743 is worthwhile reading for one
set of registries take on this; their approach is conditioned by
complexities that don't hit everyone, but is still worth trying
to bend your brain around.

>I agree with Stephane.  I was about to reply the opposite way yesterday but then I consulted our in-house expert on such matters.
>
>E.g., If you are in Taiwan and write "east capital" in the local written language you get two Han characters.  If you are in Japan and write "east capital" in the local written language you get the same exact looking pair of Kanji/Han characters.  Never mind that one is Chinese and the other Japanese and thus differ when read aloud, they mean the same thing and look the same on paper.

That is, after CJK unification in Unicode, the same code points are used in both
China and Japan for Han characters/Kanji.  If you select the code points that
are used for "Tokyo" in Kanji, it will also be semantically correct in Chinese
in traditional (aka "complex") characters.

>Now shift to the People's Republic of China.  You will get a different first character but when read aloud get the same sound as in Taiwan.  That's because the mainland has "simplified" (reduced the strokes) of the Han for "east."

There is a second code point for the simplified character for the first of the two
ideographs used in Tokyo.  It is semantically equivalent, and a registration
policy might connect the two.

>Let's shift to transliterating the Han to Latin characters.  You might get at least two different and possibly three different strings of Latin characters and marks corresponding to the same concept. (BTW, "east capital" is most commonly known around the world as Tokyo.)  E.g., "Middle mountain" is written as Zhongshan in the PRC and Cheongshan in Taiwan.  I don't know "Middle" in Japanese romaji.

Hmm, the Wade-Giles transliteration for Zhong is Chung, so I would say that the
pinyin transliteration Zhongshan maps to the Wade-Giles transliteration
Chungshan.

>At this point my expert said - for IDN policies we stick to just what are the equivalent looking characters.  The two native script forms (the Taiwan/Japan and the PRC) are considered equivalent, but not other semantic, homonyms, or transliterated forms.
> IDN cares about the look (the script) and not the language meaning. 

I suspect your expert was simplifying this for you.  Equivalent looking won't
work by itself, as there are code points that look equivalent and are valid
Unicode, but are generally excluded.  I think your expert was trying to get
at the idea that they consider the ideographs distinct from any transliteration,
but may treat ideographs as equivalent if they see one as a variant of the
other (see 3473 for the language variant table version of this idea).

>I.e., if I register "tokyo.biz" I do not consider "dongjing.biz" or "dong1jing1.biz" or "$1$2.biz as variants - where the $1 and $2 are the appropriate characters.  I don't get "activity.biz" (based on dong4jing4 meaning (n)activity) either.  (To an untrained ear, the tones of the Chinese language are lost making dong1jing1 sound like dong4jing4.)

In general, pronunciation is a very large rathole, as there are multiple dialects
and things that sound the same will vary from dialect to dialect.

>My new understanding is that EPP is already suitable for IDN.  I realized this after my headache evaporated.
>
>PS - My mail would be a lot clearer if my mail reader was capable of more than just ASCII. ;)
			regards,
				Ted Hardie

---

From: Edward Lewis <[email-masked]>
Date: Thu, 5 Apr 2007 15:31:25 -0400

>pinyin transliteration Zhongshan maps to the Wade-Giles transliteration

Thanks, Ted.  I think my mistake was faulty memory of the 
Cheong/Chung on the road signs, but I wasn't aware of "Wade-Giles" 
name of the transliteration approach. (I knew there was something in 
use, but hadn't learned of it by name yet.)

>at the idea that they consider the ideographs distinct from any
>transliteration, but may treat ideographs as equivalent if they see one as
>a variant of the other (see 3473 for the language variant table version of
>  this idea).

I think maybe it was my fault.  BTW, when I used "we" I am not sure I 
am speaking for my registry's policies or a community of researcher's 
policies, just to clear this up.  I think "we" would equate both the 
simplified and traditional Chinese strings for Tokyo even though they 
do not look the same, but not include the transliterations.  So, 
yeah, it's not just equivalent looking, I was over simplifying.

>In general, pronunciation is a very large rathole, as there are multiple
>dialects and things that sound the same will vary from dialect to dialect.

Yes, that is something I had been neglecting...Cantonese, etc.  I 
have only spent time trying to learn Mandarin and thus keep 
forgetting about the other Chinese dialects.

It's really humbling to travel through regions and realize the 
enormity of the IDN issue.  At APRICOT in Bali, talking to a tour 
guide was really enlightening - they know the local language 
(Balinese), the national language (Indonesian), and then the language 
of their customers - which is not just English (the usual language of 
business).  He said that many islands had a local dialect but you had 
to learn the national language in school.

Every time you think you are making headway into understanding more 
forms of human communication, there seem to be a bijillion dialects 
and transliterations lurking around the next corner.

Sarcasm doesn't scale.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 6 Apr 2007 10:51:29 +0200

On Wed, Apr 04, 2007 at 10:14:39AM -0400,
 Francisco Obispo <[email-masked]> wrote 

> form (i.e: español.com.ve -> espa&#241;ol.com.ve),

That's a strange sentence. EPP is based on XML and, for an application
which uses a XML parser, español is exactly the same as espa&#241;ol
(most XML parsers do not even inform the application what was the
original form).

To quote some relevant parts of RFC 3730 :

   All XML instances SHOULD begin with an <?xml?> declaration to
   identify the version of XML that is being used, optionally identify
   use of the character encoding used, and optionally provide a hint to
   an XML parser that an external schema file is needed to validate the
   XML instance.  Conformant XML parsers recognize both UTF-8 (defined
   in RFC 2279 [RFC2279]) and UTF-16 (defined in RFC 2781 [RFC2781]);
   per RFC 2277 [RFC2277] UTF-8 is the RECOMMENDED character encoding
   for use with EPP.

See also section 5, "Internationalization Considerations". I would say
that an EPP server which does *not* accept español is *not* a
compliant EPP server.

---

From: Yoshiro YONEYA <[email-masked]>
Date: Fri, 6 Apr 2007 20:35:57 +0900

> to bend your brain around.

Language information is important not only for 'variants selection'
but also for avoiding unwanted DRP to occur.

If a Japanese registers "Tokyo" as "Japanese", then only traditional
form will be registered and simplified form will remain as available.
If no language information is provided, simplified form will be
registered simultaneously and the registrant may be sued from Chinese
who wants to register "Tokyo" in simplified form.  How can the
registrant prove that the IDN is not Chinese?

> >Let's shift to transliterating the Han to Latin characters.  You might get at least two different and possibly three different strings of Latin characters and marks corresponding to the same conce…

"Middle" in Japanese romaji is "Naka" or "Chu".  Which is used depends
on context.  For "Middle mountain" case, "Nakayama" is usual Japanese
romaji, although it can represent as "Chusan".

-- 
Yoshiro YONEYA <[email-masked]>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 6 Apr 2007 14:25:08 +0200

On Fri, Apr 06, 2007 at 08:35:57PM +0900,
 Yoshiro YONEYA <[email-masked]> wrote 
 a message of 42 lines which said:

> Language information is important 

In the case you mention (chinese characters), yes, but it is not a
general rule.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 6 Apr 2007 08:28:49 -0400

> that an EPP server which does *not* accept español is *not* a

Well, maybe not.  The server could respond with a policy error, for
instance (on the grounds that only ASCII labels are what one wants to
allow in the DNS).

A

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 6 Apr 2007 14:52:22 +0200

On Fri, Apr 06, 2007 at 08:28:49AM -0400,
 Andrew Sullivan <[email-masked]> wrote 
 a message of 18 lines which said:

> > See also section 5, "Internationalization Considerations". I would
> > say that an EPP server which does *not* accept español is *not* a
> > compliant EPP server.

[My sentence was ambigous. I restate it: "An EPP server which does
*not* accept on-the-wire español but accepts on-the-wire espa&#241;ol
is *not* a compliant EPP server."]

> instance (on the grounds that only ASCII labels are what one wants
> to allow in the DNS).

In that case, it <rfc num="2119">MUST</rfc> rejects espa&#241;ol as
well.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 6 Apr 2007 09:20:53 -0400

>In the case you mention (chinese characters), yes, but it is not a

When something is "in the case you mention" but "it is not a general 
rule" then as a protocol developer, the protocol MUST support it but 
it's use/inclusion is OPTIONAL.  (The exception is that the new 
feature CAN'T conflict with an established feature.)  The goal of the 
protocol developer of EPP is to have a specification that is 
universal even if policies are not.

The case I raised involved Chinese and Japanese only because I have 
some but still elementary knowledge on that topic (as you can see 
from the follow up messages filling in my knowledge gaps and gaffs). 
Besides filling in what I don't know or got wrong, it would be good 
to have any other language concerns raised - if there are any.  E.g., 
I hear rumors of Arabic languages having yet another concern 
regarding representation in DNS.  Perhaps the issue (unknown to me) 
is taken care of by including the same meta-data, perhaps not.

To help us focus, the goal here isn't to argue over IDN (which we 
aren't doing) nor argue over policies (which we also aren't doing) 
but to determine what extension to EPP is needed to suit our 
collective needs.  While we are not a WG anymore, we are still about 
the engineering and I at least find this discussion enlightening.

BTW, is someone eager to document an IDN extension?  I ask as I 
believe there was already an offer or older proposal that is waiting 
in the wings.

Sarcasm doesn't scale.

---

From: "Michael Young" <[email-masked]>
Date: Sat, 7 Apr 2007 09:10:51 -0400

I know I certainly have the interest. We will have an updated version of the
older proposal up shortly.  That can be a starting point for discussion.

Michael Young
Afilias 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Edward Lewis
Sent: Friday, April 06, 2007 9:21 AM
To: [email-masked]
Cc: [email-masked]
Subject: [ietf-provreg] Re: EPP Extensions for IDN

>In the case you mention (chinese characters), yes, but it is not a 

When something is "in the case you mention" but "it is not a general rule"
then as a protocol developer, the protocol MUST support it but it's
use/inclusion is OPTIONAL.  (The exception is that the new feature CAN'T
conflict with an established feature.)  The goal of the protocol developer
of EPP is to have a specification that is universal even if policies are
not.

The case I raised involved Chinese and Japanese only because I have some but
still elementary knowledge on that topic (as you can see from the follow up
messages filling in my knowledge gaps and gaffs). 
Besides filling in what I don't know or got wrong, it would be good to have
any other language concerns raised - if there are any.  E.g., I hear rumors
of Arabic languages having yet another concern regarding representation in
DNS.  Perhaps the issue (unknown to me) is taken care of by including the
same meta-data, perhaps not.

To help us focus, the goal here isn't to argue over IDN (which we aren't
doing) nor argue over policies (which we also aren't doing) but to determine
what extension to EPP is needed to suit our collective needs.  While we are
not a WG anymore, we are still about the engineering and I at least find
this discussion enlightening.

BTW, is someone eager to document an IDN extension?  I ask as I believe
there was already an offer or older proposal that is waiting in the wings.

Sarcasm doesn't scale.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 7 Apr 2007 22:18:16 +0200

On Fri, Apr 06, 2007 at 02:25:08PM +0200,
 Stephane Bortzmeyer <[email-masked]> wrote 

> In the case you mention (chinese characters), yes, but it is not a

Joe Abley kindly explained that I could have say it in a better
way. Here is a new attempt (and I suggest that a similar sentence be
included in the I-D if someone wants to revive an EPP extension for
IDN):

***************

IDN deals with scripts, not with languages. Asking what is the
language of an IDN domain name is often irrelevant and sometimes
meaningless (many corporate trademarks are not words in any human
language, for instance).

In the vast majority of writing systems, knowledge of the language
being represented is not necessary.

The Chinese/Japanese case described in RFC 3743 is a prominent example
of where the language may be relevant.

---

From: "Tan, William" <[email-masked]>
Date: Sat, 07 Apr 2007 17:06:34 -0400

I apologize for coming into this thread late.

I'm not sure how to interpret "IDN deals with scripts", because if IDN 
were to "deal" with anything, it would be a sequence of characters from 
the Unicode character repertoire. Now, that's not saying much either.

If I understand correctly, this is trying to capture a best practice / 
recommendation to restrict label registrations to only contain 
characters from a certain *table*, and that the table in defined in 
terms of scripts instead of languages.

Now, I'm not sure if this WG is really in the business of recommending 
registry policies. There is definitely a need for some form of a tag, 
especially in gTLD registries implementations, to facilitate checking 
for the rule that all characters within the requested label must fall 
within a single table.

IMHO the content of such a tag, if used, should be left up to the 
implementation. One registry might use ISO15924-based script codes, or 
RFC4646 tags, or ISO639-based codes.

=wil

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 9 Apr 2007 09:06:32 -0400

On Sat, Apr 07, 2007 at 10:18:16PM +0200, Stephane Bortzmeyer wrote:

> IDN deals with scripts, not with languages. 

My reading of the RFCs is that IDNA specifically deals with neither.
It rather deals with Unicode code points, and how they can be encoded
in ASCII.  The problem all arises above the level of IDNA (and support
for IDNA-as-implemented-by-registries is the EPP extension we're
designing, I think).

One might argue that general IDN considerations need to be taken into
account because those working on IDNA 200x and such like are worried
about _localization_ and not about _internationalization_ (or at
least, think that an emphasis on localization is needed).

That said, the policy from ICANN is ambiguous with respect to whether
the issue is "script" or "language".  (I appreciate that it is not the
policy under which everyone labours -- but given that some of us do,
any extension that is to be usable will need to accommodate the
possibility that language is the relevant category.) 

In any case,

> Asking what is the

is an oversimplification, because it's also true that asking what
script a label is in might be meaningless, for similar reasons.  I can
imagine that "αthenstravel" (in case that doesn't come through,
that's "[GREEK SMALL LETTER ALPHA]thens") could be a cool name for a
travel agency, for instance.  So, which script is
"αthenstravel.example" in?  The answer for this might turn out to be
dependent on some registry policy involving a table of allowable code
points.  (As far as I know, no registry running current Afilias code
would allow the example.)  Alas, just because we've decided to sweep
all the problems under the rug by saying "table of allowable
code-points in this script defined by the convention name
'Greek/Greece'" instead of "which language is this" doesn't mean that
we've actually solved the problem[1].

So at the very least, any extension is going to need support for both
"languages" and "scripts".  Besides, there are languages that can be
expressed in more than one script, and in those cases, you probably
need both pieces of meta-data to decide whether the desired label
meets the policy rules that are to be applied.  My guess is that there
is going to need to be some sort of indication about variants desired
or actually registered or something, as well.

A

[1] And I'm just ignoring the fact that we have apparently given up on
the idea that domain name labels are not words, and shouldn't be
understood to be words.  I reluctantly concluded some time ago that
the horse was out of the barn.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 10 Apr 2007 10:49:28 +0200

On Mon, Apr 09, 2007 at 09:06:32AM -0400,
 Andrew Sullivan <[email-masked]> wrote 
 a message of 62 lines which said:

> It rather deals with Unicode code points, 

You're right.

> I can imagine that "??thenstravel" (in case that doesn't come
> through, that's "[GREEK SMALL LETTER ALPHA]thens") could be a cool
> name for a travel agency, for instance.  So, which script is
> "??thenstravel.example" in?

Right and another example (may be more realistic) is company names in
Russia where high-tech organisations sometimes have a name where a
Latin-script acronym ("xml" for instance) is mixed with a
Cyrillic-script name.

> So at the very least, any extension is going to need support for
> both "languages" and "scripts".

May be using RFC 4646 for the tag would be the easier way to support both?

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 10 Apr 2007 09:58:42 -0400

> Latin-script acronym ("xml" for instance) is mixed with a

Yes, that is in fact a bigger concern.  The artificial example I gave
is actually ruled out by the ICANN guidelines at the moment, I think:

   3. (a) In implementing the IDN standards, top-level domain
      registries will associate each label in a registered
      internationalized domain name, as it appears in their registry
      with a single script This restriction is intended to limit the
      set of permitted characters within a label.

The problem arises exactly as you say, when you have a name for
something (which is presumably a desired label) which cannot be
expressed in a single script.  My guess is that this state of affairs
is what the exception is there to deal with:

      Alternatively, a label may be associated with a set of
      languages, or with more than one designator under the conditions
      described below.

This is sort of a policy issue, though, and since I guess we're not in
the business of telling registries what policies they should adopt,
that's probably out of scope. 

> May be using RFC 4646 for the tag would be the easier way to support both?

That seems like the best idea to me, yes.  

A