INTERNATIONAL ORGANIZATION FOR STANDARDIZATION
ORGANISATION INTERNATIONALE DE NORMALISATION
ISO/IEC JTC 1/SC 2/WG 2

Universal Multiple-Octet Coded Character Set
(UCS)
ISO/IEC JTC 1/SC 2/WG 2 N2002
1999-03-11
Title:	Principles and Procedures for Allocation of New Characters and Scripts and handling of Defect Reports on Character Names (Replaces N 1502)
Source:	Ad hoc group on Principles and Procedures (Edited by:  V.S. Umamaheswaran)
References:	See refernces section in the document
Action:	To be considered by SC 2/WG 2 and all potential submitters of proposals for new characters the repertoire of ISO/IEC 10646, and for new collection identifiers
Distribution:	ISO/IEC JTC 1/SC 2/WG 2, ISO/IEC JTC 1/SC 2 and Liaison Organizations

(Note:  This document does not include replacement for the sections on Roadmaps – Annex D (document N1876).  It will be completed based on discussion on the roadmap documents prepared by Mr. Michael Everson, at meeting M36. It incorporates all the other updates that have been approved by WG2 up to meeting M35 – Uma.)
1.	Introduction
This document is a standing document of JTC 1/SC2 WG2.  It consists of a set of Principles and Procedures on a number of items relevant to the preparation, submission and handling of proposals for additions of characters to the repertoire of the standard (ISO/IEC 10646 and the Unicode standard).  The document also contains procedures and guidelines for adding new collection identifiers to the standard.  Submitters should check the standard documents (including all the amendments and corrigenda) first before preparing new proposals.  Submitters are also encouraged to contact the convener of SC 2/WG 2 (and the chair of the Unicode Technical Committee) to check and compare any similar proposals that may already have been considered earlier.
2.	Allocation of New Characters and Scripts
Annex D of this document details a roadmap for allocation of characters in the Basic Multi-Lingual plane (BMP) and the supplementary planes (General purpose - GPSP, Ideographic – ISP, and Plane 14).  The following sections describe the principles and procedures to be used for assessing whether a proposed script or character(s) could be a candidate for inclusion in the standard, and whether it should be encoded  in the BMP or in the supplementary planes.
I.	Goals for Encoding New Characters into the BMP
A.	The Basic Multilingual Plane should contain all contemporary characters in common use:

Generally, the Basic Multilingual Plane (BMP) should be devoted to high-utility characters that are widely implemented in information technology and communication systems.  These include, for example, characters from hard copy publishing systems that are awaiting computerization, and characters recognizable and useful to a large community of customers.  The "utility" of a character in a computer or communications standard can be measured (at least in theory) by such factors as: number of publications (for example, newspapers or books) using the character, the size of the community who can recognize the character, etc.  Characters of more limited use should be considered for encoding in supplementary planes, for example, obscure archaic characters.

B.	The characters encoded into the Basic Multilingual Plane will not cover all characters included in future standards:

It is not necessary, though it may often be desirable, that all characters encoded in future international, national, and industry information technology and communication standards be included in the BMP.  The first edition used characters from pre-existing standards as a means of evaluating the established utility as well as ensuring compatibility with existing practice.  Characters encoded in future standards may or may not have proven utility, and may or may not establish themselves in common use.
II	Character Categories
SC 2/WG 2 will use the following categories to aid in assessing the encoding of the proposed characters.
A	Contemporary
There exists a contemporary community of native users who produce new printed matter with the proposed characters in newspapers, magazines, books, signs, etc.  Examples include Myanmar (Burmese), Thaana (Maldivian), Syriac, Yi, Xishuang Banna Dai.  (Note:  Since the writing of this initial set of principles and procedures several scripts have been proposed following these guidelines and have been published as amendments to the standard).
B.1	Specialized (Small Collections of Characters)
The characters are part of a relatively small set.  There exists a limited community of users (for example, ecclestiastical) who produce new printed material with these proposed characters.  Generally, these characters have few native users, or are not in day-to-day use for ordinary communication.  Examples include Javanese, Pahlavi...
B.2	Specialized (Large Collections of Characters)
The characters are part of a relatively large set.  There exists a limited community of users (for example, ecclestiastical) who produce new printed material with these proposed characters.  Generally, these characters have few native users, or are not in day-to-day use for ordinary communication.  Examples include personal name ideographs, Chu Nom, Archaic Han.
C	Major Extinct (Small Collections of Characters)
The characters are part of a relatively small set.  There exists a relatively large body of literature using these characters, and a relatively large scholarly community studying that literature.  Examples include Etruscan, Linear B.
D	Attested Extinct (Small Collections of Characters)
The characters are part of a relatively small set.  There exists a relatively limited literature using these characters and a relatively small scholarly community studying that literature.  Examples include Samaritan, Meroitic.
E	Minor Extinct
The characters are part of a relatively small set.  The utility of publicly encoding these characters is open to question.  Examples are Khotanese, Lahnda.
F	Archaic Hieroglyphic or Ideographic
These characters are part of a large set (for example, 160 or more characters) of hieroglyphic or ideographic characters.  In general, for a large character set, it is difficult to obtain information or agreement on the precise membership of the set.  Examples include Lolo, Moso,  Akkadian, Egyptian Hieroglyphics, Hittite (Luvian), Kitan, Mayan Hieroglyphics, and Jurchin.
G	Obscure or Questionable Usage Symbols
The characters are part of a small or large collection that is not yet deciphered, or not completely understood, or not well-attested by substantial literature or the scholarly community.  Or they are  symbols that are not normally used in in-line text, that are merely drawings, that are used only in two-dimensional diagrams, or that may be composed (such as, a slash through a symbol to indicate forbidden).  Examples include Phaistos, Indus, Rongo-rongo,  logos, pictures of cows, circuit components, and weather chart symbols.
III	Procedure for Encoding New Characters and Scripts
The following defines a procedure with criteria for deciding how to encode new characters in ISO/IEC 10646.  This procedure shall be used for new scripts only after thorough research into the repertoire and ordering of the characters within the script.

See submitter's responsibilities and the attached Proposal Summary Form in Annex A.
	SC 2/WG 2 Evaluation Procedure
In assessing the suitability of a proposed character for encoding, SC 2/WG 2 shall evaluate the credibility of the submitter and then use the following procedure:

