SC22/WG20 N1011

From: Matthew Deane [mailto:[email protected]]
Sent: Monday, February 10, 2003 9:49 AM
Subject: (SC22docs.1878) SC 22 N 3541 - Summary of Voting on SC 22 N 3523, Text for Second CD Ballot, ISO/IEC CD 15897 - Procedure for the Registration of Cultural Elements

ISO/IEC JTC 1/SC22
Programming languages, their environments and system software interfaces
Secretariat: U.S.A. (ANSI)

ISO/IEC JTC 1/SC22 N3541

TITLE:
Summary of Voting on SC 22 N 3523, Text for Second CD Ballot, ISO/IEC CD 15897 - Procedure for the Registration of Cultural Elements

DATE ASSIGNED:
2003-02-10

SOURCE:
SC 22 Secretariat

BACKWARD POINTER:
N/A

DOCUMENT TYPE:
Summary of Voting

PROJECT NUMBER:
1.22.15897

STATUS:
The results of this ballot are forwarded to SC 22/WG 20 for review and appropriate action.

ACTION IDENTIFIER:
ACT

DUE DATE:
N/A

DISTRIBUTION:
Text

CROSS REFERENCE:
SC 22 N3523

DISTRIBUTION FORM:
Def

Matt Deane
ANSI
25 West 43rd Street
New York, NY 10036
Telephone: (212) 642-4992
Fax:             (212) 840-2298
Email: [email protected]
_____end of cover page, beginning of document______________
SUMMARY OF VOTING ON
Letter Ballot Reference No: SC22 N3523
Circulated by:                JTC 1/SC22
Circulation Date:            2002-11-08
Closing Date:                 2003-02-08

SUBJECT: Summary of Voting on SC 22 N 3523, Text for Second CD Ballot, ISO/IEC CD 15897 - Procedure for the Registration of Cultural Elements
----------------------------------------------------------------------
The following responses have been received on the subject of approval:
"P" Members supporting this appointment
6 (China, Czech Republic, Denmark, Republic of Korea, Norway, Switzerland)
P" Members supporting this appointment, with comments
1 (Germany)
"P" Members not supporting this appointment
4 (Japan, Netherlands, UK, USA)
"P" Members abstaining
2 (Austria, France)
"P" Members not voting
11 (Belgium, Brazil, Canada, Egypt, Finland, Ireland, DPR of Korea, Romania, Russian Federation, Slovenia, Ukraine)
Note: O-member Sweden voted to approve
___________ end of summary, beginning on NB comments _____________
Germany

editorial comments:

9.2.8

"but need not refer" --> "may refer"

Annex D.2

Check the printing

Technical comments:

Introduction:

Add "XML" after SGML in the introduction and passim (of course, XML is
implied by SGML, but better be explicit)

4.4 text-file

"A file" --> "A human-readable file" (or similar)

5.5 "No modification..."

Allow versioned registrations / updates to existing registrations,
provided all older versions are still accessible and can be uniquely
identified (to a degree, this possibility is implied by Annex A, point
14)

7.3 Identity

Create and quote a URL for registrations in Russian

9.3.7, point 9

Add note on registratiosn for the European Union (EU)

9.4 "contents of a narrative cultural specification"

General:

The list of optional clauses is fairly arbitrary. However, all such
lists are more or less arbitrary, so no change is required at this point
beyond a note that should point out that the list of optional clauses
may be open to additions in the future.

Clause 1:

"Multilingual Sorting" --> "Multilingual Ordering"

The text should refer to ENV 13710 (as it stands, it suggests that
there may be a European Standard in the future, but that it does not
exist already)

Clause 16:

For curiosity: In which culture are family names capitalized
throughout?

Annex A:

The statement on copyright here conflicts with 9.3.6. Please clarifiy
(what is really needed is not a faiver of copyright but a license to use
the registrations without charge)

Japan

There are no market needs for this registration.

Netherlands

GENERAL

1 - ISO/IEC 15897 should be a self-contained standard as much as
possible. That means that references to Posix and to 14651 should be
reduced to a minimum, and where necessary, definitions and explanations
should be added, even if this implies copying lines from Posix or
14651.

2 - The reference to CEN TC304 (see clause 8.1) should be removed.

SPECIFIC

We do not have the means to deal with every clause, but we restrict
our comments to 9.4. The central question here is: Does this answer
what industry wants to know?

Clause 1-6:
Expand the text to explain what is really asked for. For example,
several readers told us that they had no idea what "deterministic
ordering" means. Also, a more logical sequence of clauses would
facilitate answering a questionnaire.

Clause 1:
This requires knowledge of the national alphabet, which is only made
available in clause 9. Thus put this clause first.
The question of ordering is repeated in clause 10. Why? What is the
difference? Are there two possible approaches of ordering?
Which of the two produces "culturally expected results"?

Clause 7:
This presupposes that such a thing exists. What if it does not?

Clause 9:
This question is worded in such a way that it may be interpreted by
readers quite differently, with as effect that answers are no longer
comparable, to the distress of industry.

Clause 10:
See above.

We may continue this way, but the most significant improvement to
9.4 would be that the questions should no longer put riddles to the
reader, which he cannot solve. A questionnaire in the present style
will
motivate very few people to give honest and true answers.

United Kingdom
The WG20 meeting in Tromso agreed that an alignment with the registration procedures in 2375 should be made; this has only be partially carried through, leaving a procedure which is far from adequate. In particular it is not acceptable that a registered set of cultural conventions should only be checked for conformance to some
format, we need to recognise that a set of cultural conventions could be transnational and need to be agreed by several national bodies through some appropriate procedure.

USA

Subject: US Comments on CD2 Text for the Revision of ISO/IEC 15897
From: US National Body
Date: 2003-01-29

References (SC 22/WG 20 documents):
N 893, Summary of voting on CD registration and CD ballot for ISO/IEC CD 15897. - Registration of cultural elements
N 957, Disposition of comments on CD of 15897
N 987, Information technology - Procedures for registration of cultural elements (ISO/IEC CD2 15987:2002(E))

Notation:
A substantial number of the US comments on the first CD were not accepted, for reasons that the US does not agree with. In addition, other US comments that were accepted (either in actuality or in principle) have not been adequately incorporated into the text of N 987. If text from an earlier comment is quoted, the original number of the comment (as it appeared in N 893 or N 957) is shown, with the prefix "CD1" to distinguish it from comments on the second CD.

Organization:
US comments consist of:

·       general comments on technical issues and on editorial issues;
·       technical comments on specific clauses; and,
·       editorial comments on specific clauses

supplemented by four appendices.
Numbering of US comments on the second CD is continuous (including the appendices).

GENERAL COMMENTS ON TECHNICAL ISSUES

General Comment #1 - Technical issue: On use of TR 14652
As specified in Annex E of the JTC 1 Procedures (<http://www.jtc1.org/directives/main.htm>]), registration requires two standards:

· a technical standard ("The standard containing the definition of the classes of objects requiring registration"), and

· the procedure standard ("The standard containing the specific procedures for the JTC 1 Registration Authority to follow")

[Quotations are from Annex E.] ISO/IEC 15897 is the procedure standard.
For a POSIX Locale or definition of a POSIX category, the applicable technical standard is ISO/IEC 9945:2002. In other clauses, this CD2 references TR 14652.

TR 14652 is being published as a Type 1 Technical Report rather than as an International Standard because consensus could not be reached on five significant topics: LC_CTYPE, LC_MONETARY, LC_TIME, LC_XLITERATE, and REPERTOIREMAP. All of the clauses dealing with these topics are marked "controversial," i.e., there are no agreed-upon specifications for these topics.

In several places, the CD2 references one of the controversial topics in TR 14652 and sometimes specifies that the controversial topic shall be used (for example, in Clause 9.3.9). Before a controversial topic can be used, the controversy must be resolved. If this is not done, the information in registrations will be unreliable, and there will be problems with interoperability.

It is unacceptable that there would be an attempt to elevate material that is specifically labeled "controversial" in TR 14562 to normative status in ISO/IEC 15897 by specifying its use. Instead, ISO/IEC 15897 must forbid use of any of the clauses in TR 14652 that are identified as "controversial".

In comments on the "Scope" clause (which is normative), the US has supplied new text to ensure that this fundamental requirement is met.

General Comment #2 - Technical issue: On specification of procedures
The US commented on CD1 clause 4 (now clause 7 in the CD2) as follows;

CD1 OBJECTION #10
Section: 4 REGISTRATION AUTHORITY
Problem and Action:
It is vital that cultural specifications be reviewed by those who represent varying viewpoints. Existing cultural specifications registered under ISO/IEC 15897 have often been written by the editor of this IS, and often accepted into the registry by the same person. This is a serious conflict of interest. The rules of the registry must be written such that a person who writes or proposes a cultural specification is not also the person who decides whether it is accepted. Further, the registration authority must be made up of representatives from different geographic areas and representing different interests (for example, industry, standards committees, government agencies). Although DKUUG is to be congratulated for volunteering to be the Registration Authority, a group with more varied backgrounds and expertise must take on this task for the registry to be successful.

The Editor responded in the DoC (N 957):

10. Accepted in principle. The proposed RAC will address this problem, as well as the N 945R contribution, which will be taken into account when writing the next draft.

The clauses in N 945R describing the procedures in detail have not been incorporated into the CD2. (See also specific technical comments between US comments on clauses 9 and 10.) The US is concerned about the lack of detailed information on procedures for the reasons given above.

JTC 1 Procedures (Annex E, Clause E2.6) require:

The procedure standard shall define the process for the JTC 1 Registration Authority to review and respond to applications to ensure fairness and shall define the maximum time intervals between steps of the process.

The requirement for fairness means that it is incumbent upon the Registration Authority to evaluate an application fully. The administrative material in an application can be checked by a single person, but when it comes to the technical aspects, no one person can be expected to be able to see all the technical ramifications of information in the application. This is particularly true when the Registration Authority is unfamiliar with the culture being specified. The Joint Advisory Committee must therefore be involved in the technical evaluation of each application. This parallels ISO/IEC 2375, where the Joint Advisory Committee is charged with the technical evaluation of all mappings to ISO/IEC 10646 characters included with applications for registration.

Clause E.2.6 also states:

Where the JTC 1 Registration Authority is expected to perform a technical role in determining conformance of the object to be registered to the technical standard, this role shall be defined in the procedure standard. The response to the applicant shall include information pertaining to the results of the technical review.

There is no question that a Cultural Specification registration is a technical document (particularly those that conform to POSIX requirements). Therefore, a technical review of each new or revised application is mandatory, and the complete process must be defined in the procedure standard.

The above comments also apply to revisions or replacements of existing registrations.

GENERAL COMMENTS ON EDITORIAL ISSUES

General Comment #3 - Editorial Issue: Poor Organization
While CD2 is an improvement over CD1, many of the organizational defects of CD1 still exist. In particular, organizational changes based on ISO/IEC 2375 which appear in document N 945R have been disregarded.

Division of the normative general content of this standard (following Terms and conditions) should be in four basic parts:

·       definition of the agencies responsible for this standard and the procedures defined in it
·       definition of the contents of the cultural specification and layout of the registration documents
·       detailed description of the procedures for submission, review, and approval of an application for registration
·       appeal procedures and subsequent procedures associated with a registration.

Specific US technical comments describe the necessary changes in detail.

General Comment US#4 - Editorial Issue: Uncaught errors
From the number of spelling and grammatical errors in CD2 15897, it is appears that the Editor did not perform spell-checking and grammar-checking on the text. This is inadequate and unacceptable -- these functions are readily available in modern word-processing software (including language-specific settings). While the Editor may intend to correct such errors at the final stage (or rely on ITTF to do so), it is preferable to catch even editorial errors at an early stage of the technical work. The US considers that every stage of a standard should be as correct in spelling and grammar as possible.

General Comment US #5 - Editorial: Titles of clauses
The titles of all clauses should follow the practice used in the ISO/IEC Directives, Part 2. That is, they should be in lower case, except for the first letter and any terms that are capitalized in the text of the standard (for example, "Registration Authority").

The ISO/IEC Directives, Part 2, do not appear to have specific instructions on capitalization of the titles of clauses (the relevant clause, 5.2.2 states only: "Each clause shall have a title, placed immediately after its number, on a line separate from the text that follows it.)."

End of General Comments

SPECIFIC TECHNICAL COMMENTS

Foreword

CD2 TECHNICAL #5
The second-last paragraph of the Foreword reads:

This International Standard registers amongst other items Cultural FDCC-sets, charmaps and repertoiremaps as defined in ISO/IEC TR 14652, and POSIX Locales and POSIX Charmaps as defined in ISO/IEC 9945-2 "POSIX shell and utilities".

Delete "and repertoiremaps"
Rationale: As noted above, repertoiremaps are identified in ISO/IEC TR 14652 as "controversial." Therefore, this International Standard cannot register "repertoire maps as defined in ISO/IEC TR 14652" because there is no agreed-upon definition.

Introduction

CD2 TECHNICAL #6
First paragraph, last sentence, and Second paragraph, first sentence:
Insert "the non-controversial clauses of" before "ISO/IEC TR 14652" in both places.
Rationale: The clauses of ISO/IEC TR 14652 marked "controversial" shall not be used. Only the non-controversial clauses may be used.

CD2 TECHNICAL #7
Second paragraph, second sentence:
In CD1 Objection #4, the US recommended a number of changes, all of which were "Accepted in principle." One of these recommendations was:

Thus, the sentence should end "...will also be freely available."

The Editor added the URL for the ISO web pages, but retained the URL for DKUUG, so that the sentence now reads:

The registration will be free-of-charge and the registered cultural elements will also be freely available on the network at the address <http://www.iso.org/mara/> (and initially at <http://www.dkuug.dk/cultreg/>).

The CD2 text now implies that the "registered cultural elements" are available at both URLs. This is incorrect. The ISO "mara" URL yields a list of registration agencies, not "registered cultural elements".

To eliminate confusion, delete both URLs, so that the sentence ends "... will also be freely available." as previously recommended.

Rationale:

(a) If the URL for the English language ISO site is given, the URL for the corresponding French language site should also be given, since French has equal status with English as an official ISO language.

(b) The URLs duplicate information that is available elsewhere:

(a) Both ISO URLs are published in clause 7.3;
(b) The DKUUG URL is published on the two ISO sites.

Including them here is excessive and unnecessary detail for an Introduction.

(c) [From CD1 OBJECTION #4} While DKUUG is the initial maintainer of these cultural definitions, that could change over time, so it seems inappropriate to list the address here in the Introduction.

See also comment on clause 7.3.

1 Scope

First paragraph, middle sentence:

The cultural specifications may include freeform narrative cultural conventions specifications, POSIX Locales and Charmaps conforming to ISO/IEC 9945-2, FDCC-sets, repertoiremaps and charmaps following the recommendations of ISO/IEC TR 14652, and SGML.

Make three changes to this sentence:

CD2 TECHNICAL #8
Change "ISO/IEC 9945-2" to "ISO/IEC 9945"
Rationale: A new consolidated edition has been published.

CD2 TECHNICAL #9
Delete "repertoiremaps" and the comma and space preceding it.
Rationale: As noted above, repertoiremaps are identified in ISO/IEC TR 14652 as "controversial." Therefore, this International Standard cannot register "repertoire maps as defined in ISO/IEC TR 14652" because there is no agreed-upon definition.

CD2 TECHNICAL #10
Insert "the non-controversial clauses of" before "ISO/IEC TR 14652".
Rationale: The clauses of ISO/IEC TR 14652 marked "controversial" shall not be used. Only the non-controversial clauses may be used.

2 Field of Application

CD2 TECHNICAL #11
Delete this clause and its text.
Rationale: Essentially repeats the last paragraph of the preceding clause.
The US recommended addition of this separate clause (as in ISO/IEC FDIS 2375) but the ITTF rejected the separate clause when FDIS 2375 was submitted for publication. The US regrets that it was not better informed when it was preparing N 945 and its revision.

3 Normative references

CD2 TECHNICAL #12
N987 includes these citations:

ISO 639:1988, Code for the representation of names of languages
ISO 639-2:1988, Code for the representation of names of languages -- Part 2 Alpha-3 code.

Update these two citations as follows:

ISO 639-1:2002, Code for the representation of names of languages - Part 1: Alpha-2 code.
ISO 639-2:1998, Code for the representation of names of languages - Part 2 Alpha-3 code.

Rationale:

(a) A new edition of Part 1 was published in 2002.
(b) The date of Part 2 is incorrect. (The date was correct in the CD1.)

CD2 TECHNICAL #13
A new edition of the ISO/IEC standard for POSIX was published in 2002. This reference is outdated.

ISO/IEC 9945-2:1993, Information technology - Portable Operating System Interface (POSIX) -- Part 2: Shell and Utilities.

The US recommends inclusion of all of the parts of the 2002 edition of the ISO/IEC standard for POSIX:

ISO/IEC 9945-1:2002, Information technology -- Portable Operating System Interface (POSIX) -- Part 1: Base Definitions.
ISO/IEC 9945-2:2002, Information technology -- Portable Operating System Interface (POSIX) -- Part 2: System Interfaces.

ISO/IEC 9945-3:2002, Information technology -- Portable Operating System Interface (POSIX) -- Part 3: Shell and Utilities.

ISO/IEC 9945-4:2002, Information technology -- Portable Operating System Interface (POSIX) -- Part 4: Rationale.

Rationale:
Previously, Part 2 contained the information about character maps, locales, the POSIX locale, etc. That information now is in Part 1.

Also, the current Part 4 contains a small sample locale, but does not contain the Danish locale that was in POSIX.2:1993, Annex G.

CD2 TECHNICAL #14
All references in this standard must be up-to-date at each stage of the technical work.
Rationale: ISO mandates (in the text introducing the normative references of a standard): "For dated references, only the edition cited applies." The most current version of standards and other normative references must be cited at each stage, to avoid any oversights later. The result will be up-to-date information in cultural specifications created according to this standard.

4 Terms and definitions

4.1 locale
CD2 TECHNICAL #15
Current text:

locale
The definition of the subset of a user's information technology environment ...See clause 2.5 of the POSIX-2 standard for a specification of the locale file format.

Problem and Action:
This reference is obsolete. Update the text to refer to the Locale section in ISO/IEC 9945-1:2002.

4.3 charmap
CD2 TECHNICAL #16
Current text:
charmap
A text file describing a coded character set. See clause 2.4 of the POSIX standard for a description of the POSIX Charmap file format...

Problem and Action:
This reference is obsolete. Update the text to refer to the Character Set section in ISO/IEC 9945-1:2002.

4.6 cultural specification
CD2 TECHNICAL #17
The definition for "cultural specification" reads:

Either a Narrative Cultural Specification, a related POSIX Locale, a related FDCC-set, a POSIX Charmap, a ISO/IEC TR 14652 Charmap, a Repertoiremap, or another machineprocessable description of cultural conventions.

Insert the following text between "Repertoiremap" and the comma which follows it:
(except an ISO/IEC TR 14652 Repertoiremap)
Rationale: In ISO/IEC TR 145526, 6 REPERTOIREMAP is marked "controversial". Since there is no agreement on the specification, an ISO/IEC TR 14552 repertoiremap shall not be used.

CD2 TECHNICAL #18
Add the term "cultural element" with definition.
Rationale: This standard "sets out the procedures for registering cultural elements" but the term "cultural element" is not defined.

5.4.1 Structure of the identifier

CD2 TECHNICAL #19
The current text of this clause is:
The structure of a token identifier is given in clause 9.3.8.
The Editor needs to insert text describing the structure of the registration number immediately before the existing text. (In particular, does it have a maximum length, and is it zero padded?)

Rationale: The current text is inadequate because subclause 5.4, Identification of an approved registration, specifies two types of identifiers: "a unique registration number" and "one or more unique token identifiers." Both identifiers must be described.

7.2 Responsibilities

CD2 TECHNICAL #20
Clause 7.2.2
Add these two additional items at the end of the list:

- corrections and revisions to existing registrations (as specified in clauses <designation to be assigned>);
- withdrawal of existing registrations (as specified in clause <designation to be assigned>).

Rationale: These are essential maintenance functions.

7.3 Identity

CD2 TECHNICAL #21
Delete the note about the "initial Registration Authority", including the URL for the cultural register.
Rationale:

1) ISO's designated site for this information is its online database of maintenance agencies and registration authorities (available in both English and French). ISO set up this site with the specific purpose of avoiding the need to revise a standard whenever a Registration Authority changed.

2) Should DKUUG ever have to give up its duties as Registration Authority, this information would then be misleading and the standard would have to be revised. The whole purpose of giving the URL for the online database of maintenance agencies and registration authorities in the standard was to avoid revision.

3) By referring only to a URL instead of providing the name and address of the currently-designated Registration Authority, this standard is consistent with JTC1 recommendations on use of the World Wide Web.

