ISO/IEC JTC 1/SC 2 N 3409 Date: 2000-02-21

ISO/IEC JTC 1/SC 2

CODED CHARACTER SETS

SECRETARIAT: JAPAN (JISC)

DOC TYPE: Summary of Voting/Table of Replies

TITLE: Summary of Voting on SC 2 N 3390, ISO/IEC CD 2375, Information technology -- Procedure for registration of escape sequences and coded character sets (Fourth Edition)

SOURCE: Secretariat, ISO/IEC JTC 1/SC 2

PROJECT: JTC 1.02.04.00.00.00.04

STATUS: This document is forwarded to WG 3 for review. WG 3 is requested to prepare a disposition of comments report, revised text and a recommendation on further processing.

ACTION ID: ACT

DUE DATE:

DISTRIBUTION: P, O and L Members of ISO/IEC JTC 1/SC 2 WG Conveners and Secretariats Secretariat, ISO/IEC JTC 1 ISO/IEC ITTF

NO. OF PAGES: 23

ACCESS LEVEL: Defined

WEB ISSUE #: 077

Contact: Secretariat ISO/IEC JTC 1/SC 2 - Toshiko KIMURA IPSJ/ITSCJ (Information Processing Society of Japan/Information Technology Standards Commission of Japan)* Room 308-3, Kikai-Shinko-Kaikan Bldg., 3-5-8, Shiba-Koen, Minato-ku, Tokyo 105-0011 JAPAN Tel: +81 3 3431 2808; Fax: +81 3 3431 6493; E-mail: [email protected] *A Standard Organization accredited by JISC Summary of Voting on SC 2 N 3390

Approve Approve Disapprove Abstain Not voted with Comments P-member Armenia X Austria X Belgium X Brazil X Canada X* Attachment 1 China X Denmark X Egypt X Finland X* Attachment 2 France X Germany X Attachment 3 Greece X Attachment 4 Iceland X India X Iran, Islamic Republic of X Ireland X Israel X Italy X Japan X Attachment 5 Korea Rep. of X Mongolia X Morocco X Netherlands X Attachment 6 Norway X Poland X Romania X Russian Federation X Singapore X Slovenia X Sweden X Attachment 7 Thailand X Tunisia X Turkey X UK X USA X* Attachment 8 Yugoslavia X 10 2 6 1 17 Total (36) 12 6 1 17 O-member Portugal 1

*=Acceptance of the reasons and appropriate changes in the text will change the vote to approval

1 Attachment 1 – Canada

Due date 2000-02-1 Document number CD2375 (JTC1/SC2 N3390)

Canada DISAPPROVES unless its comments are resolved satisfactorily, in which case the vote will be changed to a YES.

Comments:

5.3: Points 6.3, A.3, B.1.1 (except B.1.5) seem to contradict this article which seems obsolete. It seems to us that the intent of the document be that all the information ne in the registry. There are too many mandatory requirements to say that specifications may be specified elsewhere. This article needs to be rewritten.

6.2.1 Annex G (even if informative) contradicts this statement as understood in Canada: the example is a registration for Georgian sponsored by Ireland. Canada demands that the word "shall" in this clause be changed to a "should". We have no problem with the example in annex G provided that it comes from a legitimate sponsoring authority, as it is the case in the actual example.

6.2.2 We find contradictory a "shall" in this clause with the ending "as it may desire". What is the intent of such a requirement. We propose to change "shall effect" by "effects".

6.3 The first "shall" shall be changed to a "should" unless Annex E shows the complete forms, which does not seem the case right now (it only contains *sample* forms for charts). If this shall is not changed, accepting this clause is like signing a blank cheque.

7.6 This clause is very ambiguous: What is the impact of "when appropriate, shall..."? Either comments shall be included or there should not be a "shall". We propose the deletion of "when appropriate".

8.5 We demand the following changes: There should be two notes. "NOTE" should become NOTE1. This actual note contains a "shall". Now a note is *always* informative according to JTC1 directives and it can not contain a requirement. the "shall" shall be changed to a "should". NOTE 2 shall read as follows: ISO/IEC assigns normative character names in any of the official languages of ISO. Names provided by the sponsoring authority in any of these languages are considered acceptable with regards to note 1. It is recommended that names be provided in more than one official languages of ISO and that the equivalent in the national language(s) of the sponsoring authority be provided in addition.

A.2 Canada believes that A.2 is obsolete. The registration authority shall maintain a list of parties specifically requesting paper copies but it is important that there be a requirement as important as this one that the registry be maintained active with a permanent URL over the Internet. We did not see such a requirement and we demand it. This normative clause of annex A should be revisited in consequence.

Editorial comment: B.6 "to an exsting" to be fixed to "to an existing".

2 Attachment 2 – Finland

A number of items need better definition and clarification, e.g. the type of registration and the short name in normative Annex B.

3 Attachment 3 – Germany

The German vote is: Approval with comments

General remark:

This CD is a good starting point for a revision of ISO/IEC 2375. However, the number of open issues must be resolved in a second CD before the FCD stage can be envisaged.

Comments:

Major:

There is no clear rule of how to proceed if the proposal contains characters that have no equivalent in ISO/IEC 10646. Germany thinks that it must be possible for proposals to contain characters which are at present not part of the repertoire of 10646. (This may be implied by item 2 of B.5.2, but must be made explicit).

