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

["Gomes, Chuck" <cgomes@xxxxxxxxxxxx>]

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: rmohan@xxxxxxxxxxxx <mailto: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."