7.4 Registration Procedure

CD2 TECHNICAL #22
Delete this clause.
Rationale:

(a) The US proposes two new clauses of the topic of registration procedures. (See New clauses on Registration procedures below.) These new clauses are more comprehensive and cover all the items in clause 7.4 (except the incomprehensible item i).

(b) Registration procedures involve several agencies, only one of which is the Registration Authority. Therefore, a clause describing registration procedures does not belong in the clause defining the Registration Authority.

US comments on specific aspects of the text of clause 7.4 of the CD2 appear in Appendix 1. Because item i is so unclear, the US comment on it is given below.

Item i
CD2 TECHNICAL #23
Current text

In the case of comments, to optionally receive text from commenters to be added to the registration as comments.

In CD1 Objection #14, the US commented:

This text is unclear. Who can submit comments? The Sponsoring Authority only? The original author(s)? Anyone? If comments are submitted, is the Registration Authority required to accept and include them, or can they reject some comments? If so, on what basis do they decide to accept or reject comments?

Information must be added here that explains who can submit comments, and what the Registration Authority can do with those comments.

The Editor responded in the DoC:

14. Noted. probably the SA, RA and the RAC could submit comments. N 945R will be taken into account.

N 945R has not been taken into account. Except for a grammatical correction, the text is unchanged. The Editor has failed to add information to the CD to answer the questions raised by the US in CD1 OBJECTION #14 and also in N 945R (Who are these "commenters"? Anyone who chooses to send the RA a comment? And how is such a comment evaluated for accuracy?).

With respect to the Editor's surmise in the DoC, why would the SA be supplying comments? Why would the RA be supplying comments? (The RA would be giving specific instructions to the SA, possibly based on comments from reviewers.)

Clause 7.4 Registration Procedures (d) shows that the RA receives comments and forwards them to the SA for action. Perhaps one can infer that the comments in item d are comments from the SC22 and RA-JAC reviews (described in item c). But the source and processing of the comments in item i are a total mystery.

8.1 Identity [of the Sponsoring Authority]

CD2 TECHNICAL #24
Current list of who may submit applications:

a) Any Member Body or Associated Member Body of CEN or ISO/IEC JTC1, for applications related to the territories for which they have authority;

b) CEN/TC304 for applications related to the region of Europe;
c) ISO/IEC JTC 1 and its Subcommitees and Working Groups, for any applications;

Delete this list and substitute:

a)      ISO/IEC JTC 1 and its Subcommittees and Working Groups, for any applications;
b)      CEN/TC304 for applications pertaining to Europe;
c)      Any National Body or liaison organization of ISO/IEC JTC1, for applications limited to the territory or territories for which they have authority;

d) Any Member Body or Associated Member Body of CEN for applications limited to the territory or territories for which they have authority;

Rationale:
The restructuring keeps information pertaining to ISO/IEC JTC 1 separate from information pertaining to CEN.
"National body" (not "Member body") is the preferred ISO and JTC 1 term (see, for example, clause 2.2.3 in the JTC 1 Procedures).

8.2 Responsibilities

CD2 TECHNICAL #25
Replace item a

to receive applications concerning Cultural Specifications, eg. from firms or organizations in the country, or national experts;

with the following text

to receive applications concerning Cultural Specifications from organizations, firms or experts operating in the area over which the Sponsoring Authority has jurisdiction.

Rationale: The current wording is inapplicable to CEN/TC 304, which is not responsible for a particular country.

CD2 TECHNICAL #26
New item
Insert the following text as a new item immediately before item d:

if any material in an application is under copyright, to include copyright clearance from the copyright holder in the application;

Rationale: If the Sponsoring Authority is submitting material under copyright, the SA must obtain copyright clearance for it. The SA may require the organization or individual initiating the application to provide the copyright clearance. This item replaces the clause on copyright clearance in N 945R.

Note this amplifies the requirement in clause 9.3.6

A written application shall accompany the Cultural Specification and be signed by authorized personnel on behalf of the contributing organization. It shall release copyrights of the contributed sources.

and makes it clear that the Sponsoring Authority is obligated to obtain copyright clearance for any copyrighted material that is included in the application.

# Source of information

CD2 TECHNICAL #27
Add new clause and text to be supplied by the Editor.
Rationale: There is an implied assumption that the Sponsoring Authority is also source of the information in the application. This may not always be true (see clause 8.2, item a). The two need to be distinguished.

# Copyright clearance

Dealt with in new item added to clause 8.2 that makes the Sponsoring Authority responsible for obtaining copyright clearance.

Clause 9 Rules for applications

CD2 TECHNICAL #28
The US strongly recommends that this clause be restructured as shown in Appendix 2.
Additional US comments on the text of clause 9 (below) refer to individual clauses by their CD2 numbers.

Clause 9.1 Types of cultural Specifications

CD2 TECHNICAL #29
Current text:

Type 4 is for Repertoiremaps defined in this International Standard (clause 9.3.9) and in ISO/IEC TR 14652.

Change this reference to:
Type 4 is for Repertoiremaps as defined in ISO/IEC TR 14652.
Rationale: Repertoiremaps are listed as controversial in TR 14652 and shall not be elevated to normative status in this standard.

Clause 9.2 Relations between registration types

Clause 9.2.2
CD2 TECHNICAL #30
Current text:

9.2.2. The POSIX Locale shall specify appropiate aspects of a Narrative Cultural Specification in formal POSIX syntax. The POSIX Locale shall refer to the Repertoiremap being used, and should also list a number of POSIX Charmaps that it can use.

Revise the second sentence as follows:
The POSIX Locale should list one or more POSIX Charmaps it can use.
Rationale:
Since Repertoiremaps are a controversial part of TR 14652, it is inappropriate for this standard to say that they "shall" be used, thus elevating them to normative status.

Also, while this text says one should list "a number of POSIX Charmaps", the examples in Annex G only list one each; if the examples don't even bother to list "a number," that shouldn't be the recommendation here.

Clause 9.2.5
CD2 TECHNICAL #31
Current text:

In the case of a TR 14652 FDCC-set, or other machine-parsable cultural specification, it shall specify in formal syntax some aspects of a Narrative Cultural Specification, and shall refer to a corresponding Narrative Cultural Specification. In case of a TR 14652 FDCC-set it shall refer to the Repertoiremap being used, and should also list a number of Charmaps that can be used.

Add this sentence at the end of the clause:
A TR 14652 Repertoiremap shall not be used.
Rationale: In ISO/IEC TR 145526, 6 REPERTOIREMAP is marked "controversial". Since there is no agreement on the specification, an ISO/IEC TR 14552 repertoiremap cannot be used.

Clause 9.2.6
CD2 TECHNICAL #32
Current text:

In case of a ISO/IEC TR 14652 Charmap, or other machine-parsable character set descriptions it shall specify aspects of a Narrative Cultural Specification or an FDCC-set that relate to coded character sets. In case of a Charmap it shall refer to the Repertoiremap being used, but need not refer to the FDCC-set nor the Narrative Cultural Specifications using it.

Clause 9.3 Rules for Cultural Specifications

9.3.1
CD2 TECHNICAL #33
Current text:

. . . A Narrative Cultural Specification may alternatively be submitted on white paper of the approximate size 297 * 210 mm, with margins of no less than 20 mm, or one of the approved document formats of ISO/IEC JTC 1,. . .

In CD1 OBJECTION #21, the US commented:

What is the rationale for specifying the paper size here? Unless there is a good reason, this should be removed.

The Editor responded in the DoC:

21. Not accepted. The RA has a responsibility to be able to print the registry.thus all data must fit on a paper size that the RA can handle. The RA will deliver such prints on A4, which is the common papersize for such things.

Additional comments on clause 9.3.1:

1) The reliance on paper conflicts with clause 7.11.3 Electronic Document Distribution in the JTC 1 Procedures, which states:

Document distribution within JTC 1 shall be done to the maximum extent possible using the World Wide Web. The details of this policy are contained in Annex H.

2) For the convenience of the reader, the source for the "approved document formats of ISO/IEC JTC1" should be cited. Is this Annex HA Text Area for A4 and North American Paper Sizes in the JTC 1 Procedures?

3) Why say "approximate" size, and why describe the actual paper size? Why not say "A4" paper?
4) A 20 mm margin at the bottom of the page is in conflict with Annex HA of the JTC 1 Procedures, where the minimum for the bottom margin is 28 mm. Does the stated requirement for 20 mm margins apply only to the right and left margins? The minimum margins specified in Annex HA are: Top 13 mm, Bottom 28 mm, Left 20 mm, Right 13 mm, although more generous symmetrical margins are allowed.

9.3.2.
CD2 TECHNICAL #34
In CD1 OBJECTION #22, the US commented:

Section 6.2 contains a very terse list of items that could appear in a cultural specification. The description of these very terse items appears in the informative Annex G. This makes the document extremely difficult to use. When most readers see items like "Inflection" or "Coding of national entities" with *NO* further explanation, they will have no idea what is intended. They can go to Annex G, but why is the information there instead of where it is originally referenced?

The explanation of the items allowable in a cultural spec should appear in Clause 6 along with the items themselves.

This comment was accepted by the Editor. The text of Annex G has been incorporated as 9.4, with a very minor change in the introductory paragraph. However, the intent of the US comment was to eliminate double look-up. Instead of checking Annex G, the user must now check clause 9.4. The problem persists.

Additional comments:

1) The numbered lists in clause 9.3.2 replicate the fuller information in clause 9.4. This is unnecessary. The US proposes that these lists be eliminated. We will propose substitute text to improve the organization of clauses 9.3 and 9.4.

