Subject: Re: [idn] WG Update

From: Dan Oscarsson <[email-masked]>
Date: Mon, 8 Oct 2001 08:33:56 +0200 (MEST)

>> I recommend modify the last line "MUST be discussed" to be
>> "MUST be provided", as to be " Case-insensitivity for non US-ASCII MUST be
>> provided in the protocol proposal"
>
>I disagree. As it happens, all of the proposals provide case-insensitivity
>for non-US-ASCII, but it is *not* a requirement. The protocol would work
>fine and would be perfectly acceptable to users without it. We should be
>clear about the difference between features that are *desirable* (in this
>case for consistency), and *required* features.

Well, I disagree to that.

It *is* a requirement that case-insensitivity shall work for all letters.
That has been the DNS standard so far. That is what people expect.
To have case-sensitive matching is not fine for everybody.

If we are not going to support case-insensivity and case preserving in
responses, then we should turn it of for ASCII too.
Either we support full backward compatibility (that includes having
case-insensitivity and case preserving in protocol for all letters),
or we kill it off for ASCII letters too.
Just because non-ASCII has not been used, does not mean that people
expect the same rules that exist for ASCII to exist for non-ASCII.
The current DNS standard has defined that case-insensitivity shall be
used and that case should be preserved in responses. We break that
if it is not done for non-ASCII letters too.

   Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 9 Oct 2001 00:48:03 -0000

Suppose we deploy uppercase IDNs. This could turn out to be a mistake---
in fact, a complete disaster---because uppercase Alpha looks just like
uppercase A. We won't be able to fix the mistake, because people will
already be relying on domain names that contain Alpha.

Suppose, on the other hand, we initially prohibit uppercase IDNs. If
this turns out to be a mistake, we can fix it later, adding support for
uppercase IDNs, without breaking anything.

> responses, then we should turn it of for ASCII too.

Deprecating uppercase ASCII is fine. Of course, caches and servers will
have to continue accepting uppercase ASCII for compatibility, but users
shouldn't type any new names in uppercase.

> That has been the DNS standard so far. That is what people expect.

``It *is* a requirement that host names shall be ASCII. That has been
the standard so far. That is what people expect.'' Stupid argument.

---Dan

---

From: "Soobok Lee" <[email-masked]>
Date: Tue, 9 Oct 2001 13:13:01 +0900

----- Original Message ----- 
From: "D. J. Bernstein" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, October 09, 2001 9:48 AM
Subject: Re: [idn] WG Update

> already be relying on domain names that contain Alpha.

Greek small 'o' and Cyrillic small 'B' have the same looks with their
latin counterparts. This does not lead us to ban both of them.
It makes sense to map greek 'o' into latin 'o', but prohibiting greek 'o'
does not make sense. we have no standard yet on such look-alike mappings.

Desirable case preservation feature in ACE  is :

  to encode  Greek capital 'A'  as Greek small 'a' with 
     a case flag for 'Capital'.

  For example, AMC-ACE-Z encodes greek <alpha><epsilon><kappa>,
  
  all capital : U+03B1 U+03B5 U+03BA:  mxAIP 
  all small   : u+03B1 u+03B5 u+03BA:  mxaip

  Two output ACE labels are case-insensitively equivalent.

> uppercase IDNs, without breaking anything.

someone sticking to un-fixed old applications would lose.

> shouldn't type any new names in uppercase.

The case information carries valuable preferred formating of a label:
 for example,  UN.org, WHO.org are much easier to recogize.
That's one of the reasons why Most browers and email clients preserve the case informations.

Soobok

---

From: "D. J. Bernstein" <[email-masked]>
Date: 9 Oct 2001 04:37:34 -0000

> for example,  UN.org, WHO.org are much easier to recogize.

If you actually visit the UN and WHO web sites, you'll see that they
consistently give their own DNs in lowercase: who.int, for example.

> prohibiting greek 'o' does not make sense

If someone is allowed to register aol.com with a Greek lowercase o, then
nameprep is a bad joke.

---Dan

---