1.	Do not encode.
a)	If the proposed character is a (shape or other) variation of a character already encoded in the standard and therefore may be unified, or
b)	If the proposed character is a presentation form (glyph), variant, or ligature, or
c)	If the proposed character may be better represented as a sequence of standardized encoded characters, or 
e)	If the proposed character is a non-Han character, and leads to disunification with an existing character in the standard, and does not pass the formal criteria for disunification that is detailed in Annex F.
d)	If the proposed character is a precomposed character and does not pass the formal criteria for coding precomposed characters that is detailed in Annex G.

2.	Suggest use of the Private Use Area
a)	If the proposed character has an extremely small or closed community of customers, or
b)	If the proposed characters are part of a script that is very complex to implement and the script has not yet been encoded in the standard (the Private Use Area – PUA,  may be used for test and evaluation).
(Note:  Use of PUA is not standardized; its use is by agreement between sending and receiving devices, and its use should not be included in any proposal made to the standardization body for consideration.)

3.	Encode on a supplementary plane
a)	If the proposed character is used infrequently, or
b)	If it is part of a set of characters for which insufficient space is available in the Basic Multilingual Plane.

4.	Encode on the Basic Multilingual Plane
a)	If the proposed character does not fit into one of the previous criteria (1, 2, or 3), and
b)	If the proposed character is part of a well-defined character collection not already encoded in the standard, or
c)	If the proposed character is part of a small number of characters to be added to a script already encoded in the Basic Multilingual Plane (for example, the characters can be encoded at unallocated code positions within the block or blocks allocated for that script).
3.	Handling Defect Reports on Character Names
In principle, the Character Names in the standard are not to be changed.  However, there may be situations where annotations to names of characters may be warranted.  Requests for such annotations to Character Names may be made by submitting a defect report.  The principles of dealing with such defect reports by SC 2/WG2 are described in Annex B of this document.
4.	Collection Identification
Technical Corrigendum No. 2 to ISO/IEC 10646-1 defines collections (clause 4.11 collection, and clause 4.17 fixed collection).  A collection is a set of coded characters which is numbered and named and which consists of those coded characters whose code positions lie within one or more identified ranges.  If any of the identified ranges include code positions to which no character is allocated, the repertoire of the collection will change if an additional character is assigned in the standard to any of these positions in the future.  However, it is intended that the collection number and name will remain unchanged (even if the repertoire increases).  A fixed collection is a collection in which every code position within the identified range(s) has a character allocated to it, and which is intended to remain unchanged  -- the repertoire remains fixed.  A number of collections -- some marked as fixed collections with an '*' in the positions column -- are defined in Annex A of ISO/IEC 10646-1.

WG2 has accepted the following recommendations from the ad hoc on collection identifiers at WG 2 meeting 34 (see N1726):

A.	Annex A in Part 1 will be the home for all collection identifiers and their names for collections that are entirely within Part 1 (BMP) or span both Part 1 and Part 2 (BMP and supplementary planes) of ISO/IEC 10646.
B.	Annex  A in Part 1 will mark a block of numbers in it as reserved for identifying collections that are entirely within Part 2 (supplementary planes) of ISO/IEC 10646.
C.	An Annex in Part 2 should be created, similar to Annex A in Part 1, containing the list of collection identifiers, collection names for collections that are entirely within Part 2.  Also, some text should be added in this Annex to refer the readers to Annex A in Part 1 for the other collection identifiers in the standard.

A collection identifier and collection name are usually assigned whenever a new script is added to the standard.  A collection could be referenced in an application by its identifier or as a collection of collections by enumerating the collection identifiers or collection names.  However, there may be situations where an application needs a single identifier for a specific collection, and 
•	the required collection is not readily identified in the standard,  or
•	a reference to the required collection by an enumeration of standardized collections is not acceptable.
Annex E of this document provides a format and guidelines for requesting new collection identifiers in the standard.
5.	Work Flow and Stages of Progression
To give the proposers of new scripts an understanding of how WG2 deals with a proposal from its initiation to completion, Annex C contains a description of the work flow and the various stages of progression of submissions to WG 2.
6.	Roadmap
A summary of the scripts and characters that have been included in the standard, and known scripts which are either work in progress in WG 2 (for which some initial discussion documents have been made available to WG 2), or scripts which are known is shown in Annex D.  This Annex will be updated to reflect the set of scripts that have reached at least the stage of PDAM balloting (equivalent of accepted CD for balloting) and will track that script to its publication in terms of the number of code positions allocated to that script / proposed characters.  An indication of which scripts are under consideration is also included.
(Note:  This Annex D is under construction in this document and will be completed after the review of the associated Roadmap documents proposed for discussion at meeting 36).

Annex A	INFORMATION ACCOMPANYING SUBMISSIONS

The process of deciding which characters should be included in the repertoire of ISO/IEC 10646 by SC 2/WG 2 depends on the availability of accurate and most comprehensive information about any proposed additions.  SC 2/WG 2, at its San Francisco meeting 26, designed a form (template) that will assist the submitters in gathering and providing the relevant information, and will assist SC 2/WG 2 in making more informed decisions.  This form is included in the following pages of this annex.

Each new submission must be accompanied by a duly completed proposal summary form to assist SC 2/WG 2 to better evaluate the proposal, and progress the propsoal towards a speedier acceptance and inclusion in the standard.  Submitters are also requested to ensure that a proposed character does not already exist in ISO/IEC 10646.

If a submission has already been made prior to the existence of the proposal summary form, the submitters are requested to re-evaluate the submission for completeness using the form as a template, and either provide reference(s) to existing information or provide additional information.

The status of each submission is tracked in the WG2 standing document "WG 2 – Summary Status of Poroposals".
A.1	Submitter's Responsibilities
The national body or liaison organization (or any other organization or an individual) proposing  new character(s) or a new script shall provide:

1.	Proposed category for the script or character(s), character name(s), and description of usage.
2.	Justification for the category and name(s).
3.	A representative glyph(s) image on paper:
if this glyph image is similar to a glyph image of a previously encoded ISO/IEC 10646 character, then additional justification for encoding the new character shall be provided.
	Note:  Any proposal which suggests that one or more of these variant forms is actually a "distinct" character, requiring separate encoding, should provide detailed, printed evidence that there is actual, contrastive use of the variant form(s). It is insufficient for a  proposal to claim a requirement to encode "as characters" in the Standard, glyphic forms which happen to occur in another character encoding that did not follow the Character-Glyph Model that guides the choice of appropriate characters for encoding in ISO/IEC 10646.
