Re: [idn] Re: Unicode categories

["Mark Davis" <[e-mail]>]

We do not make any absolute guarantees of stability for the general category
and many other properties, because a miscategorized character would cause
incorrect behavior in computers for the languages that use it. And as new,
increasingly obscure characters are added to the standard, it may take some
time to get really accurate information.

However, I do want to call attention to certain properties of the Unicode
Standard that may be relevant -- characterizing identifer and pattern syntax
characters -- which do have strict requirements on stability. There is a
draft of the newest specification on
http://www.unicode.org/reports/tr31/tr31-5.html. Programming identifiers
have a bit different requirements from IDN, but they are related enough that
the information may be useful.

The data for Pattern_Syntax and Pattern_White_Space is in
http://www.unicode.org/Public/4.1.0/ucd/PropList-4.1.0d12.txt. For XID_Start
and XID_Continue, it is in
http://www.unicode.org/Public/4.1.0/ucd/DerivedCoreProperties-4.1.0d12.txt

All of these will be finalized and released as part of Unicode 4.1.0.

‎Mark

----- Original Message ----- 
From: "John C Klensin" <[e-mail]>
To: "Erik van der Poel" <[e-mail]>; <[e-mail]>
Cc: "Kenneth Whistler" <[e-mail]>
Sent: Saturday, March 12, 2005 08:40
Subject: [idn] Re: Unicode categories


>
>
> --On Saturday, 12 March, 2005 01:14 -0800 Erik van der Poel
> <[e-mail]> wrote:
>
> > All,
> >
> > Please do not draw any conclusions from the raw Unicode
> > category stability data that I sent earlier. Ken Whistler, a
> > Technical Director at the Unicode Consortium, was so kind to
> > provide further information to put the data into their proper
> > perspective. See below.
> >...
>
> Erik, Ken, and others,
>
> The difficulty here is not, IMO, the specific numbers or
> percentages.  It is an important difference in perspective.
> >From the standpoint of UTC, these changes are few, minor, and
> corrections to obscure errors.  That is a perfectly sensible
> position.
>
> >From the standpoint of the IETF, or anyone else worried about a
> piece of protocol that must support many applications, the
> problem is a little different.  Some of the recent developments
> in automatic updating tools notwithstanding, IDNA (and its
> supporting tables) are designed to be embedded in and used from
> clients.  Many of those clients, and the associated operating
> systems, have been historically updated only when the machine in
> which they run is replaced.   That argues for an extremely
> conservative view of protocol design and compatibility, with
> very high thresholds for justifying incompatible changes of any
> sort.  From that viewpoint, the differences between 0.01%
> changes and 5% changes is like measures of being partially
> pregnant: perhaps helpful in some types of risk assessment, but
> less so in making the next design decision.
>
>       john
>
>
>
>