From: "Soobok Lee" <[email-masked]>
Date: Tue, 9 Oct 2001 14:14:09 +0900

----- Original Message ----- 
From: "D. J. Bernstein" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, October 09, 2001 1:37 PM
Subject: Re: [idn] case preservation

> consistently give their own DNs in lowercase: who.int, for example.

That does not fully reflect the preferences of the staffs and end users.
Uppercased ones help people to recogize them more fast.
WIPO always come with uppercase one in all newspapers ever i'd read.
It's very natural for applications 
to respect its uppercase forms that end users perfer and type in.
 
> If someone is allowed to register aol.com with a Greek lowercase o, then

I heard that nameprep is for enforcing uniqueness, but only for
input convenience. There are so many equivlances that are too complex
to be solved in nameprep.
I hope you do not mix the case issue within a script block 
with look-alikeness issue across script blocks.

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 09 Oct 2001 07:54:20 +0200

> If someone is allowed to register aol.com with a Greek lowercase o, then

Already today, people can register domainnames with characters which look
"similar" like 'o' and 0, or '1' and 'l'. I.e. this is not a new problem.
It is well-known for the people which work with domain name dispute
resolution.

Further, this wg has chosen to use the Unicode Character Set and
Normalization according to UTC TR#15, normalization form KC. If you are
unhappy with how individual characters are normalized, please to go the
Unicode Consortium after reading the criteria for the normalization process
chosen.

If you are unhappy with the choice of refering to the work in the Unicode
Consortium, that is a valid concern, but should have been brought up some
1.5-2 years ago.

That horse is already dead.

   paf

---

From: "Soobok Lee" <[email-masked]>
Date: Tue, 9 Oct 2001 15:41:10 +0900

----- Original Message ----- 
From: "Patrik Fältström" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, October 09, 2001 2:54 PM
Subject: Re: [idn] case preservation

> It is well-known for the people which work with domain name dispute
But, the real problem lies in the increased number of such ambiguities.
For LDH domains, we need to know about only 'O','o','1','l' .
But for IDN, almost _ALL_ of 'a' ~ 'z' have their look-alike characters in
greek,cyrillic and cherokee script. Seeing them printed  on papers,
most people can't know whether they are LDH domains or IDN ones.

ICANN/DNSO/ccSO should make some recommendations/enforcement 
on IDN registration and dispute resolution policies 
before IDN's being deployed and owned.

Soobok Lee

---

From: "James Seng/Personal" <[email-masked]>
Date: Tue, 9 Oct 2001 14:52:12 +0800

Okay, wrong forum then. You should bring this to ICANN/DNSO/ccSO on
this, not IDN WG.

-James Seng

----- Original Message -----
From: "Soobok Lee" <[email-masked]>
To: "Patrik Fältström" <[email-masked]>; <[email-masked]>
Sent: Tuesday, October 09, 2001 2:41 PM
Subject: Re: [idn] case preservation

But for IDN, almost _ALL_ of 'a' ~ 'z' have their look-alike characters
in

Soobok Lee

---

From: "D. J. Bernstein" <[email-masked]>
Date: 9 Oct 2001 06:51:20 -0000

Patrik writes:
> characters which look "similar" like 'o' and 0, or '1' and 'l'

I am not talking about the momentary confusion between ao1.com and
aol.com. I am not talking about characters that merely look ``similar.'' 
I am talking about characters whose standard glyphs are IDENTICAL.

A properly typeset uppercase Alpha is IDENTICAL to a properly typeset
uppercase A, just as a properly typeset tab is IDENTICAL to a properly
typeset sequence of spaces. It is simply NOT POSSIBLE to tell the
difference between AOL.com and AOL.com.

This does not mean that Alpha and A are the same character, or that tab
and space are the same character. It does mean, however, that you've
done a half-assed job with the current version of nameprep.

If you're not going to do a thorough job of nameprep, then you shouldn't
be trying to deceive users into believing that IDNs can be safely typed
from textual printouts. It would be better to omit nameprep entirely;
then users will stick to mechanisms that work, such as clicking on URLs.
(Bad characters should still be avoided in registrations, of course.)

