tables document [Re: IDNA comments]

[Mark Davis]

On Sat, Jul 12, 2008 at 11:38 AM, Paul Hoffman <phoffman at imc.org> wrote:

>
>
> The "can be" works for me. Using "will be" makes it sound more like
> it is acceptable for TUC to make unacceptable changes.


"unacceptable" is the wrong term here.

Paul, perhaps you missed an earlier discussion. The purpose of the
BackwardCompatible category in the tables document is because the Unicode
consortium must sometimes make changes to properties. The character
properties are general, and for many or even most people it is more
important for them to be as correct as possible than that they be stable. It
is not always possible, especially with minority characters, to get the
properties exactly right initially.

A grandfathering clause allows for both stability for those who need it, and
correctness for others.

The consortium uses exactly the same mechanism in stabilizing its
recommended definition of program identifiers (eg like those used in Java
and other languages that allow for non-ASCII). Over the course of many
Unicode versions, a handful of characters it total have been affected. For
details, see http://www.unicode.org/reports/tr31/#Backward_Compatibility

While not by any means frequent or many, it is not unlikely that some
characters will need to be added to BackwardCompatible in some future
Unicode Version. So that event needs to be planned for, not ignored.

Whether or not any such changes are needed will be known in the beta phase
of each Unicode release, which is months ahead of the release date. So we
just need to make sure that whatever mechanism is used to update the
BackwardCompatible list can be done in months (not years). My own preference
would for this list to be hosted on IANA and subject to Expert Reviewers
Committee, with requirements set by the RFC that all and only those
characters necessary for backwards compatibility be added for each Unicode
release. But if the RFC process could accommodate a few month turn-around
(guaranteed), that would work also.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20080714/7cf435f4/attachment-0001.htm