Subject: RE: [idn] Re: stringprep and unassigned code points

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 30 Oct 2001 17:58:21 -0800

At 5:35 PM -0800 10/30/01, Yves Arrouye wrote:
>You are missing my point:

Sorry, I can now see that. I thought you were talking about software, 
not people's perceptions.

>  at the time the application gets the code point
>from its environment (the operating system), the code point *is* assigned.
>It is just not considered so because of the Stringprep profile compiled in
>the application. So while this code point is perfectly fine for 1/ the user,
>2/ the people who entered a properly processed string in Server S, the net
>effect, *from the user's perspective* may be that they see some literature
>that advertise going to \U00020000.com (where \U<eight-hex> represents a
>Unicode code point), type exactly that, but cannot get there.

Ah, I see what you are saying now. Sorry for my denseness. You are, 
of course, correct. Anyone who advertises a host name that only 
exists in some newer version of nameprep, and the string that they 
advertise will come out of the newer version different than it went 
in, will be doing a disservice to any user who has an old version.

I'll try to think up some wording relating to this and send it to the 
list for inclusion in the next draft.

>My only conclusion from that was that it is not correct to say that
>applications or their supporting libraries (for Stringprep/Nameprep) will
>not need to be upgraded.

No one ever said that they did not need to be upgraded. They do not 
need to be upgraded in order to enter characters that are valid in 
stored host names. There is a big difference.

>  It may be very easy to do as I said (e.g. on an OS
>where every app uses a shared lib for that, upgrade the lib when you add
>support for the code points in the OS through a language pack or whatever).
>It may also be a nightmare for users of many applications that each use
>their own implementation.

It is only a "nightmare" for the people who enter characters that are 
mapped. Again, it would be silly for someone to advertise a name 
knowing that people with older clients could not enter it.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Soobok Lee" <[email-masked]>
Date: Wed, 31 Oct 2001 12:58:09 +0900

----- Original Message ----- 
From: "Paul Hoffman / IMC" <[email-masked]>
> stored host names. There is a big difference.

People are familiar with case-insensitiveness in hostnames in URL.
They often type in WWW.AOL.COM with CAPSLOCK ON inadvertantly even 
after they saw lowercased advertized hostnames and
have been successful so far in reaching the right webhost for
LDH ones and will be so even for future Cyrillic IDN ones.

If they experience failure at the first attemp to visit uppercased
NEW script IDN webhost from the old nameprep browser, 
may of them will guess the webhost does not exist, and
will give up trying another lowercased new script webhost from their
past experience of case-insensitiveness in hostnames.
  
Soobok Lee

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 30 Oct 2001 20:46:36 -0800

>LDH ones and will be so even for future Cyrillic IDN ones.

How is this statement at all relevant to the topic being discussed? 
Are there any scripts that are being encoded in future versions of 
ISO 10646 that will be affected by CAPS LOCK?

Please note that the discussion we are having is about future 
characters and scripts being encoded *that also have nameprep 
mappings to other characters*. If future characters are included 
without any mappings, everything works just as the user would expect.

What Yves brought up is only valid if there are mappings; that will 
have to be explained better in the stringprep document.

--Paul Hoffman, Director

---

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

----- Original Message ----- 
From: "Paul Hoffman / IMC" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, October 31, 2001 1:46 PM
Subject: Re: [idn] Re: stringprep and unassigned code points

> ISO 10646 that will be affected by CAPS LOCK?

Switching cases in Greek/Cyrillic IME need CAPS LOCK. Don't they?
New bicameral script IME's behavior on CAPS LOCK  may resemble them
as a natural choice.

> without any mappings, everything works just as the user would expect.

X and Y  always look identical in the case of NFC X->Y . And,
script IME (or platform) often has its own preferred form between X or Y.
That's often beyond the choice and capability of the end user.
I am not sure how many NFC will be defined for new script.
But that theory will work if any.

Soobok Lee