7.3 "it shall ascertain that the proposals received meet the presentation practice of the Registration authority". What does "presentation practice" mean? Since this is obviously a crucial requirement, it should be much clearer and more detailed.

Minor:

4. Definitions: Missing: "For the purposes of this International Standard, the following definitions apply."

4.1: combining character: Use definition from 2022.

Missing definitions (at least): character, coded character set, escape sequence, byte. Take these from 2022.

Replace new definition "code position" by more common usage.

5.1 "appointed by ISO" --> "appointed by the ISO Council" (as previously, cf. 4.1 in 2375:1985).

Preferably, remove note after 6.1. Alternatively, reformulate it to: "For proposals concerning single additional control functions to be represented by the Fs escape sequences, see annex C." (or equivalent). The last sentence of this note may become a note in annex C itself.

8.4: Note 2 should be part of normative text itself. It should be reformulated as follows: "This shall not infringe upon the Sponsoring Authority's right to identify the character and to determine its mapping." (or equivalent).

The note of 8.5 should be moved up to 8.4.

12.2, Note 1: This note seems superfluous.

B.1.6, item 7: What is the difference between a "non-spacing" and a "combining" character?

B.11: Change text to: "A registration should be made available in electronic form. The registration authority should preferably chose a format that minimizes potential data interchange problems."

Note after D.2: This is evident and should be omitted.

Annex D.3.5: "to edit the documents to be submitted to a vote according to clause 10.3": There is no such clause in this CD (obviously, 12.3 is intended).

4 Attachment 4 – Greece

COMMENTS ACCOMPANYING ELOT´S NEGATIVE VOTE ON CD 2375

Regrettably, we can not accept some paragraphs of ISO/CD 2375:

Accepting these paragraphs means to us that the registration procedure will become a basket to collect everything that is in the mind of the submitter, without any possibility to correct even obvious mistakes. That will put very much into question the validity of the register and of the registration procedure.

More specifically, we can not accept:

In Paragraph 6.1, First bullet: Any committee may be willing to register something, but it should be done in co-operation with JTC1/SC2. Second Bullet: We do not accept this “group within subcommittee” invention. Fourth Bullet: Only Liaison organizations should be able to register.

In Paragraph 12, We can not accept subparagraphs 12.1.1 and 12.1.2 These paragraphs are undemocratic. Every member body, liaison organization and, at the and, everyone concerned is eligible to file an appeal. Whether it will be accepted or now, or how it is another issue.

5 Attachment 5 – Japan

The national body of Japan disapproves the ISO/IEC CD 2375 (ISO/IEC JTC1 SC2 N3390) with following comments. The national body of Japan requests to proceed to 2nd CD because the comments are very basic technical comments.

General comments. The CD 2375 (N3390) does not reflect ISO/IEC JTC1 SC2 N3381 (revised 2 N3290) which is a basic scope of this project. Thus, the CD is not yet fulfilling the project objective. Also, effects of one change to other clauses are not well sorted out. Wording should be much straight forward, because expectation is more non-native speaker’s requirements in future.

Comments. J-1: Clause 4.1 combining character: Change this definition from ISO/IEC 10646 base definition to ISO/IEC 2022 base definition. Rationale: The definition of ISO/IEC 2022 definition is a super set of ISO/IEC 10646 definitions. It is including ISO 6937 type combining characters also. And then, it will be consistent with clause B.1.1.4.3 and Annex H (5th bullet). Additional comment for J-1 Annex B, Clause B.1.1.3.4 Proposed change: "Combining characters" (as defined in ISO/IEC 2022) shall be identified as such with combining directions (FORWARD and/or BACKWARD) in a note.

J-2: Clause 7.4 2nd line: shall indicate à should recommend “shall indicate” is not clear to many of non-native speaker of English. And also, RA should not change the registration request without an agreement by the SA.

J-3: Clause 7.5: Three months circulation to JAC is too long, it should be less than a month (say three weeks). Unless, total review period might be 6 months plus, it is too long for submitter.

J-4: Annex F: Fill this annex. It may make relations and intents of the all clauses in clause 7 and 8. And might avoid the confusion of the reader of this CD.

J-5: Clause 8.3 1st line: What does “verify” means? If it does mean “check and advice”, it is acceptable. If it means “check and correct”, it should not be done.

Proposed change: change “verify” to “review”, and add a text at the end “ If necessary, RA- JAC shall provide an advice the sponsoring Authority the review result.”

J-6: Clause 8.4 1st line: What does “note mean? If it means “ JAC add a note of (U+)xxxx, then Japan does not agree. If it means “JAC confirm with a SA for recommended (U+)xxxx, it is reasonable.

Proposed change: change “note” to “review” and add a text at the end “ if necessary, RQA- JAC shall provide an advice the Sponsoring Authority the review result.”

J-7: Clause 8.4 NOTE 2: Add following text at the end. “Therefore, no change for the character identification and mapping is allowed by RA-JAC. All changes are subject to be accepted by the Sponsoring Authority.

J-8: Clause 8.5 change “determine” to “review” . and add a text “If necessary, RA-JAC shall provide an advice the Sponsoring Authority the review result”.