2) The US notes that the text in Annex G was informative (as noted in Objection #22). By its incorporation into the technical content of the standard, its status has been changed to normative. This important change should have been noted in the Disposition of Comments.

Clause 9.3.2, last two paragraphs
CD2 TECHNICAL #35
Current text:

The format of the POSIX Locale and Charmap sources shall be conformant to ISO/IEC 9945-2, or for POSIX Locales the technique specified in Annex E.

The format of the Repertoiremap shall be conformant to clause 9.3.9.

Change the text to:

The format of the POSIX Locale and Charmap sources shall be conformant to ISO/IEC 9945-1:2002.
A possible format of the Repertoiremap is described in clause 9.3.9.

Rationale

(a) The reference to 9945 is obsolete.
(b) The US objects to the technique specified in Annex E; it must not be part of this standard (see CD2 TECHNICAL OBJECTION #37).

Clause 9.3.3
CD2 TECHNICAL OBJECTION #36
Current text:

The POSIX Locale shall define all standard categories (for example by copying categories of a standard POSIX Locale; examples are given in annex F). The FDCC-set shall define all standard categories (for example by copying categories of a standard "i18n" FDCC-set; examples are given in annex F).

Substitute this text for the current text:

The POSIX Locale and FDCC-set shall define all standard categories.
Individual categories may be copied from another Locale or FDCC-set. See Annex G for examples.

Rationale: Annex F contains information on the "reorder-after" construct; not examples of POSIX locales or FDCC-sets. Annex G contains sample POSIX locales, but not FDCC-sets.

Clause 9.3.4
CD2 TECHNICAL OBJECTION #37
Current text:

The coded character set of ISO/IEC 646 International Reference Version (ISO 2375 registration number 6) shall be used to represent text for the submitted files. For enhanced network portability it is recommended that only the invariant part of ISO/IEC 646 (ISO 2375 registration number 170), which contains 83 graphical characters (including space), be used...

The US objected to this during the previous ballot, and we renew our objection.
Remove the second sentence "For enhanced network portability..."
Rationale: Both the 1993 and 2002 versions of the POSIX standards allow all graphic characters in ISO 646 IRV, and there is no reason to be more restrictive in this standard. In the DoC to our previous objection, the Editor's response was:

Not accepted. This is aligned with other specs in the field.
However, it is not aligned with the standard which invented POSIX locales and charmaps. This difference is egregious and unacceptable.

The US also notes that the Editor provided no information about the "other specs in the field" which he used to justify the rejection.

CD2 TECHNICAL #38
Add this sentence at the end of the clause, following "...character names defined in a Repertoiremap shall be used."
A TR 14652 Repertoiremap shall not be used.
Rationale: In ISO/IEC TR 145526, 6 REPERTOIREMAP is marked "controversial". Since there is no agreement on the specification, an ISO/IEC TR 14552 repertoiremap cannot be used.

Clause 9.3.7, second and third paragraphs
CD2 TECHNICAL OBJECTION #39
Current text:

For Types 1, 2, and 5, Narrative Cultural Specifications, POSIX Locales, and FDCC-sets and other formal descriptions of cultural conventions: . . .

For Types 3, 4, and 6, POSIX Charmaps, Repertoiremaps, and TR 14652 Charmaps and other formal descriptions of character sets: . . .

Revise the text as follows:

For Types 1, 2, and 5, Narrative Cultural Specifications, POSIX Locales, and Machine-parsable cultural specifications: . . .

For Types 3, 4, and 6, POSIX Charmaps, Repertoiremaps, and Machine-parsable coded character set specifications: . . .

Rationale: The descriptive names of Types 1, 2, 3, and 4 here match the type names in Section 9.1, but those for Types 5 and 6 do not. They must.

Clause 9.3.7, third paragraph
CD2 TECHNICAL #40
Add this sentence as a separate line between "10. Suggested Charmap or Repertoiremap or other name" and "All applications shall contain information on these items:"

A TR 14652 Repertoiremap shall not be used.
Rationale: In ISO/IEC TR 145526, 6 REPERTOIREMAP is marked "controversial". Since there is no agreement on the specification, an ISO/IEC TR 14552 repertoiremap cannot be used.

Clause 9.3.7, third paragraph from end (begins "Note:")
CD2 TECHNICAL #41
Change "U0020..U007E" to "U+0020..U+007E"
Rationale: ISO/IEC 10646 conventions.

Clause 9.3.7, last paragraph
CD2 TECHNICAL #42
The final paragraph of clause 9.3.7 states:

Annex A specifies a form to be filled out for each Cultural Specification; Annex B gives an example of a completed form."

There is no indication that Annex A is required, although the normative attribute of Annex A suggests this. The final paragraph should be reworded as follows:

The form in Annex A shall be included as part of an application for registration of a Cultural Specification. Annex B gives an example of a completed form.

Clause 9.3.8, third and sixth paragraphs
CD2 TECHNICAL #43
"National Standardization Organization" is an undefined term. Does it mean a "National Body" (per ISO and JTC 1 terminology), or is it intended to include additional organizations that are involved with standardization?

Clause 9.3.9
CD2 TECHNICAL OBJECTION #44
Current text:

POSIX Locale, FDCC-set and Charmap sources shall be specified in a way that is independent of coded character sets, using character names. Relation between the character names and characters shall be specified via a Repertoiremap table, giving the character name and the ISO/IEC 10646 short character ID in the form of Uxxxx or Uxxxxxxxx, and optionally the long ISO/IEC 10646 character name. It is recommended to use, whenever possible, character names specified in ISO/IEC 9945-2:1993 Annex G. The character name and the ISO/IEC 10646 canonical encoding are each surrounded by angle brackets <>, and the fields shall be separated by one or more spaces or tabs on a line. If a right angle bracket or an escape character is used within a name, it shall be preceded by the escape character. The escape character can be redefined from the default reverse solidus (\) with the first line of the Repertoiremap containing the string "escape_char" followed by one or more spaces or tabs and then the escape character.

Revise the text as follows:

POSIX Locale, FDCC-set and Charmap sources can be specified in a way that is independent of coded character sets, using character names. Relation between the character names and characters can be specified via a Repertoiremap table, giving the character name and the ISO/IEC 10646 short character ID in the form of Uxxxx or Uxxxxxxxx, and optionally the long ISO/IEC 10646 character name. The character name and the ISO/IEC 10646 canonical encoding are each surrounded by angle brackets <>, and the fields are separated by one or more spaces or tabs on a line. If a right angle bracket or an escape character is used within a name, it should be preceded by the escape character.

Rationale: There are several problems with this clause:

(a) Since the previous ballot version of this section, TR 14652 has been finalized, but much of it, including the Repertoiremap section has been designated as controversial. Since WG20 did not reach agreement on the status and syntax of Repertoiremap in TR 14652, it is not acceptable to elevate it to normative status in this standard.

(b) The previous U.S. objection to referring to the character names in ISO/IEC 9945-2:1993 Annex G was rejected with this comment: "Not accepted. There is a reason, namely that you then can reuse a lot of data." Although we do not consider this a compelling rationale, this reference has become obsolete since the CD1 was balloted. ISO/IEC 9945:2002 does not contain an Annex G with the character names referenced here. In ISO/IEC 9945-4:2002 (Rationale), there is a short sample locale, but it does not use the vast majority of the names from the 1993 version of Annex G. Since POSIX no longer includes these character names, this standard cannot do so.

(c) The information about how to redefine the escape character is inappropriate. The Editor of this standard chooses not to use the default escape character that POSIX defines, and he is free to do so. But it is not appropriate in this syntax definition to tell others how to use the same non-default escape character that he has chosen.

Clause 9.4 Contents of a Narrative Cultural Specification

Introductory paragraph, first and second sentences:
CD2 TECHNICAL OBJECTION #45
Current text:

The contents of the Narrative Cultural Specification is described in some detail in the following. it builds on information from the POSIX Shell and Utilities standard (ISO/IEC 9945-2) and the Nordic Cultural Requirements on Information Technology Summary Report.

Revise the text as follows:

The contents of the Narrative Cultural Specification are described in some detail in the following clauses. The specification builds on information from the POSIX Base Definitions standard (ISO/IEC 9945-1:2002) and the Nordic Cultural Requirements on Information Technology Summary Report.

Rationale: The POSIX reference is out-of-date, there is a grammatical error, and a typo.

Introductory paragraph, third and fourth sentences:
CD2 TECHNICAL #46
In CD1 OBJECTION #44, the US proposed changing the sentence

. . Clauses 1 to 6 are related to POSIX and the narrative description should be accompanied by a corresponding POSIX Locale specification.

to
Clauses 1 through 6 are related to POSIX.
The proposed change was partially accepted; the fourth sentence was added. However, the text which the US considered inconsistent with other parts of this standard was not removed. The text now reads:

Clauses 1 to 6 are related to POSIX and the narrative description should be accompanied by a corresponding POSIX Locale specification. If a POSIX locale is submitted, it is desirable that it be accompanied by a related narrative cultural specification.

Strike these two sentences and replace them with this text.

Clauses 1 to 6 are related to POSIX. When a POSIX locale is submitted, it should be accompanied by a corresponding narrative cultural specification.

Note that "is desirable" is not needed because use of "should" is specified in Table G.2 of Annex G Verbal forms for the expression of provisions in ISO/IEC Directives, Part 2: Rules for the structure and drafting of International Standards:

The verbal forms shown in Table G.2 shall be used to indicate that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others, or that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited.

Clause 3: Numeric formatting
CD2 TECHNICAL OBJECTION #47
Current text:

Here it is described how numbers are keyed in and formatted,. . .This is a POSIX category.

Delete current text and substitute:

This clause describes how numbers are formatted, including the format of the decimal point and the thousands separator. This is a POSIX category.

Rationale:
POSIX contains no information about how numbers are "keyed in", and neither of the sample cultural narratives in this document include such info, either. If information about keying in is needed, it should be moved to Clause 20 Numbering, ordinals and measuring systems, since it isn't part of this POSIX category. (See comment on Clause 20 for proposed text addressing how numbers are "keyed in".)

Clauses 7 through 32
CD2 TECHNICAL #48
For the guidance of users, the US recommends that the word "(Optional)" be added at the end of the heading for each of these clauses. (Clause 9.3.2 indicates, by the use of "may", that clauses 7 through 32 are optional.)

Rationale: Such guidance is particularly important now that the material from CD1 Annex G has been raised to normative status.

See Appendix 3 for US technical and editorial comments on the optional (non-POSIX) clauses. Headings for the individual clauses show the modification recommended above.

New clauses on Registration procedures

CD2 TECHNICAL #49
Minimum requirements:

1) Make clause 7.4 Registration Procedure into a top-level clause and move it so that it immediately precedes clause 10 Appeal procedures.

2) Expand the text of clause 7.4 Registration Procedure to provide a complete description of registration procedures. In particular, distinguish between procedures carried out prior to approval of an application for registration and the procedures that follow approval.

3) Change its title to Registration procedures.

Rationale:

(a)     Relocating clause 7.4 brings all procedures together in successive clauses.
(b)     This is a procedural standard, so should specify procedures completely and clearly.
(c)     Title change for consistency with the title of clause 10.

Alternative preference:
The US would prefer to see the specification of the registration procedures divided into two separate top-level clauses. These clauses should immediately precede clause 10 Appeal procedures. The individual clauses are specified in the next two comments.

Rationale (in addition to items a-c above): To make the standard easier to use.

CD2 TECHNICAL #50
This comment describes the first clause preferred by the US.
Insert a new clause with the title Initial registration procedures preceding clause 10 Appeal procedures.
The following proposed text is from clause # Registration procedure in N 945R. "x" indicates the number that identifies this clause as a whole. All items in clause 7.4 Registration Procedure are covered in the proposed text, except for item i (see CD2 Technical Comment on this item above).

<begin proposed text>
x.1 The Sponsoring Authority shall prepare an application for registration according to clause 9.
x.2 The Sponsoring Authority shall submit an application for registration of a cultural specification to the Registration Authority.

x.3 The Registration Authority shall examine each application received. It shall ascertain that
- The applicant is a Sponsoring Authority as identified in clause #. The RA shall reject applications for registrations which come from sources other than the Sponsoring Authorities as defined in clause #. The Registration Authority may refer the applicant to an appropriate Sponsoring Authority if one can be identified.

- The proposed cultural specification is not identical to one already registered.
If the application fails to meet either of these requirements, the application shall be rejected.
When requested by the RA, the RA-JAC may provide an opinion on whether an application satisfies these requirements.
x.4 The Registration Authority shall also ascertain that
- The application for registration is legible and meets the presentation requirements of this international standard. See clause <XXX>.

- The application includes the elements required from the Sponsoring Authority for the cover page. See clause <XXX>.
- The application for registration includes any required copyright permissions and endorsements. See clause <XXX>.
If the application for registration fails to meet any of these requirements, the Registration Authority shall inform the Sponsoring Authority of the changes needed to meet the requirements.

x.5 The Registration Authority shall submit the application to the RA-JAC for the technical review. The RA-JAC shall ascertain that

- The application is technically in accordance with this International Standard.
- The application for registration includes the required description of the cultural specification. See clause <XXX>.
x.6 The RA-JAC shall report the results of its evaluation to the Registration Authority and shall describe any technical concerns with the proposed registration.

x.7 The Registration Authority shall inform the Sponsoring Authority of any changes needed to satisfy the concerns of the RA-JAC.

x.8 After an application for registration has passed its review by the Registration Authority and by the RA-JAC, the Registration Authority shall circulate the application to the members and liaison organizations of the subcommittee responsible for maintaining this standard for a three-month information and comment period.

x.9 The Registration Authority shall consider all comments received. The Registration Authority shall request the RA-JAC to provide expert advice on the technical comments. The Registration Authority may incorporate comments resulting from the review specified in clause <x.8> into the final registration.

x.10 The Registration Authority shall approve or reject the application for registration.
x.11 The Registration Authority shall process approved applications in accordance with clause <Y>.
x.12 When an application for registration is rejected, the Registration Authority shall inform the Sponsoring Authority and provide the reason for the rejection.

CD2 TECHNICAL #51
This comment describes the second clause preferred by the US.
Insert a new clause with the title Processing of an approved application between the new clause Initial registration procedures and clause 10 Appeal procedures.

The following proposed text is primarily from clause Y. Processing of an approved application in N 945R. "y" indicates the number that identifies this clause as a whole.

<begin proposed text>
Following approval of an application for registration, the Registration Authority shall:
y.1 Assign a new Cultural Specification identifier as follows:
- Identifiers shall be allocated in ascending order. This allocation shall only be made immediately prior to publication of the registration, that is, after completion of all procedural steps.

- No identifiers shall be reserved for future registration applications.
- An identifier, once allocated to a registration, shall never be re-allocated for another registration.
y.2 The Registration Authority may also assign one or more token identifiers to the approved registration.
- If the Cultural Specification is identical to one already registered, the new token identifiers shall be added to the existing registration, and the addition shall be noted in the version history of that registration;

y.3 The Registration Authority shall note the date of approval in the registration.
y.4 The Registration Authority shall publish the approved registration in the ISO/IEC 15893 register.
y.5 The Registration Authority shall notify the Sponsoring Authority of the publication of the registration.
y.6 The Registration Authority shall announce publication of the registration to subcommittee responsible for maintaining this standard.

