ICANN ICANN Email List Archives

[gnso-rn-wg]


<<< Chronological Index >>>    <<< Thread Index >>>

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

  • To: "'Gomes, Chuck'" <cgomes@xxxxxxxxxxxx>, "'Sophia B'" <sophiabekele@xxxxxxxxx>, <gnso-idn-wg@xxxxxxxxx>, <gnso-rn-wg@xxxxxxxxx>
  • Subject: RE: [gnso-rn-wg] Re: Banning CCHH anywhere in a label
  • From: "Ram Mohan" <rmohan@xxxxxxxxxxxx>
  • Date: Mon, 5 Mar 2007 17:42:30 -0500

Chuck,

I agree with your statement - thanks for the correction.

 

-Ram

 

--------------------------------------------------------------------------

Ram Mohan

e:  <mailto:rmohan@xxxxxxxxxxxx> rmohan@xxxxxxxxxxxx | m: +1.215.431.0958
--------------------------------------------------------------------------

  _____  

From: owner-gnso-rn-wg@xxxxxxxxx [mailto:owner-gnso-rn-wg@xxxxxxxxx] On
Behalf Of Gomes, Chuck
Sent: Monday, March 05, 2007 5:27 PM
To: rmohan@xxxxxxxxxxxx; Sophia B; gnso-idn-wg@xxxxxxxxx;
gnso-rn-wg@xxxxxxxxx
Subject: RE: [gnso-rn-wg] Re: Banning CCHH anywhere in a label

 

Ram,

 

It seems to me that reserving CCHH strings at the third level is not out of
scope for gTLDs that register names at the third level (.pro and .name).
Would you agree with that?

 

Chuck Gomes

 

"This message is intended for the use of the individual or entity to which
it is addressed, and may contain information that is privileged,
confidential and exempt from disclosure under applicable law. Any
unauthorized use, distribution, or disclosure is strictly prohibited. If you
have received this message in error, please notify sender immediately and
destroy/delete the original transmission." 

 

 


  _____  


From: owner-gnso-rn-wg@xxxxxxxxx [mailto:owner-gnso-rn-wg@xxxxxxxxx] On
Behalf Of Ram Mohan
Sent: Monday, March 05, 2007 5:18 PM
To: 'Sophia B'; gnso-idn-wg@xxxxxxxxx; gnso-rn-wg@xxxxxxxxx
Subject: [gnso-rn-wg] Re: Banning CCHH anywhere in a label

Dear Sophia,

Thank you for bringing this topic up for discussion.  I have changed the
subject line for the purposes of clarity.  CCHH is a short-form I devised
for saying "character-character-hyphen-hypen".

 

I read your recommendation to be the following:

"CCHH strings should be banned anywhere they occur in a domain string, at
all levels of the domain."

 

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?

 

If this were implemented, then similarly, a domain name such as "1and1"
which might be represented in a local script retaining the Latin script
character "1" would be banned.  I'm not sure this accredited registrar who
presumably has worked to create a globally recognizable digital identity
would be pleased at this.  Of course, it is conceivable that such strings
exist at the top level also, in the future.

 

In general, the rationale for banning "CCHH" at a position other than the
beginning of a string/label is unclear.  Especially, as you point out below,
most CCHH strings are not going to be visible to the end user, I'm not
certain a phishing threat exists.

 

The case for banning "CCHH" at the 2nd level anywhere in a string - seems to
have the same issues as the one listed above.

 

The case for banning "CCHH" at the 3rd level - is generally out of scope of
ICANN policy.

 

Regards,

Ram

 

--------------------------------------------------------------------------

Ram Mohan

e:  <mailto:rmohan@xxxxxxxxxxxx> rmohan@xxxxxxxxxxxx | m: +1.215.431.0958
--------------------------------------------------------------------------


  _____  


From: owner-gnso-idn-wg@xxxxxxxxx [mailto:owner-gnso-idn-wg@xxxxxxxxx] On
Behalf Of Sophia B
Sent: Monday, March 05, 2007 3:46 PM
To: gnso-idn-wg@xxxxxxxxx; gnso-rn-wg@xxxxxxxxx
Subject: [gnso-idn-wg] Fwd: [gnso-rn-wg] Tagged Names Report for Review &
Approval in 5 March Meeting

 