4.	Mappings to accepted sources, for example, other standards, dictionaries, accessible published materials
5.	Computerized/camera ready font:
prior to the preparation of the final text of the next version of the standard a suitable computerized font (camera ready font) will be needed.  Camera ready copy is mandatory for final text of any pDAMs before the next revision.  Ordered preference of the fonts: True Type, PostScript or 96x96 bit-mapped format.  The minimum design resolution for the font is 96 by 96 dots matrix, for presentation at or near 22 points in print size.
6.	List of all the parties consulted.
7.	Equivalent glyph images:
if the submission intends using composite sequences of proposed or existing combining and non-combining characters, a list consisting of each composite sequence and its corresponding glyph image shall be provided to better understand the intended use.

ISO/IEC JTC 1/SC 2/WG 2
PROPOSAL SUMMARY FORM TO ACCOMPANY SUBMISSIONS
FOR ADDITIONS TO THE REPERTOIRE OF ISO/IEC 10646
Please fill all the sections A, B and C below.
A.  Administrative
1. Title: 											

2. Requester's name:										

3. Requester type (Member body/Liaison/Individual contribution):	 				

4. Submission date: 										

5. Requester's reference (if applicable):								

6. (Choose one of the following:)									
		This is a complete proposal:							; or,			More information will be provided later:							

B.  Technical - General
1. (Choose one of the following:)									
a.	This proposal is for a new script (set of characters):						
	Proposed name of script:									
b.	The proposal is for addition of character(s) to an existing block:				
	Name of the existing block: 								
2. Number of characters in proposal:								

3. Proposed category (see section II, Character Categories):					

4. Proposed Level of Implementation (see clause 15, ISO/IEC 10646-1):				
	Is a rationale provided for the choice?							
		If Yes, reference: 								

5. Is a repertoire including character names provided?: 						
	a.  If YES, are the names in accordance with the 'character naming guidelines'
	     in Annex K of ISO/IEC 10646-1?							
	b.  Are the character shapes attached in a reviewable form?					
6. Who will provide the appropriate computerized font (ordered preference: True Type,
	PostScript or 96x96 bit-mapped format) for publishing the standard?		
												
	If available now, identify source(s) for the font (include address, e-mail,
	ftp-site, etc.) and indicate the tools used:						

												
7. References:											
	a.  Are references (to other character sets, dictionaries, descriptive texts etc.)
		provided?		 							
	b.  Are published examples (such as samples from newspapers, magazines, or
		other sources) of use of proposed characters attached?				

8. Special encoding issues:
	Does the proposal address other aspects of character data processing  (if applicable) such as input, 	presentation, sorting, searching, indexing, transliteration etc. (if yes please enclose information): 	______________________________________________________________________________

C.  Technical - Justification

1. Has this proposal for addition of character(s) been submitted before? 				
	If YES explain										

2. Has contact been made to members of the user community (for example: National
	Body, user groups of the script or characters, other experts, etc.)?				
		If YES, with whom?								
		If YES, available relevant documents? 						
3. Information on the user community for the proposed characters (for example: size,
	demographics, information technology use, or publishing use) is included?			
	Reference: 										

4. The context of use for the proposed characters (type of use; common or rare)			
	Reference:										

5. Are the proposed characters in current use by the user community?				
	If YES, where?  Reference: 								

6. After giving due considerations to the principles in "Principles and Procedures" document (a WG2 standing
	document) must the proposed characters be entirely in the BMP? 			
		If YES, is a rationale provided?							
			If YES, reference: 							
7. Should the proposed characters be kept together in a contiguous range (rather than
	being scattered)?										

8. Can any of the proposed characters be considered a presentation form of an existing
 	character or character sequence? 								
		If YES, is a rationale for its inclusion provided?					
			If YES, reference: 							

9. Can any of the proposed character(s) be considered to be similar (in appearance
	or function) to an existing character?							
		If YES, is a rationale for its inclusion provided?					
			If YES, reference: 							

10. Does the proposal include use of combining characters and/or use of composite
	 sequences (see clauses 4.11 and 4.13 in ISO/IEC 10646-1)?					
		If YES, is a rationale for such use provided?					
			If YES, reference: 							
		Is a list of composite sequences and their corresponding glyph images
		(graphic symbols) provided?							
			If YES, reference: 							
11. Does the proposal contain characters with any special properties such as control function or similar
	semantics?										
		If YES, describe in detail (include attachment if necessary)				

ISO/IEC JTC 1/SC 2/WG 2
PROPOSAL SUMMARY FORM TO ACCOMPANY SUBMISSIONS
FOR ADDITIONS TO THE REPERTOIRE OF ISO/IEC 10646
An Example: Fictitious summary form filled in for illustration of the use of the form.
Please fill all the sections A, B and C below.
A.  Administrative
1. Title: 		Braille									

2. Requester's name:	Kohji Shibano, Japan							

3. Requester type (Member body/Liaison/Individual contribution):	 Individual Contribution		

4. Submission date: 								1994-10-10	
5. Requester's reference (if applicable):						J2-94-xy		
6. (Choose one of the following:)									
		This is a complete proposal:							; or,			More information will be provided later:					Yes		
B.  Technical - General
1. (Choose one of the following:)									
a.	This proposal is for a new script (set of characters):					Yes	
	Proposed name of script:								Braille	

b.	The proposal is for addition of character(s) to an existing block:			No	
	Name of the existing block: 								
2. Number of characters in proposal:							448	

3. Proposed category (see section II, Character Categories):					A	

4. Proposed Level of Implementation (see clause 15, ISO/IEC 10646-1):			1	
	Is a rationale provided for the choice?						No	
		If Yes, reference: 								

5. Is a repertoire including character names provided?: 					Yes	
	a.  If YES, are the names in accordance with the 'character naming guidelines'
	     in Annex K of ISO/IEC 10646-1?					No (will provide)	
	b.  Are the character shapes attached in a reviewable form?				Yes	