6 J-9: Clause 12.1.2 : Add one more reason for appeals “Resisterd glyph shape(s), character identification(s) and/or mapping(s) are not acceptable by the Sponsoring Authority.

Rationale: It used be no need of this text because the probability of the changes made by the RA has been low, but now because of the RA-JAC review, it is higher than it used be. Japan is projecting the most of the appeals might be this case if the CD is approved as it is now.

Note; This is a reason why RA-JAC and AG should be separated.

J-10: Clause D.3.3: It is very questionable whether if RA-JAC can act as a mediator between the Registration Authority and appealing party. Because, in the case of new CD, the most of powers of RA should move to RA-JAC, and RA it self will be just a book keeper, therefore, the most of appeals might be on what RA-JAC decided or recommended, not what RA do.

J-11 Annex D: Add new clause of “Request of the “origin” as stated in the N3381. May be, some consideration on waiver is needed as a practice.

J-12: Annex G: Remove this, this sample may mislead a reader of this standard. If sample is necessary, use proven sample.

J-13: Annex H: Make any necessary change on this annex after the disposition of comments.

Extra: May be, there are editorial error there, however, Japan limits it’s comments on the very principle matter. Because it is too important than the minor editorial.

-----end----

7 Attachment 6 – Netherlands

VOTE OF THE NETHERLANDS NB ON CD 2375 (SC2 N 3390)

Our vote is negative.

We object to the inclusion of Annex E (normative). This matter has its proper place in a document "Practice of the Registration Authority". The layout as given deviates from that in a large number of registrations. Adopting a new format as normative would force the RA to re-edit and republish almost the whole content of the International Register, not to speak of the need created to correct older SC2 standards. But the CD contains no rules for re-editing of existing registrations, which may also be needed anyhow in some cases, like when aligning character names is wanted. Expensive changes in SC2 documents cannot be justified if their nature is only cosmetic. In particular, the layout specified is in conflict with that in 646 and 4873. Should a new layout be adopted, then it be introduced in all SC2 standards at the same moment, based on a SC2 decision.

Detailed comments p.3, 12.1 Appeal against what? The current 2375:1985 is explicit in that respect. p.4, A.1 Why is 8859 included? That IS is only an elaboration of 4873 (level 1). p.6, B.1.6 (last dot) Nobody knows what "non-spacing characters" are. They are not included or defined in any coded character set standard. p.6, B.1.7 Remove last sentence. There are no "non-spacing" characters in 6937 (please consult the 1994 edition or the current CD). Should a character "result" or "be produced" by a sequence of characters, then it is nameless, and thus unidentifiable. Composite sequences are there for mapping to glyphs, and are not characters, as 10646 points out. Only 646:1991 is still being imprecise and should be corrected.

8 Attachment 7 – Sweden

General comment:

The CD forms a generally very satisfactory starting point for an updated ISO 2375. The editorial comments given below relate mostly to text kept from the original standard, not to newly- introduced text.

It is however the opinion of the Swedish NB that the text is not ready to be progressed to FCD, but that a new CD is first needed.

Technical comment:

Within SC 2, there has been uncertainty whether a registration proposal must be based on a scheme having some official status, like a national standard; or if completely new schemes can be accepted. Although the latter case has been applied in practice, and can also be deduced from the text of the CD, the matter may need further SC 2 consideration.

The main reason for accepting completely new coding schemes is that it may be desirable to give schemes of limited use an international recognition through registrations, even if they are not immediately made the base of formal standards. Registration should increase the possibilities to evaluate new schemes before a decision is taken to progress them further to formal national, international or organizational standards.

The decision on this matter, in particular any limiting factors, should be clearly declared in the standard text (not only in its annexes).

Editorial commments:

Introduction: "... should not be regarded as procedure to standardize a coded character set - it is not a standardization procedure" could be expressed in a more condensed way.

Subclause 2.1: "... sequences specified in ISO/IEC 2022 as reserved ..." may be a better wording.

Clause 3: ISO/IEC 6937 is mentioned only in subclause B.1.7, and it seems not really needed there (see comment below); the reference to it in clause 3 should therefore be removed. Further the new edition (:2000) of 10646 should be referenced.

Clause 4: The definitions should be introduced by "For the purposes of this International Standard, the following definitions apply:"

Also a number of terms are used in the CD which should be defined (like in other standards):

Bit combination Byte Character Coded character set Graphic character Position Repertoire

The term "glyph" is also used, in subclause 10.1. It is however suggested that the term be changed (or excluded) there, and therefore not defined.

9 Subclause 4.1: The 2022 definition of "combining character" should be used, not the 10646 one.

Subclause 4.3: It is suggested that the definition is removed, and that the term "code position" in the CD is generally exchanged for the self-explanatory "code table position" (as used in other standards).

Subclause 5.1: "... appointed by ISO to act ..." Is this correct? (The current edition of 2375 has "ISO Council".)

Subclause 5.3: The original wording of this paragraph appears preferable to the new one (except that the last sentence should use "identify" in place of "mention").

Subclause 6.2: The original layout of this text seems preferable, as a list rather than as numbered subclauses. This will also avoid the repetition of "A Sponsoring Authority ..."

