ICANN ICANN Email List Archives

[gnso-rn-wg]


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

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

  • To: "Sophia B" <sophiabekele@xxxxxxxxx>
  • Subject: RE: [gnso-rn-wg] RE: [gnso-idn-wg] Re: Banning CCHH anywhere in a label
  • From: "Gomes, Chuck" <cgomes@xxxxxxxxxxxx>
  • Date: Thu, 8 Mar 2007 10:09:52 -0500

Thanks Sophia for explaining but I confess that you have not convinced
me that it is worth doing.
 
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: Sophia B [mailto:sophiabekele@xxxxxxxxx] 
        Sent: Thursday, March 08, 2007 4:11 AM
        To: Gomes, Chuck
        Cc: edmon@xxxxxxxxxxx; Tan, William; rmohan@xxxxxxxxxxxx;
gnso-idn-wg@xxxxxxxxx; gnso-rn-wg@xxxxxxxxx
        Subject: Re: [gnso-rn-wg] RE: [gnso-idn-wg] Re: Banning CCHH
anywhere in a label
        
        
          

                think you said this very well Edmon.  Does this make
sense Sophia?
                Edmon describes why I did not think that this was an
issue in our RN-WG
                meeting yesterday.  Unfortunately, I was not able to
communicate nearly
                as effectively

        
        Not really Chuck:   No one suggested splitting the string.  
         
        The problem was solved unfortunately for the wrong example
<CITIBANKchina.TLD>  ,
        which everyone acknowledges, it is.  Then, Edmond was responding
to Sharam's 
        raising the issue based on the interpretation of that wrong
example, when trying to discuss 
        the justification for the original proposal to ban CCHH (or at
least xn--) in the 
        middle of IDN label.   Then Sharam went on a tangent of xn--
lables 
        into two labels before English label and the Chinese label,
therefore rejecting the idea.  
        Then Edmond got on to explain and concurred with Sharam's
rejection 
        as above saying accepting this issue would necessarily require
going to the 
        ooriginal proposal at IETF and making significant protocol
chages. Obviously too 
        late for that!   So ignore the above exchange. Status quo.
problem was solved
        based on a wrong example.  
         
        Returning to the original question of the justification and
weather we would want 
        to do that, please read the next paragraph; which I intend to
put in summary 
        form for the RN WG, as part of the IDN WG view in the short time
we discussed 
        it, a report that I will send shortly you.
         
        It has been pointed out that during  the deployment stage
literally millions of 
        software maybe slowly needed to be made IDN-aware and that
sloppily 
        programming while being made IDN-aware could take such IDN 
        labels that have xn -- (or cc--) in the middle and mistakenly
convert 
        to the pseudo-embedded U-strings. While clearly market
complaints would 
        take care of this, after preliminary analysis there appears to
be no 
        adverse consequences,  including the formal possibility of some
rare 
        cases of characters in some languages being un-registrable, for
banning 
        cc-- everywhere in the middle or ends of IDN labels. 
         
        And extending the current ban on cc-- at the beginning of IDN
labels to the rest of the 
        IDN label from a programming/implementation perspective adds
almost no 
        extra work and in fact maybe slightly simpler.  Further such
bans of 
        cc-- in the middle/end could always be lifted after several
years. Thus 
        given that at this preliminary stage of analysis there seems to
be no 
        adverse consequences and some small benefits, while it would not
be a 
        big deal whether we ban c-- in the middle/end of IDN labels or
not, my 
        personal recommendation would be to err on the side of safety
and 
        suggest banning cc-- across the board.
        
        I hope this clarifies the issue and the way forward for a
decision. 
        Sophia
         
        On 06/03/07, Gomes, Chuck <cgomes@xxxxxxxxxxxx> wrote: 

                I think you said this very well Edmon.  Does this make
sense Sophia?
                Edmon describes why I did not think that this was an
issue in our RN-WG 
                meeting yesterday.  Unfortunately, I was not able to
communicate nearly
                as effectively.
                
                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." 
                
                
                > -----Original Message-----
                > From: owner-gnso-rn-wg@xxxxxxxxx
                > [mailto:owner-gnso-rn-wg@xxxxxxxxx ] On Behalf Of
Edmon Chung
                > Sent: Monday, March 05, 2007 9:39 PM
                > To: 'Tan, William'; rmohan@xxxxxxxxxxxx
                > Cc: 'Sophia B'; gnso-idn-wg@xxxxxxxxx;
gnso-rn-wg@xxxxxxxxx
                > Subject: [gnso-rn-wg] 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
                >
                >
                >
                




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

Privacy Policy | Terms of Service | Cookies Policy