[Resending with different From: address.] Patrik F�ltstr�m <[EMAIL PROTECTED]> writes:
> --On 2002-05-31 00.26 +0900 Soobok Lee <[EMAIL PROTECTED]> wrote: > >> This issues were raised at the time of IDN WG last call, 3 months ago. > > And my answer was exactly the same then as now. We can not do better. If > Unicode is updated, you will either get inconsistency with the parties > using the new version of Unicode (if IDN is not upgraded) or inconsistency > with old registered names (if IDN is upgraded). > > The point is that the current scheme (a) trust Unicode when they say that > changes will be backward compatble and (b) IF they do an incompatible > change, we can at that point in time make the desicion -- we don't have to > decide now what path we take. Yes. I think it could be useful to have this discussion in the specifications, so it is stored in the collective memory. I am not sure everyone will remember or understand all subtle problems that will follow from changes in normalization mapping tables in a few years (I know I won't). Is the following reasonable? ,---- | If or when this specification is updated to use a more recent Unicode | normalization table, the new normalization table must be compared with | the old to spot backwards incompatible changes. If there are such | changes, they must be handled somehow, or there will be security as | well as operational implications. Methods to handle the conflicts | could include keeping the old normalization, or taking care of the | conflicting characters by operational means, or some other method. | | Implementations must never use more recent normalization tables than | the one referenced from this document, even though more recent | tables may be provided by operating systems. If an application is | unsure of which version of the normalization tables are in the | operating system, the application should include the normalization | tables itself. Using normalization tables other than the one | referenced from this specification may have security and operational | implications. `---- The transcoding problem is still open, it seems.