Subclause 6.4: The meaning of this text is not quite clear. What constitutes "convenient and applicable" conditions? And it appears that it should be the originator (if it is not the Sponsoring Authority itself) that is responsible for the mappings.

Subclause 6.5: The consequences of this text is not clear. What means "ultimate authority over the content", considering e.g. 7.4 and 8.5?

Clause 7 general: In this case also, the original list layout appears preferable to numbered subclauses.

Subclause 7.3: The subclause and its present Note needs to be rewritten to clearly define, in one continuous text, the two possible registration situations; i.e. coding schemes conforming to 2022, and other schemes. Also "... the presentation practice of ..." could be more stringent, e.g. "... the presentation practice specified by ..."

Subclause 7.6: The Registration Authority should be allowed to decide to incorporate received comments only after consulting the Sponsoring Authority concerned.

Subclause 8.3: This obviously applies only when a proposal contains mappings to 10646 (cf. 6.4), which should be stated. Also the words "in fact" appear somewhat unfortunate, implying that the RA-JAC is more capable than the originator of a proposal to identify its characters (which may of course sometimes be the case).

Subclause 8.4: The meaning of "... shall note the code position ..." is not clear. Does this refer to 10646 identifications in the Note column of the name tables?

Subclause 8.4 Note 2: This seems to partly duplicate 6.5.

Subclause 8.5: The meaning of "... identified as being identical..." is not clear. Does this refer to some documentation outside the actual registration proposal? Because if one or more proposed names in the registration are not to be found in 10646 it would mean, strictly speaking, that the proposal contains characters not existing in 10646. Is this subclause directed towards mistakes in naming?

Clause 9 general: It should be considered if, in addition to the active withdrawal of support by a Sponsoring Authority, also some kind of periodic review of registrations support should be prescribed

Subclause 9.3: "Interested parties" is somewhat vague; cf. 7.8.

10 Subclause 10.1: The Registration Authority should not be authorized to introduce "corrections" to registered character sets, particularly not to its glyphs, unless first consulting the Sponsoring Authority.

Subclause 11.2: "... grant a waiver ..." is a rather vague wording. The subclause needs stricter phrasing.

Subclause 12.2: "Registered mail" is a relic from the earlier standard. Certainly some kind of satisfactory reception verification procedures can be specified. (And Note 1 would not be necessary.)

Clause A.1: It is proposed that the enumeration of standards in the clause is replaced by "...the normative standards specified in clause 3."

Clause A.2: This clause was needed in the pre-Internet times, but its contents is now totally outdated. It seems that the clause should specify instead, in general terms, how the register shall be made accessible through Internet.

Clause A.3: Like the register itself, the RA's "Practices of the Registration Authority" should be available through Internet. And the term "explanatory" should be removed, since the document will in practice be normative.

Subclause B.1.1: PDF is indeed the natural format at present, but it seems it should not be mentioned in the standard; the formats for documents is in general decided by JTC 1.

Subclause B.1.1.1: Suggested last paragraph: "Where applicable, the formal standard(s) and/or other sources (like MIME, EDIFACT etc.) for the character set proposed shall be mentioned in the short description or under 'origin'."

Subclause B.1.1.3.2: Suggested text: "Unused positions shall be indicated by the text (This position shall not be used)"

Subclause B.1.1.3.3: Suggested text for the subclause: "Combining characters shall be identified as such, following the character name, by the text (Combining character)". (Since "combining character" is defined in clause 4 there is no need to reference 2022).

Subclause B.1.4: This text is difficult to interpret, and highlights some lack of consistency in the whole registration framework - see technical comment above.

Subclause B.1.5: The text will need modification dependent on the text of 7.3; see comment above. It should also be noted that "a complete coding system" could contain both control and graphic characters; a Note on this may be useful.

Subclause B.1.6 fourth bullet: The meaning of the text is not clear.

Subclause B.1.6 fifth bullet: Suggested change: "any definitions of ..."

Subclause B.1.6 sixth bullet: "Non-spacing characters" should be removed; such characters are covered by the 2022 combining character definition.

Subclause B.1.7: It is proposed that the text following "... obtained by combining the characters of the set" is removed.

Subclause B.3: This subclause duplicates part of clause 9, and should be shortened.

Subclause B.5: The contents of this subclause is mainly additional information to

11 clause 12. B.5.2 should be integrated in clause 12.

Subclause B.5.2 second bullet: Change to "...whether or not a character set..."

Subclause B.5.2 fourth bullet: Add a Note stating that in such cases the name shall be explicitly acknowledged in a suitable way in the Origin field (e.g. "XYZ is a trademark of XYZ Corporation, and is registered in some jurisdictions").

Subclause B.5.3: This subclause duplicates the Note to 6.2.2, and should be removed.

Clause B.6: The Note should be rewritten. Registrations intended for 8-bit coding schemes, in particular those for 8859, normally cover only parts of the respective standards (G0 or G1 set). The proper reference to a registration is therefore always the ISO-IR one, although an explanatory information can also be given, e.g. "ISO-IR 199 (G1 set of ISO/IEC 8859-14)".

Clause C.5: Suggested change of wording: "...shall include a complete definition ... used, and also justification ..."

Annex D: The title should be "The Registration Authority's Joint Advisory Committee (RA-JAC)".

