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

[Patrik Fältström <paf@cisco.com>]

--On 01-10-30 16.34 -0800 Yves Arrouye <yves@realnames.com> 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.
> 
> - 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.

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