At 12:46 01/10/24 +0200, Patrik F$BgM(Btstr$B�N(B wrote: >--On 01-10-24 17.25 +0900 Soobok Lee <[EMAIL PROTECTED]> 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.
I'm a bit confused here. This is in the stringprep draft, isn't it? But stringprep is a general framework, so it should be independent of ACE or any character encoding or other form of encoding. Either I'm totally confused (please tell me where I went wrong) or this has to be changed. > > 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. From the old, single-draft nameprep, I was under the strong impression that clients may use codepoints for which they don't know whether they are unassigned or not (they were unassigned when the client software was released, but may have been assigned in the meantime). It could be that what Soobok means is that unassigned (even in the last version) codepoints cannot be entered into registries (because server have more strict rules), and something that isn't registered won't get on a billboard,... and therefore won't get to a client and will therefore not be entered. > > 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. 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. Regards, Martin.