Subclause D.3.1: Change to "... clause 8".

Subclause D.3.4: This text, slightly modified, should belong in clause 8 (or possibly clause 7).

Subclause D.3.5: The RA-JAC, being an advisory committee, can hardly "require" a Sponsoring Authority to change its proposal.

Annex E: Pages E.1, E.2 and E.3 should be complemented by a Note explaining the shading of the tables, e.g. "The shaded positions correspond to codings reserved in ISO/IEC 2022 for control characters. For registration of character sets not conforming to that standard the shading need not be included."

12 Attachment 8 – USA 1999-Dec-23

US Comments on ISO/IEC CD 2375: 1999-11-05 (SC2 N3390)

The US votes against the adoption of ISO/IEC CD 2375 because it fails to satisfy five US requirements. If these requirements are accommodated, the US will change its vote to approval.

The US is willing to provide assistance to the editor with revising CD 2375.

In this paper, the following abbreviations are used: · SA – Sponsoring Authority · RA – Registration Authority · JAC – Joint Advisory Committee

US Requirements for CD 2375

1. The Standard Must Uphold the Rights of Interested Parties

The registration must not violate the rights of parties with an interest in a coded character set proposed for registration:

· The Sponsoring Authority shall obtain permission from the developer or publisher of a coded character set to apply for registration of that set or to update an existing registration. This requirement does not apply if the SA is a National Standards Body proposing the registration of one of its national standards. This requirement is waived if the developer or publisher no longer exists and has no successor organization.

· If a character set proposed for registration is intended to be a coded character set for a particular application, the Sponsoring Authority shall obtain the endorsement of the developer of that application.

· The RA cannot reproduce copyrighted material in the 2375 registry without permission of the owner of the copyright. If the proposed registration is for a coded character set for which ISO is the copyright owner, then no copyright release is required. For all other cases, including when the SA is the owner of the copyright, the registration request shall include permission for ISO to reproduce the copyrighted materials in the 2375 Registry.

· The SA for an existing registration is responsible for deciding whether or not to add a mapping to the registration and for providing that mapping. A mapping for an existing registration may be proposed by the original SA or another organization. If the mapping sponsor is not the original SA for the registration, the mapping sponsor shall obtain permission from the original SA and the developer or publisher of the original coded character set.

Rationale:

A SA must not initiate registration of a coded character set without the knowledge and permission of the organization most concerned with use of that set. Here is an example of this:

13 · Michael Everson cleared the Irish (NSAI) application for registration of the US ANSEL character set (ANSI/NISO Z39.47) with Pat Harris, Executive Director of NISO.

Similarly, a SA must not propose a mapping for an existing registration without the knowledge and permission of the organizations most concerned with use of that set, namely the original SA for the registration and the developer or publisher of the original coded character set.

Microsoft and Apple consider the code pages developed for use with their respective products to be proprietary. They both strenuously oppose use of the registration process to provide an unauthorized source of coded character sets for use with their respective products.

· Registration No. 210, Sami complete 8-bit graphic character set no. 1, was intended for use “primarily in Windows applications.” Microsoft (as a member company of the US NCITS/L2) opposed the registration. · Registration No. 211, Sami complete 8-bit graphic character set no. 2, was intended “primarily for Macintosh-compatible computers.” Apple (as a member company of the US NCITS/L2) opposed the registration.

The RA now requires submission of "reference material". Making such documentation available worldwide via the RA's WWW site introduces the copyright issue. Therefore, ISO/IEC 2375 must obtain copyright permission from the copyright owner if the RA is to reproduce the character set in its database. If the SA fails to provide copyright clearance, then the RA cannot register a coded character set.

2. Registration Is Not a Fast Path to Standardization

The standard must emphasize that registration is not a fast path to ISO standardization. The body of the standard should explicitly state this to emphasize the importance of this principle. The US suggests adding the following text.

[start of text] Organizations that wish ISO to create an international standard for a coded character set or that wish ISO to code additional characters into ISO/IEC 10646 shall follow the ISO procedures for doing so. In particular,

· Registration of a coded character set according to the procedures specified by this standard implies no commitment by ISO to adopt the coded character set as an ISO standard.

· The existence of a character in an approved registration does not imply a commitment by ISO to encode that character into ISO/IEC 10646. [end of text]

Rationale:

CD 2375 states in the Introduction: "Registration provides a standardized identifier for a coded character set but it should not be regarded as [a] procedure to standardize a coded character set — it is not a standardization procedure." ISO/IEC 2375 needs to emphasize this point more forcefully in the main body of the standard and not merely in the Introduction.

CD 2375 does not address the issue of using registration to justify the addition of "characters" that do not otherwise conform to WG2 requirements for additions to ISO/IEC 10646. WG 2 has stated its requirements for adding characters to ISO/IEC 10646. Sponsoring Authorities should be aware that having a coded character set registered in the ISO/IEC 2375 registry provides no justification for adding characters from this set to ISO/IEC 10646.

3. Mapping Requirements Need Additional Specifications

14 Requirements for mapping are inadequately specified. In particular:

