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

[Yves Arrouye <yves@realnames.com>]

> I must be extremely bad at expressing myself. This is now the third time
> since monday I explain how things work.

No, no, it's just me.

> > Now
> > let's suppose Unicode encodes something new, for which a new Nameprep is
> > released (because some additions to the mapping table are needed).
> 
> A mapping can only be from an earlier unassigned codepoint.

My case exactly.

> > At
> > this point, the DNS servers may contain the ACE(Nameprep(names in this
> > new thing)).
> 
> ACE have absolutely nothing to do with this. This is a stringprep issue.

I did not say it had anything to do with ACE. I used DNS and IDNA as an
example of the use of Nameprep, a stringprep profile.

> Only nameservers which do understand the new version of stringprep can
> have
> these names.
> 
> > And applications get these new codepoints,
> 
> What do you mean by "get these new codepoints"?

I mean that my mail client, for example, or my Web browser, after an OS
update, can now see these new code points, from an input method, for
example, whilst they were not generated before.

> > but because they
> > do not have the appropriate mapping table, they will pass ACE(Old
> > Nameprep(names in this new thing))
> 
> No, because the codepoint is unassigned in old version of stringsprep, and
> because of that MUST NOT be used.

See, that where there is where I get confused (must be me). The stringprep
says:

"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. Those applications MAY optionally have a
preprocessor that provide stricter checks: treating unassigned code
points in the input as errors, or warning the user about the fact that
the code point is unassigned in the version of a profile that the
software is based on; such a choice is a local matter for the software."

And

" All code points not assigned in the character repertoire named in the
stringprep profile are called "unassigned code points". Stored strings
using the profile MUST NOT contain any unassigned code points. Queries
for matching strings MAY contain unassigned code points. Note that this
is the only part of this document where the requirements for queries
differs from the requirements for stored strings."

I take it from "MUST treat U code points as if they were AO when preparing
the query" that these code points MAY be used.

What is wrong (since you say I am wrong) with my reading of these two
paragraphs?

YA