10.1 Appeals against rejection

CD2 TECHNICAL OBJECTION #52
Current text:

The Registration Authority shall accept an appeal from the Sponsoring Authority against rejection of an application, but only for this reason:

- disagreement with the Registration Authority on whether the application meets the technical or administrative requirements for a registration in clause 9.

Reword as:

If the Registration Authority rejects an application, the Sponsoring Authority may appeal that rejection based only on whether the application meets the technical or administrative requirements for a registration as described in clause 9.

Rationale: Unclear text;
Note: This is a revision of what the US originally asked for. The wording in 2375 was an attempt to change the wording of the earlier edition as little as possible.

Appeals against registration

CD2 TECHNICAL #53
Clause 7.2 of the first CD addressed objection by a Member Body to forthcoming publication of a registration. There is no corresponding clause in CD2 15897.

To remedy this oversight:

1) Renumber clauses 10.2 through 10.4 as 10.3 through 10.5.
2) Insert clause 10.2 Appeals against registration with the following text and numbering:

<begin text>
10.2.1 The Registration Authority for shall accept an appeal from the subcommittee responsible for the maintenance of this International Standard when any Member Body objects to the forthcoming publication of a registration by the Registration Authority.

10.2.2 The Registration Authority shall accept appeals from the subcommittee responsible for the maintenance of this International Standard for the following reasons only:

1) disagreement with the Registration Authority on whether the application meets the technical or administrative requirements for a registration in clauses <as specified in clause 9>.

2) disagreement with the Registration Authority on whether the application matches an existing registration.
3) disagreement on the correctness of some of the information in the cultural specification of the application.

10.3 Procedure for filing an appeal

CD2 TECHNICAL #54
Make the following changes which appear in N 945R but were not included in CD2 15897:
First line: After "registered mail", insert a comma followed by this text:
facsimile, or electronic mail
Rationale: Consistent with JTC 1 recommendation in clause 7.11.2 Use of Electronic Messaging in Procedures for the technical work of ISO/IEC JTC 1).

First bullet: Change "90" to "30"
Second bullet: Change "90" to "30"
Rationale: These are the periods in ISO/IEC 2375: 200x.

10.4 Resolution of an appeal

CD2 TECHNICAL #55
Most of clause 7.5 Resolution of an appeal was incorporated into the CD2, but clause 7.5.3 (dealing with resolution of an objection by a National Body to forthcoming publication of a registration) was omitted. To correct this error:

1) Renumber clause 10.4.3 as 10.4.4
2) Insert clause 10.4.3 and the following text (from clause 7.5.3 in N 945R)

<begin text>
If four-fifths of the members of the RA-JAC consider the appeal from the subcommittee responsible for maintaining this standard to be administratively or technically justified, the Registration Authority shall disapprove the registration application. If the appeal is based on clause 10.2.2, item 3 (correctness of some of the information) and the Sponsoring Authority modifies the questionable information to the satisfaction of the appealing party and the RA-JAC, then the Registration Authority shall register the corrected cultural specification without repeating the registration process.

CD2 TECHNICAL #56
Clause 10.4.4 (= 10.4.3 in CD2 15897):
Make the following two changes to this clause:
1) Delete the following text (including the misspelling of "receipt"):
by the Registration Authority within 90 days after the reciept of an appeal
Rationale: Communication with the "P-members of the subcommittee responsible for the maintaining of this International Standard" is the responsibility of the subcommittee's Secretariat. (The Registration Authority is, of course, responsible for making arrangements with the Secretariat.)

2) Change this text:
to decide according to its voting procedures.
to
according to the Procedures for the technical work of ISO/IEC JTC 1.
Rationale: Since this is a JTC 1 standard, JTC 1 procedures apply. The same wording appears in ISO/IEC 2375:200x.
Note that the recommended wording in N 945R:"for vote according to the Directives for technical work of ISO/IEC" is taken from an earlier stage of ISO/IEC 2375:200x.

11 The Registration Authority's Joint Advisory Committee

CD2 TECHNICAL #57
Relocate this clause immediately after clause 8 Sponsoring Authority.
Rationale: Brings all agencies defined by this standard together.

Note: For the convenience of reviewers, other changes to the text of clause 11 of the CD2 are described here.

Clause 11.1

CD2 TECHNICAL #58
Make the following changes to this clause:
1) Add this title:
Membership
Rationale: For consistency with changes to clauses 11.2 and 11.3.
2) Delete the last paragraph:

The Registration Authority may request the RA-JAC to provide expert technical advice on comments.

Rationale: Does not belong in a clause specifying the composition of the RA-JAC. The responsibilities of the RA-JAC are listed in clause 11.3.

Clause 11.2

CD2 TECHNICAL #59
Add this title to clause 11.2:
Appointment
Rationale: For consistency with other clauses describing agencies (for example, 7 Registration Authority).

Clause 11.2, first paragraph
CD2 TECHNICAL #60
Current text:

The subcommitee responsible for maintaining this standard shall appoint the members of the RA-JAC, except for the RA representative, which is appointed by the RA. The subcommitee shall appoint or confirm the members of the RA-JAC at its plenary meetings.

N 945R says to delete this phrase:
except for the RA representative.
because there is no indication of who appoints the RA representative to the Joint Advisory Committee. The resulting paragraph then specifies that all members of the Joint Advisory Committee (including the individual who represents the RA) are appointed by the subcommittee responsible for maintaining this standard (i.e., by SC22).

The Editor did not delete the phrase and added a clarification, so that the corresponding text in the CD2 now reads:
except for the RA representative, which is appointed by the RA.
This new text is unacceptable to the US for the following reasons:

a) It conflicts with the provisions of the second paragraph of this clause, which clearly states that the subcommittee (i.e., SC22) determines the members of the Joint Advisory Committee:

The subcommitee shall appoint or confirm the members of the RA-JAC at its plenary meetings.

b) It conflicts with the provisions of ISO/IEC 2375:200x. It was WG20's intent to model the administrative aspects of this revision of ISO/IEC 15897 on the thoroughly reviewed text of ISO/IEC 2375:200x.

c) It is unnecessary. The wording "representative of the Registration Authority" was used in clause 11.1 to provide flexibility in case it is not possible for the person carrying out the duties of the Registration Authority to attend meetings of the Joint Advisory Committee. It is essential for the Registration Authority to be represented at these meetings. The expectation is that the person carrying out the duties of the Registration Authority would normally be chosen by the supervisory body for this standard (i.e., SC22) for appointment as the "representative of the Registration Authority".

Clause 11.2, second paragraph
CD2 TECHNICAL #61
Insert this text after "subcommittee"
responsible for maintaining this standard
to indicate explicitly which subcommittee makes the appointments.

Clause 11.3

CD2 TECHNICAL #62
Add this title to clause 11.3:
Responsibilities
Rationale: For consistency with other clauses describing agencies (for example, 7 Registration Authority).

CD2 TECHNICAL #63
Keep this introductory text "The responsibilities of the RA-JAC shall be as follows:" and substitute the following text (based on #.4 in N 945R and clauses 11.1 and 11.3 of CD2) for the remainder of the clause.

<begin text>
-       to determine whether an application for registration meets the technical requirements of clause 9;
-       to provide expert technical advice on comments if requested by the Registration Authority;
-       to consider and vote on appeals received by the Registration Authority;
-       to act as a mediator between the Registration Authority and the appealing party, or parties.
In addition, the RA-JAC may added comments to a registration.
<end text>

Additional clauses

Insert 4 new clauses before Annex A. The clauses are described separately below. They are numbered 12 - 15, since the clause 11 is the last clause in the main text of CD2.

New clause: 12 Corrections

CD2 TECHNICAL #64
Add a new clause with the title:
Corrections
and the following text (from the corresponding clause in N 945R):
<begin text>
12.1 The Registration Authority for ISO/IEC 15987 in conjunction with the Sponsoring Authority shall correct material errors to the information included in a registration, for example typographical errors, as soon as detected.

12.2 The Registration Authority shall add the date of the correction to the corrected pages, add the date and reason for the change to the cover sheet, and publish the new corrected pages of the registration.

12.3 The Registration Authority shall notify the subcommittee responsible for maintaining this standard and the Sponsoring Authority that a registration was corrected with the nature of the correction and the date.

Note that this clause conflicts with the idea expressed in clause 5.5 that a new registration is required to make a "correction", presumably even a typographic correction.

New clause: 13 Revisions

CD2 TECHNICAL #65
Add a new clause with the title:
Revisions
and the following text (from the corresponding clause in N 945R):
<begin text>
13.1 In general, no changes to the content of a registration are permitted, as this would be contrary to the principles on which the registrations are based.

13.2 When a new registration application is based on an existing registration, then the Registration Authority shall create a new registration. The Registration Authority shall also add cross-reference notes to the two registrations.

New clause: 14 Additions to an existing registration

CD2 TECHNICAL #66
Add a new clause with the title:
Additions to an existing registration
and the following text (from CD2, clause 7.4, item f):
<begin text>
When a Cultural Specification submitted for registration is identical to one already registered, the token identifier(s) for the application shall be added to the existing registration;

The Editor is requested to supply text describing the procedures to be followed in these situations:

1) A Sponsoring Authority wishes to augment an approved registration which it submitted; or
2) A Sponsoring Authority wishes to augment an approved registration which was submitted by another Sponsoring Authority.

New clause: 15 Withdrawal

CD2 TECHNICAL #67
Add a new clause with the title:
Withdrawal
and the following text (based on the corresponding clause in N 945R):
<begin text>
15.1 Withdrawal is a formal declaration by which the Sponsoring Authority informs the Registration Authority that it withdraws its support of a registration application or of all or part of an existing registration that it has sponsored.

15.2 Such a declaration may, but need not, be accompanied by a statement of the reasons for the withdrawal.
15.3 Withdrawal of an application for registration
15.3.1 When the Registration Authority is notified, it shall take no further action to process the application.
15.3.2 If the application for registration is being circulated for comment according to clause x.8 (in Initial registration procedures), the Registration Authority shall notify the members of the subcommittee that the application has been withdrawn by the Sponsoring Authority.

15.4 Withdrawal of an entire existing registration
15.4.1 After withdrawal, the registration shall remain in the register and continue to be identified by the allocated numeric identifier.

15.4.2 After the date of withdrawal, the Registration Authority shall issue a new cover page for the registration and shall note on it that the registration has been withdrawn by the Sponsoring Authority. If the Sponsoring Authority has given a reason for the withdrawal, this may be noted in the registration.

15.4.2 After the date of withdrawal, the Registration Authority shall issue a new cover page for the registration and shall note on it that the registration was withdrawn by the Sponsoring Authority and give the date of withdrawal. When the Sponsoring Authority has given a reason for a withdrawal, the reason may be noted in the registration.

15.4.3 The Registration Authority shall inform the subcommittee responsible for maintaining this standard interested parties of the withdrawal of a registration.

15.5 Withdrawal of part of an existing application
15.5.1 After withdrawal, the registration (including the withdrawn part) shall remain in the register and continue to be identified by the allocated numeric identifier.

15.5.2 After the date of withdrawal, the Registration Authority shall issue a new cover page for the registration and shall note on it the part(s) of the registration that were withdrawn by the Sponsoring Authority. The Registration Authority shall also annotate a withdrawn part to show that it was withdrawn and give the date of withdrawal. When the Sponsoring Authority has given a reason for a withdrawal, the reason may be noted in the registration.

15.4.3 The Registration Authority shall inform the subcommittee responsible for maintaining this standard interested parties of the withdrawal of a registration.

Annex A Application form for a Cultural Specification

Items 8, 9 and 10
CD2 TECHNICAL OBJECTION #68
Current text:

For Narrative Cultural Specifications, POSIX Locales or FDCC-sets and other formal descriptions of cultural conventions (type 1, 2, and 5): . . .

For POSIX Charmaps, Repertoiremaps, or TR 14652 Charmap and other formal descriptions of character sets (type 3, 4 and 6):. . .

Revise the text as follows:

For Narrative Cultural Specifications, POSIX Locales or Machine parsable cultural specifications (type 1, 2, and 5): . . .

For POSIX Charmaps, Repertoiremaps, or Machine-parsable coded character set specifications (type 3, 4 and 6):. . .

Rationale: The descriptive names of Tues 1, 2, 3, and 4 here match the type names in Section 9.1, but those for Types 5 and 6 do not. They must.

Annex C External References to Cultural Specifications

C.3 Object Descriptors
CD2 TECHNICAL OBJECTION #69
Current text:
The object descriptors for the abstract syntax object identifiers defined in 2 above shall be . . ., as assigned per clause 4 responsibility g):

Change the reference to:
...as assigned in clause 7.4, responsibility f):
Rationale: The reference is incorrect.

C.4 Transfer Syntax
CD2 TECHNICAL OBJECTION #70
Current text:

The transfer syntax as specified in ISO 8824 defines the encoding in which the contents of a registry entry might be transferred over a network. For this purpose the transfer syntaxes as defined in ISO/IEC 2022 shall be used.

Change the text as follows:

When transferring the contents of a registry entry over a network, data shall be encoded in the UTF-8 form of ISO/IEC 10646.

Rationale: Given the increasing use of ISO/IEC 10646 as a universal encoding on the network, it should be designated as the encoding to be used when transferring the contents of an entry over the network. ISO/IEC 10646-aware software is much more prevalent than ISO 8824 and ISO/IEC 2022.

Annex D Sample Narrative Cultural Specification for Danish and Irish

See Appendix 4 for comments on individual clauses in these examples.

General comments on Annex D

CD2 TECHNICAL #71
1. Confusing title
The title of this annex fails to indicate whether these "samples" of narrative cultural specifications come from the International Register or are extracts from applications for registration submitted by Sponsoring Authorities. This is an important distinction.

The US recommends that the title of this annex indicate the nature of the content of this annex.
Rationale:
Clarifies the content of the annex.
If the examples are extracts from initial applications, alerts the user to the fact that the information in the examples will be subject to further review (as described in clause 7.4) and should not be used in for implementations.

2. Defective or outdated information
CD2 TECHNICAL #72
A number of items in these examples are defective or out-of-date. The US is concerned that the publication of defective or outdated information in the examples will reflect badly upon JTC 1 and SC 22. We are also concerned that implementers might use the information in these examples for software intended for use in Danish or Irish cultural locales (see preceding related comment).

3. Concerns about status of examples
CD2 TECHNICAL #73
For the proper guidance of users of this standard, examples in this annex should be actual examples of narrative cultural specifications as submitted by a Sponsoring Authority after review and approval according to that Sponsoring Authority's procedures. It is not clear that either example meets this qualification.