· The procedures do not address the situation where the supplier of the mapping and the experts reviewing the mapping reach an impasse. Although, such an occurrence should be rare, the standard must provide for such an eventuality. · Implementers need a soft-copy of the table for implementation. · Users of the mapping for a registration need to be made aware of any controversial or alternate mappings. · The space provided (one cell) for a mapping on the form assumes that where a 10646 mapping exists, it is always a single character; however, some conversions may require the use of combining sequences.

Discussion:

The Japanese NB wrote: "As far as Japan understand is that the ownership of character shape (in print), character name and mapping to UCS are with Sponsoring Authority." The Japanese NB position conflicts with an earlier US recommendation that mapping be reviewed by qualified experts to ensure that the proposed mapping is reasonable: "If mapping is done by people who lack the appropriate expertise, the result can be mappings with erroneous and[/or] contentious content, as evidenced by many of the proposed registrations being reviewed." The US feels that ultimate "ownership" of the mapping in a registration lies with the owner of the 2375 standard (SC 2) and that 2375 needs to include a review process to ensure that a proposed mapping is at least reasonable. The review process is intended to protect the developers who use the registrations by preventing "incorrect" character mappings and by identifying character mappings with alternatives. Presumably, if the review process identifies real errors, the SA will agree to correct them and resubmit a corrected proposal. More likely, some characters will have alternative mappings. The US believes that, as the owner of the 2375 registry, SC 2 through the RA and the JAC has an obligation to make those alternatives known in the registration, even over the possible objections of the SA.

The US proposes that any disagreements between the SA and the JAC be resolved by (a) retaining the mapping preferred by the SA, and (b) identifying the controversy and documenting the alternative mappings in the registration. This solution ensures that the SA controls its submission for the registration (character shapes, character names, and its preferred mapping), but also ensures that the registration identifies problematic mappings to developers. Here is an example of a procedure to do this : If the JAC identifies a concern with the mapping, it would contact the SA (via the RA) with a proposed change so that the SA can decided whether to update the proposed registration or not. If the SA decides not to change the proposal and the JAC still disagrees with the SA on the mapping, the JAC would then document the controversy and the alternate mappings for addition to the proposed registration.

The US proposes that if registration includes the optional mapping to ISO/IEC 10646, that a machine- readable (soft-copy) of the mapping be required for the registration. For each implementer to recreate the mapping table from a printed document is a waste of time and subject to human errors. It makes sense for the SA to do this once and for it to be included in the registration materials. The standard must document the format for this optional material.

The US proposes that the standard specify how alternate mappings for a particular character are to be documented in the mapping accompanying the proposed registration. For example, should the alternative be included immediately with the mapping for a particular character, or should all of the alternate mappings be included under a separate subheading of the mapping portion of the registration? (In cases where the SA and the JAC disagree, it may be easier to document any alternatives in a separate subsection.)

15 The US proposes that the concept of character mapping in a 2375 registration be extended to include the possibility of mapping one character in a source coded character set into a multiple character, combining sequence in ISO/IEC 10646. However, when both a single character and a combining- sequence mapping exist for a character in the proposed registration, the registration should list the single character mapping rather than the mapping to the combining sequence.

4. RA Principles Accepted by SC 2 Must Be Included in the Standard

· CD 2375 does not include the exception that "reference material" is not needed when an ISO or ISO/IEC standard is being registered. This was principle 2.a. articulated by the RA (Registration Authority) in SC2 N 3381. The Japanese NB reemphasized this point at the draft review stage (SC2 WG3 N430). The US believes that this principle is reasonable and that it should be included in 2375.

· The standard should continue to reflect RA principle 2.b., Character shapes and character names of the "ORIGIN" should not be changed. The US believes that it may be confusing to the users if a registration were to have a different set of names from the names in the original document specifying the coded character set.

5. The SA Must Be Responsible for Providing the Optional Mapping into ISO/IEC 10646.

The RA-JAC is a committee of volunteers who should not be held responsible for creating a mapping into ISO/IEC 10646 for the SA. Although the SA may ask the RA-JAC for assistance with the mapping table, the RA-JAC must not be responsible for creating the entire table unless the RA-JAC agrees to do so.

Additional US Comments

1. Users of the 2375 Registry Need an Index Ordered by Escape Sequences into the Registrations

Users of the standard should not need to read every registration to find the one that corresponds to a particular ISO/IEC 2022 escape sequence. The US therefore recommends that (a) the RA add an index to the registrations by ISO/IEC 2022 escape sequences, and (b) the standard reflect this need in the description of the registry.

2. Correct Sentence in Clause C.4

The last sentence of Clause C.4 reverses the intent of Annex C. The sentence should read, "Any candidate for such allocation shall first be submitted to this subcommittee as the Sponsoring Authority for escape Fs (ESC Fs) sequences." rather than ending in "… as the Sponsoring Authority for escape sequences other than ESC Fs.", which reverses the intent of the statement in the context of Annex C.

3. Simplify Annex E

Annex E could be simplified by defining the minimal requirements and then using the illustrations as examples rather than having them specify the precise format for the code tables.

The SA should not be required to redraw the code table to precisely the format of the examples of Annex E provided the code table meets minimal requirements for format, organization, and legibility. The minimal requirement is that the information be arranged in a table where the indices and the shape of the characters are clearly legible. ISO also uses the convention that the columns represent the high- order digit of the code position and the rows represent the low-order digit of the code position. The code table should use either decimal or hexadecimal digits, or both, as labels for the rows and

