Subject: 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

From: Matthew Deane <[email-masked]>
Date: Mon, 10 Feb 2003 09:49:26 -0500

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-masked] 
_____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.
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.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). 
	(c)	As noted before, the TR 14652 Repertoiremap is controversial
and shall not be a normative part of this standard.

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.
<end proposed text>

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.
<end proposed text>

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.
<end text>

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.
<end text>

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.
<end text>

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.
<end text>

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;
<end text>

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.
<end text>

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 6th 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,
		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.

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 3rd and 4th
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