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

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

--On 01-10-24 17.25 +0900 Soobok Lee <lsb@postel.co.kr> wrote:

> I finished careful reading your clear answers titled with
>  "Re: [idn] questions: unassigned code points in nameprep".
> 
> What I understand is:
> 
>   "saved string" :  generated ACE labels by applications 
>                       with known version of nameprep
> 
>   "query"        :  received ACE label from other applications
>                       the ACE label may have been generated by 
>                          unknown version of nameprep
> 
>  from this understanding,

Yes. Sounds like a good definition.

>  1) I will prefer to use "generated ACE label" and "received ACE label".
>  They seem to be  more intuitive.

Ok.

>  2) Current stringprep prohibits old nameprep to encode into ACE labels 
>   any unassigned code points. (MUST NOT).

Yes.

>  3) Therefore, Unassigned code points cannot even begin its trip to other
> applications from the old nameprep applications. 

Correct.

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

When the stringprep/nameprep documents is done, they will reference one
specific version of the Unicode standard. It looks like version 3.1 at the
moment. Applications made for this version will not be able to handle
codepoints which are unassigned in this version of Unicode.

Now, we all know that new versions of the Unicode Standard will come, with
more codepoints assigned.

If I were an application developer I would not hardcode the tables needed
in the application itself. This so when a new version of the
stringprep/nameprep document comes out after a new version of Unicode
tables is done, the user should be able to upgrade his software in a very
easy way. When the software is upgraded, he can use the newly assigned
codepoints.

And, yes, I have already dealt with this problem once as a programmer, and
saw that this was the easiest way of handling versioning in the software.

    paf