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

From: Yves Arrouye <[email-masked]>
Date: Mon, 29 Oct 2001 21:15:38 -0800

Good point about the "no typing in uppercase" unless we consider other
mappings (e.g. deletions).

> In all cases, the process that encodes the hostname is responsible for
> applying nameprep, not the process that makes the query.

Hmmm. Is that true? And can it be enforced? It is interesting that you
consider that when one types a URL in an editor, the editor is the one
"encoding" the host name. But paste the same string in the browser, and  is
the browser then re-"encoding" it? Most likely.

I think that at the end of the day, while we agree that adding more code
points to Unicode will break some applications that use a Nameprep released
before the code points were assigned, it is also true that it is likely that
IDN will become an OS-based service and that it will be upgraded soon
enough. I can definitely imaging Microsoft shipping updates to a
Nameprep/Stringprep/IDN library as part as language support (e.g. you get
the support for the new language/script, you get the rest with it). But it
is still possible to generate perfectly legal Nameprepped data from an older
standard that cannot be matched agains the same data Nameprepped from a more
recent revision. 

YA

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 30 Oct 2001 07:04:11 +0100

--On 01-10-29 21.15 -0800 Yves Arrouye <[email-masked]> wrote:

> But it
> is still possible to generate perfectly legal Nameprepped data from an
> older standard that cannot be matched agains the same data Nameprepped
> from a more recent revision. 

Wrong. See the specification of stringprep, section 6.

   paf

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 30 Oct 2001 08:37:41 -0800

At 9:15 PM -0800 10/29/01, Yves Arrouye wrote:
>before the code points were assigned,

We don't agree here. Following the rules in stringprep, no 
application will be broken by adding new code points. We (or, more 
accurately, Patrik Fältström and Mark Davis) specifically designed it 
that way. Applications taking queries should look at characters that 
they think are unassigned and pass them in the query.

Nor will new code points "break" name servers. A name server that is 
told to store a name that has what it thinks is an unassigned code 
point will simply say "no". Nothing will break. In order to get it to 
say "yes", you update the table of unassigned characters to the 
newer, now-smaller table.

I heartily request that people read this section of the stringprep 
draft and, if you find places where we can make it clearer, by all 
means let me know soon.

--Paul Hoffman, Director
--Internet Mail Consortium