6. Who will provide the appropriate computerized font (ordered preference: TrueType,
	PostScript or 96x96 bit-mapped format) for publishing the standard?		
										Japan		
	If available now, identify source(s) for the font (include address, e-mail,
	ftp-site, etc.) and indicate the tools used:						
							IBM Japan (ftp://ifi.jp/pub/font)		
7. References:											
	a.  Are references (to other character sets, dictionaries, descriptive texts etc.)
		provided?		 					ISO TC 173	
	b.  Are published examples (such as samples from newspapers, magazines, or
		other sources) of use of proposed characters attached?		No (will provide)	
8. Special encoding issues:
	Does the proposal address other aspects of character data processing  (if applicable) such as input, 	presentation, sorting, searching, indexing, transliteration etc. (if yes please enclose information): 	______________________________________________________________________________

C.  Technical - Justification

1. Has this proposal for addition of character(s) been submitted before?			 No	
	If YES explain										

2. Has contact been made to members of the user community (for example: National
	Body, user groups of the script or characters, other experts, etc.)?			No	
		If YES, with whom?								
		If YES, available relevant documents? 						
3. Information on the user community for the proposed characters (for example: size,
	demographics, information technology use, or publishing use) is included?			
	Reference:	 		People with impaired vision (info will be provided)			

4. The context of use for the proposed characters (type of use; common or rare)	Common		
	Reference:		on-line database services for Braille-translated text (e.g. www: braille.dknet.dk)	

5. Are the proposed characters in current use by the user community?			Yes	
	If YES, where?  Reference: 						Worldwide	

6. After giving due considerations to the principles in "Principles and Procedures" document (a WG2 standing
	document) must the proposed characters be entirely in the BMP? 		Yes	
		If YES, is a rationale provided?							
			If YES, reference: 							

7. Should the proposed characters be kept together in a contiguous range (rather than
	being scattered)?									Yes	

8. Can any of the proposed characters be considered a presentation form of an existing
 	character or character sequence? 							No	
		If YES, is a rationale for its inclusion provided?					
			If YES, reference: 							
9. Can any of the proposed character(s) be considered to be similar (in appearance
	or function) to an existing character?						No	
		If YES, is a rationale for its inclusion provided?					
			If YES, reference: 							

10. Does the proposal include use of combining characters and/or use of composite
	 sequences (see clauses 4.11 and 4.13 in ISO/IEC 10646-1)?				No	
		If YES, is a rationale for such use provided?						
			If YES, reference: 							
		Is a list of composite sequences and their corresponding glyph images
		(graphic symbols) provided?							
			If YES, reference: 							
11. Does the proposal contain characters with any special properties such as control function or similar
	semantics?									No	
		If YES, describe in detail (include attachment if necessary)				

ISO/IEC JTC 1/SC 2/WG 2
PROPOSAL SUMMARY FORM TO ACCOMPANY SUBMISSIONS
FOR ADDITIONS TO THE REPERTOIRE OF ISO/IEC 10646
An Example: Fictitious summary form filled in for illustration of the use of the form.
Please fill all the sections A, B and C below.
A.  Administrative
1. Title: 			Addition of two Latin characters					

2. Requester's name:		Danish Standards Association					

3. Requester type (Member body/Liaison/Individual contribution):	 		NB		

4. Submission date: 								1995-03-10	

5. Requester's reference (if applicable):								

6. (Choose one of the following:)									
		This is a complete proposal:						Yes	; or,			More information will be provided later:							
B.  Technical - General
1. (Choose one of the following:)									
a.	This proposal is for a new script (set of characters):					No	
	Proposed name of script:									
b.	The proposal is for addition of character(s) to an existing block:			Yes	
	Name of the existing block: 				Table 4 - Row 01: Latin Extended-B

2. Number of characters in proposal:							2	
3. Proposed category (see section II, Character Categories):					A	

4. Proposed Level of Implementation (see clause 15, ISO/IEC 10646-1):			1	
	Is a rationale provided for the choice?							
		If Yes, reference: 								

5. Is a repertoire including character names provided?: 					Yes	
	a.  If YES, are the names in accordance with the 'character naming guidelines'
	     in Annex K of ISO/IEC 10646-1?						Yes	
	b.  Are the character shapes attached in a reviewable form?				Yes	
6. Who will provide the appropriate computerized font (ordered preference: True Type,
	PostScript or 96x96 bit-mapped format) for publishing the standard?		
					Michael Everson, Everson Gunn Teoranta			
	If available now, identify source(s) for the font (include address, e-mail,
	ftp-site, etc.) and indicate the tools used:						
					Michael Everson, Everson Gunn Teoranta			
7. References:											
	a.  Are references (to other character sets, dictionaries, descriptive texts etc.)
		provided?		 						Yes	
	b.  Are published examples (such as samples from newspapers, magazines, or
		other sources) of use of proposed characters attached?			Yes	
   8. Special encoding issues:
	Does the proposal address other aspects of character data processing  (if applicable) such as input, 	presentation, sorting, searching, indexing, transliteration etc. (if yes please enclose information):
	Specifications enclosed								

C.  Technical - Justification
1. Has this proposal for addition of character(s) been submitted before?			 No	
	If YES explain										

2. Has contact been made to members of the user community (for example: National
	Body, user groups of the script or characters, other experts, etc.)?			Yes	
		If YES, with whom?			Irish National Body, Oxford University 	
		If YES, available relevant documents? 				Enclosed		
3. Information on the user community for the proposed characters (for example: size,
	demographics, information technology use, or publishing use) is included?		Yes	
	Reference: 		The Community of Gothic and Medieval English Literature	

4. The context of use for the proposed characters (type of use; common or rare)		Rare	
	Reference:										

5. Are the proposed characters in current use by the user community?			Yes	
	If YES, where?  Reference: 		Scholar Communities				

6. After giving due considerations to the principles in "Principles and Procedures" document (a WG2 standing
	document) must the proposed characters be entirely in the BMP? 		Yes	
		If YES, is a rationale provided?						Yes	
			If YES, reference: 		Enclosed					

7. Should the proposed characters be kept together in a contiguous range (rather than
	being scattered)?									No	

8. Can any of the proposed characters be considered a presentation form of an existing
 	character or character sequence? 							No	
		If YES, is a rationale for its inclusion provided?					
			If YES, reference: 							

9. Can any of the proposed character(s) be considered to be similar (in appearance
	or function) to an existing character?						No	
		If YES, is a rationale for its inclusion provided?					
			If YES, reference: 							

10. Does the proposal include use of combining characters and/or use of composite
	 sequences (see clauses 4.11 and 4.13 in ISO/IEC 10646-1)?				No	
		If YES, is a rationale for such use provided?					
			If YES, reference: 							
		Is a list of composite sequences and their corresponding glyph images
		(graphic symbols) provided?							
			If YES, reference: 							
11. Does the proposal contain characters with any special properties such as control function or similar
	semantics?									No	
		If YES, describe in detail (include attachment if necessary)				

Annex B	Handling of Defect Reports on Character Names
Since the publication of ISO/IEC 10646-1 in May 1993, several defect reports requesting changes to character names have been received by WG 2.  In principle, the names in the standard are not to be changed.  However, there may be situations where an annotation to the character name may be warranted.
B.1	Principles to be used by WG 2
The following paragraphs describe the principles of dealing with defect reports on character names:

A.	Explanatory information in Annex P, “Additional Information on Characters” of the standard:
If WG 2 decides that the request is justified, WG 2 will first consider accommodating the request by adding explanatory text to Annex P of the standard.
B.	Non-normative parenthetic annotation of the name:
If WG 2 considers that the request falls within the guidelines of Rule 12 in Annex K - Character naming guidelines in the standard, then an appropriate annotation will be added to the character name.
C.	In instances where a name change causes a potential problem for compliance by implementations of existing standard, and if the concern expressed in the defect report may be handled with a simple explanatory note, a note may be added.
D.	Deprecation:
If WG 2 considers that the character identified in the defect report should not have been in the standard, for reasons such as duplication, or incorrect inclusion in a block, then that coded character will be marked with the annotation "(deprecated character)" after its name.  Note, however, that the character will never be removed from the standard.
E.	Reject:
In all other situations, where WG 2 considers that the request is not sufficiently justified or none of the above-mentioned measures is warranted, the defect report will be rejected with an explanation.
B.2	Some Guidelines for Submitters of Defect Reports:
As a supplement to the above information on dealing with defect reports, the submitters can assist the working group by following the guidelines given below:

a)	report all defects associated with characters from the same block or set of characters as a single defect report (for example, use a single one for all defects from within a character block such as Malayalam), instead of one for each character.
b)	avoid including defective characters from different character blocks or sets in the same report.
c)	please check if the defect has already been reported by some one else or considered earlier by WG 2.  Copies of the dispositions of prior defect reports can be obtained from the SC 2 Secretariat.
d)	if one or more new character(s) - with their own new name and glyph -  is proposed to be added in conjunction with a defect report, please submit the addition requests separate from the defect report along with the Proposal Summary Form for the new characters.

