L2/00-432

NCITS/L2 response on JTC 1 N6345
(Proposed Modifications to the SC 22 Programme of Work)

From: NCITS/L2, Kenneth Whistler [kenw@sybase.com]

Date: Monday, December 11, 2000

The U.S. objects to the retention of project JTC 1.22.15435, API for internationalization. Unlike the other projects proposed for retention, there is every reason to believe that project JTC 1.22.15435 will  *not* be completed.

Project JTC 1.22.15435 has seen several drafts to date, each of which has been massively defective and roundly criticized, with no clear evidence of a path forward to reach a document of sufficient quality to warrant CD balloting.

Although the U.S. has provided thorough review comments to each draft, there is little indication that the most fundamental recommendations regarding the scope and design of the API are being applied to the draft in any significant way. Therefore, there currently is no reason to believe that this project can achieve the consensus necessary to become an international standard. We object to having to continue to spend resources responding to fundamentally flawed drafts.

The current manifestation of project 22.15435 fails to reflect state of the art practice in internationalization API design within the software industry.  Given the failure to achieve consensus despite successive drafts, the US has no reason to believe that this grave deficiency will be remedied even if the requested extension is granted.

Participation in development of the API for internationalization standard has been minimal -- largely limited to a single national body, with active opposition from several national bodies, including the U.S., Japan, Ireland, Sweden, and the U.K.

The U.S. believes that attempting to move forward on development of an API standard that has no consensus in the developing committee and minimal participation would be a poor course of action, likely  to lead to a bad standard of very limited market relevance.

Furthermore, the U.S. objects to the inclusion of an instruction to the convener of WG20 to initiate a CD registration ballot by a certain date for Project JTC 1.22.15435. A CD registration ballot should be initiated by a technical committee when there is clear evidence that a  standards document has reached a level of technical maturity and consensus  that warrants balloting. That maturity and consensus is clearly not present for Project JTC 1.22.15435. Unlike the committee courtesy shown in the requests for extensions for Projects JTC 1.15436 and  JTC 1.22.34, which merely request a year extension, the inclusion of an  instruction to the Convener of WG20 in the request for extension for  Project JTC 1.22.15435 reflects the level of confrontation and *lack* of  consensus associated with that project. It strikes us as an attempt to  force a standard to start its balloting process, despite the lack  of a consensus in the relevant committee to recommend that such  balloting commence.

In summary, the US recommends that JTC 1 refuse to grant an extension for project JTC 1.22.15435, API for internationalization and thereby terminate the project.

End of document