[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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.