Annex C	Work Flow and Stages of Progression
This annex contains a description of the UCS work flow and stages in progression from initial proposal to final publication.
C.1	The UCS work flow
UCSwork flow can be illustrated in a simplified form as follows:

Communication  to WG2 and communication inside WG2 related to populating the standard	Communication from WG2 to the world outside	
				
Input
	Process	Output	Output
	
From whom	What	Under meetings	After meetings	What	To whom	
•	Convener
•	SC2
•	JTC1
•	ITTF	•	Agenda (e.g. N1387)
•	Ballots	Resolutions (e.g. N1354)	•	Minutes (e.g. N1353):
•	Action Items	Result of request:
•	Acceptance
•	Rejection	Requester
	
•	NBs
•	WG experts
•	IRG-group
•	Liaisons	Input documents:
•	Requests (e.g. N1324)
•	Defect reports (e.g. N1806)
•	Working documents
•	Liaison statements			•	Editorial corrigenda.
•	Technical corrigenda. (e.g. N1393)
•	Amendments (e.g. N1310)
•	Standards (e.g. ISO/IEC 10646-1)	•	SC2
•	JTC1
•	ITTF	
•	Secretary
•	Editor	•	Minutes:
•	Action Items
•	Standing documents				•	IRG	
	Types of Documents	How	
•	Secretary
•	Editor	Standing documents:
•	WG2 distribution list (e.g. N1351)
•	Document register (e.g. N1300)
•	Summary of WG2 work (e.g. N1302)
•	Cumulative list of repertoire additions (Buckets) (e.g. N1385)
•	Alphabetic (Arabic, Cyrillic, Hebrew, Latin, etc.)
•	Symbols
•	Ideographs
•	Cumulative list of Corrigenda (editorial, technical) (e.g. N1384)
•	ISO/IEC 10646-1 Corrigendum (e.g. N1396)
•	List of character names and code positions allocated (e.g. N1675)
•	Principles and procedures (e.g. N 1352)
•	Overview of the basic Multilingual Plane (e.g. N1332)	Presentation forms:
•	Paper documents
•	Web site (the WG2 web site at DKUUG and the IRG web site in HK)	
C.2	The stages of work:
Any new proposal for addition of new characters will pass a number of stages from initial proposal to finalized publication.  The stages are:
•	Initial proposal
•	Provisional acceptance
•	Final acceptance (Bucket)
•	Hold for ballot

This terminology indicates the stage of maturity of the proposal and the WG’s confidence in the proposal.

		In process within WG 2
	Further progression	
Stage 

______

Item
		Initial proposal	Provisional acceptance	Final acceptance (allocation of bucket)	Hold for ballot	Progression/ Publication status	
						SC2
Ballot	JTC 1 Ballot	ITTF
Publication	
		1	2	3	4	5	6	7**	
1*	Character shapes	1.1	2.1						
2*	Character names	1.2	2.2						
3*	Code position allocation	1.3	2.3						
4*	Text to be included in the standard	1.4	2.4						
5*	Font**	1.5	2.5						
6  	Other items from proposal summary form	1.6	2.6						
* Items 1 through 5 are mandatory for entering “final acceptance” stage
** Camera ready copy is mandatory for stage 7.  It is expected that the quality of the fonts will improve to camera ready quality as the proposal progress trough the various stages.  For information on the format of the font see the “Proposal summary form”.

•	Stages 1 to 3 may contain provisionally allocated code positions.  When a proposal enters stage 4 the code positions are final.
•	The content of the Buckets are reviewed at every meeting to decide whether the content shall progress for balloting (stage 4).
•	The progress of the proposals are recorded in the WG2 standing document Summary of WG2 work (the WG2 standing document in the form of a spread sheet).
•	When a proposal reaches stage 4 its status is included in List of character names and code positions allocated.
C.3	Examples:
List of character names and code positions allocated:
Code position	Status	Reference	Character name	
...				
20AB	6	N1092	DONG SIGN	
...				
012C			LATIN CAPITAL LETTER I WITH BREVE	
...				
00E6	7	N1128	LATIN SMALL LETTER AE (ash)	
...				
1E9B	6	N1132	LATIN SMALL LETTER  LONG S WITH DOT ABOVE	
...				
FFFC	2	N1365	OBJECT REPLACEMENT CHARACTER	

