Public Review Issues

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 page.

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.

Open Issues for Public Review

69	Proposed Update UAX #24, Script Names	2005.08.09
This is an initial update for Unicode 5.0.0 which proposes the addition of an appendix of iconic script indicators, derivative from the usage of last resort font missing glyph forms. Additional updates will be needed to reflect the planned additions of scripts to 5.0.0. Those will be in a subsequent draft.
70	Proposed Draft UTS #37, Registration of Ideographic Variation Sequences	2005.08.09
The UTC approved the development of a Unicode Technical Standard establishing a registry of variation sequences for Ideographic characters. The UTC recognizes that the needs of various user communities for such variation sequences cannot be accommodated by a single, unified collection of sequences. The purpose of the registry is to ensure that multiple collections can coexist without compromising the interchangeability of texts using them. This proposed draft Unicode Technical Standard describes the operation of the registry.
71	Questions on Malayalam Digits	2005.08.09
It has come to the attention of the UTC that the glyph printed in the standard for U+0D66 MALAYALAM DIGIT ZERO is incorrect, and information is being sought. Three numeric signs have been identified for future encoding, and further information is being sought. Details on these questions are in the accompanying document.
72	Stability of the Bidi Mirrored Property	2005.08.09
In a bidirectional context, the images of many characters need to be oriented depending on the writing direction of the text in which they occur. The Bidi Mirrored property defines this behavior, but the model it implements has a few inconsistencies. Ideally, these would be corrected, but doing so will destabilize all documents containing the affected characters. A stability policy would freeze future changes, but should one last round of improvements be carried out? Your input on the range of possible actions is solicited, whether you are a language expert, user. or implementer.
73	Representative Glyphs for Arabic Characters U+06DF, U+06E0, and U+06E1	2005.08.09
The representative glyphs for several Arabic characters used to annotate the Koran have been reported as being possibly incorrect. The UTC has tentatively decided to revise them as explained in the accompanying document. The UTC invites anyone knowledgeable in their use to provide additional information or recommendations.
74	Change to Default Localization for NaN in CLDR	2005.10.31
There has been a request to change the default localization for a NaN from the character U+FFFD (�) REPLACEMENT CHARACTER to another representation. The NaN floating-point value means "Not a Number", and represents an undefined result of a mathematical operation such as (0 ÷ 0) or (∞ - ∞). Unfortunately, there is no generally accepted mathematical symbol for NaN (e.g., from the American Mathematical Society). The character currently used as the default (root) localization follows Java usage, where it was originally chosen because it is a symbol (thus not an English-specific abbreviation), and has a sense that roughly corresponds to NaN. The CLDR technical committee is somewhat reluctant to make a change, given that this has been in use in Java for many years. If there is a change, possibilities are to revert to the English abbreviation "NaN" or to chose another character such as U+26A0 (⚠) WARNING SIGN. The committee would appreciate comments on this issue.

Note: for constraints on proposed changes, see the Unicode Stability Policies.