16 columns. Specifying the column and row indices in binary should not be a requirement. Here is some suggested text for Annex E.

[start of text] The minimum requirement for the code table is for the character shapes to be arranged in the cells of a table where the high-order digit, or digits, index the columns and the low-order digit indexes the rows. The column and row indices, and the character shapes in the table shall be of sufficient size and print quality so that they are clearly distinguishable. Code tables shall be arranged as follows:

· 32 control characters (2 columns by 16 rows)

· 95 or 96 graphic characters (6 columns by 16 rows),

· 191 or 192 graphic characters (embedded in 16 columns by 16 rows)

· 256 graphic characters (16 columns by 16 rows)

The row and column indices shall be labeled in decimal or hexadecimal digits, or both. A code table for the registration may optionally display the column and row indices in binary. [end of text]

If the editor decides not to accept the above comment, then the revised Annex E need to include the template for a 16 × 16 table for multi-byte coded character sets.

4. Addition to Annex H

Annex H (which lists the principal differences from the previous edition) needs to note that this edition adds the option of including a mapping to ISO/IEC 10646 in registrations. Even if it is optional, this is a major change to the content of the registry, and it needs to be noted as such in this Annex.

5. Potential Conflict of Interest

If a member of the JAC also represents the SA, should this member be required to abstain on votes on proposals from his or her SA?

6. Usability of the Standard

The standard would be easier to use if parts were relocated to group discussions of similar topics together. The Annex of this document has comments on how the CD might be reorganized to improve usability.

17 Annex to US Comments on ISO/IEC CD 2375: 1999-11-05 One Possible Way to Reorganize the Structure of CD 2375

Current Contents

Foreword Introduction 1. Scope 2. Field of application 3. Normative references 4. Definitions 5. Registration Authority 6. Sponsoring Authorities 7. Registration procedure 8. Review procedure 9. Withdrawal procedure 10. Correction procedure 11. Revision procedure 12. Appeal procedure Annex A: Registration Authority Annex B: International Register Annex C: Criteria for the allocation of ESC Fs sequences Annex D: The Registration Authority’s Joint Advisory Committee (RA-JAC) Annex E: Layout of code tables Annex F: Flowchart showing the registration process Annex G: Example registration Annex H: Principal differences in editions

Proposed Organizational Topics

The proposed reorganization moves the exiting content of CD 2375 into the following broad topics.

1. Fundamentals 2. Interested Parties 3. Registration Procedures 4. Modifications To Approved Registrations 5. Specifications For Component Parts Of Application For Registration

Note to the Editor : The headings in all caps in the following outline are not intended to be headings in 2375, but are merely provided as a guide so we can see the high-level structure and be sure that (a) related things are discussed together, and (b) the standard follows a top-to-bottom sequence of information.

FUNDAMENTALS

Foreword

Introduction

1. Scope OK

2. Field of application

18 Add Clause 5.3

3. Normative references Add Amendments to ISO/IEC 10646 citation or substitute citation to 2nd edition.

4. Terminology Add: coded character set

5. Identification of Registration Clause B.6

INTERESTED PARTIES

6. ISO Supervisory Body Proposed text: The ISO/IEC JTC1 subcommittee concerned with coded character sets has administrative responsibility for this standard.

7. Registration Authority 7.1. Role Clause 5.2 Needs a parallel clause to cover the mapping tables 7.2. Authorization Clause 5.1 and A.1 7.3. Functions Muddled up with registration procedure A.2 is obsolete A.3 may be superseded by this revision

8. Owner of Origin The Owner of Origin is the organization or individual responsible for the development of a coded character set. The Owner of Origin has ultimate authority over the content of its character sets. (Clause 6.5, modified) ***Comment to the Editor “Origin” reflects RA usage in ISO/IEC JTC1 SC2 N 3381 ***

9. Copyright Owner The Copyright Owner is the organization or individual that owns the copyright for a publication that specifies a coded character set.

10. Registration Sponsor ("Sponsoring Authority") 10.1. Identity Clause 6.1 10.2. Functions In this order: 6.2, 6.2.1, 6.2.2, 6.2.3, 6.3, 6.4, 6.2.4 10.3. Obligations 10.3.1. Copyright Clearance The Registration Sponsor shall obtain copyright permission from the Copyright Owner so that the Registration Authority may reproduce the publication that specifies the coded character set in the International Register if the application for registration is approved. If the Copyright Owner no longer exists and has no successor organization, this requirement is waived. 10.3.2. Clearances by Application Developer If a character set proposed for registration is intended to be a code page for a particular application, the Registration Sponsor shall obtain the endorsement of the developer of that application to register the coded character set.

19 11. Joint Advisory Committee 11.1. Identity Clauses D.2 11.2. Appointment Clause D.1 11.3. Functions Clauses 8.1, 8.3, 8.4. (8.2 is redundant), D.3.1, D.3.2, D.3.3, Need to add prohibition against the JAC creating mappings to 10646 if not part of application unless requested by the SA. Although the JAC.intends not to do this, including an explicit prohibition responds to a concern of the Japanese NB.

REGISTRATION PROCEDURES