WG2 standing document "Status Summary of WG2 work items" shows the status of different proposals.
Annex D	Roadmap
(Note:  This Annex D is under construction in this document and will be completed after the review of the associated Roadmap documents proposed for discussion at meeting 36).  See latest WG 2 documents N1876, N1949 and N1955.

Annex E	Request for new collection identifiers
(Source:  ISO/IEC JTC 1/SC 2/WG 2 N1877 – modified based on discussion at M35; AI-M35-6b)

Request For Collection Identifier
For A Sub-Repertoire Of ISO/IEC 10646
		Date:  	
SOURCE:		
Email address of source: 			
Phone number of source: 		
Fax number of source: 		
Address of Source: 		

		
		
WG 2 SPONSOR:		
(Preferably a member body or liaison organization of ISO/IEC JTC 1 or its subcommittees and working groups)
SUBMITTER's REFERENCE: 			

SUBMITTER AND THE SPONSOR SHOULD DO THE FOLLOWING:
A.	Ensure that no existing collection identified with a Collection Identifier in ISO/IEC 10646-1 satisfies their needs.  If a single collection does not exist, provide justification why an enumeration of two or more identified collections cannot satisfy the need.
B.	Ensure that the proposed collection of characters is a true subset of the repertoire of characters of ISO/IEC 10646 (including all its amendments and corrigenda).  The list of character names in Annex E of ISO/IEC 10646-1 can be used as an aid.  If any character is NOT currently encoded in the standard, that character should be submitted for inclusion in the standard, following the guidelines documented in Section 1 and in Annex A of this document.
C.	Prepare a list of existing collections that are fully contained in the proposed collection.  Ensure that you have considered all the approved amendments of the Standard while preparing this list of collections.  (Note:  Only Group 00, Plane 00 code positions are defined to date.  Planes 1, 2 and 14 are being defined as part of ISO/IEC 10646-2 by ISO/IEC JTC 1/SC 2/WG 2).
D.	List any code positions that are included in the proposed collection, but are NOT included in the list of existing collections identified in Step C above.
E.	For each of the existing collection that is identified in step C above, list any code position that is to be excluded from the proposed collection.
F.	If the proposed collection is to be marked as FIXED, provide a list of individual code positions that are NOT allocated in each of the collections identified in step C above, and therefore to be excluded from the proposed collection.
G.	Decide if the collection is to be marked as a Fixed collection (see section 4 of this document).
H.	Prepare a background document, including the rationale and intended use of the collection and forward it to the Convener of ISO/IEC JTC 1/SC 2/WG 2 for consideration, acceptance and assignment of a Collection Identifier by WG 2.

Format to be used for sub-repertoire submission

An example format of the proposal for collection definition is given below:  The final form of documenting the sub-repertoire in the standardr is at the discretion of the project editor(s).

Collection Name:  EXAMPLE COLLECTION
(Note: This example is based on an input document on Latin Characters based on ISO/IEC 6937:1994, from Mr. Johan van Wingen, Netherlands;  the Euro Sign has been added; see WG2 N1881 - Request for Collection Identifiers for European Repertoires.)

Collection to be marked as Fixed (Yes / No):    YES
Plane 00
Rows 	Positions (Cells)	
00	20-7E, A0-FF	
01	00-13 16-2B 2E-4D 50-7E	
02	C7 D8-DB DD	
1E	80-85 F2 F3	
20	15 18 19 1C 1D AC	
21	22 26 5B-5E 90-93	
26	6A	

Collections containing the proposed sub-repertoire
The following UCS collections from Annex A of ISO/IEC 10646-1 contain characters of the above proposed collection:

ID	UCS-Collection Name / Code Positions	Positions to be included or excluded	
1	BASIC LATIN 0020–007E	All are included	
2 	LATIN-1 SUPPLEMENT 00A0–00FF	All are included	
3	LATIN EXTENDED-A 0100–017F	Only 0114, 0115, 012C, 012D, 014E, 014F, and 017F are included.	
6	SPACING MODIFIER LETTERS 02B0–02FF	Only 02C7, 02D8—02DB and 02DD are included.	
32	GENERAL PUNCTUATION 2000–206F	Only 2015, 2018, 2019, 101C and 201D are included.	
34	CURRENCY SYMBOLS 20A0–20CF	Only 20AC is included.	
36	LETTERLIKE SYMBOLS 2100–214F	Only 2122 and 2126 are included.	
37	NUMBER FORMS 2150–218F	Only 215B—215E are included.	
38	ARROWS 2190–21FF	Only 2190—2193 are included.	
47	MISCELLANEOUS SYMBOLS 2600–26FF	Only 266A is included.	

Justification for a Single Collection Identifier Request
(For example) A single collection identifier is required to tag textual data in a particular protocol with a character set identifier.

WG 2 ADMINISTRATIVE:
ACCEPTED:	Reference: 	Amendment number or edition: 	____________;
Collection identifier:		____________;
Resolution number: 		____________
REJECTED:	Reference: 	Document containing response to submitter:
WG 2 document no.:	____________;
Resolution number:	 ___________

Annex F	Formal criteria for disunification
(Source:  ISO/IEC JTC1/SC2/WG2 N1724 – adopted with revisions at M34 – action item M34-7d.)

There have been repeated proposals to disunify existing characters.  These proposals cannot be fully evaluated without a more rigorous framework concerning the disunification / unification of characters.  Without such formal criteria, all decisions are 'ad-hoc' and different proposals may get different levels of review.  Both ISO/IEC JTC 1/SC 2/WG 2 and the Unicode Technical Committee need to spend some time in evaluating and possibly formalizing the criteria that we use to decide these cases.  This is similar to the formalization we have done for script prioritization, but uses different criteria.

NOTE:  The unification criteria used for the Han script are very thorough and quite sufficient.  This document attempts to establish formal criteria for use in other scripts.  There is no attempt to change the procedures used in Han unification.
F.1	What is disunification?
Disunification is the introduction of a new character which can also be encoded by an existing character. A strong case of disunification occurs where there is prevalent practice of using the existing character. A weak case of disunification occurs where there is little or no use of the existing character for the purpose for which the new character is intended.
Example: Adding a period in a new script is a weak disunification if we assume that nobody has an existing implementation of that script using the regular period.  Adding a clone of a Latin letter for use with Cyrillic script is a strong disunification as mixed Latin/Cyrillic character sets exist and have almost certainly been used for encoding the languages that the new characters are intended for.
F.2	Cost and Benefits
Proposals always claim that disunification brings benefits. Formal criteria attempt to critically evaluate those benefits, but also compare them to the costs.  Any disunification, especially strong disunification, introduces several types of cost to all complete implementations of the Standard. 

