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

["Tina Dam" <tina.dam@xxxxxxxxx>]

Tin Wee, All,
While it naturally is impossible to test all applications the Technical Test
Phase II is focused on the application area. It is in progress of being
defined and planned and will contain elements around communication as well.
(communication to application providers...so far we have received quite some
interest in getting this right which is good).

Further, the revision of the protocol does not expect to be changing the
prefix and also one of the main reasons for the revision is to be able to
proceed with a non-unicode-version dependant protocol to avoid continuously
revisions, which could create further problems as you mention below.

I am not sure I follow your AXN-- discussion below...but I support Will and
Edmon comments on this. The protocol does not work mid-way strings. What
that means is that it is entirely possible to register a string that midway
has "xn--" in it, and I don't see any need for reserving such names. Sloppy
applications that take such strings and convert to U-strings should quickly
be revised by market complaints. As mentioned while some application testing
is in place, we need to keep in mind that (i) we cant test all applications
that exists now and in the future (ii) even if tested the providers can
change the implementation at any time.

Tina

PS> Sorry I was not on the call last night. I arrived late evening from a
long into LA and did not managed to stay up for the 3am call. I will listen
to the recording and if I have input I will provide it to the list.


> -----Original Message-----
> From: owner-gnso-idn-wg@xxxxxxxxx 
> [mailto:owner-gnso-idn-wg@xxxxxxxxx] On Behalf Of Tan Tin Wee
> Sent: Tuesday, March 06, 2007 4:06 PM
> To: edmon@xxxxxxxxxxx
> Cc: 'Shahram Soboutipour'; owner-gnso-idn-wg@xxxxxxxxx; 
> 'Sophia Bekele'; gnso-idn-wg@xxxxxxxxx; gnso-rn-wg@xxxxxxxxx
> Subject: Re: [gnso-idn-wg] Re: Banning CCHH anywhere in a label
> 
> 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 agree with the comments made so far.
> xn-- in the case mentioned by Ram won't happen in the current 
> way Punycode works as William and Edmon pointed out.
> 
> Having said that, I agree that for the moment we may not want 
> to add more complication by recommending to split the IDN 
> label with xn-- embedded inside because xn-- can occur in 
> punycode within a label like (using Ram's example and 
> modifying it...) citibankxn-<China> will appear as 
> xn--citibankxn--b28qq03g (e.g. 
> http://mct.verisign-grs.com/conversiontool/convertServlet?inpu
> t=xn--citibankxn--b28qq03g&type=PUNYCODE
> converting from Punycode xn--citibankxn--b28qq03g to Unicode: 
> citibankxn-?? or use
> http://www.afilias.info/cgi-bin/convert_punycode.cgi)
> ...
> which I think was the nub of Shahram's point:
>  > <CCHH>citibank-<CCHH><encodedCHINA>.tld
> 
> Of course, xn-- at the prefix will cause the rest of the 
> label "citibankxn--b28qq03g" to be processed as such, but still
> xn-- as mentioned by Sophia will pop up here and there by 
> accident or by deliberate design by non-bonafide registrants.
> 
> I think what Sophia meant which Ram misunderstood was for 
> some mechanism to trap xn-- inside labels to ensure that for 
> instance, it doesn't confuse software programmers with sloppy 
> programming that picks out xn-- inside an xn-- prefixed 
> string (non-greedy algorithm) like in the case I mentioned, 
> and display the wrong IDN label; or that with the mixed 
> scripts thing, if we don't look carefully in the xn-- or CCHH 
> issue, if the next Unicode version pops up that is of enough 
> drastic change, and we need to migrate, and in the process 
> change xn-- to some other CCHH for example by way of 
> illustration, we may lose the option if xm-- or xe-- etc was 
> already registered as axe-?? with xn--axe--3f5fw08b at the 
> back end encoding or AXN-??  with xn--axn--3f5fw08b which is 
> a conceivable registration by the AXN satellite channel.
> OR in cases of spoofing or passing off by confusing people 
> with citibankxn-?? and citibank.xn-?? which look pretty 
> close, that may get punycoded to
> http://mct.verisign-grs.com/conversiontool/convertServlet?inpu
> t=citibankxn-%E4%B8%AD%E5%9B%BD&type=UTF8
> xn--citibankxn--b28qq03g
> and
> http://mct.verisign-grs.com/conversiontool/convertServlet?inpu
> t=citibank.xn-%E4%B8%AD%E5%9B%BD&type=UTF8
> citibank.xn--xn--x68dy61b
> respectively.
> Try these two labels with Affilias converter and the second 
> one will generate block, while 
> http://www.nameisp.com/punycode.asp will work just like the 
> verisign converter... So these are programming variations we 
> may need to follow though.
> 
> If we recommend against AXN-?? because it generates a 
> potentially confusing xn-- string inside a punycode label, 
> then AXN?? could be an option, as it will generate 
> xn--axn-x68dy61b, which is xn- and not xn--.
> 
> Finally,
> Edmon Chung wrote:
>  > Nevertheless, with regards to our discussion at hand, I am 
> quite certain  > we have comprehensive protection with the 
> CCHH reserved as a prefix.
> 
> Yes, I suspect this might be the case, but somebody might 
> want to get a team of programmers to run a check on some test 
> cases. Does anyone know if this kind of scenario is being 
> tested at the moment in the ICANN testing contract?
> 
> bestrgds
> 
> tin wee
> 
> 
> Edmon Chung wrote:
> > 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 3^rd 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 2^nd 
> and 3^rd ) 
> > but seems higher levels other than 3^rd are out of scope of ICANN's 
> > policy, BUT must be mentioned in their own technical 
> decision makings.
> > 
> >  
> > 
> >  
> > 
> > Regards,
> > 
> >  
> > 
> > /*Shahram Soboutipour*/ <BLOCKED::mailto:soboutipour@xxxxxxxxxxx>
> > 
> > *President and CEO*
> > 
> > *Karmania Media* <BLOCKED::http://www.karmania.ir/>
> > 
> > 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
> > 
> >  
> > 
> >  
> > 
>