Subject: [idn] Fw: Cyrillics - Latin

From: "James Seng/Personal" <[email-masked]>
Date: Mon, 4 Feb 2002 20:58:30 +0800

fyi

----- Original Message -----
From: "Sergey Charikov" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Monday, February 04, 2002 4:34 PM
Subject: Cyrillics - Latin

> Do believe there's absolutely no any confusion of Latin vs Cyrillics
for
> Russian community.
>
> We can see many familiar words in another language characters
combinations,
> especially if there are similar drawing characters.
>
> The matter is when Russians see COBET (printed) they see "Soviet" and
no
> more
> And they print on a business card - COBET for website with cyrillics
content
> (for russian and cyrillics markets)
> but they take SOVIET usually for webpages on english.
> We should understand the cyrillics domains required for cyrillics
folks
> only.
>
> A PY (Paraguay) case is a funny thing only. This says about rushing to
use
> the native language even in such a way.
>
> Best Regards,
> Serguei Charikov
> Chair of Russian Language WG of MINC
> www.minc.org/WG/russian
>
> >
> > If I may add a note on Latin-Cyrillic confusion. Quoted
> > from an explanation I have been providing to another group.
> >
> > An aside note - I learnt from Russian colleagues that some
> > Russian favor to register domain names under .PY (ccTLD for
Paraguay)
> > rather that .RU (ccTLD for Russia). The reason is that "PY"
> > is the beginning of the word "Russia" in Cyrillic - PYCCU[R].
> > The last caracter is Cyrillic "ya", see below, any other is
identical
> > printing in Latin and Cyrillic, different code points in Unicode,
> > identical code point in "LDH".
> >
> > Best regards,
> > Elisabeth Porteneuve
> > --
> >
> >    Let have a glimpse on both end-user and intellectual property
> >    perspectives with an example.
> >
> >    The word "COBET" reads as it is if one assumes it is Latin
> >    alphabet, but spells "soviet" if one assumes it is Cyrillic.
> >    The Unicode code point representation for Cyrillic "C", 0x0421,
> >    is different from code point representation for Latin "C",
0x0043,
> >    but they are identical on a printed paper, business cards
> >    or a screen. Taking into account the above, a usage of Unicode
> >    code points subsequently makes it impossible to communicate
> >    with anybody without knowing which language is _printed_, or,
> >    even worst, which letter or sign is printed in which language.
> >
> >    In the famous TOYS[R]US the R in brackets is a Cyrillic
> >    code point 0x042f spelled "ya", which also happen to be the
> >    letter R seen as in mirror, spelled "are". With the exception
> >    of that letter [R], any other one in TOYS[R]US may be read
> >    either as Latin or as Cyrillic code point, different spellings,
> >    different code points, identical printing on paper or screen.
> >    In an example of a word of 6 code points, with the same
> >    printing but 2 different contents there is 2**6 = 64 possible
> >    combinations  It is the number of times a 6 letters word
> >    should be registered to preserve its whole intellectual
> >    property rights in 2 alphabets, Latin and Cyrillic.
> >    It is also the maximal number of tries an end-user should
> >    made to get to a website, if she or he got only a printed
> >    information.
> >    I have no competencies to expand this example to other
> >    alphabets or code points. Hovever, as far as I understand,
> >    the problem of Chinese code points have some similarity.
> >
> > --
> >
> >
> >
>

---

From: John C Klensin <[email-masked]>
Date: Mon, 04 Feb 2002 09:24:50 -0500

James,

Same old problem.   Mr. Charikov's note assumes that there is
sufficient context to know whether to interpret COBET as
Cyrillic or Latin characters.  In almost any normal context -- a
sentence, a conversation, usually even a business card, that is
a reasonable assumption.  In the DNS, especially in a generic
TLD, where a name or name-reference (e.g., a URI) may exist with
no context at all, it is often is not.  For the DNS, we have the
additional problem that, in many societies, we now have years of
experience with Latin-character DNS names/ URLs in web and email
addresses on business cards that are otherwise exclusively in
other scripts.  So the _context_ of [email-masked] might
well cause one to predict a Latin-based interpretation for the
ambiguous characters, even if the business card is in Cyrillic.

We have been down this line of argument many times.  It is a
problem.  We don't have a solution within the DNS.  All of the
proposed solutions-by-extended-matching lead to absurdities or
to overly-severe constraints about how one of the languages
involved is used.  The alternatives are 

(i) to accept the problems, move forward, and hope that the
consequences are not as severe as many of us (for different
reasons, and with different languages or scripts as the focus
for our concerns) fear   or

(ii) to give it up and conclude that there are no reasonable
solutions within the DNS that do not cause unacceptable risks of
user confusion and identifier ambiguity.

And, James and Marc, you can consider that a comment on the Last
Calls.

    john

--On Monday, 04 February, 2002 20:58 +0800 "James Seng/Personal"
<[email-masked]> wrote:

