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

[Yves Arrouye <yves@realnames.com>]

> > >  4) If we finalize IDN before TAGALOG is added, there is 
> no way to support
> > >   seamlessly support of TAGALOG input in older nameprep 
> applications
> > >   but for users to upgrade their s/w.
> >
> >I would like to rephrase this. Your wording is very drastic.
> >
> 
> [...]
> 
> The way I was understanding things is that the server side where the
> new name is registered has to be upgraded to the new version including
> Tagalog (and this may be done by a new table, or whatever). 
> The client,
> and in particular the stringprep/nameprep/ace part of it, won't need
> any upgrades. Of course, there may be a need for installing a Tagalog
> keyboard driver or other components to input Tagalog, but that's
> a separate problem.

I have the same understanding you do re: when unassigned code points may be
generated (by an application that gets code points from a version of Unicode
that was released after the version of Nameprep it uses). Now let's suppose
Unicode encodes something new, for which a new Nameprep is released (because
some additions to the mapping table are needed). At this point, the DNS
servers may contain the ACE(Nameprep(names in this new thing)). And
applications get these new codepoints, but because they do not have the
appropriate mapping table, they will pass ACE(Old Nameprep(names in this new
thing)) which will sometimes match the new labels, and sometimes not. Am I
right in thinking that applications do not need to be updated only if
Nameprep does not change for the new code points (looks like common sense
anyway)?

YA