RE: [gnso-idn-wg] Re: Banning CCHH anywhere in a label
- To: "'Tan, William'" <William.Tan@xxxxxxxxxxx>, <rmohan@xxxxxxxxxxxx>
- Subject: RE: [gnso-idn-wg] Re: Banning CCHH anywhere in a label
- From: "Edmon Chung" <edmon@xxxxxxxxxxx>
- Date: Tue, 6 Mar 2007 10:38:36 +0800
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:
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)
Using the example described:
where <CHINA> is in Chinese, William's explanation is correct, it should become:
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.
> -----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
> > 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.