[Python-checkins] r42954 - in python/trunk: Doc/lib/libunicodedata.tex Include/ucnhash.h Lib/encodings/idna.py Lib/stringprep.py Modules/unicodedata.c

Fri Mar 17 19:37:49 CET 2006

M.-A. Lemburg wrote:
>>This I don't understand: what new features could these
>>be? All features of the Unicode database range back to
>>the earliest versions, including data which we currently
>>don't expose.
>>> I meant new features as in: new fields in the database or
> new values for categories.

I very much doubt that the Unicode consortium adds new
fields in the database or new values for categories. If
they ever do, we can worry about it then.
If you want to worry now: Adding a new category is completely backwards
compatible. The category value just won't appear in the old version of
the database, which doesn't cause any problems whatsoever.
For new fields in the database, we should assume that
in older versions, the assigned characters have the same
values of the properties as in the most recent version,
unless the Unicode consortium specifies otherwise.
> If we expose new features that are only available in 4.1
> and not in 3.2, then you have a compatibility problem
> since the 3.2 version won't supply the needed data.

So you use the 4.1 data instead, and apply them to
all characters that were assigned in 3.2.
However, there *are* no features that are available in
4.1 and not in 3.2.
> The reason stringprep is tied to Unicode 3.2 stems from the
> need to provide explicit tables for the string pre-processing.
>> I don't see why the IETF should not update the RFC with a new
> set of tables against the Unicode 4.1 (or a later) database
> version.

That shows that you haven't been following the IDNA discussions.
Some of the IDNA authors are very concerned about changes to
the normalization, and will strongly oppose proposals to move
to a new version of the database.
Regards,
Martin