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

["Sophia B" <sophiabekele@xxxxxxxxx>]

> 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
> >
> >
> >