Subject: Re: [ietf-provreg] Re: EPP Extensions for IDN

From: Elisabeth Porteneuve <[email-masked]>
Date: Tue, 10 Apr 2007 17:57:07 +0200 (MET DST)

If we have native Ukrainian or Russian speakers on this list, it would
be of help. I read cyrillic, and still can speak a little.

Please beware that there are differences between cyrillic used in Russian
and a cyrillic used in Ukrainian.
There is no latin shape letter "i" in Russian (the sound "i" writes "u"
in Russian cyrillic), while that letter does exist in Ukrainian cyrillic.

Look for the name of Lviv in the URL http://www.ipk.polynet.lviv.ua/lviv/
ans its Ukrainian cyrillic just right to the city arms, word after Micto ...
(you spell Micto - misto - city) -- you see letter "i" (you spell it "i"),
between two "B" (spelled "v").

What I want to say it is just impossible in my view to separate
Latin and Cyrillic. As far as I know the similar mixtures are common
in Bielorus as well.

I would not like to forbid ".Lviv" in Ukrainian cyrillic, just because
it is against theory of not mixing scripts.

Kind regards,
Elisabeth Porteneuve

--

> Date: Tue, 10 Apr 2007 09:58:42 -0400
> From: Andrew Sullivan <[email-masked]>
> 
> On Tue, Apr 10, 2007 at 10:49:28AM +0200, Stephane Bortzmeyer wrote:
> 
> > 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.
> 
> 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
> 
> -- 
> Andrew Sullivan                         204-4141 Yonge Street
> Afilias Canada                        Toronto, Ontario Canada
> <[email-masked]>                              M2P 2A8
> jabber: [email-masked]                 +1 416 646 3304 x4110
> 
>

---

From: "Tan, William" <[email-masked]>
Date: Tue, 10 Apr 2007 12:29:23 -0400

> Latin and Cyrillic. As far as I know the similar mixtures are common
That is why it is not recommended to mix Latin and Cyrillic. A label 
should contain only either Latin *OR* Cyrillic, and not both. If 
registries wish to support both scripts within a label, it SHOULD 
implement bundling in order to minimize the risk of homographic attacks.

> it is against theory of not mixing scripts.

The "i" you mentioned in "Львів" is "U+0456 CYRILLIC SMALL LETTER 
BYELORUSSIAN-UKRAINIAN I" so the whole label is in Cyrillic. It is in a 
single script and therefore there is no need to forbid them.

So, I'm not sure I understand your view. Maybe I missed something.

=wil

---

From: "Dan Maharry" <[email-masked]>
Date: Thu, 12 Apr 2007 11:00:07 +0100

RFC4646 maybe a way forward, but is it possible to look at this unambiguously but in a more compact way?
IDNs are domain names using the Unicode character set which is divided into codepages.
So maybe all the <domain:create> command actually needs is the Unicode name of the domain and the codepage on which those characters are located. 

From reading this discussion, that covers the Simplified Chinese\Kanji issue of writing out 'East Capital' (I think) - the owner of Tokyo.com should register two IDNs, one for each codepage \ character set.

Registries could let it be known which code pages they support and registrars likewise

So you get 

<domain:create>
	<name>blahblah.com</name>
	<IDN:codepage>1232</IDN:codepage>
...
</domain:create>

And the A-name is derived later on - name and codepage are the primary key for the name in the registry.

dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tan, William
Sent: 10 April 2007 17:29
To: Elisabeth Porteneuve
Cc: [email-masked]; [email-masked]
Subject: Re: [ietf-provreg] Re: EPP Extensions for IDN

=wil

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

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: "Tan, William" <[email-masked]>
Date: Thu, 12 Apr 2007 11:33:14 -0400

> So maybe all the <domain:create> command actually needs is the Unicode name of the domain and the codepage on which those characters are located. 
When you say codepages, do you mean scripts? "Code page" is a legacy 
encodings in my dictionary, and have very little to do with Unicode 
other than the fact that Unicode imported characters from them.

> And the A-name is derived later on - name and codepage are the primary key for the name in the registry.

I would advocate for looser interpretation of the 
script/language/codepage value. Registries today use a variety of tag 
types for that field. NeuStar uses ISO 639-2 to identify our tables. It 
is quite conceivable that another registry may allow many Latin 
characters in a table, and then allows the registration to be optionally 
tagged with a language just for statistics collection purposes.

Likewise, different registries collect and store variations of U-label 
and A-label combination. Some only take the A-label, does IDNA toUnicode 
to validate the characters, and then toASCII again to make sure it 
matches the original A-label. Some take both the U-label and A-label, 
and perform a variation of the previous steps. So, my suggestion is to 
offer the ability to hold a U-label in EPP, but make it optional in the 
schema.

For example, we could have:

<domain:create>
  <name>xn--rsum-bpad.com</name>
  <IDN:ulabel>résumé.com</IDN:ulabel>
  <IDN:tag type="iso639-2">fr</IDN:tag>
</domain:create>

=wil

---

From: Gregory Berezowsky <[email-masked]>
Date: Thu, 12 Apr 2007 14:04:36 -0400

On 12-Apr-07, at 11:33 AM, Tan, William wrote:

>> So maybe all the <domain:create> command actually needs is the  
>> Unicode name of the domain and the codepage on which those  
>> characters are located.
> When you say codepages, do you mean scripts? "Code page" is a  
> legacy encodings in my dictionary, and have very little to do with  
> Unicode other than the fact that Unicode imported characters from  
> them.
>
>> From reading this discussion, that covers the Simplified Chinese 
>> \Kanji issue of writing out 'East Capital' (I think) - the owner  
>> of Tokyo.com should register two IDNs, one for each codepage \  
>> character set.
>>
>> And the A-name is derived later on - name and codepage are the  
>> primary key for the name in the registry.
>>
>
> I would advocate for looser interpretation of the script/language/ 
> codepage value. Registries today use a variety of tag types for  
> that field. NeuStar uses ISO 639-2 to identify our tables. It is  
> quite conceivable that another registry may allow many Latin  
> characters in a table, and then allows the registration to be  
> optionally tagged with a language just for statistics collection  
> purposes.

A possibility could be for the value to be a reference to a table (or  
subtable...) as suggested in informational RFC 4290.  The URI for the  
supported table(s) for a given registry could be published in its EPP  
greeting.  This would allow quite open-ended definition of what a  
registry allows while making it fairly simple (and standardized) to  
determine from the client side what a registry actually supports.

>
> Likewise, different registries collect and store variations of U- 
> label and A-label combination. Some only take the A-label, does  
> IDNA toUnicode to validate the characters, and then toASCII again  
> to make sure it matches the original A-label. Some take both the U- 
> label and A-label, and perform a variation of the previous steps.  
> So, my suggestion is to offer the ability to hold a U-label in EPP,  
> but make it optional in the schema.
>

---
Gregory Berezowsky
Systems Architecture Team Lead
Afilias Canada

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Thu, 19 Apr 2007 16:43:21 +0200

> So maybe all the <domain:create> command actually needs is the Unicode 
name of the domain and the codepage on which those 
> characters are located.

Transmitting a "codepage" (did you maybe mean Unicode block?) or a script 
property along with a domain name as a separate parameter is a nonsense. 
Those are intrinsic properties of each of the codepoints building up the 
domain labels.

Regards
Marcos