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

From: Yves Arrouye <[email-masked]>
Date: Tue, 30 Oct 2001 16:34:58 -0800

> At 9:15 PM -0800 10/29/01, Yves Arrouye wrote:
> >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,
> 
> 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.
>
> [...]
>
> 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.

Well, I heartily request that people read my emails carefully or use replies
different than "you're wrong" (not you, Paul). I did read section 6 of
Stringprep, even before Patrick suggested I do so (would make sense,
right?). My understanding is still that the following scenario is possible
(rephrasing it since my previous attempts at quoting Stringprep section 6
were apparently unproductive):

- Application A uses a profile of Stringprep where say U+20000 and above are
unassigned, because U+20000 was not in Unicode at the time that application
was written. It generates queries for server S, getting Unicode code points
from an operating-system provided input method. Per the Stringprep spec, and
your explanation above, when A gets U+20000 it passes it untouched in the
query.

- Server S benefits from a more recent implementation whose profile of
Stringprep has U+20000 to U+200FF assigned. And it has some mapping for
U+20000. Let's say we're talking DNS (what people here relate the most to),
and it is using a Nameprep version with a map that says:

	20000; 20021; Case map

(I could use deletion as well to go around David's argument of bicameral
scripts). Strings that have been Name/String-prepped for server S have
U+20000 mapped to U+20021. As a result, S and A cannot understand each other
when S receives a string that has U+20000 in it. Unless you suggest that S
should reprocess A's query, but I do not think that has been suggested.

I will be glad to understand that I am wrong in saying that this scenario
shows that some queries from older applications won't have the expected
result against more recent servers (older/recent as far as Stringprep goes).
But can you please point out where my reasoning is then?

Thanks,
YA

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 31 Oct 2001 06:24:12 +0100

--On 01-10-30 16.34 -0800 Yves Arrouye <[email-masked]> wrote:

> - Application A uses a profile of Stringprep where say U+20000 and above
> are unassigned, because U+20000 was not in Unicode at the time that
> application was written. It generates queries for server S, getting
> Unicode code points from an operating-system provided input method. Per
> the Stringprep spec, and your explanation above, when A gets U+20000 it
> passes it untouched in the query.
> 
> U+20000. Let's say we're talking DNS (what people here relate the most
> to), and it is using a Nameprep version with a map that says:
> 
> 	20000; 20021; Case map
> 
> U+20000 mapped to U+20021. As a result, S and A cannot understand each
> other when S receives a string that has U+20000 in it. Unless you suggest
> that S should reprocess A's query, but I do not think that has been
> suggested.

The _intention_ of the versioning (I am not saying that is what the wording
is) is that the application which first encounters U+20000 must do one of
these two things:

 If it has support of the new version of stringprep
 - Reject the character because it belive it is unassigned

 If it doesn't have support for new version of stringprep
 - Map U+20000 -> U+20021

This implies that a user which happen to have support for a new version of
stringprep can register a domainname which include U+20000 (even though
U+20021 ends up in the DNS zonefile). This user presents the new domainname
to another user which have an old application.

Now, what happens?

The goal is (once again, this might not be what the text says) that the
application which the second user uses, which belive U+20000 is unassigned
should reject the domainname which this user entered.

This implies that the second user can not type in / use / whatever the
domainname which the first user have registered.

I saw that Paul said he has some ideas on how to explain this in text in
the document, so, yes, we will be more clear on this.

It is basically the same thing as someone else commented, that we in the
document have to be much more clear about what it means by "the first
application which encounters the domainname".

    paf