---Dan

---

From: "Soobok Lee" <[email-masked]>
Date: Tue, 9 Oct 2001 16:15:55 +0900

----- Original Message ----- 
From: "D. J. Bernstein" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, October 09, 2001 3:51 PM
Subject: Re: [idn] case preservation

> from textual printouts. 

Recent Nameprep revision already contains one statement for caution
wrt similarly-looking characters it don't solve.

>It would be better to omit nameprep entirely;

nameprep is not mature but _useful_ for input convenience even with its inability to solve look-alike problems.

---

From: "Soobok Lee" <[email-masked]>
Date: Tue, 9 Oct 2001 17:31:00 +0900

----- Original Message ----- 
From: "James Seng/Personal" <[email-masked]>
To: "Soobok Lee" <[email-masked]>; "Patrik Fältström" <[email-masked]>; <[email-masked]>
Sent: Tuesday, October 09, 2001 3:52 PM
Subject: Re: [idn] case preservation

> Okay, wrong forum then. You should bring this to ICANN/DNSO/ccSO on

Partly No. The problem has some aspects that lies between IETF and ICANN.
For example, some equilvalences are now being solved by NFKC,
while others are not  only because UTC has no standard for them NOW.
Therefore, human interventions on them and its social/financial overheads
are inevitable. Explanation and justification for that cannot be done 
only in ICANN . IDN WG should provide some techinical rationale for
them and that's what i have concerns about. What if some ICANN members
ask back  "why didn't you solve that problem ?". This WG has been  for
about 2 years.

I got an impression that you says " we IETFer's are never responsible for that issues!". I hope my impression was  false.

Soobok

---

From: "James Seng/Personal" <[email-masked]>
Date: Tue, 9 Oct 2001 17:14:58 +0800

I agree with your assessment that it maybe appropriate for this wg to
publish a document on the shortfalls of the work we doing. perhaps this
document could contain information on operational issues & localization
consideration etc for domain names holder, zone administrator,
registries etc. This idea have been bouncing around for a while but it
is more important for someone to pick this up and write a draft on it.
(You will have my support in my personal capacity :-)

However, do take note that it is inappropriate for this wg to instruct
ICANN on the deployment of IDN or write a document for their
education/purpose.

"The group will not address the question of what, if any, body should
administer or control usage of names that use this functionality"

-James Seng

----- Original Message -----
From: "Soobok Lee" <[email-masked]>
To: "James Seng/Personal" <[email-masked]>; <[email-masked]>
Sent: Tuesday, October 09, 2001 4:31 PM
Subject: Re: [idn] case preservation

----- Original Message -----
From: "James Seng/Personal" <[email-masked]>
To: "Soobok Lee" <[email-masked]>; "Patrik Fältström" <[email-masked]>;
<[email-masked]>

> Okay, wrong forum then. You should bring this to ICANN/DNSO/ccSO on

Partly No. The problem has some aspects that lies between IETF and
ICANN.
For example, some equilvalences are now being solved by NFKC,
while others are not  only because UTC has no standard for them NOW.
Therefore, human interventions on them and its social/financial
overheads
are inevitable. Explanation and justification for that cannot be done
only in ICANN . IDN WG should provide some techinical rationale for
them and that's what i have concerns about. What if some ICANN members
ask back  "why didn't you solve that problem ?". This WG has been  for
about 2 years.

I got an impression that you says " we IETFer's are never responsible
for that issues!". I hope my impression was  false.

Soobok

---

From: Martin Duerst <[email-masked]>
Date: Tue, 09 Oct 2001 17:51:56 +0900

>be trying to deceive users into believing that IDNs can be safely typed

I think it was never a goal to have mixed-script names
(e.g. <A-Greek><O-Cyrillic><L-Latin>) to be easy to type.
The main problem in such cases for actual input is that
you have to switch (software) keyboards, even if it is
very clear which script the character comes from.
There was never even a goal to fully support completely
mixed-script labels, because they don't really make sense.
However, because names e.g. of the form latin-greek
could make sense, mixed-script labels as such were
included in the requirements.