Clause D.1 is entitled "Danish language locale for Denmark, Narrative Cultural Specification".
There is a published "Danish language locale for Denmark, Narrative Cultural Specification" (<http://anubis.dkuug.dk/cultreg/registrations/number/2>), but it predates ISO/IEC 15897:1999, the first edition of this standard.

Clause D.1 must therefore show the narrative cultural specification from a new application (under ISO/IEC 15897) for "Danish language locale for Denmark".

Different versions of this narrative cultural specification appear in CD1 and CD2. The CD2 version differs from the CD1 version in a number of items; for example, discussion of the Greenlandic letter "KRA" has been moved from CD1 clause 12 to CD2 clause 1. The source statements are:

In CD2 - Source: Dansk Standard, date: 2002-10-08, version: 2.5
In CD1 - Source: Dansk Standard, date: 1994-07-28, version: 2.4
It is not clear which version represents the actual narrative cultural specification submitted by Dansk Standard. (But note that the date of the CD1 version is earlier than the publication date of the first edition of this standard.)

CD2 TECHNICAL #74
Clause D.2 is entitled "Irish language locale for Ireland, Narrative Cultural Specification". It is undated. Its version number is given as "0.6 (Unofficial draft)".

The US recommends that clause D.2 be deleted until the following two conditions are met:

1) the content of the narrative cultural specification has been finalized, that is, it is no longer "draft"
2) the narrative cultural specification has been officially approved as correct for Ireland by the National Standards Authority of Ireland according to its formal procedures.

Annexes E and F

· Annex E, "reorder-after" construct in POSIX LC_COLLATE
· Annex F Information on "reorder-after" construct in LC_COLLATE)

CD2 TECHNICAL #75
Remove both Annex E and Annex F.
The US objected to these Annexes in CD1 Objections #39 and #41.

# 39: The reorder-after and reorder-end keywords are described in ISO/IEC 14651, and should not be repeated here. This annex should be removed, or rewritten simply to point to ISO/IEC 14651.

# 41: As with Annex E, the reorder-after keyword is described in ISO/IEC 14651, so information about it is not necessary in this document. This annex should be removed.

The Editor rejected both comments, stating as his reason:
These specs are also applicable to POSIX locales while 14651 specs are not.
The U.S. continues to object strongly to including these Annexes. The syntax described already exists in ISO/IEC 14651, and should not be repeated here.

If this syntax is designed to be applicable to POSIX locales, then the syntax should be in POSIX itself. It is incorrect for this standard to add normative capabilities to POSIX without the knowledge or consent of those working on ISO/IEC 9945.

There also are numerous errors in Annex E, but we are not listing them here, since we believe the entire annex must be removed. Some of the problems with the content of Annex E were described in CD1 Objection #40 (see the next comment).

Clause E.3 Example of "reorder-after"

CD2 TECHNICAL #76
This extract from N 957 gives the disposition on US Objection #40:
OBJECTION #40
Section: E.3 (Example of "reorder-after")
Current text:
". . .
<O/ <O/>;<NONE>;<CAPITAL>
<o/ <O/>;<NONE>;<SMALL>
<AA <AA>;<NONE>;<CAPITAL>
<aa <AA>;<NONE>;<SMALL>
reorder-end
. . .
2. The second "reorder-after" statement. . .initiates a second list, rearranging the order and weights for the <AE>, <ae>, <A:>, <a:>, <O/>, and <o/collating elements after the <z8collating symbol in the copied specification.

. . .
4. Thus for the original sequence
...
this example reordering gives
... Uu Vv Ww Xx ( Yy Üü ) Zz ( Ææ Ää ) Øø Åå
5. . . .
the example reordering in E.3.1 gives
... ( Uu Ùù Úú ) Vv Ww Xx ( Yy __ Üü ) ( Zz Zz )
( Ææ ?Æ?æ ¯Æ¯æ Ää ) ( Øø ?Ø?ø Öö ) ( Åå ( AA Aa aA aa ) ?Å?å )"
Problem and Action:
So much text is quoted because it is completely inconsistent. The example syntax shows <AAand <aa>, but not Å and å (<A-ringand <a-ring>). The explanation in item #2 includes neither the <AA>/<aapair, nor <A-ring/<a-ring>. The reordering in item #4 shows <A-ring/<a-ring>, but not <AA>/<aa>. The reordering in item #5 shows <AA>/<aaand <A-ring/<a-ring>.

Much of this text is wrong, but it's not clear what the author intended, so no alternative text is suggested here. Fix the text to be consistent and correct.

40. Not accepted. Text will not been changed (for now).
This is unacceptable. US Objection #40 pointed out a serious technical problem in the content of Annex E. The editor submitted CD2 15897 for ballot with no changes to the defective text, but implied (via the parenthetical "for now") that corrections might be made in the future. Any necessary changes should have been made before CD2 15897 was issued so that all P-members could review them as part of this ballot.

Annex H Differences from ISO/IEC 15897:1999 and CEN ENV 12005:1996

H.2 Changes from CEN ENV 12005:1996
CD2 TECHNICAL #77
Problem and Action:
The detailed changes listed for this standard as compared to CEN ENV 12005:1996 all include references to clause numbers from the previous draft, not this draft. For example, there is the sentence "In clause 4 the contact information for the Registration Authority has been updated", but in this CD2, clause 4 contains Terms and Definitions, and contact info is in clause 7.3. This and all other incorrect references in this section must be updated.

Bibliography

CD2 TECHNICAL #78
Current text:

2. ISO/IEC TR 14652:2001 Information technology - Specification method for cultural conventions.

Problem and Action:
This TR was not published in 2001; it has not yet been published.
ISO/IEC Directives, Part 2: Rules for the structure and drafting of International Standards specify:
For dated references, each shall be given with its year of publication, or, in the case of enquiry or final drafts, with a dash together with a footnote "To be published.", and full title.

The correct publication year needs to be inserted when if it is available.

End of Specific Technical Comments

SPECIFIC EDITORIAL COMMENTS

Foreword

CD2 EDITORIAL #79

1) Change "ISO/IEC 9945-2" to "ISO/IEC 9945-1".

Rationale: The reference to ISO/IEC 9945-2 refers to an obsolete edition.

2) Change "shell and utilities" to "Base Definitions".

Rationale: In the 2002 version of ISO/IEC 9945, POSIX locales and charmaps are covered in Part 1: Base Definitions.

Introduction

CD2 EDITORIAL #80
Second paragraph, second sentence:
Change "network" to "Internet"
Rationale: "network" is a generic term and could refer to any network. The correct term is "Internet".
JTC 1 practice appears to be to capitalize "Internet" (as in Annex HF Glossary of Terms in Procedures for the technical work of ISO/IEC JTC 1).

CD2 EDITORIAL #81
Second paragraph, second sentence
Change "eg" to "for example,"
Rationale: Better style for an introduction.
Erroneous forms of the abbreviation "e.g." occur throughout the text. They should all be corrected or changed to "for example". (Both alternatives are used in ISO and JTC 1 documentation.)

4 Terms and definitions

CD2 EDITORIAL #82
Arrangement
In N 945R, the terms were arranged in alphabetical order. Alphabetical order was not used for the Terms and definitions in CD2. The Editor explained (in e-mail) that this was not done because translations must be identical. When alphabetical order is used, there could be problems with a translation. If the order of the source was retained, some terms might be out of alphabetical order in the translation. On the other hand, if the translated terms were ordered according to the alphabetical order of the language of translation, the order of terms might be different in the source and the translation.

It is difficult to see any order in the current text, except that locale is superior to all other terms.
The specific requirement in the ISO/IEC Directives, Part 2 is:
4.5 Equivalence of official language versions
The texts in the different official language versions shall be technically equivalent and structurally identical. The use of bilingualism from the initial stage of drafting is of great assistance in the preparation of clear and unambiguous texts.

There is no stated requirement for the order of the Terms and definitions clause in a document. The order of an independent terminology standard "should be preferably classified." (clause 6.2.1). However, this clause continues:

Lists of equivalent terms in different languages may be presented either in systematic order as indicated above (in which case alphabetical indexes shall be given for each of the languages), or in alphabetical order of the terms in the first of the languages used (in which case alphabetical indexes shall be given for each of the other languages).

Note that in Annex E: Registration Definitions and Guidelines for Procedure Standards in Procedures for the technical work of ISO/IEC JTC 1, the elements in clause E.1 Definitions are ordered alphabetically.

This revised standard is being developed in English. In a translation, the number assigned to each term must be retained to meet the "structurally identical" requirement of clause 4.5 of the ISO/IEC Directives. Variations from the alphabetic order of the language of translation should be explained in a Note, for example:

NOTE: The order of the terms corresponds to their order in the original English language version of this standard.

Draft note for the French translation:

NOTE: L'ordre des termes correspond à leur ordre dans la version originale d'anglais de cette norme.

Draft note for the Russian translation:

ПРИМЕЧАНИЕ: Порядок терминов соответствует их порядку в оригинальной версии этого стандарта на Английском языке.

4.7 narrative cultural specification
CD2 EDITORIAL #83
The definition for "narrative cultural specification" was modified in response to CD1 Objection #9. The definition now reads:

A narrative description of culturally dependent information pertaining to software use on computers. Such information may be useful when designing computer systems and software. See clause 9.3.2 and 9.4.

Delete the phrase "pertaining to software use on computers".
Rationale:

(a) It could be misunderstood as limiting the information only to information about ("pertaining to") the use of software on computers.

(b) It essentially repeats what the second sentence says better.

5.4.1 Structure of the identifier

CD2 EDITORIAL #84
Change the title of this clause to:
Structure of the identifiers
Note that "identifiers" should not be capitalized.
Rationale: There are two types of identifiers for registrations.

5.4.2 Reference to an approved registration

CD2 EDITORIAL #85
The final sentence is:
Examples are listed in clause 9.3.8.
These are examples of token identifiers. At least one example of a registration number must be given as well (either as an example here, or by means of a reference to the place where the example appears.)

5.5 No modification nor deletion of registrations

CD2 EDITORIAL #86
Current text:
The contents of an individual registration shall never be changed or deleted once it has been registered (except for name additions)...

Change "it has been registered" to "the application for registration has been approved".
Rationale:
Incorrect grammar (plural/singular mismatch)
The point at which further changes are prohibited is when the application is approved. The rewording makes this clear.

7.3 Identity

CD2 EDITORIAL #87
Change the URL for Maintenance agencies and registration authorities from
http://www.iso.ch/mara
to
http://www.iso.org/mara
Change the URL for Autorités de mise à jour et organismes d'enregistrement, from
http://www.iso.ch/mara-fr
to
http://www.iso.org/mara-fr
Rationale: Although either URL works, ISO appears to prefer ".org" to ".ch".

7.4 Registration Procedure

Item h
CD2 EDITORIAL #88
Current text:
"to inform the appropriate Sponsoring Authority when a application does not comply to the rules."
Problem and Action:
Grammar; "...comply with the rules;"

Item f
CD2 EDITORIAL #89
The current text is identical to the text in the CD1 except that one change -- "proposal" to "application"- has been made:

to assign to the Cultural Specification appropriate token identifiers based on the information given by the Sponsoring Authority, and to assign to the Cultural Specification the next available number to be used as a numeric identifier when the application complies with the rules, unless the Cultural Specification is identical to one already registered, in which case the new token identifiers shall be added to the existing registration;

Split this excessively complex item into a new paragraph with two parts worded as follows:
Following approval of an application for registration, the Registration Authority shall:
a) to assign to the a new Cultural Specification appropriate token identifiers based on the information given by the Sponsoring Authority, and to assign to the Cultural Specification the next available number to be used as a numeric identifier ;

b) If the Cultural Specification is identical to one already registered, the new token identifiers shall be added to the existing registration, and the addition shall be noted in the version history of that registration;

Rationale: Reduction of complexity.
Note that "when the proposal complies with the rules" has been replaced by "Following approval of an application for registration" (which occurs because "the proposal complies with the rules").

Item i
CD2 EDITORIAL #90
In the title of this clause, change "Procedure" to "procedure".

8.1 Identity [of the Sponsoring Authority]

CD2 EDITORIAL #91
Second paragraph:
Sponsoring Authorities may submit applications for registration of the types Charmaps and Repertoiremaps to support their other Cultural Specifications.

Move this paragraph to Clause 8.2 Responsibilities, and insert it immediately after item (d).
Rationale: This paragraph describes an action that the Sponsoring Authority may perform. It does not belong in a clause defining the Sponsoring Authority itself.

CD2 EDITORIAL #92
Third paragraph:
Current text of this paragraph:
The RA shall reject applications for registrations which come from sources other than Sponsoring Authorities, or applications from Sponsoring Authorities that they do not have the authority to register. The RA may refer the applicant (eg. a firm or an organization) to an appropiate Sponsoring Authority, if one can be identified.

Make the changes specified below to the text of this paragraph and move the modified text to the end of the clause dealing with Registration procedures.

Rationale for moving the paragraph: This paragraph describes actions carried out by the Registration Authority. It has nothing to do with the definition of the Sponsoring Authority. It is in the wrong place.

1) Change "RA" to "Registration Authority" (two occurrences).

Rationale: For consistency with "Sponsoring Authority/Authorities" in this paragraph.

2) Change the phrase "other than Sponsoring Authorities" to "other than the Sponsoring Authorities as defined in clause 8.1."

Rationale: Current text lacks precision.

3) Delete the following text

or applications from Sponsoring Authorities that they do not have the authority to register.

Rationale:

(a) To what does "they" refer?
(b) "they" must mean "Sponsoring Authorities" (if "they" is interpreted as "the Registration Authority", the text makes no sense). But registration is done by the Registration Authority, not by Sponsoring Authorities.

(c) A submitter of an application that does not fall into one of the categories defined in clause 8.1 is NOT a "Sponsoring Authority," merely a sponsor or a submitter.

4) Change "eg" to "for example,"
5) Change the first comma after the first occurrence of "Sponsoring Authorities" to a full stop (because the remainder of the sentence has been deleted).

8.2 Responsibilities

CD2 EDITORIAL #93
Change "eg." to "for example,"

CD2 EDITORIAL #94
Item b
Change "an application" to "applications".
Rationale: For consistency with other items, where the plural form "applications" is used.

CD2 EDITORIAL #95
Item e
Replace item e
to forward to the Registration Authority those applications that have their support;
with the following text:

to submit applications for the registration of Cultural Specifications to the Registration Authority;

Rationale:

(a) "that have their support" is redundant. A Sponsoring Authority would not submit an application that did not have its approval.

(b) "their" à "its" ("a Sponsoring Authority" is singular)

CD2 EDITORIAL #96
Item f
Change this text:
their respective countries or organizations.
to
its respective country, region, or organizations.
Rationale: Grammar -- to agree with the implied "Sponsoring Authority" which is singular.
Note: It is OK to drop "countries" from item f since Sponsoring Authorities for this standard will not have jurisdiction for multiple countries. (CEN has jurisdiction for Europe as a whole.)

# The Joint Advisory Committee for ISO/IEC 15897

CD2 EDITORIAL #97
Carry out the textual changes specified for clause 11 and then relocate the whole clause (including its heading) immediately after clause 8 Sponsoring Authority.

Rationale: The definition of the Joint Advisory Committee must be grouped with the definitions of all other functional agencies applicable to this standard.

Currently, in CD2 15897, the abbreviation "RA-JAC" is used in clause 10, but (a) the abbreviation is not explained, and (b) the Joint Advisory Committee is not defined until the following clause (11). This is a serious editorial defect that the Editor failed to correct for CD2 15897.

Clause 9.1 Types of cultural Specifications