Dear Ram and All,

 

I have sent this to Chuck and the RN-WG, as my own views on a fix to be made
on the Tagged Name report.  It appears that I did not get my point across
from the point I have raised below and /or my explanations to the group. 

 

Therefore, Chuck has suggested to share it with the IDN WG and see if there
could be further, perhaps better examples. 

 

There are two issues here:

1- Is there an issue

2- What are the risks if we do not address the issue.

 

Pease note cc-- is (character, character --).

 

Thank you ahead,

Sophia

 


---------- Forwarded message ----------
From: Sophia B <sophiabekele@xxxxxxxxx>
Date: 04-Mar-2007 20:27 
Subject: Re: [gnso-rn-wg] Tagged Names Report for Review & Approval in 5
March Meeting
To: "Gomes, Chuck" <cgomes@xxxxxxxxxxxx>
Cc: gnso-rn-wg@xxxxxxxxx

 

Chuck,

 

I know I joined the WG later, and trying to get caught up with all the
reports and the "Tagged name' was one that was NOT the easiest to grasp.
Additionally, I decided to start from your report to "questions for the IDN
Experts" last week, with one that you had marked as "no questions"; one
being the same report.  

 

C. Tagged Domain Names.

All labels with hyphens in the third and fourth character positions (e.g.,
"bq--1k2n4h4b" or "xn--ndk061n").  *        No questions

In any case, I am not at all an IDN expert, but after much interpretations,
translation/transliteration of this report;), I think we have a bit of a
'big miss' on the IDN side of the Tagged Names report.  I am not to say, as
usual that the document is very ASCII centric, but it is to be expected in
the 'ICANN" world which might be a good idea to reserve "ICANN' IDN version
with is labeling, so that the non-ascii world could state their opinion
(that was the humor).  

But on the serious side, these are my comments:

I agree that CC-- reservation should apply to all levels.

However, IDNs in Unicode are going to be deployed at TLD level and other
levels subsequent to the TLD. Such registrations at the registry levels are
represented in ASCII using an ASCII Compatible Encoding, that maps the IDN
label into ASCII prefixed by xn-- (or any future 
changes of two alternative characters followed by two hyphens, as has
happened in the past, e.g. bq--). 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).
Moreover, any IDNs that look like xn--... (or CC--.... for future changes)
should not be allowed. This is because during the roll-out of the IDN
deployments, xn-- may appear in Internet software applications which are not
ACE/IDN-aware, and do not load the appropriate IDN label when it encounters
xn-- prefix and by default, ends up displaying the xn-- ACE label. 

Non-Internet Software applications may not necessarily be IDN-aware when
users are attempting to convey addresses in IDN, and
instead of displaying http://IDN.IDN.IDN <http://idn.idn.idn/>  (URLs) or
UUUU@xxxxxxx (email address) in the language it is supposed to represent,
ends up
writing http://xn--ASCII.xn--ASCII.xn--ASCII or UUUU@xxxxxxxxxxxx--ASCII

Therefore, the modalities of you want to re-phrase the above could be left
for the group to figue out, 

ie. " All labels with hyphens in the third and fourth character positions (
e.g., "bq--1k2n4h4b" or "xn--ndk061n" ) 

to add perhaps a statement "only when "--" is preceded by xn and bq anywhere
in the character ...."

 

kind regards,

Sophia

-------------------------
 



On 02/03/07, Gomes, Chuck <cgomes@xxxxxxxxxxxx > wrote: 

Here is the Tagged Name Report for review and approval in our meeting on
Monday, 5 March.  Changes from earlier versions are highlighted to make it
easier to review.

 

Chuck Gomes

 

"This message is intended for the use of the individual or entity to which
it is addressed, and may contain information that is privileged,
confidential and exempt from disclosure under applicable law. Any
unauthorized use, distribution, or disclosure is strictly prohibited. If you
have received this message in error, please notify sender immediately and
destroy/delete the original transmission." 

 




 



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy