202	Extensions to NameAliases.txt for Unicode 6.1.0	2011.10.24
Status:	Open
Originator:	UTC
Informal Discussion:	Unicode Mail List (Join)
Formal Feedback:	Reporting Form

Description of Issue:

The UTC is planning to extend the format and content of the Unicode Character Database file NameAliases.txt for Unicode 6.1.0. In addition to the current scope of NameAliases.txt, which covers the definition of formal name aliases for characters whose names have serious mistakes in them, the intent is to add various standard and de facto aliases for control characters, which have no names defined for them in the Unicode Standard, as well as various character abbreviations which are in widespread use.

Because NameAliases.txt is used as part of the input which enforces name uniqueness for the Unicode character namespace, adding aliases for control codes and commonly used abbreviations for characters would prevent accidental name collisions in the future for character "name" matches in implementations such as regular expressions.

The current scope of NameAliases.txt in Unicode 6.0 can be seen in:
http://www.unicode.org/Public/6.0.0/ucd/NameAliases.txt

The proposed scope of extensions to NameAliases.txt can be seen in:
http://www.unicode.org/review/pri202/NameAliasesProv-6.1.0.txt

The UTC would like public feedback on this planned extension to NameAliases.txt. In particular, feedback on the following issues would be welcome:

• Are there other character abbreviations in widespread use which should be added to this listing? (Note that the intention is for the list to contain useful abbreviations relevant to implementation name matching, rather than serve as an encyclopedia of every obscure character abbreviation ever used.)
• Should name aliases be provided for U+0080, U+0081, and U+0099, despite the fact that those control functions are not defined in ISO 6429 and thus have no names in that standard?
• What would be the preferred order of listing for the data file? Should it be grouped by type, as currently drafted? Or would a purely code point order of entries be preferable, and why?

Note that the proposed update to NameAliases.txt contains multiple entries for some code points. This might prove to be a challenge to some existing parsers and implementations, which may expect UCD data files to always contain no more than a single entry per code point.

For information about how to discuss this issue and how to supply formal feedback, please see the feedback and discussion instructions. The accumulated feedback received so far on this issue is shown below, or you can look at a full page view.