12. Application Procedures 12.1. Application agent The Registration Sponsor submits an application for registration of a coded character set to the Registration Authority. 12.2. Component parts of application The application for registration shall consist of the first item and the other items as required: a) cover sheet b) the coded character set to be registered as originally published (showing original shapes of characters and original character names) c) permissions and endorsement (as specified in new Clause 10.3) d) optionally, a proposed mapping of the characters in the proposed coded character set to equivalent characters in ISO/IEC 10646-1:2000. Specifications for each part are given in Clauses XX – XX. 12.2.1. Requirements for component parts The SA shall submit the cover sheet for all applications for registration. The coded character set as originally published is not required when the application is for registration of an ISO or ISO/IEC standard. Clause B.1.5, first paragraph. A copy of the coded character set is required in all other cases. Clearances as specified in Clause 10.3 shall be submitted if applicable. If the application is for registration of an ISO or ISO/IEC standard, Clause 10.3.1 is waived and Clause 10.3.2 does not apply. The proposed mapping to ISO/IEC 10646 characters is optional. It is strongly recommended that the SA include the mapping.

13. Review Procedures 13.1. Review by Registration Authority Clauses 7.1, 7.3 (7.2 is redundant) Is the RA supposed to review proposed mappings initially? Perhaps to verify that they conform to formatting and other requirements? (If non-conformant, the proposal is returned to Sponsor just as cover sheet, etc.) 13.1.1. Similar Sets 13.1.1.1. Identical Sets Clause B.1.6 13.1.1.2. Multiple registrations Clause B.4.1 13.1.2. Outcome of review by Registration Authority 7.5 (in part) if application ok. 7.4 if application not ok. 13.2. Review by Joint Advisory Committee Clauses 8.1, 8.3, 8.4 without notes, 8.5 without note. (Note D.3.1 refers to Clause 7 – error?) 13.2.1. Outcome of review by Joint Advisory Committee 7.5 (in part) if mapping ok. No provision for resolution of disagreement. 13.3. External review Clause 7.5 (in part)

20 13.3.1. Outcome of external review Clause 7.6 (Is the JAC consulted by the RA about external comments?)

14. Appeal Procedures 14.1. Against registration Clause 12.1.1, second half 14.2. Against rejection of application Clause 12.1.1, first half 14.2.1. Valid Grounds Clauses 12.1.2, B.4.2, B.5 (non-grounds) 14.3. Against changes to proposed mappings Is this clause needed? US position is that instead of an appeals procedure, disagreements shall be recorded as part of the mapping. 14.4. Procedures for filing an appeal Clause 12.2, but specify registered mail and fax as alternatives to e-mail. 14.5. Resolution of an appeal Clause 12.3, D.3.4, D.3.5 (reference to 10.3 should be to 12.3)

15. Processing of approved application 15.1. Assignment of meaning Clauses 7.7, 7.8, B.2 15.2. Approval of proposed mapping Proposed text: The Registration Authority shall make the approved mapping for a registration available in machine-readable form. 15.3. Relationship to existing registrations Clause B.1.4

MODIFICATIONS TO APPROVED REGISTRATIONS

16. Corrections Clause 10

17. Revisions Clause 11

18. Withdrawal Combine Clauses 9 and B.3

SPECIFICATIONS FOR COMPONENT PARTS OF APPLICATION FOR REGISTRATION

19. Cover page (Make this in to a new Annex, which is normative) Clause B.1.1.1 If there is a specific form and layout, it should be reproduced in an Annex to the standard.

20. Coded character set 20.1. Repertoire Clause B.1.7 20.2. Code tables Clause B.1.1.2 20.3. Character names Clauses B.1.1.3.1, B.1.1.3.2 20.4. Other information Clauses B.1.1.3.3, B.1.1.3.4, B.1.2, B.1.3

21. Clearances (Permissions)

21 As specified in Clause 10.3 Obligations.

22. Proposed Mapping Shall be in machine-readable form. Details regarding data elements and structure in Annex “E-plus” (this new Annex should be positioned immediately after Annex E. Contents to be specified). Printed form of the data is optional.

Annex A: Registration Authority Incorporated into body of standard

Annex B: International Register Leave the form of IR up to the RA. Parts that apply to the application belong in specification of application documents

Annex C: Criteria for the allocation of ESC Fs sequences OK except for C.4 which repeats the NOTE to Clause 6.1 and the last sentence should be corrected to read, "Any candidate for such allocation shall first be submitted to this subcommittee as the Sponsoring Authority for escape Fs (ESC Fs) sequences."

Annex D: The Registration Authority’s Joint Advisory Committee (RA-JAC) Incorporated into body of standard

Annex E: Layout of code tables Needs to be extended to cover multi-byte sets, or simplified to simply describe the required data elements.

Annex F: Flowchart showing the registration process Split into two parts – application for escape sequence and mapping

Annex G: Example registration OK We had considered giving a pointer to the registry on the WWW. However, if you add a pointer to the web site and the RA changes, the standard may need to be updated to point to a different URL. Do we point people to the ISO/IEC JTC 1/SC 2 web page to find the pointer to the 2375 Registry?

Annex H: Principal differences in editions Need to note that this edition adds the option of including a mapping to ISO/IEC 10646.

22