[gnso-rn-wg] RE: [gnso-idn-wg] Re: Banning CCHH anywhere in a label

["Edmon Chung" <edmon@xxxxxxxxxxx>]

Hi Shahram,

 

There was an extensive discussion in the original IDN protocol development 
about the use of the prefix (or suffix or other possible identifiers), and 
finally CCHH was chosen.  I highly doubt that we would be choosing a scheme 
that would split up a label (for many good reasons including bidi and single 
script considerations) into different chunks with different prefixes, but no 
one can predict the future I suppose :-)

 

Nevertheless, with regards to our discussion at hand, I am quite certain we 
have comprehensive protection with the CCHH reserved as a prefix.

 

Edmon

 

 

 

 

 

From: owner-gnso-idn-wg@xxxxxxxxx [mailto:owner-gnso-idn-wg@xxxxxxxxx] On 
Behalf Of Shahram Soboutipour
Sent: Tuesday, March 06, 2007 4:50 PM
To: owner-gnso-idn-wg@xxxxxxxxx
Cc: 'Sophia Bekele'; gnso-idn-wg@xxxxxxxxx; gnso-rn-wg@xxxxxxxxx
Subject: RE: [gnso-idn-wg] Re: Banning CCHH anywhere in a label

 

Dear Edmon

 

Regarding the sample CITIBANKchina.TLD (where china is in Chinese charset), I 
think there is a 3rd possibility which might be Sophia’s idea:

<CCHH>citibank-<CCHH><encodedCHINA>.tld

It means that every separate part of a label in non-ascii strings be translated 
with a CCHH at first. I am not sure if there is a rule for this right now or 
not, but I myself do not agree with this type. I prefer 
<CCHH>citibank-<encodedCHINA>.tld cause:

1. I think there is enough space for possible further changes and developments 
in IDNA standard in CC part of CCHH, so there must be no worries.

2. the CCHH (at first) is a good rule to define an IDN , and I think it can be 
a rule in all the levels of a url (not only 2nd and 3rd) but seems higher 
levels other than 3rd are out of scope of ICANN’s policy, BUT must be mentioned 
in their own technical decision makings.

 

 

Regards,

 

 <BLOCKED::mailto:soboutipour@xxxxxxxxxxx> Shahram Soboutipour

President and CEO

 <BLOCKED::http://www.karmania.ir/> Karmania Media

Tel: +98 341 2117844,5

Mobile: +98 913 1416626

Fax: +98 341 2117851

-----Original Message-----
From: owner-gnso-idn-wg@xxxxxxxxx [mailto:owner-gnso-idn-wg@xxxxxxxxx] On 
Behalf Of Edmon Chung
Sent: Tuesday, March 06, 2007 6:09 AM
To: 'Tan, William'; rmohan@xxxxxxxxxxxx
Cc: 'Sophia B'; gnso-idn-wg@xxxxxxxxx; gnso-rn-wg@xxxxxxxxx
Subject: RE: [gnso-idn-wg] Re: Banning CCHH anywhere in a label

 

I dont think you are missing anything William.

Was trying to speak up during the call earlier, I dont think the concern Sophia 
was articulating should be an issue.

 

If I am not mistaken, Sophia was asking whether it would be necessary to 
reserve names such as:

 

abc<CCHH>xyz.tld

 

These names would NOT be considered IDN nor parts of which IDN, but are simply 
ASCII domains.  <CCHH> can be best seen as a prefix to denote that a domain 
label (i.e. between two dots) has at least one non LDH (letter-digit-hyphen) 
character.

 

Using the example described:

 

citibank<CHINA>.tld

 

where <CHINA> is in Chinese, William's explanation is correct, it should become:

 

<CCHH>citibank-<encodedCHINA>.tld

 

And NOT

 

Citibank<CCHH><encodedCHINA>.tld

 

So, by reserving <CCHH> at the front (i.e. first 4 characters, or more 
precisely, hyphens in the third and fourth character> we cover all cases of 
intended IDN expressions.

 

Edmon

 

 

 

 

> -----Original Message-----

> From: owner-gnso-idn-wg@xxxxxxxxx [mailto:owner-gnso-idn-wg@xxxxxxxxx] On

> Behalf Of Tan, William

> Sent: Tuesday, March 06, 2007 7:47 AM

> To: rmohan@xxxxxxxxxxxx

> Cc: 'Sophia B'; gnso-idn-wg@xxxxxxxxx; gnso-rn-wg@xxxxxxxxx

> Subject: Re: [gnso-idn-wg] Re: Banning CCHH anywhere in a label

> 

> Hi all,

> 

> I believe the motivations behind banning strings with hyphens in the

> *third *and *fourth *positions are:

> 1. to protect registries who do not offer IDN registrations from

> unknowingly registering IDNs; and

> 2. to reserve future revisions to the IDNA standard where a different

> prefix might be assigned.

> 

> 

> Ram Mohan wrote:

> >

> > Are you saying – something like <*CITIBANKchina.TLD*> where “china” is

> > in local script while CITIBANK is in Latin script should be banned,

> > because its Punycode translation would result in an <xn--> midway

> > through the string?

> >

> I'm not sure I follow this. CITIBANKchina.TLD would translate to

> xn--citibank-encodedchunk.TLD, so xn-- would not occur midway in the ACE

> string.

> 

> > In general, the rationale for banning “CCHH” at a position other than

> > the beginning of a string/label is unclear.

> I have not seen any documents that suggest banning CCHH at anything but

> the beginning of a string. Am I missing something?

> 

> 

> Sophia said:

> > All registrations should

> > be in the IDN label, and that the ACE label should be internal to the

> > operations of the registration. *One should not be offering to

> > register xn--.... as a label or any ACE label since it is an internal

> > encoding, so as to prevent confusion and other malfeasance (phishing)*.

> Many registries today use the ACE string at the registration protocol

> level, so your statement would essentially be advising against that

> practice. Personally, I don't think it is a problem unless the registry

> does NOT offer IDN and is accepting xn-- labels (in which case it

> probably simply treats the registration as ASCII and does not check for

> IDNA validity.) We may be in agreement here, but I wanted to further

> qualify your statement.

> 

> 

> In table 4.4 of "Recommendation Tables for RN-WG Reports.doc":

> > For each IDN gTLD proposed, applicant must provide both the "ASCII

> > compatible (ACE) form of an IDNA valid string" (“A-label”) and in

> > local script form (Unicode) of the top level domain (“U-label”).

> I would also add that the applicant should provide additional strings

> that, after applying IDNA ToASCII operation, result in the A-label.

> 

> Additionally, there may also be complications where the U-label could be

> entered into an application using an input method editor ("keyboard")

> that may produce a sequence of Unicode characters that may not convert

> to the A-label (either becomes a different A-label or fails conversion.)

> This may be due to user perception that a character is what one thinks

> it is, but when entered using the local input software produces a

> different character due to locale differences. I will try to dig up some

> examples. This is not a technical / policy issue, but is a usability

> issue that affects the stability of IDNs.

> 

> 

> 

> Best,

> 

> =wil