[gnso-idn-wg] apologies fro missing today's call

["Marilyn Cade" <marilynscade@xxxxxxxxxxx>]

My apologies for missing today's call. Will follow up with Alistair and read
the transcript to catch up. Marilyn 

 

  _____  

From: owner-gnso-idn-wg@xxxxxxxxx [mailto:owner-gnso-idn-wg@xxxxxxxxx] On
Behalf Of Edmon Chung
Sent: Tuesday, March 06, 2007 4:53 AM
To: 'Shahram Soboutipour'; 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

 

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