1.	Any complete implementation will have to add and support both an additional entry in the properties as well as an additional glyph, or glyph mapping for the disunified character. 
2.	Whenever the character in question has no appearance distinction, there is the cost of accidental confusion and mis-identification. All implementations will need sophisticated handling of equivalencies, especially, where disunification occurs on well-established characters (as opposed to among the characters of an entirely new script being fine-tuned in the proposal stage). 
3.	Keyboards that support the disunification need to be widely (and by default) available, this is especially troublesome for strong disunification of Latin characters as most keyboards have a Latin layer from which it is easy to type the existing and now-disunified character. 
F.3	Criteria of analysis
I. Costs
The following questions are designed to evaluate the costs associated with the disunification.
1.	Is there a glyphic distinction?
2.	Is there a behaviour difference?
3.	Is the use of the new character restricted to a new context (for example, use with a novel script)?
4.	Is the use of the existing, ambiguous character instead of the proposed new character common, prevalent or established practice?
5.	Does the character exist in ASCII (ISO 646IRV)?

II. Benefits

1.	Appearance: does disunification help to allow multilingual monofont text in an environment where this is commonly needed? In what way? 
2.	Layout: does disunification solve common layout differences (this would mostly be true for punctuation)? 
3.	Searching/sorting: Is there a common case where disunification allows better support for these? 
4.	Mapping to another standard: Is there a widely used standard that disunifies the characters in question? Are the characters in question the only ones that prevent cross mapping? 

III. Alternatives
Finally, the analysis must explore whether other alternatives are possible.

1.	Can the desired effect be achieved by changes to the display layer?
2.	Can the desired effect be achieved by changes to protocols?
3.	Can the desired effect be achieved by processing algorithms?
F.4	Some Examples of Precedents
Character:  Generic Decimal Separator Mark

In 1991 the proposal was made to add a new punctuation character in the General Punctuation block that would have the semantic property of decimal separator, but could be imaged as either period, comma, space or apostrophe depending on the locale.

Asserted benefit:  Solve the locale dependent display of numbers.

Costs:  This new character would have disunified four widely used characters.  Mapping from existing character sets would have become locale dependent.  Users would have to turn on a special show-invisible-character mode to distinguish the new character from existing characters.  Such modes exist, but are limited to word processing software, where numbers usually occur embedded in text, which in turn is 'frozen' into a given language.  Database software, where locale dependent numeric displays are much more of an issue, does not normally need or support a show-invisible-character mode.  Finally, in 1991 there were no keyboards supporting this new character, but it would be needed in all languages and applications, and all software would have to be specially adapted for it.

Alternatives: There already is an established technology to deal with locale differences, and in a way that is not limited to decimal numbers.

Result:  Rejected.  The costs far outweigh the benefits.

Character:  Angstrom Symbol

Asserted benefit: Provide roundtrip mapping for East Asian character sets.

Costs: This character disunifies A WITH RING, which is in wide use in only a limited number of languages that all use Latin-1.  In the Latin-1 context, it would be natural to use A WITH RING as the Angstrom Symbol.  The Angstrom unit is not one of the preferred powers for the metric units of SI, but it is still commonly used in some disciplines as it is convenient for atomic length scales.  Disunifying the A WITH RING adds the important round trip mapping capabilities for East Asian character sets, but makes it harder to use the Standard as a pivot between these character sets and Latin-1.  However, almost none of the other SI units that have explicit character codes in East Asian character sets can be mapped 1:1 with Latin-1, so the Angstrom Symbol adds little to that problem.  Searching needs to support equivalencies, however, in the East Asian context the need for extended equivalencies (beyond simple case equivalence) is common.

Alternatives: None.

Result: Accepted.  The benefits far outweigh the costs.

Annex G	Formal criteria for coding precomposed characters
(Source:  ISO/IEC JTC1/SC2/WG2 N1725 – adopted with revisions at M34 – action item M34-7e.)

This annex addresses in brief the criteria that support or militate against encoding of any specific proposed characters as precomposed characters instead of as combining character sequences.  The positive criteria are of the form of necessary conditions, but not in themselves sufficient to make the decision.  Proposals that meet the negative criteria should use composed character sequences instead.  The cost criteria are provided as a help to gauge the impact of encoding new precomposed forms. 

Positive:
•	Existence in another character encoding standard (for the purpose of 1:1 character conversion)
•	Existence of a precomposed letter in a well-established or official alphabet.

Negative:
•	If it were to introduce multiple spellings(encodings) for a script where NO multiple spellings existed previously..
•	If combining  character sequences can be shown to meet the stated information processing needs (e.g. archival use)
•	If solely intended to overcome short-term deficiency of rendering technology.
•	If the intended use of the character is solely for transliteration purposes.

Cost criteria
•	Incremental cost for each additional character
•	Incremental cost for each new multiple spelling
•	Declining benefit if immediate and widespread use is not anticipated.
•	Effect on system / products that use pre-composed form as canonical (since addition of precomposed characters makes this set of canonicals unstable).

Note: some existing and widely available implementations of internal processes (collation) may use decomposed characters even where the editing interface does not support them.  For these cases, additional multiple spellings provide explicit additional costs without any benefit.

•	Short term solution versus permanent cost

Note: the level of support for combining characters in Latin, Greek and Cyrillic documents is not as widespread as was anticipated when the first edition of the standard was published.  It may be tempting to introduce precomposed forms as a short term solution as long as the level of support for combining characters in Latin, Greek and Cyrillic documents is not yet widespread.  Key font technologies with support for combining have been developed and at the same time, an increasing number of platforms routinely know how to handle combining marks for other scripts.  Adding new precomposed characters could be a permanent unwarranted cost for such newer technologies versus the short term benefit of being able to reuse not-so-new technologies.

