[idn] Re: :Re: Last Call: Preparation of Internationalized Strings

[simon+idn@josefsson.org]

[Resending with different From: address.]

Patrik Fältström <paf@cisco.com> writes:

> --On 2002-05-31 00.26 +0900 Soobok Lee <lsb@postel.co.kr> 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.