Accredited Standards Committee	Doc. No.	X3L2/92-080
X3, Information Processing Systems*	Date	14 April, 1992
X3L2, Codes and Character Sets     	 Project	396-D
					Reply to	Jerome J. Anderson
To		JTC1 TAG		IBM Corporation
						C71/673
						P. O. Box 12195
						Research Triangle Park, NC  27709
						Voice	+1 919 254-6554
						FAX  	+1 919 254-5410

Subject	Points for consideration of the JTC1 TAG when voting on US position on ISO/IEC DIS 10646-1.2

Action Requested	Review before balloting

X3L2 recommends that the United States vote "yes with comments" on ISO/IEC DIS 10646-1.2.

The following are points for consideration by JTC1 TAG members
 
X3L2 strongly supports DIS 10646‑1.2, and recommends a positive vote by the United States. X3L2 also has a number of concerns about the long term future of 10646, beyond its acceptance. Some stem from the fact that this DIS results from the merger of the concepts and repertoires of the first DIS 10646, and Unicode ‑ a code standard created by the Unicode consortium. Others have to do with problems that may arise during maintenance of 10646. We wish to highlight these concerns as indicating areas where future work may need to be done by the relevant standards organizations.
 
A.	X3L2 is anxious to prevent the creation of two competing international coded character sets and has included in the proposed US position language to this effect. We have also instructed our liaison to the Unicode Consortium to make it aware of our concerns. A mechanism needs to be put in place to guarantee continued cooperation between JTC1/SC2/WG2 and the Unicode Consortium, which have different constituencies to whom they are responsible.  Allowing Unicode and 10646 to diverge would be highly undesirable; keeping the two synchronized would be invaluable. We feel that an effort must be made to identify means by which Unicode and ISO 10646 will remain merged, by creating mechanisms to guarantee continued cooperation between JTC1/SC2/WG2 and the Unicode Consortium.
 
B.	The structure of future character allocations is not well-defined, and X3L2 is concerned about the process by which new characters and scripts will be added to 10646 in cooperation with Unicode. How should new characters be added? Where will they be added? Who decides where they will go? How will a character be identified as a new character, as opposed to a character already included?
 
We are particularly concerned that companies or individuals may find the international standards process frustratingly slow when it comes to adding the characters or scripts they want. Efforts must be made to keep the process of adding characters and scripts to 10646 timely and responsive, and this process and the coordination with Unicode needs to be clearly defined. We believe there is a need for
 
	a)	maximizing the utility of the Basic Multilingual Plane,
 
	b)	creating a policy on additions of precomposed and variant characters,
 
	c)	creating a policy on duplication of characters,
 
	d)	creating a flexible and speedy process for adding characters, and
 
	e)	defining a maintenance process that is germane to the nature of the standard and its intended usage.
 
C.	X3L2 has been made aware that JTC1 SC18 and JTC1 SC22 perceive the need for a firm definition of the word "character" (as opposed to "glyph") in 10646. X3L2 is currently considering how best to meet this need, but generally agrees that "glyph" and "character" need to be more clearly defined and differentiated. This would help clarify the charters of committees such as X3L2 and would also be valuable in setting criteria for the future addition of characters to 10646. In particular, there is concern that an expanded number of glyphs or presentation variants may preempt space in the Basic Multilingual Plane and that space is needed for future assignment of characters.
 
D.	X3L2 understands that migration to this standard may require a significant investment and encounter difficulties. Existing software written in C or other programming languages may attempt to treat strings of 10646 data as if strings of ASCII (ISO 646) text, which would create problems because many of the valid bit combinations of 10646 contain what appear to be control characters, including embedded NULL octets. We believe efforts should be made to identify smooth transition paths from 8‑bit character sets to the new multi‑octet one.
 
Finally, we note that one X3L2 member believes that migration problems could best be minimized by modifying 10646 to eliminate embedded NULL codes. This concern is known to be shared by at least some standards committees and companies outside X3L2. The proposed solution, however, would create other concerns with other standards committees and companies. The majority view in X3L2 is that, on balance, the 10646 DIS 1.2 architecture is technically superior.