>(Bad characters should still be avoided in registrations, of course.)

Bad character combinations should be avoided with registration.
The only registrations for things like <A-Greek><O-Cyrillic><L-Latin>
will come from spoofers, and the only way such spoofers have
a chance is through clicking on URIs or a similar interface.

Regards,    Martin.

---

From: "Soobok Lee" <[email-masked]>
Date: Tue, 9 Oct 2001 18:56:51 +0900

----- Original Message ----- 
From: "Martin Duerst" <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>; <[email-masked]>
> a chance is through clicking on URIs or a similar interface.

You forgot to mention this type :
All-cyrillic(or All cherokee) uppercase "SEX,CISCO,ATT,HOME,IBM" have the
same look with all-latin uppercase ones.

SOobok

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 09 Oct 2001 15:44:38 +0200

> be trying to deceive users into believing that IDNs can be safely typed

I have definitly never said that. The contrary.

I have said that nameprep _only_ follow the technical note which Unicode
Consortium have created, because systems which handle Unicode will also use
the same mechanism, which means that data in Unicode _might_ be normalized
inside a unicode system without the knowledge of the user.

Note the might.

  paf

---

From: Dave Crocker <[email-masked]>
Date: Tue, 09 Oct 2001 08:00:47 -0700

>difference between AOL.com and AOL.com.

Thank you for providing an example that very nicely shows this to be an old 
problem  for which there is no known solution.

Feel free to offer text to add to the specification, if you feel it will 
solve the problem.

d/

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

---

From: Dan Ebert <[email-masked]>
Date: Tue, 09 Oct 2001 08:14:31 -0700

> same look with all-latin uppercase ones.

But, as Martin said, those links will only be 'used' by spoofers and
only work via clicking on URIs.  (Things like this already happen anyway
... i.e. Someone registers AOL-billing.foo then spams AOL users asking
for updated credit card info ...) If the spoofed domain were printed on
paper the end user would (most likely) interpret the characters as Latin
and type them in accordingly and go to the 'real' site, not the spoofed
site.

-- 
Dan Ebert      <[email-masked]>       eNIC Corporation
-----------------------------------------------------
 "What is wanted is not the will to believe, but the 
    will to find out, which is the exact opposite."
       -- Bertrand Russell, "Skeptical_Essays", 1928
-----------------------------------------------------

---

From: "ben" <[email-masked]>
Date: Tue, 9 Oct 2001 12:08:32 -0400

> "similar" like 'o' and 0, or '1' and 'l'. I.e. this is not a new

I have been discussing my Supreme CDN system offline and have come to
the conclusion that it will *never* become a standard because it is
simply not interoperable with existing systems.  But as I have said,
that is okay as I believe all along that all the other CDN systems
(although not as perfect as mine) are absolutely 100% fine exactly the
way they are.

Offline, I have gotten less then pleasant remarks about why "some
people are trying to cause trouble/delay the progress/make things more
difficult then they really are/etc, etc."  Those remarks are made
*not* because of a lack of respect for people's contribution to this
WG but simply because of a lack of understanding of the Chinese
culture and why TC<->SC is so important- which can lead to fustrations
that are fully understandable.  Although we may never come up with a
solution that will be agreed upon by the majority of this WG, the fact
remains that TC<->SC is of paramount importance to the users of
CDNs... and the above 'O', '0','1','l' issue just gave me a good idea
on how to explain why it is so (not sure if this analogy had ever been
made before, but it shouldn't hurt to repeat it.)

At first, the '1','l' may not seem like a good analogy for TC<->SC
conversion because we definitely do *not* want to map 'l' with '1'.
However, the confusion of '1' and 'l' does illustrate why TC<->SC is
so important.  For example, when a person is given 'l.TLD', he can
easy type in '1.TLD' instead and have absolutely no idea why he cannot
reach the intended website.  In English the chance of such a confusion
is only limited to a few cases (such as '0' and '1') where as for
Chinese, *every single* Chinese character poises the opportunity for
such confusion.  Remember, Simplified Chinese and Traditional Chinese
are indistinguishable to many users of CDNs of certain
backgroud/education/location/culture.  (Given certain Chinese
characters, even someone as educated in Chinese as I, cannot tell you
whether it is traditional Chinese or simplified Chinese.)

Thanks
Ben Chan

---

From: Martin Duerst <[email-masked]>
Date: Wed, 10 Oct 2001 13:49:01 +0900

>whether it is traditional Chinese or simplified Chinese.)