History of this document
This document was originally prepared by Mark Davis, Edwin Hart and Sten G. Lindberg, as document N 946 (dated 11 October 1994), based on N 884 (authored by Rick McGowan and Joe Becker).  It has been enhanced by an ad hoc group on principles and procedures set up at the San Francisco SC 2/WG 2 meeting no. 26, The result was presented as SC2/WG 2 N1116.  The following is a summary of changes made since that time: 
1.	At the Geneva SC 2/WG 2 meeting no 27, where some enhancements were proposed.  The result was presented as SC2/WG 2 N1202.
2.	At the Helsinki SC 2/WG 2 meeting no 28, some enhancements were proposed and adopted.  The result was presented as SC2/WG 2 N1252.  The document was accepted, following Resolution M28.6 at that meeting.
3.	At the meeting no 31 a new Annex C: " Description of the UCS work flow and stages in progression from initial proposal to final publication” was added.  Furthermore a new question (C 10) regarding some properties of proposed characters has been included in the proposal summary form.
4.	At the meeting no 32 a new Annex D:”BMP and Supplementary Planes Allocation Roadmap”.  The annex D is the inclusion of the US contribution N1499 only with minor editorial changes.  Minor editorial changes have been made to align the different standing documents.
5.	Principles regarding allocation of '00' position in a block (resolution M33.12)  and regarding considerations for half-block boundary (per resolution M33.11) have been added.
6.	The ad hoc report on collection identifiers for parts 1 and 2 (document N1726) from meeting 34, and a form for submission of requests for collection identifiers (document N1735, amended per AI-35-6-b) have been incorporated.
7.	The principle of '1K boundary for allocations in Plane 1 for ease of use with UTF-16' (per Action Item AI-35-6-a) has been added.
8.	The unused 'WG2 administration section D' has been removed from the proposal summary form (at meeting 36).
9.	Formal Criteria for Dis-Unification based on document N1724 (per AI-34-7-d, based on document N1724) was added.
10.	Formal Criteria for Coding Pre-Composed Characters (per AI-34-7-e, based on document N1725) was added.
11.	A note has been added on the need for stronger justification for proposals to include 'Glyph Variants'.
12.	A sample picture of the 'spread sheet' illustrating the skeleton format and column headings used in the parallel WG 2 standing document 'Status summary of WG2 work items' has been removed, with the reference to that standing document.
13.	The document has been reorganized slightly for better readability.  This is presented as document N2002 at M36 (the revised Annex D is left as 'to do' pending acceptance of other roadmap contributions).

The ad hoc group on principles and procedures had different members over time.  The current members of the ad hoc group are:

V.S. Umamaheswaran (Current editor of this document)
Mike Ksar
Michael Everson
Ken Whistler
Keld Simonsen

References
Document numbers in the first column in the following table refer to WG 2 working documents (ISO/IEC JTC 1/SC 2/WG 2/ Nxxx), except where noted otherwise.

Doc. No.	Title	Author(s)	Date	
946	Proposed principles and procedures for allocation of new characters and scripts	Davis /Hart /Lindberg	1993-11-03	
947	A proposed initial list of character allocations	Davis /Hart /Lindberg	1993-11-03	
995	10646-1 Proposed Draft Amendment 3 (section 9-a-i.3)	Mark Davis WG2 Project Editor	1994-03-03	
1002	Comments on N 947 "Proposed categorization and allocation of characters"	Japan (TKS)	1994-03-28	
1061	IRG Comments to WG2 N 946 (Proposed Principles and Procedures for Allocation of New Character and Scripts)	IRG	1994-09-14	
1117	Unconfirmed Minutes of Meeting 26 San Francisco CA	Meeting Secretary - Uma	1994-10-31	
1118	Resolutions of WG 26 Meeting in San Francisco CA WG2		1994-10-14	
1137	Handling of Defect Reports on Character Names	Ad hoc group on Principles and Procedures - Messrs. V.S. Umamaheswaran Sven Thygesen Peter Edberg,	1995-01-27	
1203	Unconfirmed minutes of SC2/WG2 Meeting 27, Geneva; (sections 6.1, 6.2 and 10.1.12)	V.S. UMAmaheswaran and Mike Ksar	1995-05-03	
1218	Comments on Character Addition Proposal Summary Form (N 1116)	Japan - TKS	1995-05-03	
1370	Road map to 10646 BMP	Michael Everson	1996-04-22	
1464	Guidance and Assistance in the Prioritization of the Allocation of Code Positions in ISO/IEC 10646 (see ftp://dkuug.dk/JTC 1/SC 2/WG 2/docs/N1464.doc)	Sven Thygesen	1996-10-02	
1499	BMP and Supplementary Planes Allocation Roadmap
(see http://www.indigo.ie/egt/standards/iso10646/)	U.S.	1996-12-27	
1502	Update of N 1402 – Principles & Procedures of WG2
ftp://dkuug.dk/JTC 1/SC 2/WG 2/docs/N1502.xls and .doc	Sven Thygesen	1997-01-24	
1603	Draft Minutes of WG2 Meeting 33 – Heraklion, Greece	Ksar/Uma	1997-10-24	
1703	Draft Minutes WG 2 Meeting 34 -  Remond, WA	Ksar/Uma	1998-07-02	
1724	Formal criteria on disunification	US/Unicode – Asmus Freytag	1998-033-05	
1725	Formal criteria for coding precomposed characters	Expert contribution – Asmus Freytag, Ken Whistler	1998-03-17	
1726	Report of Ad Hoc on Collection Identifiers for Parts 1 and 2	Ad Hoc on Collection ID at M34	1998-03-18	
1735	Request for Collection Identifier in ISO/IEC 10646	Ksar / Uma	1998-03-21	
1791	Repertoire additions for 10646-1 – Cumulative List 7	Paterson	1998-06-08	
SC2N3082	Final Text - Technical Corrigendum No. 2 to ISO/IEC 10646-1:1993; (See http://dkuug.dk/JTC 1/SC 2/)	Paterson	1998-04-07	
1876	Proposed replacement text for Annex D of N1502, Principles and Procedures document	Uma + ad hoc	1998-09-20	
1877	New Annex in Principles and Procedures document N1502 - Request for Collection Identifiers	Uma	1998-09-20	
1903	Draft minutes of meeting 35	Uma/Ksar	1998-12-30	
1949	BMP Roadmap	Everson	1999-01-25	
1955	Plane 1 Roadmap	Everson	1999-01-25	
TR152825	An Operational Model for Characters and Glyphs		1998	
Unicode document	Proposed Unicode Characters (see http://www.unicode.org/unicode/alloc/Pipeline.html for latest)	Mark Davis	1996-10-25