|
|||||
From time to time the Unicode Consortium seeks wide public review and feedback for certain proposed actions. The purpose of the review is to elicit better information on the practical impact of such proposals on users or implementers as well as broaden the review of technical details. Any feedback on Public Review Issues will be used in the deliberations of the relevant Unicode Consortium technical committee. These open issues are listed here. Each issue has a number, title, summary, and deadline for receipt of public review comments. The link on the title points to a background document if any. When issues are closed, they are moved to the Resolved Issues pages (1-99, 100-199).
Public Review Issues are often targeted at the next version of a particular specification, such as the Unicode Standard. Where the specification is issued by the UTC, the closing date is set to one week before the next quarterly UTC meeting so that any feedback can be reviewed in the meeting. When the specification is due for release only after further meetings, the closing date is typically extended to each subsequent meeting to allow for more feedback.
Organizations and interested individuals are invited to submit public review comments on these issues. Feedback may be submitted via the online contact form; be sure to indicate the number and title of the issue you are providing feedback for, and try to be as explicit as possible in your suggestions. You may also wish to join the Unicode discussion list, where open discussion of all issues related to the Unicode Standard is held.
Material intended for consideration at a Unicode Technical Committee meeting must be submitted at least one week before the start of that meeting. Material intended for consideration by the CLDR Technical Committee should not use the reporting form; instead please see Filing CLDR Bug Reports.
Public Review issues are different from public resolutions of the Unicode Consortium on external issues of particular public importance to the computing industry. Such resolutions are documented as Unicode Consortium Public Positions.
Note: for constraints on proposed changes, see the Unicode Stability Policies.
| 155 | Proposed Update UTS #39: Unicode Security Mechanisms | 2010.01.26 |
For review of the data and suggesting changes:
Draft updated 2010-02-04. |
||
| 154 | Proposed Update UTR #36: Unicode Security Considerations | 2010.01.26 |
|
This revision adds two new sections: 3.6 Secure Encoding Conversion and 3.7 Enabling Lossless Conversion to Unicode |
||
| 153 | Proposal to Deprecate Five Character Properties Defined in UAX #44 | 2010.01.26 |
|
The Unicode Technical Committee is considering the deprecation of the property FC_NFKC_Closure. The purpose for which this property was originally created has been superseded by the NFKC_Casefold property. The UTC is also considering the deprecation of the four encoding properties Expands_On_NFC, Expands_On_NFD, Expands_On_NFKC, and Expands_On_NFKD. Those properties are easily computed, and do not cover the two most common encoding forms, UTF-8 and UTF-16. Information on all five of these properties can be found in the proposed update of UAX #44: Unicode Character Database, by following the links above. Public feedback on this issue is invited. |
||
| 152 | Proposed Update UAX #15: Unicode Normalization Forms | 2010.05.03 |
|
This revision corrects the definitions of classes of characters in the Composition Exclusion Table and rewrites Section 19.3, "Guaranteeing Process Stability" for clarity and correctness. (Draft updated 2010-01-22) |
||
| 151 | Proposed Update UAX #44: Unicode Character Database | 2010.05.03 |
|
This revision indicates the changed status of several properties as Deprecated, adds tables listing Deprecated and Stabilized properties, and extends the discussion of the significance of the Bidi_Mirroring_Glyph property. (Draft updated 2009-12-02) |
||
| 150 | Draft UTS #46: Unicode IDNA Compatibility Processing | 2010.01.26 |
|
This document provides a specification for processing that provides for compatibility between older and newer versions of internationalized domain names (IDN) for lookup in client software. It allows applications such as browsers and emailers to be able to handle both the original version of internationalized domain names (IDNA2003) and the newer version (IDNA2008) compatibly, avoiding possible interoperability and security problems. (Draft updated 20100-02-04) |
||
For closed issues, see the Resolved Issues pages ( 1-99,
100-199).