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" <[EMAIL PROTECTED]> To: "Erik van der Poel" <[EMAIL PROTECTED]>; <[email protected]> Cc: "Kenneth Whistler" <[EMAIL PROTECTED]> Sent: Saturday, March 12, 2005 08:40 Subject: [idn] Re: Unicode categories > > > --On Saturday, 12 March, 2005 01:14 -0800 Erik van der Poel > <[EMAIL PROTECTED]> 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 > > > >
