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

[Yves Arrouye <yves@realnames.com>]

> > No. I don't think so. Remember this section 6 of stringprep, that says
> > that for queries (which is what I believe you are talking about now)
> > applications should treat U code points the same as AO? Well U+20000
> > being U, it will be passed on, since this second application is making
> > queries.
> 
> Ok. I understand where the text is unclear. What I am talking about is a
> query, yes. The idea is that the application which is generating/sending
> the query is doing the stringprep, has the old version, and reject the
> codepoint. So the codepoint is not even sent to the server (which _DO_
> understand the new codepoint).

That is actually against Stringprep section 6.1 which states (note the
MUST):

"Applications creating queries MUST treat U code points as if they were
AO when preparing the query to be entered in the process described by a
profile of stringprep."

Which makes sense since it provides for a very good chance that the
application will be able to cope with later revisions of Unicode (modulo the
caveats that started this whole thread).

> The important thing is that nothing unassigned end up in the zonefile.

Agreed. Stringprep is clear on that, no ambiguity there. I think it is also
clear on the query (the part I quoted above). The ambiguities are in the
assumptions that are then made and that can be broken (eg: passing
unassigned code points is a 100% guarantee of working with future
registrations; it is not if mapping tables change but is in the other
cases). That is what will benefit from some clarifications.

YA