CD2 EDITORIAL #98
Capitalize "cultural" in the title of this clause.
Explanation: Although the title of a clause is normally all lowercase except for the first letter, "Cultural Specification" is treated as a proper noun (with capitals) in this standard.

Clause 9.2 Relations between registration types

Clause 9.2.1, first sentence:
CD2 EDITORIAL #99
In clause 9.2.1, in the phrase "any of the official ISO languages: English, French, or Russian," change "ISO" to "ISO/IEC JTC 1".

Rationale: The Procedures for the technical work of ISO/IEC JTC 1 is the applicable authority. This is the relevant text from the Procedures:

7.9.1 The languages of JTC 1 are English, French and Russian. In general, the work of JTC 1 and its subsidiary bodies may be in any one or more of the above-mentioned languages. However, meetings are conducted in any one of these. The Chairman or Convener is entitled to authorize participants to speak in a language other than that in which the meeting is conducted. The NB for the Russian Federation provides all interpretation and translation into or from the Russian language into or from another official language.

Clause 9.3 Rules for Cultural Specifications

Clause 9.3.5
CD2 EDITORIAL #100
Current text:

The sources shall be delivered electronically, either via electronic mail or on a diskette, to the Registration Authority.

Reword as:
either via electronic mail or on physical storage media
Rationale: Current wording is too restrictive and backward looking.

Clause 9.3.7
CD2 EDITORIAL #101
Change "all" to "All"
Rationale: Orthographic conventions.

Clause 9.3.8
CD2 EDITORIAL #102
Current text of the 6^th paragraph (between the two Notes) ends:
... thus giving preference specifications from National Standardization Organizations.
Insert "to" between "preference" and "specifications"
Rationale: Grammar.

Clause 9.4 Contents of a Narrative Cultural Specification

CD2 EDITORIAL #103
Wherever possible in the text describing the individual clauses, change the passive "Here ... is described" construction to "This clause describes ..." (or "This clause includes ..." when only some of the contents of the clause are mentioned).

Clause 1: Alphanumeric deterministic ordering
CD2 EDITORIAL #104
Current text:

Issues to cover may be: are there any letters that are sorted differently from other languages, are capital letters sorted before small letters, are there a specific ordering of accents, in which order should different scripts be, do some characters sort equally at first and then when the whole string is otherwise consider red equal, should they then be sorted differently at other levels?

Rewrite as:

Issues to cover may include whether there are letters that sort differently from common use in other languages, whether capital letters sort before small letters, or whether there is a specific ordering of diacritics. Further, this section may describe the ordering of scripts, and sorting levels -- that is, if there are cases when characters sort equally at first, but then may sort differently at other levels.

Rationale: Grammar.

CD 2 EDITORIAL #105
The title of this clause is inappropriate because its content may cover scripts that are not alphabets. New name should be:

Ordering of textual data

Clauses 7 through 32
See Appendix Four for US technical and editorial comments on the optional (non-POSIX) clauses.

10 Appeal procedures

CD2 EDITORIAL #106
Delete the first line of text:
Appeal against the decision of the Registration Authority can be made as follows:
Rationale: Redundant. The title of the clause says the same thing more succinctly.

Clause 11.2

First paragraph
CD2 EDITORIAL #107
Spelling of "subcommittee' still has to be corrected by inserting "t".

Annex A Application form for a Cultural Specification

Introductory paragraph
CD2 EDITORIAL #108
Current text:
Please specify all data relevant for the Cultural Specification type, indicating non-available data by "not available"...

Reword as:
Please specify all data relevant for the Cultural Specification type, or enter "not applicable"...
Rationale: Clarity.

Annex D Sample Narrative Cultural Specification for Danish and Irish

CD2 EDITORIAL #109
Change title of Annex D to:
Examples of Narrative Cultural Specifications
Rationale:

(a) These are "examples", not "samples". (For examples of use, see Annex B and Annex G in ISO/IEC Directives, Part 3 Rules for the structure and drafting of International Standards)

(b) The examples are intended to show the content of narrative cultural specifications, without emphasis on language.

Annex H Differences from ISO/IEC 15897:1999 and CEN ENV 12005:1996

H.1 Changes from ISO/IEC 15897:1999
CD2 EDITORIAL #110
Current text:
3. The text was revised to align with wordings of the new ISO/IEC 2375 International Standard, which the original wordings in the CEN ENV 12005 was build from.

Reword as:
3. The text was revised to align with ISO/IEC 2375.
Rationale:

(a) Grammar ("wording" is singular; "was built" not "was build")
(b) Removal of text that applies to the 1999 version of this standard.

CD2 EDITORIAL #111
Current text:
7. Some parts of the text was moved around, eg annex G which is now clause 9.4.
Reword as:
7. Some parts of the text were moved around. For example, the former Annex G is now clause 9.4.
Rationale: Grammar.

End of Specific Editorial Comments

APPENDIX 1

US comments on specific aspects of the text of clause 7.4

The US recommends (see Technical Comments) that clause 7.4 be replaced by two more detailed clauses. The comments in this appendix identify problems with the text of clause 7.4 as it exists.

Item c
CD2 TECHNICAL #112
Current text:
to circulate applications to ISO/IEC JTC1/SC22 members, liaisons and the Registration Authority's Joint Advisory Group,...

Insert a reference identifying the clause where the Registration Authority's Joint Advisory Group is described in detail immediately after "Group".

Rationale: The RA-JAC has not yet been defined.

CD2 TECHNICAL #113
The text of item c, clause 4 Registration Authority of the CD1 reads:

in the case of a POSIX Locale, to ascertain that the POSIX Locale and the corresponding Narrative Cultural Specification are not in contradiction

In CD1 Objection #12, the US asked:

What if the two do contradict each other? Suppose there is a "foo" POSIX locale definition, and a "foo" narrative cultural spec. Suppose the cultural spec includes <a-acutein the character set list, but the locale does not include it in the <alphaclass. Now what? Which is considered wrong? Is one rejected, or asked to be revised? What if the locale was registered a few years ago, and changing attitudes now make the fact that <a-acuteis not included obsolete? To give a concrete example, locales from the early 1990s often include a limited repertoire of characters -- Western European ones may only include a subset of ISO 8859-1 characters. Locales (or cultural specifications) written now often take a broader definition of what should be included. Under this clause, is one of these wrong? What must be done? Should the older one be marked obsolete? What about users who depend on it?

The existing text is incomplete and vague about the Registration Authority should do if a contradiction exists. More information must be added - once decisions about what happens have been made.

In the DoC, the Editor responded:

12. Noted. There will always be errors. The RA should probably send an application back if it sees errors, and the SA would then have a chance to correct and then resubmit. The RA should then register, and probably come forward with comments. The RAC could also make comments. N 945R is addressing this, and text will be added to clarify it.

In the CD2, the responsibility for resolving inconsistencies between a POSIX Locale and the corresponding Narrative Cultural Specification appears to have now been assigned entirely to the Sponsoring Authority (clause 8.2 Responsibilities [of a Sponsoring Authority], item c).

in the case of a POSIX Locale, to ascertain that the POSIX Locale and the corresponding Narrative Cultural Specification are not in contradiction;

Item d
CD2 TECHNICAL #114
Current text:

to forward the comments received to the Sponsoring Authority for possible integration in the final documents;

Problem and Action:
From this text, it sounds as if the RA is merely a clearinghouse for comments; that it makes no judgments on the contents of proposals or on comments that others make. Is that the case? It seems more appropriate for the RA to be the body that debates the contents and decides whether they are acceptable. Otherwise, it appears that the SA has all the power to decide what a proposal will contain, as well as power to dispose of any comments received.

This problem is addressed in the first of the two clauses that the US proposes as replacements for clause 7.4. In particular, following technical review by the RA-JAC,

x.7 The Registration Authority shall inform the Sponsoring Authority of any changes needed to satisfy the concerns of the RA-JAC.

and, following review by the P-members of SC22,

Item e
CD2 TECHNICAL #115
Current text:

in the case of comments, to optionally receive from the Sponsoring Authority revised applications addressing the comments received;

Substitute this text for the current text:

to receive revised applications from the Sponsoring Authority that address comments made about the application by reviewers, and to decide whether the revisions are acceptable;

Rationale:

1) There is no way to "optionally receive" something. Shouldn't this say "...optionally accept"?
2) The "optionally" is perhaps intended to convey the fact that not every application will need to be revised in response to comments.

3) "in the case of comments" is redundant.

End of Appendix 1

APPENDIX 2

Rearrangement of Clause 9 Rules for Applications

To facilitate the use of ISO/IEC 15897, the US proposes that clause 9 be reorganized into six separate clauses dealing with these topics:

1.      Types and relationships of cultural specifications;
2.      Contents of a narrative cultural specification;
3.      Use of character names;
4.      Requirements for applications;
5.      Format of registration documents;
6.      Specification of the token identifier;

In the rearrangement, an ordinal number enclosed in square brackets (for example, "[1st]") represents the number of a main clause. Subclauses are numbered in the usual way.

The text is almost entirely taken from clause 9 of N 987. Text from N 987 has been copied "as is," which means that typographical or grammatical errors have not been corrected. Clause numbering from N 987 is included as an aid to reviewers.

The very few pieces of text that were inserted or ~~deleted~~ for stylistic reasons are shown by underline or strikethrough respectively. US recommendations for changes to the text itself have NOT been applied here, so that reviewers can focus entirely on how this clause ought to be restructured.

[1st]. TYPES AND RELATIONSHIPS OF CULTURAL SPECIFICATIONS
[1st].1 Types of cultural specifications = 9.1 Types of cultural Specifications
A number of types of Cultural Specifications can be registered according to this International Standard:
1. Narrative Cultural Specification
2. POSIX Locale
3. POSIX Charmap
4. POSIX Repertoiremap
5. Machine-parsable cultural specification
6. Machine-parsable coded character set specification

Type 1 are for Narrative Cultural Specifications, further specified in clause 9.3.2.
Types 2 and 3 are for POSIX specification of cultural conventions defined in ISO/IEC 9945-2.
Type 4 is for Repertoiremaps defined in this International Standard (clause 9.3.9) and in ISO/IEC TR 14652.
Types 5 and 6 are for specification of cultural conventions in a machine-parsable format, such as specified in ISO/IEC TR 14652, XML or SGML table formats. Any format is allowed as long as it is machine parsable and adheres to the following rules: It is a TR 14652 FDCC-set, a TR 14652 charmap, or the first line of the file identifies the file format.

[1st].2 Relations between registration types = 9.2 Relations between registration types
~~The relation between the types is the following:~~
Registration types are related as follows:
[1st].2.1 Narrative Cultural Specification
9.2.1. The Narrative Cultural Specification specify cultural conventions in narrative form in any of the official ISO languages English, French and/or Russian, and it may give equivalent specifications in other languages. It may thus address issues which have not yet been codified by formal methods for specifications of cultural conventions. If parts of a Narrative Cultural Specification has been specified also in POSIX Locale or Charmap format, this Locale or Charmap should be referenced in the specification.

[1st].2.2 POSIX Locale
9.2.2. The POSIX Locale shall specify appropiate aspects of a Narrative Cultural Specification in formal POSIX syntax. The POSIX Locale shall refer to the Repertoiremap being used, and should also list a number of POSIX Charmaps that it can use.

9.3.3 (part) The POSIX Locale shall define all standard categories (for example by copying categories of a standard POSIX Locale; examples are given in annex F).

9.4 (part) If a POSIX locale is submitted, it is desirable that it be accompanied by a related narrative cultural specification.

[1st].2.3 POSIX Charmap
9.2.3. The POSIX Charmap shall specify aspects of a Narrative Cultural Specification or a POSIX Locale that relate to coded character sets. A POSIX Charmap shall refer to the Repertoiremap being used, but need not refer to the POSIX Locales nor the Narrative Cultural Specifications using it.

[1st].2.4 Repertoiremap
9.2.4. The Repertoiremap is used as a tool to enable a POSIX Locale or a Narrative Cultural Specification to be independent of coded character sets, and to remove the requirement for POSIX Charmaps when registering a POSIX locale. It need not refer to other Cultural Specifications.

[1st].2.5 Other specifications
9.2.5. In the case of a TR 14652 FDCC-set, or other machine-parsable cultural specification, it shall specify in formal syntax some aspects of a Narrative Cultural Specification, and shall refer to a corresponding Narrative Cultural Specification. In case of a TR 14652 FDCC-set it shall refer to the Repertoiremap being used, and should also list a number of Charmaps that can be used.

9.3.3 (part)The FDCC-set shall define all standard categories (for example by copying categories of a standard "i18n" FDCC-set; examples are given in annex F).

9.2.6. In case of a ISO/IEC TR 14652 Charmap, or other machine-parsable character set descriptions it shall specify aspects of a Narrative Cultural Specification or an FDCC-set that relate to coded character sets. In case of a Charmap it shall refer to the Repertoiremap being used, but need not refer to the FDCC-set nor the Narrative Cultural Specifications using it.

NOTE: It is the intention to allow more formal specification methods in future revisions of this International Standard when they become standardized methods; for the time being these specifications can be registered as type 1, 5 or 6.

[2nd]. CONTENTS OF A NARRATIVE CULTURAL SPECIFICATION
= 9.4 Contents of a Narrative Cultural Specification
The contents of the Narrative Cultural Specification is described in some detail in the following. it builds on information from the POSIX Shell and Utilities standard (ISO/IEC 9945-2) and the Nordic Cultural Requirements on Information Technology Summary Report.

Clause 7 to 32 are to provide information, which is not presently expressible in POSIX notation. Examples of Narrative Cultural Specifications are given in annex D.

[2nd].1 Mandatory Clauses
9.3.2 The format of a Narrative Cultural Specification shall contain the clauses (numbered 1-6) specified below. 9.4 These clauses are POSIX categories. The Narrative Cultural Specification should be accompanied by a corresponding POSIX Locale specification. 9.3.2 The information given in these clauses of the Narrative Cultural Specification may also be described in an FDCC-set, or other machine parsable cultural specification:

Clause 1: Alphanumeric deterministic ordering
Here the specification of a national standard for ordering should be listed. If there are more standards, or options for a standard, there should be one POSIX specification for each of the standards or options. A European Multilingual Sorting standard, or other international standards, already in this registry, could be referenced and possible deviations, if any, could be described. Issues to cover may be: are there any letters that are sorted differently from other languages, are capital letters sorted before small letters, are there a specific ordering of accents, in which order should different scripts be, do some characters sort equally at first and then when the whole string is otherwise considerered equal, should they then be sorted differently at other levels? Does the language require reordering of some characters before collation weighting (e.g. Thai)? Does the language sort on a syllabic basis, rather than merely letter-by-letter (e.g. Burmese)? Does the language make use of ideographs, and if so, how are they handled with respect to other characters? If aspects of the ordering for the language extend beyond what a POSIX specification can handle, then details can be described in Clause 10.

Clause 2: Classification of characters
The POSIX standard allows descriptions of what is alphabetic characters, capital and small letters, digits, hexadecimal digits, punctuation characters, spaces, graphical characters and control characters.

Clause 3: Numeric formatting
Here it is described how numbers are keyed in and formatted, including the format of the decimal point and the thousands separator.

