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

["Edmon Chung" <edmon@xxxxxxxxxxx>]

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