This is a good point. But please note that you don't actually have
to know whether a character is simplified or traditional. If you
work on a simplified Chinese system or with a simplified Chinese
input method, you will just get simplified Chinese characters
as the first choice from you input method. Same thing the other
way round for traditional Chinese.

This means that if somebody wants to have a domain name usable
both is China,Singapore,.. and in Taiwan,Hong Kong,..., they
have to do two registrations. Of course, there are cases where
there are more registrations needed (e.g. for simplified
characters used in Taiwan), but these are exceptions.

Also, for most characters where there is actually a difference
(there are many cases where there is none, and which are
therefore unified), it is quite easy to tell whether they
are simplified or not. The main reason for this is that
most simplifications are very systematic. Of course, because
there are so many Chinese characters, there are always some
that you don't know. That is something that applies to any
other aspect of Chinese characters.

Regards,    Martin.

---

From: "Soobok Lee" <[email-masked]>
Date: Wed, 10 Oct 2001 17:12:19 +0900

----- Original Message ----- 
From: "Dan Ebert" <[email-masked]>
To: "Soobok Lee" <[email-masked]>
Cc: "D. J. Bernstein" <[email-masked]>; <[email-masked]>; "Martin Duerst" <[email-masked]>
Sent: Wednesday, October 10, 2001 12:14 AM
Subject: Re: [idn] case preservation

> only work via clicking on URIs.  

No. Regimate registrants could own the domains and use them publicly.
Cyrillic 'H'  ( cyrillic upper EN) is read differenly from Latin 'H'.
Cyrillic 'HOME' has nothing to do with English "HOME".

>(Things like this already happen anyway
> for updated credit card info ...) 

the number of such severe security breaches  and confusions matters. 
AOL and  AOL  versus  AOL and AOL-billing ? not comparable.

>If the spoofed domain were printed on

Most Russians would interpret them as Cyrillic ones, while non-Russian would not.

Soobok

---

From: Martin Duerst <[email-masked]>
Date: Wed, 10 Oct 2001 17:31:08 +0900

>Cyrillic 'HOME' has nothing to do with English "HOME".

There is indeed a non-zero (but very, very small) probability
for such cases. But if domain names are written in lower case
the way they mostly have been up to now, a word in a language
written in Cyrillic looking the same as a word in a language
written in Latin would be about as rare as a four-leaf clover.

>Most Russians would interpret them as Cyrillic ones, while non-Russian 

Most people will interpret them in context, if necessary.
Machines are very bad at using context, but people
are very good.

Regards,    Martin.

---

From: "Soobok Lee" <[email-masked]>
Date: Thu, 11 Oct 2001 00:55:17 +0900

----- Original Message ----- 
From: "Martin Duerst" <[email-masked]>
To: "Soobok Lee" <[email-masked]>; "Dan Ebert" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 10, 2001 5:31 PM
Subject: Re: [idn] case preservation

> written in Latin would be about as rare as a four-leaf clover.
Now it may be rare as you said. 
But, LDH.com and LDH.RU are already saturated or
being saturated, while cyrillic ML.com are still 'fresh' 
and waiting for being populated with private companies
by the development of Russian market economy.

> Machines are very bad at using context, but people

The amount of first-time confusions in IDN deployment in Russia may be 
very different than that in China and Korea.
It may need some research how to teach IDN to Russians familiar with
LDH.ru type of domains.

Regards,

Soobok Lee

---

From: "ben" <[email-masked]>
Date: Wed, 10 Oct 2001 12:06:25 -0400