Clause 4: Monetary formatting
Here formatting rules for monetary amounts, as well as local and international currency symbols according to ISO 4217, are described, as well as the relation between the amount, a sign and the currency symbol.

Clause 5: Date and time conventions
Various names for days and months are given, together with formats for writing date and time. Things to consider are: do day and month names start with a capital letter or a small letter? Are there well recognized abbreviations for the day and month names? Is ISO 8601 formatting widespread? As the date formats are for use in POSIX, for example when listing files, consideration should be given to possible POSIX conventions in the culture.

Clause 6: Affirmative and negative answers
Here the short notation for "yes" and "no" answers in the language can be specified. If the culture has strong relations to several languages, for example in a multilingual country, it should be permitted to answer in any of the languages. As English is widely used in many cultures, allowing responses in the English language should be considered.

[2nd].2 Optional Clauses
9.3.2 (remainder) The Narrative Cultural Specification may also include other culturally dependent information, specified in clauses 7-32. 9.4 These clauses are not directly related to POSIX Locales:

NOTE: Further information about the categories, along with specific examples illustrating their use may be found in ~~clause 9.4 and in~~ the Nordic Cultural Requirements on Information Technology (Summary Report).

Clause 7: National or cultural Information Technology terminology
Here terminology for a language or culture can be listed, for example a translation of ISO terminology for Information Technologies.

Clause 8: National or cultural profiles of standards
Here profiles of standards can be listed, for example, OSI national profiles, or profiles of the POSIX standards. See the POSIX ISO/IEC 9945-2 standard for an example.

Clause 9: Character set considerations
Here it can be described how characters are used in the culture, for example:
- which characters are necessary to write a particular language,
- which characters are used to give further precision in the language,
- which characters are usually used in newspapers and books for writing of names and places,
- which characters are used for historic writing of the language,
- and which characters are used for other purposes.
This clause may also be used to specify which coded character sets are common in the culture and what coded character sets are recommended. Also further descriptions of coded character sets may be described; it is also possible to document these in the form of a POSIX Charmap registration.

9.3.2 (part) In clause 9 it is possible to give further information on characters classified in clause 2 (mandatory).
Clause 10: Sorting and searching rules
This is much like clause 1, but can be used for further descriptions, such as how to split a record into sorting fields, and special words which are ignored when comparing or searching. Also sound based matching rules may be described here. What can be accomplished with POSIX should be described in clause 1.

Clause 11: Transformation of characters
Here transliterations and transformations of characters can be described, for example transliteration rules between Latin, Greek and Cyrillic, or fallback notation for some frequent letters. Also this is the place to write about standards in the culture for character conversion.

Clause 12: Character properties
Here additional considerations further than those given in clause 2 can be given, for example how small letters without a direct capital counterpart may be capitalized, or special capitalization rules.

9.3.2 (part) Clause 12 is for description of cultural aspects in excess of what can be described in the corresponding POSIX clause 2.

Clause 13: Use of special characters
Here use of special characters, such as quotation marks, abbreviation marks, and punctuation marks can be described. Also interesting here may be what to avoid, for example number signs, pilcrow sign and division signs are not used in documents in several cultures. Spacing rules and the relation between different punctuation signs is also relevant here.

Clause 14: Character rendition
Special considerations about rendition such as what alternatives may be considered adequate, and acceptable glyphs, may be described in this clause.

Clause 15: Character inputting
A keyboard seldom has separate keys for all the characters needed. This clause is intended for description of keyboard inputting rules and other input methods.

Clause 16: Personal names rules
Personal naming differs from culture to culture, for example what is considered the family name, how titles are used, are family names spelt thruout in capital letters, and whether given names or initial are used. Also the rules for children inheriting their fathers' and mothers' family name, and what happens for married couples may bedescribed here.

Clause 17: Inflection
Languages vary much with respect to inflection, different forms of words depending of the context. here the rules can be described or referenced. Some common translation APIs today take some aspects of this into account, eg. the UNIX gettext() functions deal with singular/plural forms of nouns.

Clause 18: Hyphenation
Hyphenation rules can be described here, and also references to the specifications for a language may be done here.
Clause 19: Spelling
This clause is for specification of spelling rules and spelling lists, or reference to orthographic documentation.
Clause 20: Numbering, ordinals and measuring systems
Here measurement systems can be described (normally this is the ISO SI system). Use of decimal points and thousands separator should be described in clause 3.

9.3.2 (part) Clause 20 is for description of cultural aspects in excess of what can be described in the corresponding POSIX clause 3.

Clause 21: Monetary amounts
Here further considerations to clause 4 can be described, such as old currencies.
9.3.2 (part) Clause 21 is for description of cultural aspects in excess of what can be described in the corresponding POSIX clause 4.

Clause 22: Date and time
This is for considerations in excess of clause 5, such as non-POSIX date conventions, time zone names and daylight savings rules, and other written expressions like "half seven" - what is then really meant - 06:30 as in Germany or Denmark, or 07:30 as in Britain?

9.3.2 (part) Clause 22 is for description of cultural aspects in excess of what can be described in the corresponding POSIX clause 5.

Clause 23: Coding of national entities
Here coding for different entities can be described, such as postal codes, administrative codes for local government, police districts, abbreviations for cities or provinces, and time zone names relating to different parts of the culture.

Also specifications should be given for identification of the whole culture, for example ISO country codes for a nation.

Clause 24: Telephone numbers
The formatting of telephone numbers, nationally and internationally.
Clause 25: Mail addresses
The formatting of postal addresses, where to put the title of the addressee, the street number and the postal code, what are the names of the storeys, and other conventions used.

Clause 26: Identification of persons and organizations
A culture may have numbering schemes for persons and organizations, for example social security numbers, and general tax numbers for companies, together with registries for different organisation forms such as limited companies and associations. This clause may be used to describe such numbering systems.

Clause 27: Electronic mail addresses
Cultural conventions for Internet and X.400 electronic addresses etc. may be described here.
Clause 28: Payment account numbers
Cultural conventions for bank account numbers can be described here.
Clause 29: Keyboard layout
Here the conventions for keyboard layout may be described.
Clause 30: Man-machine dialogue
Considerations for how to localize products may be described here.
9.3.2 (part) Clause 30 is for description of cultural aspects in excess of what can be described in the corresponding POSIX clause 6.

Clause 31: Paper formats
Here it can be described what the conventions are for paper size (normally ISO standards) and the use of window envelopes, etc. Also how punched holes are placed in paper may be relevant here.

Clause 32: Typographical conventions
This clause may be used for how layout is done, for example how to layout a business letter, or a fax. Use of special characters, for example quotation marks, should be described in clause 13.

[2nd].3 Limitations on Character Content
9.3.7 (part) The information in items 8 to 14 is used in the token identifier for the Cultural Specifications.
Items 8 to 13 may contain digits 0123456789 and the characters uppercase and lowercase forms of
ABCDEFGHIJKLMNOPQRSTUVWXYZ
Item 10 may also contain the special characters:
/()*-.:_
Note: all of these characters are included in ISO/IEC 10646-1 U0020..U007E.
Case of letters is not significant in token identifiers.

[3rd]. USE OF CHARACTER NAMES
9.3.9 POSIX Locale, FDCC-set and Charmap sources shall be specified in a way that is independent of coded character sets, using character names. Relation between the character names and characters shall be specified via a Repertoiremap table, giving the character name and the ISO/IEC 10646 short character ID in the form of Uxxxx or Uxxxxxxxx, and optionally the long ISO/IEC 10646 character name. It is recommended to use, whenever possible, character names specified in ISO/IEC 9945-2:1993 Annex G. The character name and the ISO/IEC 10646 canonical encoding are each surrounded by angle brackets <>, and the fields shall be separated by one or more spaces or tabs on a line. If a right angle bracket or an escape character is used within a name, it shall be preceded by the escape character. The escape character can be redefined from the default reverse solidus (\) with the first line of the Repertoiremap containing the string "escape_char" followed by one or more spaces or tabs and then the escape character.

[4th]. REQUIREMENTS FOR APPLICATIONS
9.3.6 A written application shall accompany the Cultural Specification and be signed by authorized personnel on behalf of the contributing organization. It shall release copyrights of the contributed sources.

9.3.7 (part) Annex A specifies a form to be filled out for each Cultural Specification; Annex B gives an example of a completed form.

9.3.7 (part) If any of the ~~above~~ information specified below is non-existent, it must be stated in each case; the corresponding string is then the empty string. The default case in 11 and 12 is also represented by an empty string. If required information is not present in any of the ISO 639 parts or ISO 3166, the relevant Maintenance Authority shall be approached by the Sponsoring Authority to get the needed item registered.

[4th].1 Required for All Applications
9.3.7 The written Cultural Specification application shall contain information on the following items:
1. Cultural Specification type number (as in 9.1 above)
2. Organization name of Sponsoring Authority
3. Organization postal address
4. Name of contact person
5. Electronic mail address of the organization, or contact person
6. Telephone number for the organization, in international format.
7. Fax number for the organization, in international format.
All applications shall contain information on these items:
11. If not for general use, an indication of the intended user audience. The Registration Authority decides on a corresponding identifier element, to be used in the token identifier for the specification.

12. If for use of a special application, a description of the application. The Registration Authority decides on a corresponding identifier element, to be used in the token identifier for the specification.

13. Short name for Sponsoring Authority, for possible use in the token identifier. Blank if this is from a National Standardization Organization.

14. Revision number consisting of digits and zero or more full stops (".").
15. Revision date in the format according to this example: "1995-02-05" meaning the 5th of February, 1995.
[4th].2 Required for Types 1, 2 and 5
9.3.7 (part) For Types 1, 2, and 5, Narrative Cultural Specifications, POSIX Locales, and FDCCsets and other formal descriptions of cultural conventions:

8. Natural language, as specified in ISO 639-1, or ISO 639-2 terminology codes if an ISO 639-1 code does not exist.
9. Territory, as two-letter form of ISO 3166
[4th].3 Required for Types 3, 4, and 6
9.3.7 (part) For Types 3, 4, and 6, POSIX Charmaps, Repertoiremaps, and TR 14652 Charmaps and other formal descriptions of character sets:

10. Suggested Charmap or Repertoiremap or other name

[5th]. FORMAT OF REGISTRATION DOCUMENTS
[5th].1 General
9.3.1 A application for registration of a Cultural Specification shall be submitted as a Text File. A Narrative Cultural Specification may alternatively be submitted on white paper of the approximate size 297 by 210 mm, with margins of no less than 20 mm, or one of the approved document formats of ISO/IEC JTC 1, as noted in JTC 1 directives.

9.3.5 The sources shall be delivered electronically, either via electronic mail or on a diskette to the Registration Authority. Narrative Cultural Specifications may alternately be delivered on paper.

9.3.4 The coded character set of ISO/IEC 646 International Reference Version (ISO 2375 registration number 6) shall be used to represent text for the submitted files. For enhanced network portability it is recommended that only the invariant part of ISO/IEC 646 (ISO 2375 registration number 170), which contains 83 graphical characters (including space), be used. Comments shall be given in the English language, and equivalent comments may also be given in other languages. If characters outside ISO/IEC 646 International Reference Version are needed, character names defined in a Repertoiremap shall be used.

[5th].2 Narrative Cultural Specification
9.3.2 (part) Each clause shall begin on a new line after at least one blank line, and each clause shall be introduced by the string "Clause ", followed by the decimal clause number for the issue as listed above, then a colon and a space, and then the title of the clause, using the titles above (examples are given in annex D).

9.3.2 (part) The body of the clause shall follow on the succeeding lines. A reference to a clause within the specification shall consist of the string "=> Clause " followed by the clause number. A reference to another specification shall consist of the string "=> Spec. "followed by the registration number of the specification and, optionally, the string "Clause " and a clause number.

[5th].3POSIX Locale and Charmap
9.3.2 (part) The format of the POSIX Locale and Charmap sources shall be conformant to ISO/IEC 9945-2, or for POSIX Locales the technique specified in Annex E.

[5th].4 Repertoiremap
9.3.2 (part) The format of the Repertoiremap shall be conformant to clause 9.3.9.

[6th]. SPECIFICATION OF THE TOKEN IDENTIFIER
Token Identifiers are assigned by the Registration Authority.
9.3.8 The information in item 8 to 14 is used by the Registration Authority to construct a token identifier for the Cultural Specification according to the following rules. The token identifier may then be used to uniquely identify a Cultural Specification in a manner that may be more indicative of its contents than a mere numeric identifier.

For Narrative Cultural Specifications, POSIX Locales and FDCC-sets the token identifier will be:
8_9+11+12,13_14
And for Charmaps and Repertoiremaps the token identifier will be:
10+11+12,13_14
where 11 and 12 and preceding pluses shall be omitted when not needed to specify position, and 13 may be omitted after request from the Sponsoring Authority, if this is a National Standardization Organization.

The HYPHEN character "-" may be substituted for the UNDERLINE character "_", in order to align names with RFC 3066.

NOTE: A combination of a POSIX Locale or FDCC-set, and a Charmap may be designated by the Locale or FDCC-set identifier and the Charmap identifier separated by a solidus (/).

When referencing a Cultural Specification, the version number or parts thereof taken from the right may be omitted, to refer to the Cultural Specification with the highest digital version number available with the given version number prefix. If the item 13 is an empty string, referencing the token identifier without the preceding comma and items 13 and 14 shall give the Cultural Specification with the highest digital version number, thus giving preference specifications from National Standardization Organizations.

NOTE: The version number may be used by the Sponsoring Authority to mark major releases, minor revisions and error corrections. It is recommended that major releases be reflected as the first number, minor revisions in the second number, and error corrections in the third number.

EXAMPLE 1: _EU,CEN_3.5 for the CEN European POSIX Locale
EXAMPLE 2: da_DK,_2.4 for the Danish Standards Danish POSIX Locale
EXAMPLE 3: ISO_8859-1:1987,DS_1.0 for the DS Charmap for ISO 8859-1

End of Appendix 2

APPENDIX 3

Technical and editorial comments on optional (non-POSIX) clauses

Clause 8: National or cultural profiles of standards (Optional)
CD2 TECHNICAL #116
Current text:
"Here profiles of standards can be listed, for example, OSI national profiles, or profiles of the POSIX standards. See the POSIX ISO/IEC 9945-2 standard for an example."

Problem and Action:
The reference to POSIX is out-of-date and obsolete. ISO/IEC 9945-2 now contains system interface definitions, and does NOT contain an example of a profile.

Remove the sentence "See the POSIX..."

Clause 11: Transformation of characters (Optional, Not recommended)
CD2 TECHNICAL #117
Current text
Here transliterations and transformations of characters can be described, for example transliteration rules between Latin, Greek and Cyrillic, or fallback notation for some frequent letters. Also this is the place to write about standards in the culture for character conversion.

In CD1 Objection #49, the US proposed removal of this clause because:
This is too vague to be useful, as the Danish example in Annex D illustrates.
The Editor responded in the DoC:

49. Not accepted. There are already many quite elaborate transliteration specs in 14652 style.

The US recommends that this clause be annotated "Not recommended."
Rationale: The instructions on the content of this clause are too vague to be useful (as the Danish example in Annex D illustrates).