> To: <[email-masked]>;
> <[email-masked]> Sent: Monday, February 04, 2002 4:34
> PM
>> > is the beginning of the word "Russia" in Cyrillic -
>> > PYCCU[R]. The last caracter is Cyrillic "ya", see below,
>> > any other is
> identical
>> > printing in Latin and Cyrillic, different code points in
>> > Unicode, identical code point in "LDH".
>> > 
>> > Best regards,
>> > Elisabeth Porteneuve
>> > --
>> > 
>> >    Let have a glimpse on both end-user and intellectual
>> >    property perspectives with an example.
>> > 
>> >    The word "COBET" reads as it is if one assumes it is
>> >    Latin alphabet, but spells "soviet" if one assumes it is
>> >    Cyrillic. The Unicode code point representation for
>> >    Cyrillic "C", 0x0421, is different from code point
>> >    representation for Latin "C",
> 0x0043,
>> >    or a screen. Taking into account the above, a usage of
>> >    Unicode code points subsequently makes it impossible to
>> >    communicate with anybody without knowing which language
>> >    is _printed_, or, even worst, which letter or sign is
>> >    printed in which language.
>> > 
>> >    code point 0x042f spelled "ya", which also happen to be
>> >    the letter R seen as in mirror, spelled "are". With the
>> >    exception of that letter [R], any other one in TOYS[R]US
>> >    may be read either as Latin or as Cyrillic code point,
>> >    different spellings, different code points, identical
>> >    printing on paper or screen. In an example of a word of
>> >    6 code points, with the same printing but 2 different
>> >    contents there is 2**6 = 64 possible combinations  It is
>> >    the number of times a 6 letters word should be
>> >    registered to preserve its whole intellectual property
>> >    rights in 2 alphabets, Latin and Cyrillic. It is also
>> >    the maximal number of tries an end-user should made to
>> >    get to a website, if she or he got only a printed
>> >    information.
>> >    alphabets or code points. Hovever, as far as I
>> >    understand, the problem of Chinese code points have some
>> >    similarity.
>> > 
>> > --
>> > 
>> > 
>> > 
>> 
> 
> 
> 
>

---

From: "Mark Davis" <[email-masked]>
Date: Mon, 4 Feb 2002 08:01:51 -0800

I agree with John that there is no solution in DNS. I would go further
in that I don't think a solution is possible in DNS.

On the other hand, I think it would be quite useful--as I suggested
some time ago--to add some text that strongly recommended that
browsers and similar programs that display URLs indicate with some
sort of visual mechanism where they contains mixed scripts, e.g.
highlight those characters not in the script of the majority of the
characters (with a different color or background).

Mark
—————

Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ
[For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]

http://www.macchiato.com

---

From: John C Klensin <[email-masked]>
Date: Mon, 04 Feb 2002 11:09:34 -0500

--On Monday, 04 February, 2002 08:01 -0800 Mark Davis
<[email-masked]> wrote:

> I agree with John that there is no solution in DNS. I would go
> further in that I don't think a solution is possible in DNS.

"Not possible in DNS" is what I meant to say, so I think we
agree.

> On the other hand, I think it would be quite useful--as I
> suggested some time ago--to add some text that strongly
> recommended that browsers and similar programs that display
> URLs indicate with some sort of visual mechanism where they
> contains mixed scripts, e.g. highlight those characters not in
> the script of the majority of the characters (with a different
> color or background).

I believe that it would be a significant service to the
community --I would suggest that it is nearly necessary-- to
write strong "security considerations" sections for these
documents, or separate documents, that explicitly identify the
character and range of as many of these problems as are
well-understood.  I think that incorporating suggestions like
Mark's into such explanations would be very helpful.

     john

---

From: Dave Crocker <[email-masked]>
Date: Mon, 04 Feb 2002 08:18:05 -0800

Folks,

>experience with Latin-character DNS names/ URLs in web and email

         nova.com

Is that

         a) a latin-related reference to an astronomical activity

         b) an american reference to a car

         c) a spanish reference to something that is stationary (or does 
not work properly)

         d) something else