> way round for traditional Chinese.
You *do* need to know whether the characters of the CDN are
traditional or simplified.  This is analogous to the 'l','1' issue.
One must be aware enough to recognize that the 'l' is the 'lowercase
L' and not the 'number one'.

> characters used in Taiwan), but these are exceptions.

Yes, this is certainly one of the ways to achieve TC<->SC equivalence.
Again, this is analogous to someone registering both the '1.TLD' and
the 'l.TLD' (or maybe even 'I.TLC') to cover all bases.

> other aspect of Chinese characters.

For people who use exclusively TC *or* exclusively SC in their
everyday lives,  it is easier.  However, for people who use them
interchangably, it is much harder.  But in any case, every user must
atleast make the conscious effort to be aware of whether a CND  is SC
or TC much the same as a user must make the conscious effort to be
aware whether 'l.TLD' is a 'number one' or a 'lowercase-L'.

Now... ofcourse, whether this justifies having TC<->SC conversion as a
standard is obviously not up to me to decide... but up to this WG.
(As I have humbly learned from my experience with my "Supreme CDN
system"- although supreme, is not interoperable with others.)
However, I do hope that this analogy using 'l','1','O','0' will
atleast offer much more understanding as to why TC<->SC is such a
critical issue for the Chinese culture.

Thanks,
Ben Chan

---

From: "Soobok Lee" <[email-masked]>
Date: Thu, 18 Oct 2001 16:13:01 +0900

some corrections:

----- Original Message ----- 
From: "Soobok Lee" <[email-masked]>
To: "Dan Ebert" <[email-masked]>; "Martin Duerst" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, October 11, 2001 12:55 AM
Subject: Re: [idn] case preservation

> > written in Latin would be about as rare as a four-leaf clover.

No. mcuh more  frequent than you guess.

Cyrillic small 'a' 'e' 'o' 'c' 'p' 'x' 'y'  'i' 'j' 's' have the exactly same look with latin small ones. All word combinations of them will collide with LDH.ru ones.
For example, lowercased Cyrillic  "cape, sexy, epoxy, ceo, pay, cpa "
cannot be distinguished from english ones in most rendering environments.

see http://www.unicode.org/charts/PDF/U0400.pdf

Only Cyrillic 'B' 'H' 'M' 'T' have lowercase forms which look the same with uppercase ones.

Soobok Lee

---

From: Martin Duerst <[email-masked]>
Date: Thu, 18 Oct 2001 18:32:20 +0900

At 16:13 01/10/18 +0900, Soobok Lee wrote:

>Cyrillic small 'a' 'e' 'o' 'c' 'p' 'x' 'y'  'i' 'j' 's' have the exactly 
>same look with latin small ones.

Yes. But 'i' 'j' 's' are not actually used in most languages
that are written in Cyrillic. And in all languages, most of
the possible letter combinations are not actually used. And
the longer a word is, the more quickly the probabilities
approach zero.

Regards,   Martin.

---

From: "Soobok Lee" <[email-masked]>
Date: Thu, 18 Oct 2001 20:35:26 +0900

----- Original Message ----- 
From: "Martin Duerst" <[email-masked]>
To: "Soobok Lee" <[email-masked]>; "Soobok Lee" <[email-masked]>; "Dan Ebert" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, October 18, 2001 6:32 PM
Subject: Re: [idn] case preservation

> the longer a word is, the more quickly the probabilities

 the _SUM_ of the probability for every word length 1..big N   may converge to
a certain non-zero value that should not be neglected. With 'HMTB',it will be much bigger than that.

it's well known that all 3 letter labels are registered in LDH.com,.net,.org.
every 3-letter cyrillic label from 'aeocpxy' collides with a 3-letter LDH.com .
"copy.com" "coca.com" "ec.com" "ace.com" "eco.com" "ocx.com" "oxy.com" "cap.com" ....   :-))

 Cyrillic 'i' 'j' 's' are not used in Russian. But, as you know,
 'j' is used in serbian,azerbaijani language in cyrillic script.
 and 'i' is ByeloRussian-Ukrainian 'I'.  
Are these characters extinct or live?

Soobok Lee