> > 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