CD2 TECHNICAL #118
If actual, usable "elaborate transliteration specs in 14652 style" exist, then at least one appropriate example should be cited (and added to the Bibliography). This will provide that Sponsoring Authorities with a well-formed example of what should be in this clause.

Clause 13: Use of special characters (Optional)
CD2 TECHNICAL #119
Although the US comment CD1 OBJECTION #31 to "revise the text to clarify the information about order" was not accepted, the text dealing with quotes in Clause 13 has been revised and is clearer:

For quoting, the character pairs <"><">, <«><»> and <"><">are used,; the first character in each pair is used to start a quote, and the last to end the quote.

CD2 TECHNICAL #120
Clause 13 is a collection of examples of use of special characters (or advice on use in the case of the number sign). What is needed is a definition stating exactly what "special characters" are.

CD2 TECHNICAL #121
Delete this line:
NUMBER SIGN <#> is seldomly used, and should be avoided.
Rationale: Dictating whether a country or region should make use of NUMBER SIGN in its orthography is totally out of scope for this standard.

CD2 EDITORIAL #122
The US notes that "seldomly" is grammatically incorrect. The correct usage is "seldom".

Clause 16: Personal name rules (Optional, Not recommended)
CD2 TECHNICAL #123
Current text:
Personal naming differs from culture to culture, for example what is considered the family name, how titles are used, are family names spelt thruout in capital letters, and whether given names or initial are used. Also the rules for children inheriting their fathers' and mothers' family name, and what happens for married couples may be described here.

Problem and Action as stated in CD1 OBJECTION #50:
"While this may be interesting information, of what use is it to software developers? For most countries, there are general conventions about family names, but so many individual exceptions that the conventions cannot be hard-coded into software. What is the justification for including this information?"

The DoC was "Not accepted. see 33." (CD1 Objection #33 was a comment on the Danish example in Annex D.)
DEFECTIVE DISPOSITION. While it was appropriate to refer Objection #33 to the Danish NB for resolution, it is incumbent upon the editor to respond to the problems identified CD1 Objection #50.

The US notes that the editor did correct "first" to "given" (as suggested in #33).

CD2 TECHNICAL #124
The US recommends that this clause be annotated "Not recommended".
Rationale: It is questionable that the information requested here, which may include many exceptions, can be expressed in software.

Clause 17: Inflection (Optional, Not recommended)
CD2 TECHNICAL #125
Current text:
"Languages vary much with respect to inflection, different forms of words depending of the context. here the rules can be described or referenced. Some common translation APIs today take some aspects of this into account, eg. the UNIX gettext() functions deal with singular/plural forms of nouns."

Remove the sentence beginning "Some common translation APIs..."
Rationale:
First, gettext() is not a translation API; it is a messaging API. Second, while it may have some very, very limited capabilities with respect to singular/plural nouns in a few languages, it most definitely does NOT have the capability of handling all the varying inflection rules that languages around the world use. This is misleading at best and inaccurate at worst.

CD2 TECHNICAL #126
The US recommends that this clause be annotated "Not recommended".
Rationale: It is questionable that the information requested here, which may quite complex for some languages (as shown by the Irish example), can be expressed in software.

Clause 20: Numbering, ordinals, and measuring systems (Optional)
CD2 EDITORIAL #127
In the technical comment on Clause 3: Numeric formatting, it was pointed out that information on how numbers are "keyed in" could not be included since Clause 3 is defined as a POSIX category, and "POSIX contains no information about how numbers are "keyed in".

In case information about keying in is needed, the US provides the following replacement text:

This clause includes the description of the measurement system or systems used. (Usually, the measurement system is the ISO SI system.). A description of how numbers are keyed in may be included here. Use of decimal points and thousands separator shall be described in clause 3.

This replacement text also fixes these defects:

(a) corrects the erroneous plural "decimal points";
(b) changes "should" to "shall" in the last sentence. Clause 3 is a required data element of a registration (as specified in clause 9.3.2).

Clause 22: Date and time (Optional, Not recommended)
CD2 TECHNICAL #128
Current text:
"This is for considerations in excess of clause 5, such as non-POSIX date conventions, time zone names and daylight savings rules, and other written expressions like "half seven" - what is then really meant - 06:30 as in Germany or Denmark, or 07:30 as in Britain?"

The U.S. still objects strongly to including time zone information in cultural narratives (as stated in CD1 Objection #51).

Remove the phrase "...time zone names and daylight savings rules..."
Additional Rationale:
Time zones cross national borders and so are not limited to a single culture. Also, time zone information in a locale or cultural narrative was labeled controversial in TR 14652, and it is incorrect to elevate it to normative status in this standard.

CD1 OBJECTION #51
Section: Annex G, clause 22 (Date and time)
Current text:
Text is now in 9.4, clause 22
"This is for considerations in excess of clause 5, such as non-POSIX date conventions, time zone names and daylight savings rules, . . ."

Problem and Action:
Time zone names and daylight savings rules should not be in a cultural narrative. Especially for large countries, there are too many zones and local exceptions for this information to be useful. Time zones are geographical and political rather than cultural.

Remove this clause.
51. Not accepted. The information can be used to set TZ, and in the case of more than one, it can be used to select the correct one.

CD2 TECHNICAL #129
The example is defective. "Half seven" is an English language phrase, and means 7:30 am or pm (that is, 0730 or 1930 hours). The German phrase "halb sieben" means only 0630. (The Danish NB is invited to supply the corresponding Danish phrase for 0630.)

We also note that "half seven" is British usage. English-speakers in other cultures (US and Australia, for example) say "half past seven."

CD2 TECHNICAL #130
If the phrase "...time zone names and daylight savings rules..." is not removed, then the US strongly recommends that this clause be annotated "Controversial" (rather than simply "Not recommended").

Rationale: To agree with WG20's decision on time zone information in TR 14652.
If the phrase "...time zone names and daylight savings rules..." is removed as the US has requested, then this clause should be annotated "Not recommended".

Rationale: Because there are problems with all aspects of the description.

Clause 23: Coding of national entities (Optional, Not recommended)
CD2 TECHNICAL #131
The US recommends that this clause be annotated "Not recommended".
Rationale: The instructions on the content of this clause are too vague to be useful.

Clauses 26, 27, 28 and 30 (Optional, Not recommended)
CD2 TECHNICAL #132
26. Identification of persons and organizations
27. Electronic mail addresses
28. Payment account numbers
29. Man-machine dialogue
The US recommends that these clauses be annotated "Not recommended".
Rationale: The definitions are vague, or contain information that is application-specific rather than culture-specific.

End of Appendix 3

APPENDIX 4

US Comments on Annex D, Sample Narrative Cultural Specification for Danish and Irish

Objections specific to the Danish or Irish examples are listed here.
These US comments consist of new comments on the CD2, and earlier comments (previously submitted with the US vote on CD1) that are still applicable to the CD2. These are distinguished by the prefix "CD2" or "CD1". Some objections are specific instances of general comments above.

In N 957 Disposition of comments on CD of 15897 (that is, CD1), the Editor responded:

28-38. These comments will be relayed to the Danish member body for possible changes.

Comments 28-37 were not accepted for this reason.

Corrections to the Danish example should be done with input from the Danish member body. The Danish member body is kindly invited to provide suggestions for changes, if appropriate.

This consolidated list of comments is submitted to assist the Danish and Irish NBs should they wish to address the US concerns expressed in the US comment on this Annex as a whole.

CD1 OBJECTION #28
Section: Annex D, Clause 7 (National or cultural Information Technology terminology)
Current text:
"The official Information Technology terminology is "Edb-ordbog", DS 2049-1970, Gjellerup, København. A newer description can be found in Lars Frank: "edb-ordbogen", Kommunetryk, København 1984."

Problem and Action:
Citing documents that were written 31 and 17 years ago as relevant for information technology is not useful. Technology and its terminology change so quickly that these documents must be out-of-date. Remove this clause.

Perhaps there are more recent IT vocabulary sources for Danish speakers that could be cited.

CD2 TECHNICAL #133
Section: Annex D, Clause 11
Current text:
"Transliteration of Cyrillic and Arabic is quite different from English conventions. Examples of transliterated Cyrillic names are Tjajkovskij, Gorbatjov, and Jeltsin; an example of a translitterated Arabic name is Khadaffi. For a fallback notation of some letters, refer to the following table:"

Problem and Action:
It still is not clear why the Danish Standards body wants to state that transliteration "...is quite different from English" without giving a full description, but that is their choice. However, do they really want to provide a list of "fallback notation of *some* letters" (emphasis added)? Wouldn't it be preferable to provide a full list?

Editorial: correct spelling of second use of "transliterated".
The US previously commented on this clause as follows:
CD1 OBJECTION #29
Section: Annex D, Clause 11 (Transformation of characters)
Current text:
"Transliteration of Cyrillic and Arabic is very different from English conventions.
For a fallback notation of some letters, refer to the following table:
original letter 2-char 1-char
Æ AE E
Ø OE Y
Å AA O
. . ."
Problem and Action:
According to Annex G, this clause is for defining transliteration and transformations of characters ("...for example transliteration rules between Latin, Greek and Cyrillic, or fallback notation for some frequent letters...") Note that this cultural specification simply says that "Transliteration of Cyrillic and Arabic is very different from English conventions" without giving any specific information about the differences, and without giving any information at all about how to do a transliteration. In other words, this provides no concrete information that a software engineer could use. The sentence "Transliteration of Cyrillic..." therefore must be removed.

The fallback information is a bit more useful, but does not provide any guidance about when such fallbacks are permitted. Can they be used any time the original letters are not available, or are there restrictions against their use in some circumstances? Are there requirements to keep an original copy of the data so that data is not lost?

More information is needed on fallbacks to make this clause useful.

CD2 TECHNICAL #134
Section: Annex D, Clause 14
Current text:
"The Danish letters <Ø> and <ø> are often misprinted. . ."
Problem and Action:
Is this still true, or was it true 8-10 years ago when much of this annex was originally written? The Danish Standards group may wish to recheck this information and see whether this still is relevant.

The US previously commented on this clause as follows:
CD1 OBJECTION #32
Section: Annex D, Clause 14 (Character rendition)
Current text:
"The Danish letters <Øand <øare often misprinted. The stroke in the letters is the problem. If you consider a rectangle box surrounding the letter, then the stroke should cross from the upper right corner to the opposite corner."

Problem and Action:
First, is this information still accurate, or was it accurate 7-10 years ago when commercial fonts were not as readily available as they are today?

A more general problem is how this Clause might be used for other cultural specifications. If rendering issues with a single Danish letter are considered the appropriate information to put here, what might a Traditional Chinese cultural specification include, as it tried to explain all the nuances of rendering traditional Han ideographs? Or an Arabic specification that tried to explain how to render Arabic?

This section as described, and as this example shows, does not scale well beyond languages and cultures that have one or two specific rendering issues. This is inadequate and should be removed.

CD2 TECHNICAL #135
Section: Annex D, Clause 15 (Character inputting)
Current text:
"A proposed general input method is included in DS/ISO/IEC 9945-1 annex F."
Problem and Action:
This is incorrect. First, the reference to ISO/IEC 9945-1 is obsolete since the standard has been reissued in 2002. Second, it is incorrect for the 1993 version of ISO/IEC 9945-1 (which includes POSIX.1b). Annex F in that version is about Portability Considerations, and contains no information about input methods or Danish.

Annex E (Sample National Profile), and Section E.1 (Profile for Denmark) may be the intended reference, but this also does not seem to include more than cursory information about input methods. The only relevant text seems to be Section E.1.2 (Character Encoding and Display; lines 73-75):

"For input, if the character name is undefined in the current charmap file, the data shall be left untouched (including the <intro> character) and the behavior is implementation defined."

This does not propose a general input method. The Danish Standards organization must correct this reference, since it specifies a incorrect annex in an obsolete version of the standard, and since there seems not to be a description of a Danish input method anywhere in ISO/IEC 9945-1:1993.

CD1 OBJECTION #33
Section: Annex D, Clause 16 (Personal names rules)
Current text:
"Personal names are commonly spelt with the full first name, while use of initials only is seen also. People are mostly addressed by voice by their first name. The common address form is the informal "du", and the more formal "De" is becoming more common. The family name is never spelt in capital letters only,. . ."

Problem and Action:
This information is vague or useless. How would a software engineer use the information that "People are mostly addressed by voice by their first name" (which, by the way, should be their "given name", not their "first name")? The fact that "De" is "becoming more common" tells an engineer nothing concrete and so is useless. These sentences should be removed.

The US notes that "full first name" has been changed to "full first given name" in CD2 15897.

CD1 OBJECTION #34 (re Danish example)
Section: Annex D, Clause 17 (Inflection)
Current text:
"The Danish grammar is defined in "Retskrivningsordbogen". Danish has more inflections than English, for example nouns will have 8 forms based on indefinite/definite, singularis/pluralis and nominative+others/genitive."

Problem and Action:
First, why does the information about Danish inflection compare it to English? Second, what would a software engineer be expected to do with these two sentences? Referring someone to a book about overall Danish grammar probably would have only the most limited value, but at least it points toward an agreed-upon standard. But why call out inflection separately, since it is only one part of grammatical rules?

This example simply illustrates why an earlier OBJECTION calls for removing this clause all together.
Re Irish example:
The Irish example gives a minimal description of the complex inflection of Irish Gaelic, and refers the user to specific grammar books.

CD2 TECHNICAL #136
Section: Annex D, Clause 23
Current text:
"...Denmark is situated about 54 - 58 degrees North, and 8 - 15 degrees East. Denmark has an area of about 43.069 km2 and 5,2 mill inhabitants (1995)..."

Problem and Action:
It's curious that Denmark wants to use a seven-year-old population figure. According to Statistics Denmark 2002 (http://www.dst.dk/imf), the current population is 5,4 million (rounded up from 5,374 million).

The Danish Standards organization may wish to update its information.

CD1 OBJECTION #35
Section: Annex D, Clause 23 (Coding of national entities)
Problem and Action:
An earlier OBJECTION describes why this clause should be removed. The information here is such a random collection of factoids that it is useless.

CD1 OBJECTION #37
Section: Annex D, Clause 27 (Electronic mail addresses) and Clause 28 (Payment account numbers)
Problem and Action:
Remove these sections, as explained in an earlier OBJECTION. These are not cultural-specific.

CD2 TECHNICAL #137
Section: Clause 28 (Payment account numbers)
In Danish bank account numbers, is there a separator character between the branch identification code and the bank account number? How long can the branch account number be?

The textual description of the structure of numbering for Danish Postal Giro accounts does not agree with the example. It is true that there are 7 digits in the example, but there is also a hyphen. Why is the hyphen not mentioned in the textual description? Is it always positioned between the 3^rd and 4^th digits?

CD1 OBJECTION #38
Section: Annex D, Clause 30 (Man-machine dialogue)
Problem and Action:
Remove this section, as explained in an earlier OBJECTION. This is too vague to be useful.
38. See response 23.
The Editor's disposition on US comment 23 was:

23. Not accepted. It is commonly accepted good procedures for registries not to delete entries, or possibilities for entries. The proposal here would invalidate already existing entries in the registry.

The Minutes of the WG 20 meeting #22 (N 932) show that this comment was not accepted because "WG20 is not in a position to change the Danish specification."

End of US comments