(I particularly like that the actual site contains a pointer to other uses 
of the name: <http://www.nova.com/other-nova/index.html>.)

In other words, we already have opportunities for confusion in domain 
names.  We deal with them adequately.

Domain names are character strings, they are not language.  All of this 
debate pertains to very important issues about language usage.  It is 
outside the scope of the working group.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: "Soobok Lee" <[email-masked]>
Date: Tue, 5 Feb 2002 06:11:53 +0900

----- Original Message -----
From: "Dave Crocker"
>
> Domain names are character strings, they are not language.

Domain names are not pure character strings.
Rather, Domain names are a subset of entire character strings
*with imposed rules and constraints and requirements*
to serve as identifiers to *name* uniquely and unambigously
domains in the DNS for international user communities.

Your claim seems to be insisting that IDN is for *machines*, not for human beings.
machines don't complain about the ambiguity between .com and .com.

Morover, the problem of IDN itself may become out-of-scope of this WG by introducing the
out-of-scope *policy* rules.

Any sound address system or identifier systems should be self-contained and
self-complete. Deadly needs for per-zone basis compensating solutions like
policy-based multiple registrations prove and admit that IDN must not be pure strings.
The "policy" cannot be applied or coded or enforced further into numerous independant applications,
but only into per zone authoratative servers.
Such inconsistency due to two-layered (stringprep and then policy) rules will cause
confusions and troubles.

This WG is not qualified to discuss the success of such "policy", and its discussion is
surely out of scope of this WG. If current IDN solutions rely on such
out-of-scope and still-unresolved and not-existing and not-verified "policy",
how can we declare this IDN solution is okay and justify last calls for it?

Soobok Lee

---

From: "Soobok Lee" <[email-masked]>
Date: Tue, 5 Feb 2002 06:45:55 +0900

(sorry for my previous posting in bad html settings, i repost this in pure text)
----- Original Message ----- 
From: "Dave Crocker" <[email-masked]>

Your claim seems to be insisting that IDN is for *machines*, not for human beings.
machines don't complain about the ambiguity between <latin A>.com and <Cyrilic A>.com. 

Moreover, the problem of IDN itself may become out-of-scope of this WG by introducing the 
out-of-scope *policy* rules. 

Any sound address systems or identifier systems should be self-contained and
self-complete.  Deadly needs for per-zone basis compensating solutions like
policy-based multiple registrations prove and admit that IDN must not be pure strings.
The "policy" cannot be applied or coded or enforced further into numerous independant applications, 
but only into per zone  authoritative servers. 
Such inconsistency due to two-layered (stringprep and then policy) rules will cause 
confusions and troubles.

Soobok Lee

---

From: "Masahiro Sekiguchi" <[email-masked]>
Date: Tue, 5 Feb 2002 09:18:47 +0900

> outside the scope of the working group.

Sounds reasonable.

Then, what we need to make clear is the answer to a question:

    Why is uppercase/lowercase issue that is unique to a
    particular group of scripts covered in this group?

Or, in other words,

    Are there any reason we can't remove case mapping from
    our spec?  (Other than something like "because it is a
    natural English convention..." :-)

Once some persuasive statements are included in our draft,
most of complains (if not all) about lack of some language-
dependent processing from our spec will disappear.

---

From: "James Seng/Personal" <[email-masked]>
Date: Tue, 5 Feb 2002 08:40:02 +0800

Just one clarification, but one I feel quite important: The inclusion of
case mapping is not because it is "English convention".

The case mapping data of Nameprep comes from the definition of Unicode
Technical Report #21 Case Mapping which includes mapping for scripts that is
bicameral, ie scripts that have well-defined upper & lower case. (Note: we
still talking about scripts, not languages)

It is definately appropriate to question the inclusion or exclusion of
UTR#21.

The choice open to the group include:
1. Choose to include UTR#21 in IDN; or
2. Choose excluse UTR#21 from IDN

But it is out-of-scope for the IDN to change/modify/bypass/adopt-and-extend
UTR#21. These are better done in the UTC.

-James Seng

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 4 Feb 2002 17:13:35 -0800

>     particular group of scripts covered in this group?

Very good point. I think we did have that justification in the 
distant past, but it was lost along the way. We will add it after the 
WG last call. The reason is that the current DNS has case-insensitive 
matching for current names; if we did not do that for the additional 
characters being added, you would get great user confusion. For 
example, "Abc" matches "abc", but "<Capital-A-with-accent>bc" would 
not match "<lowercase-a-with-accent>bc".

>     natural English convention..." :-)

Yes, there is a good reason: removing the table would introduce confusion.

>dependent processing from our spec will disappear.

We only wish. :-) Note that the case conversion is not 
"language-dependent" or even "script-dependent": it was added for all 
scripts (which are used in many languages) that have standardized 
case conversions.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "D. J. Bernstein" <[email-masked]>
Date: 5 Feb 2002 02:53:18 -0000

Paul Hoffman / IMC writes:
  [ if domain names become case-sensitive ]
> you would get great user confusion

URLs are already case-sensitive. Do you claim that users are confused by
this---so confused, in fact, to justify the costs of making all URLs
case-insensitive? Where are the studies supporting your claims?

The careful approach is to start with (1) case-sensitive IDNs in which
(2) uppercase letters are prohibited. If it turns out that users really
need case insensitivity, we can add it later, because of #2. Otherwise,
we'll avoid huge implementation and deployment costs, because of #1.

---Dan

---

From: YangWoo Ko <[email-masked]>
Date: Tue, 5 Feb 2002 15:23:01 +0900

> Mark's into such explanations would be very helpful.

Dear John C Klensin and others,

Even though I doubt whether peoples out there may take "security
considerations" seriously enough to minimize problems, this is
one of what we MUST do.

I want to elaborate this idea a little bit. The security consideration 
section should cover at least three areas;
* For IDNA implementers
* For zone administrators (especially gTLD registries)
* For end users

Some may disagree with second and/or third area, we should never
forget that all of those problems will arise from registration 
and use of domain name not from bad implementation.

Regards

-- 
/*------------------------------------------------
YangWoo Ko : [email-masked]
We Invent Enterprise Software Solutions
and Make You Secure & Powerful.
------------------------------------------------*/