From owner-sc22docs@dkuug.dk  Mon Feb 10 15:50:44 2003
Received: (from majordom@localhost)
	by dkuug.dk (8.9.2/8.9.2) id PAA52355
	for sc22docs-domo; Mon, 10 Feb 2003 15:50:44 +0100 (CET)
	(envelope-from owner-sc22docs@dkuug.dk)
X-Authentication-Warning: ptah.dkuug.dk: majordom set sender to owner-sc22docs@dkuug.dk using -f
Received: from email1.ansi.org (email1.ansi.org [12.15.192.17])
	by dkuug.dk (8.9.2/8.9.2) with ESMTP id PAA52348
	for <sc22info@dkuug.dk>; Mon, 10 Feb 2003 15:50:25 +0100 (CET)
	(envelope-from mdeane@ANSI.org)
Received: by email1.ansi.org with Internet Mail Service (5.5.2653.19)
	id <T1YPLXSP>; Mon, 10 Feb 2003 09:49:31 -0500
Message-ID: <2F81C8110D55D411882A0020356797B2027FE0D5@email1.ansi.org>
From: Matthew Deane <mdeane@ANSI.org>
To: "'SC 22 Distribution List'" <sc22info@dkuug.dk>
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 
Date: Mon, 10 Feb 2003 09:49:26 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2D113.9B6FE2A0"
Sender: owner-sc22docs@dkuug.dk
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2D113.9B6FE2A0
Content-Type: text/plain;
	charset="iso-8859-1"

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:  mdeane@ansi.org 
_____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






------_=_NextPart_001_01C2D113.9B6FE2A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>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 </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Courier New">ISO/IEC JTC 1/SC22<BR>
Programming languages, their environments and system software =
interfaces<BR>
Secretariat:&nbsp; U.S.A.&nbsp; (ANSI)</FONT>=20
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">ISO/IEC JTC 1/SC22 N3541</FONT>=20
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">TITLE:<BR>
Summary of Voting on SC 22 N 3523, Text for Second CD Ballot, ISO/IEC =
CD 15897 - Procedure for the Registration of Cultural =
Elements</FONT><FONT FACE=3D"Courier New"> </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">DATE ASSIGNED:<BR>
2003-02-10 </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">SOURCE:<BR>
SC 22 Secretariat </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">BACKWARD POINTER:<BR>
N/A </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">DOCUMENT TYPE:<BR>
Summary of Voting </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">PROJECT NUMBER:<BR>
1.22.15897</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">STATUS:<BR>
The results of this ballot are forwarded to SC 22/WG 20 for review and =
appropriate action.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">ACTION IDENTIFIER:<BR>
ACT </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">DUE DATE:<BR>
N/A </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">DISTRIBUTION:<BR>
Text </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">CROSS REFERENCE:<BR>
SC 22 N3523 </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">DISTRIBUTION FORM:<BR>
Def </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Matt Deane<BR>
ANSI<BR>
25 West 43rd Street<BR>
New York, NY&nbsp; 10036<BR>
Telephone:&nbsp; (212) 642-4992<BR>
Fax:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; (212) 840-2298<BR>
Email:&nbsp; mdeane@ansi.org</FONT><FONT FACE=3D"Courier New"></FONT>=20
<BR><FONT SIZE=3D2 FACE=3D"Courier New">_____end of cover page, =
beginning of document______________</FONT><FONT FACE=3D"Arial Unicode =
MS"> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">SUMMARY OF VOTING ON</FONT>=20
<BR><FONT SIZE=3D2 FACE=3D"Arial">Letter Ballot Reference No:&nbsp; =
SC22 N3523<BR>
Circulated =
by:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; JTC 1/SC22<BR>
Circulation =
Date:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
2002-11-08<BR>
Closing =
Date:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2003-02-08</FONT><BR>
<BR>
<FONT SIZE=3D2 FACE=3D"Arial">SUBJECT:&nbsp; Summary of Voting on SC 22 =
N 3523, Text for Second CD Ballot, ISO/IEC CD 15897 - Procedure for the =
Registration of Cultural Elements</FONT><BR>
<FONT SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
-------------</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">The following responses have been =
received on the subject of approval:</FONT>=20
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;P&quot; Members supporting this =
appointment<BR>
6 (China, Czech Republic, Denmark, Republic of Korea, Norway, =
Switzerland)</FONT>=20
<BR><FONT SIZE=3D2 FACE=3D"Arial">P&quot; Members supporting this =
appointment, with =
comments&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;<BR>
1 (Germany)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;P&quot; Members not supporting =
this appointment<BR>
4 (Japan, Netherlands, UK, USA) </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;P&quot; Members =
abstaining&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
2 (Austria, France) </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;P&quot; Members not =
voting&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
11 (Belgium, Brazil, Canada, Egypt, Finland, Ireland, DPR of Korea, =
Romania, Russian Federation, Slovenia, Ukraine) </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Note:&nbsp; O-member Sweden voted to =
approve</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">___________ end of summary, beginning =
on NB comments _____________</FONT>=20
<BR><U><B><FONT FACE=3D"Arial">Germany</FONT></B></U><B></B><FONT =
FACE=3D"Times New Roman"> </FONT>
</P>

<P><FONT FACE=3D"Times New Roman">editorial comments:</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">&nbsp;9.2.8</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">&nbsp; &quot;but need not refer&quot; =
--&gt; &quot;may refer&quot;</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">&nbsp;Annex D.2</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">&nbsp; Check the printing</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">Technical comments:</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">&nbsp;Introduction:</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">&nbsp; Add &quot;XML&quot; after SGML =
in the introduction and passim (of course, XML is </FONT>
<BR><FONT FACE=3D"Times New Roman">implied by SGML, but better be =
explicit)</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">&nbsp;4.4 text-file</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">&nbsp;&nbsp; &quot;A file&quot; =
--&gt; &quot;A human-readable file&quot; (or similar)</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">&nbsp;5.5 &quot;No =
modification...&quot;</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">&nbsp; Allow versioned registrations =
/ updates to existing registrations, </FONT>
<BR><FONT FACE=3D"Times New Roman">provided all older versions are =
still accessible and can be uniquely </FONT>
<BR><FONT FACE=3D"Times New Roman">identified (to a degree, this =
possibility is implied by Annex A, point </FONT>
<BR><FONT FACE=3D"Times New Roman">14)</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">&nbsp;7.3 Identity</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">&nbsp; Create and quote a URL for =
registrations in Russian</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">&nbsp;9.3.7, point 9</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">&nbsp; Add note on registratiosn for =
the European Union (EU)</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">&nbsp;9.4 &quot;contents of a =
narrative cultural specification&quot;</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">&nbsp; General:</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">&nbsp;&nbsp; The list of optional =
clauses is fairly arbitrary. However, all such </FONT>
<BR><FONT FACE=3D"Times New Roman">lists are more or less arbitrary, so =
no change is required at this point </FONT>
<BR><FONT FACE=3D"Times New Roman">beyond a note that should point out =
that the list of optional clauses </FONT>
<BR><FONT FACE=3D"Times New Roman">may be open to additions in the =
future.</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">&nbsp; Clause 1:</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">&nbsp;&nbsp; &quot;Multilingual =
Sorting&quot; --&gt; &quot;Multilingual Ordering&quot;</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">&nbsp;&nbsp; The text should refer to =
ENV 13710 (as it stands, it suggests that </FONT>
<BR><FONT FACE=3D"Times New Roman">there may be a European Standard in =
the future, but that it does not </FONT>
<BR><FONT FACE=3D"Times New Roman">exist already)</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">&nbsp; Clause 16:</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">&nbsp;&nbsp; For curiosity: In which =
culture are family names capitalized </FONT>
<BR><FONT FACE=3D"Times New Roman">throughout?</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">&nbsp;Annex A:</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">&nbsp; The statement on copyright =
here conflicts with 9.3.6. Please clarifiy </FONT>
<BR><FONT FACE=3D"Times New Roman">(what is really needed is not a =
faiver of copyright but a license to use </FONT>
<BR><FONT FACE=3D"Times New Roman">the registrations without =
charge)</FONT>
</P>
<BR>

<P><U><B><FONT FACE=3D"Arial">Japan</FONT></B></U><B></B>
</P>

<P><FONT FACE=3D"Times New Roman">There are no market needs for this =
registration.</FONT>
</P>
<BR>

<P><U><B><FONT FACE=3D"Arial">Netherlands</FONT></B></U>
</P>

<P><FONT FACE=3D"Times New Roman">GENERAL</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">1 - ISO/IEC 15897 should be a =
self-contained standard as much as</FONT>
<BR><FONT FACE=3D"Times New Roman">possible. That means that references =
to Posix and to 14651 should be</FONT>
<BR><FONT FACE=3D"Times New Roman">reduced to a minimum, and where =
necessary, definitions and explanations</FONT>
<BR><FONT FACE=3D"Times New Roman">should be added, even if this =
implies copying lines from Posix or</FONT>
<BR><FONT FACE=3D"Times New Roman">14651.</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">2 - The reference to CEN TC304 (see =
clause 8.1) should be removed.</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">SPECIFIC</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">We do not have the means to deal with =
every clause, but we restrict</FONT>
<BR><FONT FACE=3D"Times New Roman">our comments to 9.4. The central =
question here is: Does this answer</FONT>
<BR><FONT FACE=3D"Times New Roman">what industry wants to know?</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">Clause 1-6:</FONT>
<BR><FONT FACE=3D"Times New Roman">Expand the text to explain what is =
really asked for. For example,</FONT>
<BR><FONT FACE=3D"Times New Roman">several readers told us that they =
had no idea what &quot;deterministic</FONT>
<BR><FONT FACE=3D"Times New Roman">ordering&quot; means. Also, a more =
logical sequence of clauses would</FONT>
<BR><FONT FACE=3D"Times New Roman">facilitate answering a =
questionnaire.</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">Clause 1:</FONT>
<BR><FONT FACE=3D"Times New Roman">This requires knowledge of the =
national alphabet, which is only made</FONT>
<BR><FONT FACE=3D"Times New Roman">available in clause 9. Thus put this =
clause first.</FONT>
<BR><FONT FACE=3D"Times New Roman">The question of ordering is repeated =
in clause 10. Why? What is the</FONT>
<BR><FONT FACE=3D"Times New Roman">difference? Are there two possible =
approaches of ordering?</FONT>
<BR><FONT FACE=3D"Times New Roman">Which of the two produces =
&quot;culturally expected results&quot;?</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">Clause 7:</FONT>
<BR><FONT FACE=3D"Times New Roman">This presupposes that such a thing =
exists. What if it does not?</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">Clause 9:</FONT>
<BR><FONT FACE=3D"Times New Roman">This question is worded in such a =
way that it may be interpreted by</FONT>
<BR><FONT FACE=3D"Times New Roman">readers quite differently, with as =
effect that answers are no longer</FONT>
<BR><FONT FACE=3D"Times New Roman">comparable, to the distress of =
industry.</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">Clause 10:</FONT>
<BR><FONT FACE=3D"Times New Roman">See above.</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">We may continue this way, but the =
most significant improvement to</FONT>
<BR><FONT FACE=3D"Times New Roman">9.4 would be that the questions =
should no longer put riddles to the</FONT>
<BR><FONT FACE=3D"Times New Roman">reader, which he cannot solve. A =
questionnaire in the present style</FONT>
<BR><FONT FACE=3D"Times New Roman">will</FONT>
<BR><FONT FACE=3D"Times New Roman">motivate very few people to give =
honest and true answers.</FONT>
</P>
<BR>

<P><U><B><FONT FACE=3D"Arial">United Kingdom</FONT></B></U><B></B>
<BR><FONT FACE=3D"Times New Roman">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<BR>
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.</FONT></P>

<P><U><B><FONT FACE=3D"Arial">USA</FONT></B></U><B></B>
</P>

<P><B><FONT FACE=3D"Arial">Subject</FONT></B><FONT FACE=3D"Arial">: US =
Comments on CD2 Text for the Revision of ISO/IEC 15897</FONT>
<BR><B><FONT FACE=3D"Arial">From</FONT></B><FONT FACE=3D"Arial">:&nbsp; =
US National Body</FONT>
<BR><B><FONT FACE=3D"Arial">Date:</FONT></B> <FONT =
FACE=3D"Arial">2003-01-29</FONT>
</P>

<P><B><FONT FACE=3D"Arial">References (SC 22/WG 20 =
documents):</FONT></B>
<BR><FONT FACE=3D"Arial">N 893, Summary of voting on CD registration =
and CD ballot for ISO/IEC CD 15897. - Registration of cultural =
elements</FONT>
<BR><FONT FACE=3D"Arial">N 957, Disposition of comments on CD of =
15897</FONT>
<BR><FONT FACE=3D"Arial">N 987, Information technology - Procedures for =
registration of cultural elements (ISO/IEC&nbsp; CD2 =
15987:2002(E))</FONT>
</P>

<P><B><FONT FACE=3D"Arial">Notation:</FONT></B>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><B><FONT FACE=3D"Arial">Organization:</FONT></B>
<BR><FONT FACE=3D"Arial">US comments consist of: </FONT>
<UL>
<P><FONT FACE=3D"Symbol">&#183;<FONT FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></FONT> <FONT =
FACE=3D"Arial">general comments on technical issues and on editorial =
issues;</FONT>
<BR><FONT FACE=3D"Symbol">&#183;<FONT FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></FONT> <FONT =
FACE=3D"Arial">technical comments on specific clauses; and,</FONT>
<BR><FONT FACE=3D"Symbol">&#183;<FONT FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></FONT> <FONT =
FACE=3D"Arial">editorial comments on specific clauses</FONT>
</UL>
<P><FONT FACE=3D"Arial">supplemented by four appendices.</FONT>
<BR><FONT FACE=3D"Arial">Numbering of US comments on the second CD is =
continuous (including the appendices).</FONT>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">GENERAL COMMENTS ON =
TECHNICAL ISSUES</FONT></B></U></P>

<P><U><B><FONT FACE=3D"Arial">General Comment #1 - Technical issue: On =
use of TR 14652 </FONT></B></U>
<BR><FONT FACE=3D"Arial">As specified in Annex E of the JTC 1 =
Procedures (</FONT><U><FONT COLOR=3D"#0000FF" FACE=3D"Arial">&lt;<A =
HREF=3D"http://www.jtc1.org/directives/main.htm" =
TARGET=3D"_blank">http://www.jtc1.org/directives/main.htm</A>&gt;</FONT>=
</U><FONT FACE=3D"Arial">]), registration requires two standards: =
</FONT></P>
<UL>
<P><FONT FACE=3D"Symbol">&#183;<FONT FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></FONT> <FONT =
FACE=3D"Arial">a technical standard (&quot;The standard containing the =
definition of the classes of objects requiring registration&quot;), and =
</FONT></P>

<P><FONT FACE=3D"Symbol">&#183;<FONT FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></FONT> <FONT =
FACE=3D"Arial">the procedure standard (&quot;The standard containing =
the specific procedures for the JTC 1 Registration Authority to =
follow&quot;) </FONT></P>
</UL>
<P><FONT FACE=3D"Arial">[Quotations are from Annex E.] ISO/IEC 15897 is =
the procedure standard.</FONT>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">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,&nbsp; 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.</FONT></P>

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

<P><FONT FACE=3D"Arial">It is unacceptable that</FONT><U><FONT =
FACE=3D"Arial"></FONT></U> <FONT FACE=3D"Arial">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</FONT><U> <FONT =
FACE=3D"Arial">forbid</FONT></U><FONT FACE=3D"Arial"> use of any of the =
clauses in TR 14652 that are identified as "controversial".</FONT></P>

<P><FONT FACE=3D"Arial">In comments on the "Scope" clause (which is =
normative), the US has supplied new text to ensure that this =
fundamental requirement is met. </FONT></P>

<P><U><B><FONT FACE=3D"Arial">General Comment #2 - Technical issue: On =
specification of procedures</FONT></B></U>
<BR><FONT FACE=3D"Arial">The US commented on CD1 clause 4 (now clause 7 =
in the CD2) as follows;</FONT>
<UL><UL>
<P><FONT FACE=3D"Arial">CD1 OBJECTION #10</FONT>
<BR><FONT FACE=3D"Arial">Section: 4 REGISTRATION AUTHORITY</FONT>
<BR><FONT FACE=3D"Arial">Problem and Action:</FONT>
<BR><FONT FACE=3D"Arial">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.</FONT></P>
</UL></UL>
<P><FONT FACE=3D"Arial">The Editor responded in the DoC (N 957):</FONT>
<UL><UL>
<P><B><FONT FACE=3D"Arial">10. Accepted in principle.</FONT></B> <FONT =
FACE=3D"Arial">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.</FONT></P>
</UL></UL>
<P><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">JTC 1 Procedures (Annex E, Clause E2.6) =
require:</FONT>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">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.</FONT></P>
</UL></UL>
<P><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">Clause E.2.6 also states:</FONT>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">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.</FONT></P>
</UL></UL>
<P><FONT FACE=3D"Arial">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</FONT><U> <FONT =
FACE=3D"Arial">complete</FONT></U><FONT FACE=3D"Arial"> process must be =
defined in the procedure standard.</FONT></P>

<P><FONT FACE=3D"Arial">The above comments also apply to revisions or =
replacements of existing registrations.</FONT>
</P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">GENERAL COMMENTS ON =
EDITORIAL ISSUES</FONT></B></U></P>

<P><U><B><FONT FACE=3D"Arial">General Comment #3 - Editorial Issue: =
Poor Organization</FONT></B></U>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">Division of the normative general content of =
this standard (following<I> Terms and conditions</I>) should be in four =
basic parts:</FONT></P>
<UL>
<P><FONT FACE=3D"Symbol">&#183;<FONT FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></FONT> <FONT =
FACE=3D"Arial">definition of the agencies responsible for this standard =
and the procedures defined in it</FONT>
<BR><FONT FACE=3D"Symbol">&#183;<FONT FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></FONT> <FONT =
FACE=3D"Arial">definition of the contents of the cultural specification =
and layout of the registration documents</FONT>
<BR><FONT FACE=3D"Symbol">&#183;<FONT FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></FONT> <FONT =
FACE=3D"Arial">detailed description of the procedures for submission, =
review, and approval of an application for registration</FONT>
<BR><FONT FACE=3D"Symbol">&#183;<FONT FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></FONT> <FONT =
FACE=3D"Arial">appeal procedures and subsequent procedures associated =
with a registration.</FONT>
</UL>
<P><FONT FACE=3D"Arial">Specific US technical comments describe the =
necessary changes in detail.</FONT>
</P>

<P><U><B><FONT FACE=3D"Arial">General Comment US#4 - Editorial Issue: =
Uncaught errors</FONT></B></U>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><U><B><FONT FACE=3D"Arial">General Comment US #5 - Editorial: Titles =
of clauses</FONT></B></U>
<BR><FONT FACE=3D"Arial">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").</FONT></P>

<P><FONT FACE=3D"Arial">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.)."</FONT></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">End of General =
Comments</FONT></B></U></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">SPECIFIC TECHNICAL =
COMMENTS</FONT></B></U></P>

<P ALIGN=3DCENTER><U><B><FONT =
FACE=3D"Arial">Foreword</FONT></B></U></P>

<P><FONT FACE=3D"Arial">CD2 TECHNICAL #5</FONT>
<BR><FONT FACE=3D"Arial">The second-last paragraph of the Foreword =
reads:</FONT>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">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 &quot;POSIX shell and =
utilities&quot;.</FONT></P>
</UL></UL>
<P><FONT FACE=3D"Arial">Delete "and repertoiremaps"</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
As noted above, repertoiremaps are identified in ISO/IEC TR 14652 as =
"controversial." Therefore, this International Standard</FONT><U> <FONT =
FACE=3D"Arial">cannot</FONT></U> <FONT FACE=3D"Arial">register =
"repertoire maps as defined in ISO/IEC TR 14652" because there is no =
agreed-upon definition.</FONT></P>

<P ALIGN=3DCENTER><U><B><FONT =
FACE=3D"Arial">Introduction</FONT></B></U></P>

<P><FONT FACE=3D"Arial">CD2 TECHNICAL #6</FONT>
<BR><FONT FACE=3D"Arial">First paragraph, last sentence, and Second =
paragraph, first sentence:</FONT>
<BR><FONT FACE=3D"Arial">Insert "the non-controversial clauses of" =
before "ISO/IEC TR 14652" in both places.</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
The clauses of ISO/IEC TR 14652 marked "controversial" shall not be =
used. Only the non-controversial clauses may be used.</FONT></P>

<P><FONT FACE=3D"Arial">CD2 TECHNICAL #7</FONT>
<BR><FONT FACE=3D"Arial">Second paragraph, second sentence:</FONT>
<BR><FONT FACE=3D"Arial">In CD1 Objection #4, the US recommended a =
number of changes, all of which were "Accepted in principle." One of =
these recommendations was:</FONT></P>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Thus, the sentence should end =
&quot;...will also be freely available.&quot;</FONT>
</UL></UL>
<P><FONT FACE=3D"Arial">The Editor added the URL for the ISO web pages, =
but retained the URL for DKUUG, so that the sentence now reads:</FONT>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">The registration will be =
free-of-charge and the registered cultural elements will also be freely =
available on the network at the address</FONT><U> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&lt;<A =
HREF=3D"http://www.iso.org/mara/" =
TARGET=3D"_blank">http://www.iso.org/mara/</A>&gt;</FONT></U><FONT =
SIZE=3D2 FACE=3D"Arial"> (and initially at</FONT><U> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&lt;<A =
HREF=3D"http://www.dkuug.dk/cultreg/" =
TARGET=3D"_blank">http://www.dkuug.dk/cultreg/</A>&gt;</FONT></U><FONT =
SIZE=3D2 FACE=3D"Arial">).</FONT></P>
</UL></UL>
<P><FONT FACE=3D"Arial">The CD2 text now implies that the "registered =
cultural elements" are available at</FONT><U> <FONT =
FACE=3D"Arial">both</FONT></U><FONT FACE=3D"Arial"> URLs. This is =
incorrect. The ISO "mara" URL yields a list of registration agencies, =
not "registered cultural elements".</FONT></P>

<P><FONT FACE=3D"Arial">To eliminate confusion, delete both URLs, so =
that the sentence ends "... will also be freely available." as =
previously recommended.</FONT></P>

<P><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT =
FACE=3D"Arial">:</FONT>
<UL>
<P><FONT FACE=3D"Arial">(a)&nbsp;&nbsp;&nbsp;&nbsp; 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.</FONT></P>

<P><FONT FACE=3D"Arial">(b)&nbsp;&nbsp;&nbsp;&nbsp; The URLs duplicate =
information that is available elsewhere:</FONT>
<UL><UL>
<P><FONT FACE=3D"Arial">(a)&nbsp;&nbsp;&nbsp;&nbsp; Both ISO URLs are =
published in clause 7.3;</FONT>
<BR><FONT FACE=3D"Arial">(b)&nbsp;&nbsp;&nbsp;&nbsp; The DKUUG URL is =
published on the two ISO sites.</FONT>
</UL></UL></UL>
<P><FONT FACE=3D"Arial">Including them here&nbsp; is excessive and =
unnecessary detail for an Introduction.</FONT>
<UL>
<P><FONT FACE=3D"Arial">(c)&nbsp;&nbsp;&nbsp;&nbsp; [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.</FONT></P>
</UL>
<P><FONT FACE=3D"Arial">See also comment on clause 7.3.</FONT>
</P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">1 Scope</FONT></B></U></P>

<P><FONT FACE=3D"Arial">First paragraph, middle sentence:</FONT>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">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.</FONT></P>
</UL></UL>
<P><FONT FACE=3D"Arial">Make three changes to this sentence:</FONT>
</P>

<P><FONT FACE=3D"Arial">CD2 TECHNICAL #8</FONT>
<BR><FONT FACE=3D"Arial">Change "ISO/IEC 9945-2" to "ISO/IEC =
9945"</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
A new consolidated edition has been published.</FONT>
</P>

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

<P><FONT FACE=3D"Arial">CD2 TECHNICAL #10</FONT>
<BR><FONT FACE=3D"Arial">Insert "the non-controversial clauses of" =
before "ISO/IEC TR 14652".</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
The clauses of ISO/IEC TR 14652 marked "controversial" shall not be =
used. Only the non-controversial clauses may be used.</FONT></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">2 Field of =
Application</FONT></B></U></P>

<P><FONT FACE=3D"Arial">CD2 TECHNICAL #11</FONT>
<BR><FONT FACE=3D"Arial">Delete this clause and its text.</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
Essentially repeats the last paragraph of the preceding clause.</FONT>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">3 Normative =
references</FONT></B></U></P>

<P><FONT FACE=3D"Arial">CD2 TECHNICAL #12</FONT>
<BR><FONT FACE=3D"Arial">N987 includes these citations: </FONT>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">ISO 639:1988,</FONT><I> <FONT SIZE=3D2 =
FACE=3D"Arial">Code for the representation of names of =
languages</FONT></I><FONT SIZE=3D2 FACE=3D"Arial"> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">ISO 639-2:1988,</FONT><I><FONT =
SIZE=3D2 FACE=3D"Arial"> Code for the representation of names of =
languages -- Part 2</FONT></I><FONT SIZE=3D2 FACE=3D"Arial"></FONT><I> =
<FONT SIZE=3D2 FACE=3D"Arial">Alpha-3 code</FONT></I><FONT SIZE=3D2 =
FACE=3D"Arial">. </FONT>
</UL></UL>
<P><FONT FACE=3D"Arial">Update these two citations as follows:</FONT>
<UL><UL>
<P><FONT FACE=3D"Arial">ISO 639-1:2002,</FONT><I><FONT FACE=3D"Arial"> =
Code for the representation of names of languages - Part 1: Alpha-2 =
code.</FONT></I>
<BR><FONT FACE=3D"Arial">ISO 639-2:1998,</FONT><I><FONT FACE=3D"Arial"> =
Code for the representation of names of languages - Part 2 Alpha-3 =
code.</FONT></I>
</UL></UL>
<P><U><FONT FACE=3D"Arial">Rationale:</FONT></U>
<UL>
<P><FONT FACE=3D"Arial">(a)&nbsp;&nbsp;&nbsp;&nbsp; A new edition of =
Part 1 was published in 2002.</FONT>
<BR><FONT FACE=3D"Arial">(b)&nbsp;&nbsp;&nbsp;&nbsp; The date of Part 2 =
is incorrect. (The date was correct in the CD1.)</FONT>
</P>
</UL>
<P><FONT FACE=3D"Arial">CD2 TECHNICAL #13</FONT>
<BR><FONT FACE=3D"Arial">A new edition of the ISO/IEC standard for =
POSIX was published in 2002. This reference is outdated.</FONT>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">ISO/IEC 9945-2:1993,</FONT><I> <FONT =
SIZE=3D2 FACE=3D"Arial">Information technology - Portable Operating =
System Interface (POSIX) -- Part 2: Shell and Utilities.</FONT></I></P>
</UL></UL>
<P><FONT FACE=3D"Arial">The US recommends inclusion of all of the parts =
of the 2002 edition of the ISO/IEC standard for POSIX:</FONT>
<UL><UL>
<P><FONT FACE=3D"Arial">ISO/IEC 9945-1:2002,</FONT><I> <FONT =
FACE=3D"Arial">Information technology -- Portable Operating System =
Interface (POSIX) -- Part 1: Base Definitions</FONT></I><FONT =
FACE=3D"Arial">.</FONT>
<BR><FONT FACE=3D"Arial">ISO/IEC 9945-2:2002,</FONT><I> <FONT =
FACE=3D"Arial">Information technology -- Portable Operating System =
Interface (POSIX) -- Part 2: System Interfaces.</FONT></I></P>

<P><FONT FACE=3D"Arial">ISO/IEC 9945-3:2002,</FONT><I> <FONT =
FACE=3D"Arial">Information technology -- Portable Operating System =
Interface (POSIX) -- Part 3: Shell and Utilities.</FONT></I></P>

<P><FONT FACE=3D"Arial">ISO/IEC 9945-4:2002,</FONT><I> <FONT =
FACE=3D"Arial">Information technology -- Portable Operating System =
Interface (POSIX) -- Part 4: Rationale.</FONT></I>
</UL></UL>
<P><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Rationale</FONT></U><FONT =
COLOR=3D"#000000" FACE=3D"Arial">: </FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">Previously, Part 2 contained =
the information about character maps, locales, the POSIX locale, etc. =
That information now is in Part 1.</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">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. </FONT></P>

<P><FONT FACE=3D"Arial">CD2 TECHNICAL #14</FONT>
<BR><FONT FACE=3D"Arial">All references in this standard must be =
up-to-date at each stage of the technical work.</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
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. </FONT></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">4 Terms and =
definitions</FONT></B></U></P>

<P><U><B><FONT FACE=3D"Arial">4.1 locale</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #15</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<UL><UL>
<P><B><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">locale</FONT></B>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">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.</FONT></P>
</UL></UL>
<P><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Problem and =
Action:</FONT></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">This reference is obsolete. =
Update the text to refer to the Locale section in ISO/IEC =
9945-1:2002.</FONT>
</P>

<P><U><B><FONT FACE=3D"Arial">4.3 charmap</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #16</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">charmap</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">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...</FONT></P>

<P><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Problem and =
Action:</FONT></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">This reference is obsolete. =
Update the text to refer to the Character Set section in ISO/IEC =
9945-1:2002.</FONT>
</P>

<P><U><B><FONT FACE=3D"Arial">4.6 cultural specification</FONT></B></U>
<BR><FONT FACE=3D"Arial">CD2 TECHNICAL #17</FONT>
<BR><FONT FACE=3D"Arial">The definition for "cultural specification" =
reads:</FONT>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">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.</FONT></P>
</UL></UL>
<P><FONT FACE=3D"Arial">Insert the following text between =
"Repertoiremap" and the comma which follows it:</FONT>
<BR><FONT FACE=3D"Arial">(except an ISO/IEC TR 14652 =
Repertoiremap)</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
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.</FONT></P>

<P><FONT FACE=3D"Arial">CD2 TECHNICAL #18</FONT>
<BR><FONT FACE=3D"Arial">Add the term "cultural element" with =
definition.</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
This standard "sets out the procedures for registering cultural =
elements" but the term "cultural element" is not defined.</FONT></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">5.4.1 Structure of the =
identifier</FONT></B></U></P>

<P><FONT FACE=3D"Arial">CD2 TECHNICAL #19</FONT>
<BR><FONT FACE=3D"Arial">The current text of this clause is:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">The structure of a token identifier =
is given in clause 9.3.8.</FONT>
<BR><FONT FACE=3D"Arial">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?)</FONT></P>

<P><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
The current text is inadequate because subclause 5.4,</FONT><I> <FONT =
FACE=3D"Arial">Identification of an approved registration,</FONT></I> =
<FONT FACE=3D"Arial">specifies</FONT><U> <FONT =
FACE=3D"Arial">two</FONT></U> <FONT FACE=3D"Arial">types of =
identifiers: "a unique registration number" and "one or more unique =
token identifiers." Both identifiers must be described.</FONT></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">7.2 =
Responsibilities</FONT></B></U></P>

<P><FONT FACE=3D"Arial">CD2 TECHNICAL #20</FONT>
<BR><FONT FACE=3D"Arial">Clause 7.2.2</FONT>
<BR><FONT FACE=3D"Arial">Add these two additional items at the end of =
the list:</FONT>
<UL><UL>
<P><FONT FACE=3D"Arial">-&nbsp; corrections and revisions to existing =
registrations (as specified in clauses &lt;designation to be =
assigned&gt;);</FONT>
<BR><FONT FACE=3D"Arial">-&nbsp; withdrawal of existing registrations =
(as specified in clause &lt;designation to be assigned&gt;).</FONT>
</UL></UL>
<P><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
These are essential maintenance functions.</FONT>
</P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">7.3 =
Identity</FONT></B></U></P>

<P><FONT FACE=3D"Arial">CD2 TECHNICAL #21</FONT>
<BR><FONT FACE=3D"Arial">Delete the note about the "initial =
Registration Authority", including the URL for the cultural =
register.</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT =
FACE=3D"Arial">:</FONT>
<UL>
<P><FONT FACE=3D"Arial">1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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.</FONT></P>

<P><FONT FACE=3D"Arial">2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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. </FONT></P>

<P><FONT FACE=3D"Arial">3)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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.</FONT></P>
</UL>
<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">7.4 Registration =
Procedure</FONT></B></U></P>

<P><FONT FACE=3D"Arial">CD2 TECHNICAL #22</FONT>
<BR><FONT FACE=3D"Arial">Delete this clause.</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale: </FONT></U>
<UL>
<P><FONT FACE=3D"Arial">(a)&nbsp;&nbsp;&nbsp;&nbsp; The US proposes two =
new clauses of the topic of registration procedures. (See</FONT><I> =
<FONT FACE=3D"Arial">New clauses on Registration =
procedures</FONT></I><FONT FACE=3D"Arial"> below.) These new clauses =
are more comprehensive and cover all the items in clause 7.4 (except =
the incomprehensible item i).</FONT></P>

<P><FONT FACE=3D"Arial">(b)&nbsp;&nbsp;&nbsp;&nbsp; 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.</FONT></P>
</UL>
<P><FONT FACE=3D"Arial">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.</FONT></P>

<P><U><B><FONT FACE=3D"Arial">Item i</FONT></B></U>
<BR><FONT FACE=3D"Arial">CD2 TECHNICAL #23</FONT>
<BR><FONT FACE=3D"Arial">Current text</FONT>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">In the case of comments, to optionally =
receive text from commenters to be added to the registration as =
comments.</FONT>
</UL></UL>
<P><FONT FACE=3D"Arial">In CD1 Objection #14, the US commented:</FONT>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">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?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Information must be added here that =
explains who can submit comments, and what the Registration Authority =
can do with those comments.</FONT></P>
</UL></UL>
<P><FONT FACE=3D"Arial">The Editor responded in the DoC:</FONT>
<UL><UL>
<P><B><FONT SIZE=3D2 FACE=3D"Arial">14. Noted.</FONT></B><FONT SIZE=3D2 =
FACE=3D"Arial"> probably the SA, RA and the RAC could submit comments. =
N 945R will be taken into account.</FONT>
</UL></UL>
<P><FONT FACE=3D"Arial">N 945R has</FONT><U> <FONT =
FACE=3D"Arial">not</FONT></U><FONT FACE=3D"Arial"> been taken into =
account. Except for a grammatical correction, the text is</FONT><U> =
<FONT FACE=3D"Arial">unchanged</FONT></U><FONT FACE=3D"Arial">. 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 </FONT><FONT =
SIZE=3D2 FACE=3D"Arial">(Who are these "commenters"? Anyone who chooses =
to send the RA a comment? And how is such a comment evaluated for =
accuracy?)</FONT><FONT FACE=3D"Arial">.</FONT></P>

<P><FONT FACE=3D"Arial">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</FONT><U> <FONT =
FACE=3D"Arial">instructions</FONT></U><FONT FACE=3D"Arial"> to the SA, =
possibly based on comments from reviewers.)</FONT></P>

<P><FONT FACE=3D"Arial">Clause 7.4</FONT><I> <FONT =
FACE=3D"Arial">Registration Procedures</FONT></I><FONT FACE=3D"Arial"> =
(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.</FONT></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">8.1 Identity [of the =
Sponsoring Authority]</FONT></B></U></P>

<P><FONT FACE=3D"Arial">CD2 TECHNICAL #24</FONT>
<BR><FONT FACE=3D"Arial">Current list of who may submit =
applications:</FONT>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">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;</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">b) CEN/TC304 for applications related =
to the region of Europe;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">c) ISO/IEC JTC 1 and its Subcommitees =
and Working Groups, for any applications;</FONT>
</UL></UL>
<P><FONT FACE=3D"Arial">Delete this list and substitute:</FONT>
<UL>
<P><FONT FACE=3D"Arial">a)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ISO/IEC JTC 1 =
and its Subcommittees and Working Groups, for any applications;</FONT>
<BR><FONT FACE=3D"Arial">b)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CEN/TC304 for =
applications pertaining to Europe;</FONT>
<BR><FONT FACE=3D"Arial">c)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Any National =
Body or liaison organization of ISO/IEC JTC1, for applications limited =
to the territory or territories for which they have =
authority;</FONT></P>

<P><FONT FACE=3D"Arial">d)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Any Member =
Body or Associated Member Body of CEN for applications limited to the =
territory or territories for which they have authority;</FONT></P>
</UL>
<P><U><FONT FACE=3D"Arial">Rationale: </FONT></U>
<BR><FONT FACE=3D"Arial">The restructuring keeps information pertaining =
to ISO/IEC JTC 1 separate from information pertaining to CEN.</FONT>
<BR><FONT FACE=3D"Arial">"National body" (not "Member body") is the =
preferred ISO and JTC 1 term (see, for example, clause 2.2.3 in =
the</FONT><I> <FONT FACE=3D"Arial">JTC 1 Procedures</FONT></I><FONT =
FACE=3D"Arial">). </FONT></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">8.2 =
Responsibilities</FONT></B></U></P>

<P><FONT FACE=3D"Arial">CD2 TECHNICAL #25</FONT>
<BR><FONT FACE=3D"Arial">Replace item a</FONT>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">to receive applications concerning =
Cultural Specifications, eg. from firms or organizations in the =
country, or national experts;</FONT></P>
</UL></UL>
<P><FONT FACE=3D"Arial">with the following text</FONT>
<UL><UL>
<P><FONT FACE=3D"Arial">to receive applications concerning Cultural =
Specifications from organizations, firms or experts operating in the =
area over which the Sponsoring Authority has jurisdiction.</FONT></P>
</UL></UL>
<P><U><FONT FACE=3D"Arial">Rationale:</FONT></U><FONT FACE=3D"Arial"> =
The current wording is inapplicable to CEN/TC 304, which is not =
responsible for a particular country.</FONT>
</P>

<P><FONT FACE=3D"Arial">CD2 TECHNICAL #26</FONT>
<BR><U><FONT FACE=3D"Arial">New item</FONT></U>
<BR><FONT FACE=3D"Arial">Insert the following text as a new item =
immediately before item d:</FONT>
<UL><UL>
<P><FONT FACE=3D"Arial">if any material in an application is under =
copyright, to include copyright clearance from the copyright holder in =
the application;</FONT></P>
</UL></UL>
<P><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
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.</FONT></P>

<P><FONT FACE=3D"Arial">Note this amplifies the requirement in clause =
9.3.6 </FONT>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">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.</FONT></P>
</UL></UL>
<P><FONT FACE=3D"Arial">and makes it clear that the Sponsoring =
Authority is</FONT><U> <FONT FACE=3D"Arial">obligated</FONT></U><FONT =
FACE=3D"Arial"> to obtain copyright clearance for any copyrighted =
material that is included in the application.</FONT></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial"># Source of =
information</FONT></B></U></P>

<P><FONT FACE=3D"Arial">CD2 TECHNICAL #27</FONT>
<BR><FONT FACE=3D"Arial">Add new clause and text to be supplied by the =
Editor.</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
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.</FONT></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial"># Copyright =
clearance</FONT></B></U></P>

<P><FONT FACE=3D"Arial">Dealt with in new item added to clause 8.2 that =
makes the Sponsoring Authority responsible for obtaining copyright =
clearance.</FONT></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">Clause 9 Rules for =
applications</FONT></B></U></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #28</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">The US</FONT><U> <FONT =
COLOR=3D"#000000" FACE=3D"Arial">strongly</FONT></U><FONT =
COLOR=3D"#000000" FACE=3D"Arial"> recommends that this clause be =
restructured as shown in Appendix 2.</FONT>
<BR><FONT FACE=3D"Arial">Additional US comments on the text of clause 9 =
(below) refer to individual clauses by their CD2 numbers.</FONT>
</P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">Clause 9.1 Types of =
cultural Specifications</FONT></B></U></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #29</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<UL><UL>
<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Type 4 is for =
Repertoiremaps defined in this International Standard (clause 9.3.9) =
and in ISO/IEC TR 14652.</FONT>
</UL></UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial">Change this reference =
to:</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">Type 4 is for Repertoiremaps =
as defined in ISO/IEC TR 14652.</FONT>
<BR><U><FONT COLOR=3D"#000000" =
FACE=3D"Arial">Rationale:</FONT></U><FONT COLOR=3D"#000000" =
FACE=3D"Arial"> Repertoiremaps are listed as controversial in TR 14652 =
and shall not be elevated to normative status in this standard. =
</FONT></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">Clause 9.2 Relations =
between registration types</FONT></B></U></P>

<P><U><B><FONT FACE=3D"Arial">Clause 9.2.2</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #30</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<UL><UL>
<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">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.</FONT></P>
</UL></UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial">Revise the second sentence as =
follows:</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">The POSIX Locale should list =
one or more POSIX Charmaps it can use.</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Rationale</FONT></U><FONT =
COLOR=3D"#000000" FACE=3D"Arial">:</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">Since Repertoiremaps are a =
controversial part of TR 14652, it is inappropriate for this standard =
to say that they &quot;shall&quot; be used, thus elevating them to =
normative status. </FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">Also, while this text says =
one should list &quot;a number of POSIX Charmaps&quot;, the examples in =
Annex G only list one each; if the examples don't even bother to list =
&quot;a number,&quot; that shouldn't be the recommendation =
here.</FONT></P>

<P><U><B><FONT FACE=3D"Arial">Clause 9.2.5</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #31</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">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.</FONT></P>
</UL></UL>
<P><FONT FACE=3D"Arial">Add this sentence at the end of the =
clause:</FONT>
<BR><FONT FACE=3D"Arial">A TR 14652 Repertoiremap shall not be =
used.</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
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.</FONT></P>

<P><U><B><FONT FACE=3D"Arial">Clause 9.2.6</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #32</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">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.</FONT></P>
</UL></UL>
<P><FONT FACE=3D"Arial">Add this sentence at the end of the =
clause:</FONT>
<BR><FONT FACE=3D"Arial">A TR 14652 Repertoiremap shall not be =
used.</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
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.</FONT></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">Clause 9.3 Rules for =
Cultural Specifications</FONT></B></U></P>

<P><U><B><FONT FACE=3D"Arial">9.3.1</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #33</FONT>
<BR><U><FONT FACE=3D"Arial">Current text:</FONT></U>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">. . . 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,. . .</FONT></P>
</UL></UL>
<P><FONT FACE=3D"Arial">In CD1 OBJECTION #21, the US commented:</FONT>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">What is the rationale for specifying =
the paper size here? Unless there is a good reason, this should be =
removed.</FONT>
</UL></UL>
<P><FONT FACE=3D"Arial">The Editor responded in the DoC:</FONT>
<UL><UL>
<P><B><FONT SIZE=3D2 FACE=3D"Arial">21. Not accepted.</FONT></B><FONT =
SIZE=3D2 FACE=3D"Arial"> 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.</FONT></P>
</UL></UL>
<P><U><FONT FACE=3D"Arial">Additional comments on clause =
9.3.1:</FONT></U>
<UL>
<P><FONT FACE=3D"Arial">1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The reliance =
on paper conflicts with clause 7.11.3</FONT><I> <FONT =
FACE=3D"Arial">Electronic Document Distribution</FONT></I><FONT =
FACE=3D"Arial"> in the</FONT><I> <FONT FACE=3D"Arial">JTC 1 =
Procedures</FONT></I><FONT FACE=3D"Arial">, which states:</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">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.</FONT></P>
</UL>
<P><FONT FACE=3D"Arial">2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; For the =
convenience of the reader, the source for the "approved document =
formats of ISO/IEC JTC1" should be cited. Is this Annex</FONT><I> <FONT =
FACE=3D"Arial">HA Text Area for A4 and North American Paper =
Sizes</FONT></I><FONT FACE=3D"Arial"> in the</FONT><I> <FONT =
FACE=3D"Arial">JTC 1 Procedures?</FONT></I></P>

<P><FONT FACE=3D"Arial">3)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Why say =
"approximate" size, and why describe the actual paper size? Why not say =
"A4" paper?</FONT>
<BR><FONT FACE=3D"Arial">4)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A 20 mm =
margin at the bottom of the page is in conflict with Annex HA of =
the</FONT><I> <FONT FACE=3D"Arial">JTC 1 Procedures</FONT></I><FONT =
FACE=3D"Arial">, 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.</FONT></P>
</UL>
<P><U><B><FONT FACE=3D"Arial">9.3.2.</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #34</FONT>
<BR><FONT FACE=3D"Arial">In CD1 OBJECTION #22, the US commented:</FONT>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">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 &quot;Inflection&quot; or &quot;Coding of national =
entities&quot; 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?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The explanation of the items allowable =
in a cultural spec should appear in Clause 6 along with the items =
themselves. </FONT>
</UL></UL>
<P><FONT FACE=3D"Arial">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.</FONT></P>

<P><U><FONT FACE=3D"Arial">Additional comments:</FONT></U>
<UL>
<P><FONT FACE=3D"Arial">1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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.</FONT></P>

<P><FONT FACE=3D"Arial">2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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.</FONT></P>
</UL>
<P><U><B><FONT FACE=3D"Arial">Clause 9.3.2, last two =
paragraphs</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #35</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<UL><UL>
<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">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.</FONT></P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">The format of the =
Repertoiremap shall be conformant to clause 9.3.9.</FONT>
</UL></UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial">Change the text to:</FONT>
<UL><UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial">The format of the POSIX =
Locale and Charmap sources shall be conformant to ISO/IEC =
9945-1:2002.</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">A possible format of the =
Repertoiremap is described in clause 9.3.9.</FONT>
</UL></UL>
<P><U><FONT FACE=3D"Arial">Rationale</FONT></U>
<UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial">(a)&nbsp;&nbsp;&nbsp;&nbsp; =
The reference to 9945 is obsolete.</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">(b)&nbsp;&nbsp;&nbsp;&nbsp; =
The US objects to the technique specified in Annex E; it must not be =
part of this standard (see CD2 TECHNICAL OBJECTION #37). </FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">(c)&nbsp;&nbsp;&nbsp;&nbsp; =
As noted before, the TR 14652 Repertoiremap is controversial and shall =
not be a normative part of this standard.</FONT></P>
</UL>
<P><U><B><FONT FACE=3D"Arial">Clause 9.3.3</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL OBJECTION =
#36</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<UL><UL>
<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">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 &quot;i18n&quot; FDCC-set; examples are given =
in annex F).</FONT></P>
</UL></UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial">Substitute this text for the =
current text:</FONT>
<UL><UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial">The POSIX Locale and FDCC-set =
shall define all standard categories.</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">Individual categories may be =
copied from another Locale or FDCC-set. See Annex G for =
examples.</FONT>
</UL></UL>
<P><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Rationale</FONT></U><FONT =
COLOR=3D"#000000" FACE=3D"Arial">: Annex F contains information on the =
&quot;reorder-after&quot; construct; not examples of POSIX locales or =
FDCC-sets. Annex G contains sample POSIX locales, but not FDCC-sets. =
</FONT></P>

<P><U><B><FONT FACE=3D"Arial">Clause 9.3.4</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL OBJECTION =
#37</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<UL><UL>
<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">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...</FONT></P>
</UL></UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial">The US objected to this =
during the previous ballot, and we renew our objection. </FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">Remove the second sentence =
&quot;For enhanced network portability...&quot;</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Rationale</FONT></U><FONT =
COLOR=3D"#000000" FACE=3D"Arial">: 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: </FONT></P>

<P><B><FONT COLOR=3D"#000000" FACE=3D"Arial">Not =
accepted.</FONT></B><FONT COLOR=3D"#000000" FACE=3D"Arial"> This is =
aligned with other specs in the field.</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">However, it is</FONT><U> =
<FONT COLOR=3D"#000000" FACE=3D"Arial">not</FONT></U> <FONT =
COLOR=3D"#000000" FACE=3D"Arial">aligned with the standard which =
invented POSIX locales and charmaps. This difference is egregious and =
unacceptable.</FONT></P>

<P><FONT FACE=3D"Arial">The US also notes that the Editor provided no =
information about the "other specs in the field" which he used to =
justify the rejection.</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #38</FONT>
<BR><FONT FACE=3D"Arial">Add this sentence at the end of the clause, =
following "...character names defined in a Repertoiremap shall be =
used."</FONT>
<BR><FONT FACE=3D"Arial">A TR 14652 Repertoiremap shall not be =
used.</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
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.</FONT></P>

<P><U><B><FONT FACE=3D"Arial">Clause 9.3.7, second and third =
paragraphs</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL OBJECTION =
#39</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<UL><UL>
<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">For Types 1, 2, and =
5, Narrative Cultural Specifications, POSIX Locales, and FDCC-sets and =
other formal descriptions of cultural conventions: . . .</FONT></P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">For Types 3, 4, and =
6, POSIX Charmaps, Repertoiremaps, and TR 14652 Charmaps and other =
formal descriptions of character sets: . . .</FONT></P>
</UL></UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial">Revise the text as =
follows:</FONT>
<UL><UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial">For Types 1, 2, and 5, =
Narrative Cultural Specifications, POSIX Locales, and Machine-parsable =
cultural specifications: . . .</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">For Types 3, 4, and 6, POSIX =
Charmaps, Repertoiremaps, and Machine-parsable coded character set =
specifications: . . .</FONT>
</UL></UL>
<P><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Rationale:</FONT></U><FONT =
COLOR=3D"#000000" FACE=3D"Arial"> 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. </FONT></P>

<P><U><B><FONT FACE=3D"Arial">Clause 9.3.7, third =
paragraph</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #40</FONT>
<BR><FONT FACE=3D"Arial">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:"</FONT></P>

<P><FONT FACE=3D"Arial">A TR 14652 Repertoiremap shall not be =
used.</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
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.</FONT></P>

<P><U><B><FONT FACE=3D"Arial">Clause 9.3.7, third paragraph from end =
(begins "Note:")</FONT></B></U>
<BR><FONT FACE=3D"Arial">CD2 TECHNICAL #41</FONT>
<BR><FONT FACE=3D"Arial">Change "U0020..U007E" to =
"U+0020..U+007E"</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale:</FONT></U> <FONT =
FACE=3D"Arial">ISO/IEC 10646 conventions.</FONT>
</P>

<P><U><B><FONT FACE=3D"Arial">Clause 9.3.7, last =
paragraph</FONT></B></U>
<BR><FONT FACE=3D"Arial">CD2 TECHNICAL #42</FONT>
<BR><FONT FACE=3D"Arial">The final paragraph of clause 9.3.7 =
states:</FONT>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Annex A specifies a form to be filled =
out for each Cultural Specification; Annex B gives an example of a =
completed form."</FONT></P>
</UL></UL>
<P><FONT FACE=3D"Arial">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:</FONT></P>
<UL><UL>
<P><FONT FACE=3D"Arial">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.</FONT></P>
</UL></UL>
<P><U><B><FONT FACE=3D"Arial">Clause 9.3.8, third and sixth =
paragraphs</FONT></B></U>
<BR><FONT FACE=3D"Arial">CD2 TECHNICAL #43</FONT>
<BR><FONT FACE=3D"Arial">"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?</FONT></P>

<P><U><B><FONT FACE=3D"Arial">Clause 9.3.9</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL OBJECTION =
#44</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<UL><UL>
<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">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 &lt;&gt;, 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&quot; followed by one =
or more spaces or tabs and then the escape character.</FONT></P>
</UL></UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial">Revise the text as =
follows:</FONT>
<UL><UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial">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 &lt;&gt;, 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.</FONT></P>
</UL></UL>
<P><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Rationale:</FONT></U><FONT =
COLOR=3D"#000000" FACE=3D"Arial"> There are several problems with this =
clause:</FONT>
<UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial">(a)&nbsp;&nbsp;&nbsp;&nbsp; =
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. </FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">(b)&nbsp;&nbsp;&nbsp;&nbsp; =
The previous U.S. objection to referring to the character names in =
ISO/IEC 9945-2:1993 Annex G was rejected with this comment: &quot;Not =
accepted. There is a reason, namely that you then can reuse a lot of =
data.&quot; 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.</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">(c)&nbsp;&nbsp;&nbsp;&nbsp; =
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.</FONT></P>
</UL>
<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">Clause 9.4 Contents of a =
Narrative Cultural Specification</FONT></B></U></P>

<P><U><B><FONT FACE=3D"Arial">Introductory paragraph, first and second =
sentences:</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL OBJECTION =
#45</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<UL><UL>
<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">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.</FONT></P>
</UL></UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial">Revise the text as =
follows:</FONT>
<UL><UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial">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.</FONT></P>
</UL></UL>
<P><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Rationale:</FONT></U> =
<FONT COLOR=3D"#000000" FACE=3D"Arial">The POSIX reference is =
out-of-date, there is a grammatical error, and a typo.</FONT>
</P>

<P><U><B><FONT FACE=3D"Arial">Introductory paragraph, </FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial">third and fourth =
sentences:</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #46</FONT>
<BR><FONT FACE=3D"Arial">In CD1 OBJECTION #44, the US proposed changing =
the sentence </FONT>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;. . Clauses 1 to 6 are related =
to POSIX and the narrative description should be accompanied by a =
corresponding POSIX Locale specification.</FONT></P>
</UL></UL>
<P><FONT FACE=3D"Arial">to</FONT>
<BR><FONT FACE=3D"Arial">Clauses 1 through 6 are related to =
POSIX.</FONT>
<BR><FONT FACE=3D"Arial">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:</FONT></P>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">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.</FONT></P>
</UL></UL>
<P><FONT FACE=3D"Arial">Strike these two sentences and replace them =
with this text.</FONT>
<UL><UL>
<P><FONT FACE=3D"Arial">Clauses 1 to 6 are related to POSIX. When a =
POSIX locale is submitted, it should be accompanied by a corresponding =
narrative cultural specification.</FONT></P>
</UL></UL>
<P><FONT FACE=3D"Arial">Note that "is desirable" is not needed because =
use of "should" is specified in Table G.2 of Annex G</FONT><I> <FONT =
FACE=3D"Arial">Verbal forms for the expression of provisions</FONT></I> =
<FONT FACE=3D"Arial">in</FONT><I> <FONT FACE=3D"Arial">ISO/IEC =
Directives, Part 2: Rules for the structure and drafting of =
International Standards</FONT></I><FONT FACE=3D"Arial">:</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">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.</FONT></P>

<P><U><B><FONT FACE=3D"Arial">Clause 3: Numeric =
formatting</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL OBJECTION =
#47</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<UL><UL>
<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Here it is described =
how numbers are keyed in and formatted,. . .This is a POSIX =
category.</FONT>
</UL></UL>
<P><FONT FACE=3D"Arial">Delete current text and substitute:</FONT>
<UL><UL>
<P><FONT FACE=3D"Arial">This clause describes how numbers are =
formatted, including the format of the decimal point and the thousands =
separator. This is a POSIX category.</FONT></P>
</UL></UL>
<P><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Rationale:</FONT></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">POSIX contains no =
information about how numbers are &quot;keyed in&quot;, 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</FONT><I> <FONT COLOR=3D"#000000" FACE=3D"Arial">Numbering, =
ordinals and</FONT></I><FONT COLOR=3D"#000000" =
FACE=3D"Arial"></FONT><I> <FONT COLOR=3D"#000000" =
FACE=3D"Arial">measuring systems</FONT></I><FONT COLOR=3D"#000000" =
FACE=3D"Arial">, since it isn't part of this POSIX category. =
(</FONT><FONT FACE=3D"Arial">See comment on Clause 20 for proposed text =
addressing how numbers are "keyed in".)</FONT></P>

<P><U><B><FONT FACE=3D"Arial">Clauses 7 through 32</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #48</FONT>
<BR><FONT FACE=3D"Arial">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.)</FONT></P>

<P><U><FONT FACE=3D"Arial">Rationale:</FONT></U><FONT FACE=3D"Arial"> =
Such guidance is particularly important now that the material from CD1 =
Annex G has been raised to normative status.</FONT></P>

<P><FONT FACE=3D"Arial">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.</FONT></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">New clauses on =
Registration procedures</FONT></B></U><U><B><I></I></B></U></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #49</FONT>
<BR><U><B><FONT FACE=3D"Arial">Minimum requirements:</FONT></B></U>
<UL>
<P><FONT FACE=3D"Arial">1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Make clause =
7.4</FONT><I> <FONT FACE=3D"Arial">Registration =
Procedure</FONT></I><FONT FACE=3D"Arial"> into a top-level clause and =
move it so that it immediately precedes clause 10</FONT><I> <FONT =
FACE=3D"Arial">Appeal procedures</FONT></I><FONT =
FACE=3D"Arial">.</FONT></P>

<P><FONT FACE=3D"Arial">2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Expand the =
text of clause 7.4</FONT><I> <FONT FACE=3D"Arial">Registration =
Procedure</FONT></I><FONT FACE=3D"Arial"> to provide a</FONT><U> <FONT =
FACE=3D"Arial">complete</FONT></U><FONT FACE=3D"Arial"> 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.</FONT></P>

<P><FONT FACE=3D"Arial">3)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Change its =
title to</FONT><I> <FONT FACE=3D"Arial">Registration =
procedures.</FONT></I><FONT FACE=3D"Arial"> </FONT>
</UL>
<P><U><FONT FACE=3D"Arial">Rationale:</FONT></U><FONT FACE=3D"Arial"> =
</FONT>
<UL><UL><UL>
<P><FONT FACE=3D"Arial">(a)&nbsp;&nbsp;&nbsp;&nbsp; Relocating clause =
7.4 brings all procedures together in successive clauses.</FONT>
<BR><FONT FACE=3D"Arial">(b)&nbsp;&nbsp;&nbsp;&nbsp; This is a =
procedural standard, so should specify procedures completely and =
clearly.</FONT>
<BR><FONT FACE=3D"Arial">(c)&nbsp;&nbsp;&nbsp;&nbsp; Title change for =
consistency with the title of clause 10.</FONT>
</UL></UL></UL>
<P><U><B><FONT FACE=3D"Arial">Alternative preference:</FONT></B></U>
<BR><FONT FACE=3D"Arial">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</FONT><I> =
<FONT FACE=3D"Arial">Appeal procedures</FONT></I><FONT FACE=3D"Arial">. =
The individual clauses are specified in the next two =
comments.</FONT></P>

<P><U><FONT FACE=3D"Arial">Rationale (in addition to items a-c =
above):</FONT></U> <FONT FACE=3D"Arial">To make the standard easier to =
use.</FONT>
</P>

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

<P><FONT FACE=3D"Arial">&lt;begin proposed text&gt;</FONT>
<BR><FONT FACE=3D"Arial">x.1 The Sponsoring Authority shall prepare an =
application for registration according to clause 9.</FONT>
<BR><FONT FACE=3D"Arial">x.2 The Sponsoring Authority shall submit an =
application for registration of a cultural specification to the =
Registration Authority.</FONT></P>

<P><FONT FACE=3D"Arial">x.3 The Registration Authority shall examine =
each application received. It shall ascertain that</FONT>
<BR><FONT FACE=3D"Arial">- 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.</FONT></P>

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

<P><FONT FACE=3D"Arial">- The application includes the elements =
required from the Sponsoring Authority for the cover page. See clause =
&lt;XXX&gt;.</FONT>
<BR><FONT FACE=3D"Arial">- The application for registration includes =
any required copyright permissions and endorsements. See clause =
&lt;XXX&gt;.</FONT>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">x.5 The Registration Authority shall submit the =
application to the RA-JAC for the technical review. The RA-JAC shall =
ascertain that</FONT></P>

<P><FONT FACE=3D"Arial">- The application is technically in accordance =
with this International Standard.</FONT>
<BR><FONT FACE=3D"Arial">- The application for registration includes =
the required description of the cultural specification. See clause =
&lt;XXX&gt;.</FONT>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">x.7 The Registration Authority shall inform the =
Sponsoring Authority of any changes needed to satisfy the concerns of =
the RA-JAC.</FONT></P>

<P><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">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 &lt;x.8&gt; into the final =
registration.</FONT></P>

<P><FONT FACE=3D"Arial">x.10 The Registration Authority shall approve =
or reject the application for registration.</FONT>
<BR><FONT FACE=3D"Arial">x.11 The Registration Authority shall process =
approved applications in accordance with clause &lt;Y&gt;.</FONT>
<BR><FONT FACE=3D"Arial">x.12 When an application for registration is =
rejected, the Registration Authority shall inform the Sponsoring =
Authority and provide the reason for the rejection.</FONT></P>

<P><FONT FACE=3D"Arial">&lt;end proposed text&gt;</FONT>
</P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #51</FONT>
<BR><FONT FACE=3D"Arial">This comment describes the second clause =
preferred by the US.</FONT>
<BR><FONT FACE=3D"Arial">Insert a new clause with the title</FONT><I> =
<FONT FACE=3D"Arial">Processing of an approved =
application</FONT></I><FONT FACE=3D"Arial"> between the new =
clause</FONT><I> <FONT FACE=3D"Arial">Initial registration =
procedures</FONT></I><FONT FACE=3D"Arial"> and clause 10</FONT><I> =
<FONT FACE=3D"Arial">Appeal procedures</FONT></I><FONT =
FACE=3D"Arial">.</FONT></P>

<P><FONT FACE=3D"Arial">The following proposed text is primarily from =
clause Y.</FONT><I> <FONT FACE=3D"Arial">Processing of an approved =
application</FONT></I><FONT FACE=3D"Arial"> in N 945R. "y" indicates =
the number that identifies this clause as a whole.</FONT></P>

<P><FONT FACE=3D"Arial">&lt;begin proposed text&gt;</FONT>
<BR><FONT FACE=3D"Arial">Following approval of an application for =
registration, the Registration Authority shall:</FONT>
<BR><FONT FACE=3D"Arial">y.1 Assign a new Cultural Specification =
identifier as follows:</FONT>
<BR><FONT FACE=3D"Arial">- 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.</FONT></P>

<P><FONT FACE=3D"Arial">- No identifiers shall be reserved for future =
registration applications.</FONT>
<BR><FONT FACE=3D"Arial">- An identifier, once allocated to a =
registration, shall never be re-allocated for another =
registration.</FONT>
<BR><FONT FACE=3D"Arial">y.2 The Registration Authority may also assign =
one or more token identifiers to the approved registration.</FONT>
<BR><FONT FACE=3D"Arial">- 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;</FONT></P>

<P><FONT FACE=3D"Arial">y.3 The Registration Authority shall note the =
date of approval in the registration.</FONT>
<BR><FONT FACE=3D"Arial">y.4 The Registration Authority shall publish =
the approved registration in the ISO/IEC 15893 register.</FONT>
<BR><FONT FACE=3D"Arial">y.5 The Registration Authority shall notify =
the Sponsoring Authority of the publication of the registration.</FONT>
<BR><FONT FACE=3D"Arial">y.6 The Registration Authority shall announce =
publication of the registration to subcommittee responsible for =
maintaining this standard.</FONT></P>

<P><FONT FACE=3D"Arial">&lt;end proposed text&gt;</FONT>
</P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">10.1 Appeals against =
rejection</FONT></B></U></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL OBJECTION =
#52</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<UL><UL>
<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">The Registration =
Authority shall accept an appeal from the Sponsoring Authority against =
rejection of an application, but only for this reason:</FONT></P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">- disagreement with =
the Registration Authority on whether the application meets the =
technical or administrative requirements for a registration in clause =
9.</FONT></P>
</UL></UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial">Reword as:</FONT>
<UL><UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial">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.</FONT></P>
</UL></UL>
<P><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Rationale:</FONT></U><FONT =
COLOR=3D"#000000" FACE=3D"Arial"> Unclear text; </FONT>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">Appeals against =
registration</FONT></B></U></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #53</FONT>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">To remedy this oversight:</FONT>
<UL>
<P><FONT COLOR=3D"#000000" =
FACE=3D"Arial">1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Renumber clauses 10.2 =
through 10.4 as 10.3 through 10.5.</FONT>
<BR><FONT COLOR=3D"#000000" =
FACE=3D"Arial">2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Insert clause =
10.2</FONT><I> <FONT FACE=3D"Arial">Appeals against =
registration</FONT></I><FONT FACE=3D"Arial"> with the following text =
and numbering:</FONT>
</UL>
<P><FONT FACE=3D"Arial">&lt;begin text&gt;</FONT>
<BR><FONT FACE=3D"Helvetica">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.</FONT></P>

<P><FONT FACE=3D"Helvetica">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:</FONT></P>
<UL>
<P><FONT FACE=3D"Helvetica">1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
disagreement with the Registration Authority on whether the application =
meets the technical or administrative requirements for a registration =
in clauses &lt;as specified in clause 9&gt;.</FONT></P>

<P><FONT FACE=3D"Helvetica">2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
disagreement with the Registration Authority on whether the application =
matches an existing registration.</FONT>
<BR><FONT FACE=3D"Helvetica">3)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
disagreement on the correctness of some of the information in the =
cultural specification of the application.</FONT>
</UL>
<P><FONT FACE=3D"Helvetica">&lt;end text&gt;</FONT>
</P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">10.3 Procedure for filing =
an appeal</FONT></B></U></P>

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

<P><FONT FACE=3D"Arial">First bullet: Change "90" to "30"</FONT>
<BR><FONT FACE=3D"Arial">Second bullet: Change "90" to "30"</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
These are the periods in ISO/IEC 2375: 200x.</FONT>
</P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">10.4 Resolution of an =
appeal</FONT></B></U></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #55</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">Most of clause 7.5</FONT><I> =
<FONT COLOR=3D"#000000" FACE=3D"Arial">Resolution of an =
appeal</FONT></I><FONT COLOR=3D"#000000" FACE=3D"Arial"> was =
incorporated into the CD2, but clause 7.5.3 (dealing with resolution of =
an</FONT> <FONT FACE=3D"Arial">objection by a National Body to =
forthcoming publication of a registration) was omitted. To correct this =
error:</FONT></P>
<UL>
<P><FONT COLOR=3D"#000000" =
FACE=3D"Arial">1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Renumber clause 10.4.3 =
as 10.4.4</FONT>
<BR><FONT COLOR=3D"#000000" =
FACE=3D"Arial">2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Insert clause 10.4.3 =
and the following text (from clause 7.5.3 in N 945R)</FONT>
</UL>
<P><FONT FACE=3D"Arial">&lt;begin text&gt;</FONT>
<BR><FONT FACE=3D"Helvetica">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.</FONT></P>

<P><FONT FACE=3D"Arial">&lt;end text&gt;</FONT>
</P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #56</FONT>
<BR><U><B><FONT FACE=3D"Arial">Clause 10.4.4 (=3D 10.4.3 in CD2 =
15897):</FONT></B></U>
<BR><FONT FACE=3D"Arial">Make the following two changes to this =
clause:</FONT>
<BR><FONT FACE=3D"Arial">1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Delete the =
following text (including the misspelling of "receipt"):</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">by the Registration Authority within =
90 days after the reciept of an appeal</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
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.)</FONT></P>

<P><FONT FACE=3D"Arial">2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Change this =
text:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to decide according to its voting =
procedures.</FONT>
<BR><FONT FACE=3D"Arial">to</FONT>
<BR><FONT FACE=3D"Arial">according to the</FONT><I> <FONT =
FACE=3D"Arial">Procedures for the technical work of ISO/IEC JTC =
1</FONT></I><FONT FACE=3D"Arial">.</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
Since this is a JTC 1 standard, JTC 1 procedures apply. The same =
wording appears in ISO/IEC 2375:200x.</FONT>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">11 The Registration =
Authority's Joint Advisory Committee</FONT></B></U></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #57</FONT>
<BR><FONT FACE=3D"Arial">Relocate this clause immediately after clause =
8</FONT><I> <FONT FACE=3D"Arial">Sponsoring Authority.</FONT></I>
<BR><U><FONT FACE=3D"Arial">Rationale:</FONT></U><FONT FACE=3D"Arial"> =
Brings all agencies defined by this standard together.</FONT>
</P>

<P><FONT FACE=3D"Arial">Note: For the convenience of reviewers, other =
changes to the text of clause 11 of the CD2 are described here.</FONT>
</P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">Clause =
11.1</FONT></B></U></P>

<P><FONT FACE=3D"Arial">CD2 TECHNICAL #58</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">Make the following changes =
to this clause:</FONT>
<BR><FONT FACE=3D"Arial">1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Add this =
title:</FONT>
<BR><FONT FACE=3D"Arial">Membership</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
For consistency with changes to clauses 11.2 and 11.3.</FONT>
<BR><FONT FACE=3D"Arial">2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Delete the =
last paragraph:</FONT>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">The Registration Authority may request =
the RA-JAC to provide expert technical advice on comments.</FONT>
</UL></UL>
<P><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
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.</FONT></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">Clause =
11.2</FONT></B></U></P>

<P><FONT FACE=3D"Arial">CD2 TECHNICAL #59</FONT>
<BR><FONT FACE=3D"Arial">Add this title to clause 11.2:</FONT>
<BR><FONT FACE=3D"Arial">Appointment</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
For consistency with other clauses describing agencies (for example, =
7</FONT><I> <FONT FACE=3D"Arial">Registration Authority</FONT></I><FONT =
FACE=3D"Arial">).</FONT>
</P>

<P><U><B><FONT FACE=3D"Arial">Clause 11.2, first =
paragraph</FONT></B></U>
<BR><FONT FACE=3D"Arial">CD2 TECHNICAL #60</FONT>
<BR><U><FONT FACE=3D"Arial">Current text:</FONT></U>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">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.</FONT></P>
</UL></UL>
<P><FONT FACE=3D"Arial">N 945R says to delete this phrase:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">except for the RA =
representative.</FONT>
<BR><FONT FACE=3D"Arial">because there is no indication of who appoints =
the RA representative to the Joint Advisory Committee. The resulting =
paragraph then specifies that</FONT><U> <FONT =
FACE=3D"Arial">all</FONT></U> <FONT FACE=3D"Arial">members of the Joint =
Advisory Committee (</FONT><U><FONT FACE=3D"Arial">including the =
individual who represents the RA</FONT></U><FONT FACE=3D"Arial">) are =
appointed by the subcommittee responsible for maintaining this standard =
(i.e., by SC22).</FONT></P>

<P><FONT FACE=3D"Arial">The Editor did not delete the phrase and added =
a clarification, so that the corresponding text in the CD2 now =
reads:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">except for the RA representative, =
which is appointed by the RA.</FONT>
<BR><FONT FACE=3D"Arial">This new text is unacceptable to the US for =
the following reasons:</FONT>
<UL>
<P><FONT FACE=3D"Arial">a)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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:</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">The subcommitee shall appoint or =
confirm the members of the RA-JAC at its plenary meetings.</FONT>
</UL>
<P><FONT FACE=3D"Arial">b)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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.</FONT></P>

<P><FONT FACE=3D"Arial">c)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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".</FONT></P>
</UL>
<P><U><B><FONT FACE=3D"Arial">Clause 11.2, second =
paragraph</FONT></B></U>
<BR><FONT FACE=3D"Arial">CD2 TECHNICAL #61</FONT>
<BR><FONT FACE=3D"Arial">Insert this text after "subcommittee"</FONT>
<BR><FONT FACE=3D"Arial">responsible for maintaining this =
standard</FONT>
<BR><FONT FACE=3D"Arial">to indicate explicitly which subcommittee =
makes the appointments.</FONT>
</P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">Clause =
11.3</FONT></B></U></P>

<P><FONT FACE=3D"Arial">CD2 TECHNICAL #62</FONT>
<BR><FONT FACE=3D"Arial">Add this title to clause 11.3:</FONT>
<BR><FONT FACE=3D"Arial">Responsibilities</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
For consistency with other clauses describing agencies (for example, =
7</FONT><I> <FONT FACE=3D"Arial">Registration Authority</FONT></I><FONT =
FACE=3D"Arial">).</FONT>
</P>

<P><FONT FACE=3D"Arial">CD2 TECHNICAL #63</FONT>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">&lt;begin text&gt;</FONT>
<BR><FONT FACE=3D"Arial">-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to =
determine whether an application for registration meets the technical =
requirements of clause 9;</FONT>
<BR><FONT FACE=3D"Arial">-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to =
provide expert technical advice on comments if requested by the =
Registration Authority;</FONT>
<BR><FONT FACE=3D"Arial">-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to =
consider and vote on appeals received by the Registration =
Authority;</FONT>
<BR><FONT FACE=3D"Arial">-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to act =
as a mediator between the Registration Authority and the appealing =
party, or parties.</FONT>
<BR><FONT FACE=3D"Arial">In addition, the RA-JAC may added comments to =
a registration.</FONT>
<BR><FONT FACE=3D"Arial">&lt;end text&gt;</FONT>
</P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">Additional clauses</FONT></=
B></U></P>

<P><FONT FACE=3D"Arial">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.</FONT></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">New clause: 12 =
Corrections</FONT></B></U></P>

<P><FONT FACE=3D"Arial">CD2 TECHNICAL #64</FONT>
<BR><FONT FACE=3D"Arial">Add a new clause with the title:</FONT>
<BR><FONT FACE=3D"Arial">Corrections</FONT>
<BR><FONT FACE=3D"Arial">and the following text (from the corresponding =
clause in N 945R):</FONT>
<BR><FONT FACE=3D"Helvetica">&lt;begin text&gt;</FONT>
<BR><FONT FACE=3D"Helvetica">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.</FONT></P>

<P><FONT FACE=3D"Helvetica">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.</FONT></P>

<P><FONT FACE=3D"Helvetica">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.</FONT></P>

<P><FONT FACE=3D"Helvetica">&lt;end text&gt;</FONT>
</P>

<P><FONT FACE=3D"Arial">Note that this clause</FONT> <FONT =
FACE=3D"Helvetica">conflicts with the idea expressed in clause 5.5 that =
a new registration is required to make a "correction", presumably even =
a typographic correction.</FONT></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">New clause: 13 =
Revisions</FONT></B></U></P>

<P><FONT FACE=3D"Arial">CD2 TECHNICAL #65</FONT>
<BR><FONT FACE=3D"Arial">Add a new clause with the title:</FONT>
<BR><FONT FACE=3D"Arial">Revisions</FONT>
<BR><FONT FACE=3D"Arial">and the following text (from the corresponding =
clause in N 945R):</FONT>
<BR><FONT FACE=3D"Helvetica">&lt;begin text&gt;</FONT>
<BR><FONT FACE=3D"Helvetica">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.</FONT></P>

<P><FONT FACE=3D"Helvetica">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.</FONT></P>

<P><FONT FACE=3D"Helvetica">&lt;end text&gt;</FONT>
</P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">New clause: 14 Additions =
to an existing registration</FONT></B></U></P>

<P><FONT FACE=3D"Arial">CD2 TECHNICAL #66</FONT>
<BR><FONT FACE=3D"Arial">Add a new clause with the title:</FONT>
<BR><FONT FACE=3D"Arial">Additions to an existing registration</FONT>
<BR><FONT FACE=3D"Arial">and the following text (from CD2, clause 7.4, =
item f):</FONT>
<BR><FONT FACE=3D"Helvetica">&lt;begin text&gt;</FONT>
<BR><FONT FACE=3D"Arial">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;</FONT></P>

<P><FONT FACE=3D"Helvetica">&lt;end text&gt;</FONT>
</P>

<P><FONT FACE=3D"Arial">The Editor is requested to supply text =
describing the procedures to be followed in these situations:</FONT>
<UL>
<P><FONT FACE=3D"Arial">1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A Sponsoring =
Authority wishes to augment an approved registration which it =
submitted; or </FONT>
<BR><FONT FACE=3D"Arial">2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A Sponsoring =
Authority wishes to augment an approved registration which was =
submitted by another Sponsoring Authority.</FONT></P>
</UL>
<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">New clause: 15 =
Withdrawal</FONT></B></U></P>

<P><FONT FACE=3D"Arial">CD2 TECHNICAL #67</FONT>
<BR><FONT FACE=3D"Arial">Add a new clause with the title:</FONT>
<BR><FONT FACE=3D"Arial">Withdrawal</FONT>
<BR><FONT FACE=3D"Arial">and the following text (based on the =
corresponding clause in N 945R):</FONT>
<BR><FONT FACE=3D"Helvetica">&lt;begin text&gt;</FONT>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

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

<P><FONT FACE=3D"Arial">15.4 Withdrawal of an entire existing =
registration</FONT>
<BR><FONT FACE=3D"Arial">15.4.1 After withdrawal, the registration =
shall remain in the register and continue to be identified by the =
allocated numeric identifier.</FONT></P>

<P><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">15.4.3 The Registration Authority shall inform =
the subcommittee responsible for maintaining this standard interested =
parties of the withdrawal of a registration.</FONT></P>

<P><FONT FACE=3D"Arial">15.5 Withdrawal of part of an existing =
application</FONT>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">15.4.3 The Registration Authority shall inform =
the subcommittee responsible for maintaining this standard interested =
parties of the withdrawal of a registration.</FONT></P>

<P><FONT FACE=3D"Helvetica">&lt;end text&gt;</FONT>
</P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">Annex A Application form =
for a Cultural Specification</FONT></B></U></P>

<P><FONT FACE=3D"Arial">Items 8, 9 and 10</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL OBJECTION =
#68</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<UL><UL>
<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">For Narrative =
Cultural Specifications, POSIX Locales or FDCC-sets and other formal =
descriptions of cultural conventions (type 1, 2, and 5): . . =
.</FONT></P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">For POSIX Charmaps, =
Repertoiremaps, or TR 14652 Charmap and other formal descriptions of =
character sets (type 3, 4 and 6):. . .</FONT></P>
</UL></UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial">Revise the text as =
follows:</FONT>
<UL><UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial">For Narrative Cultural =
Specifications, POSIX Locales or Machine parsable cultural =
specifications (type 1, 2, and 5): . . .</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">For POSIX Charmaps, =
Repertoiremaps, or Machine-parsable coded character set specifications =
(type 3, 4 and 6):. . .</FONT>
</UL></UL>
<P><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Rationale:</FONT></U><FONT =
COLOR=3D"#000000" FACE=3D"Arial"> 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. </FONT></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">Annex C External =
References to Cultural Specifications</FONT></B></U></P>

<P><U><B><FONT FACE=3D"Arial">C.3 Object Descriptors</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Times New Roman">CD2 TECHNICAL =
OBJECTION #69</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">The object =
descriptors for the abstract syntax object identifiers defined in 2 =
above shall be . . ., as assigned per clause 4 responsibility =
g):</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">Change the reference to: =
</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">...as assigned in clause =
7.4, responsibility f):</FONT>
<BR><U><FONT COLOR=3D"#000000" =
FACE=3D"Arial">Rationale:</FONT></U><FONT COLOR=3D"#000000" =
FACE=3D"Arial"> The reference is incorrect. </FONT>
</P>

<P><U><B><FONT FACE=3D"Arial">C.4 Transfer Syntax</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL OBJECTION =
#70</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<UL><UL>
<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">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.</FONT></P>
</UL></UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial">Change the text as =
follows:</FONT>
<UL><UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial">When transferring the =
contents of a registry entry over a network, data shall be encoded in =
the UTF-8 form of ISO/IEC 10646.</FONT></P>
</UL></UL>
<P><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Rationale:</FONT></U> =
<FONT COLOR=3D"#000000" FACE=3D"Arial">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. </FONT></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">Annex D Sample Narrative =
Cultural Specification for Danish and Irish</FONT></B></U></P>

<P><FONT FACE=3D"Arial">See Appendix 4 for comments on individual =
clauses in these examples.</FONT>
</P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">General comments on Annex =
D</FONT></B></U></P>

<P><FONT FACE=3D"Arial">CD2 TECHNICAL #71</FONT>
<BR><U><FONT FACE=3D"Arial">1. Confusing title</FONT></U>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">The US recommends that the title of this annex =
indicate the nature of the content of this annex.</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale:</FONT></U>
<BR><FONT FACE=3D"Arial">Clarifies the content of the annex.</FONT>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><U><FONT FACE=3D"Arial">2. Defective or outdated =
information</FONT></U>
<BR><FONT FACE=3D"Arial">CD2 TECHNICAL #72</FONT>
<BR><FONT FACE=3D"Arial">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).</FONT></P>

<P><U><FONT FACE=3D"Arial">3. Concerns about status of =
examples</FONT></U>
<BR><FONT FACE=3D"Arial">CD2 TECHNICAL #73</FONT>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">Clause D.1 is entitled "Danish language locale =
for Denmark, Narrative Cultural Specification". </FONT>
<BR><FONT FACE=3D"Arial">There is a published "Danish language locale =
for Denmark, Narrative Cultural Specification" (</FONT><U><FONT =
COLOR=3D"#0000FF" FACE=3D"Arial">&lt;<A =
HREF=3D"http://anubis.dkuug.dk/cultreg/registrations/number/2" =
TARGET=3D"_blank">http://anubis.dkuug.dk/cultreg/registrations/number/2<=
/A>&gt;</FONT></U><FONT FACE=3D"Arial">), but it predates ISO/IEC =
15897:1999, the first edition of this standard.</FONT></P>

<P><FONT FACE=3D"Arial">Clause D.1 must therefore show the narrative =
cultural specification from a new application (under ISO/IEC 15897) for =
"Danish language locale for Denmark".</FONT></P>

<P><FONT FACE=3D"Arial">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:</FONT></P>

<P><FONT FACE=3D"Arial">In CD2 - Source: Dansk Standard, date: =
2002-10-08, version: 2.5</FONT>
<BR><FONT FACE=3D"Arial">In CD1 - Source: Dansk Standard, date: =
1994-07-28, version: 2.4</FONT>
<BR><FONT FACE=3D"Arial">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.)</FONT></P>

<P><FONT FACE=3D"Arial">CD2 TECHNICAL #74</FONT>
<BR><FONT FACE=3D"Arial">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)".</FONT></P>

<P><FONT FACE=3D"Arial">The US recommends that clause D.2 be deleted =
until the following two conditions are met:</FONT>
<UL>
<P><FONT FACE=3D"Arial">1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the content of =
the narrative cultural specification has been finalized, that is, it is =
no longer "draft"</FONT>
<BR><FONT FACE=3D"Arial">2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the narrative =
cultural specification has been officially approved as correct for =
Ireland by the National Standards Authority of Ireland according to its =
formal procedures.</FONT></P>
</UL>
<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">Annexes E and =
F</FONT></B></U></P>
<UL><UL><UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Symbol">&#183;<FONT FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></FONT> <FONT =
COLOR=3D"#000000" FACE=3D"Arial">Annex E,</FONT><I> <FONT =
COLOR=3D"#000000" FACE=3D"Arial">&quot;reorder-after&quot; construct in =
POSIX LC_COLLATE</FONT></I>
<BR><FONT COLOR=3D"#000000" FACE=3D"Symbol">&#183;<FONT FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></FONT> <FONT =
COLOR=3D"#000000" FACE=3D"Arial">Annex F</FONT><I> <FONT =
COLOR=3D"#000000" FACE=3D"Arial">Information on =
&quot;reorder-after&quot; construct in LC_COLLATE)</FONT></I>
</UL></UL></UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Times New Roman">CD2 TECHNICAL =
#75</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">Remove both Annex E and =
Annex F.</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">The US objected to these =
Annexes in CD1 Objections #39 and #41.</FONT>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial"># 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.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial"># 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.</FONT></P>
</UL></UL>
<P><FONT FACE=3D"Arial">The Editor rejected both comments, stating as =
his reason:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">These specs are also applicable to =
POSIX locales while 14651 specs are not.</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">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. </FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">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.</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">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).</FONT></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">Clause E.3 Example of =
"reorder-after"</FONT></B></U></P>

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

<P><FONT FACE=3D"Courier">. . .</FONT>
<BR><FONT FACE=3D"Courier">4. Thus for the original sequence</FONT>
<BR><FONT FACE=3D"Courier">...</FONT>
<BR><FONT FACE=3D"Courier">this example reordering gives</FONT>
<BR><FONT FACE=3D"Courier">... Uu Vv Ww Xx ( Yy =DC=FC ) Zz ( =C6=E6 =
=C4=E4 ) =D8=F8 =C5=E5</FONT>
<BR><FONT FACE=3D"Courier">5. . . .</FONT>
<BR><FONT FACE=3D"Courier">the example reordering in E.3.1 gives</FONT>
<BR><FONT FACE=3D"Courier">... ( Uu =D9=F9 =DA=FA ) Vv Ww Xx ( Yy __ =
=DC=FC ) ( Zz Zz )</FONT>
<BR><FONT FACE=3D"Courier">( =C6=E6 ?=C6?=E6 =AF=C6=AF=E6 =C4=E4 ) ( =
=D8=F8 ?=D8?=F8 =D6=F6 ) ( =C5=E5 ( AA Aa aA aa ) ?=C5?=E5 =
)&quot;</FONT>
<BR><FONT FACE=3D"Courier">Problem and Action:</FONT>
<BR><FONT FACE=3D"Courier">So much text is quoted because it is =
completely inconsistent. The example syntax shows &lt;AAand &lt;aa&gt;, =
but not =C5 and =E5 (&lt;A-ringand &lt;a-ring&gt;). The explanation in =
item #2 includes neither the &lt;AA&gt;/&lt;aapair, nor =
&lt;A-ring/&lt;a-ring&gt;. The reordering in item #4 shows =
&lt;A-ring/&lt;a-ring&gt;, but not &lt;AA&gt;/&lt;aa&gt;. The =
reordering in item #5 shows &lt;AA&gt;/&lt;aaand =
&lt;A-ring/&lt;a-ring&gt;.</FONT></P>

<P><FONT FACE=3D"Courier">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.</FONT></P>

<P><B><FONT FACE=3D"Courier">40. Not accepted.</FONT></B><FONT =
FACE=3D"Courier"> Text will not been changed (for now).</FONT>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">Annex H Differences from =
ISO/IEC 15897:1999 and CEN ENV 12005:1996</FONT></B></U></P>

<P><U><B><FONT FACE=3D"Arial">H.2 Changes from CEN ENV =
12005:1996</FONT></B></U>
<BR><FONT FACE=3D"Arial">CD2 TECHNICAL #77</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Problem and =
Action:</FONT></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">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 &quot;In clause 4 the contact =
information for the Registration Authority has been updated&quot;, 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.</FONT></P>

<P ALIGN=3DCENTER><U><B><FONT =
FACE=3D"Arial">Bibliography</FONT></B></U></P>

<P><FONT FACE=3D"Arial">CD2 TECHNICAL #78</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<UL><UL>
<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">2. ISO/IEC TR =
14652:2001 Information technology - Specification method for cultural =
conventions.</FONT>
</UL></UL>
<P><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Problem and =
Action:</FONT></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">This TR was not published in =
2001; it has not yet been published.</FONT>
<BR><I><FONT FACE=3D"Arial">ISO/IEC Directives, Part 2: Rules for the =
structure and drafting of International Standards</FONT></I><FONT =
COLOR=3D"#000000" FACE=3D"Arial"> specify:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">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. </FONT></P>

<P><FONT FACE=3D"Arial">The correct publication year needs to be =
inserted when if it is available.</FONT>
</P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">End of Specific Technical =
Comments</FONT></B></U></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">SPECIFIC EDITORIAL =
COMMENTS</FONT></B></U></P>

<P ALIGN=3DCENTER><U><B><FONT =
FACE=3D"Arial">Foreword</FONT></B></U></P>

<P><FONT FACE=3D"Arial">CD2 EDITORIAL #79</FONT>
<UL>
<P><FONT FACE=3D"Arial">1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Change =
"ISO/IEC 9945-2" to "ISO/IEC 9945-1". </FONT>
</UL>
<P><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
The reference to ISO/IEC 9945-2 refers to an obsolete edition. </FONT>
<UL>
<P><FONT FACE=3D"Arial">2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Change "shell =
and utilities" to "Base Definitions". </FONT>
</UL>
<P><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
In the 2002 version of ISO/IEC 9945, POSIX locales and charmaps are =
covered in</FONT><I> <FONT FACE=3D"Arial">Part 1: Base =
Definitions.</FONT></I>
</P>

<P ALIGN=3DCENTER><U><B><FONT =
FACE=3D"Arial">Introduction</FONT></B></U></P>

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

<P><FONT FACE=3D"Arial">CD2 EDITORIAL #81</FONT>
<BR><FONT FACE=3D"Arial">Second paragraph, second sentence </FONT>
<BR><FONT FACE=3D"Arial">Change "eg" to "for example,"</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
Better style for an introduction.</FONT>
<BR><FONT FACE=3D"Arial">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.)</FONT></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">4 Terms and =
definitions</FONT></B></U></P>

<P><FONT FACE=3D"Arial">CD2 EDITORIAL #82</FONT>
<BR><U><B><FONT FACE=3D"Arial">Arrangement</FONT></B></U>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">It is difficult to see any order in the current =
text, except that locale is superior to all other terms.</FONT>
<BR><FONT FACE=3D"Arial">The specific requirement in the</FONT><I> =
<FONT FACE=3D"Arial">ISO/IEC Directives, Part 2</FONT></I><FONT =
FACE=3D"Arial"> is:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">4.5 Equivalence of official language =
versions</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">There is no stated requirement for the order of =
the</FONT><I> <FONT FACE=3D"Arial">Terms and =
definitions</FONT></I><FONT FACE=3D"Arial"> clause in a document. The =
order of an independent terminology standard "should be preferably =
classified." (clause 6.2.1). However, this clause continues:</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">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).</FONT></P>

<P><FONT FACE=3D"Arial">Note that in Annex E:</FONT><I> <FONT =
FACE=3D"Arial">Registration Definitions and Guidelines for Procedure =
Standards</FONT></I><FONT FACE=3D"Arial"> in</FONT><I> <FONT =
FACE=3D"Arial">Procedures for the technical work of ISO/IEC JTC =
1</FONT></I><FONT FACE=3D"Arial">, the elements in clause E.1</FONT><I> =
<FONT FACE=3D"Arial">Definitions</FONT></I><FONT FACE=3D"Arial"> are =
ordered alphabetically.</FONT></P>

<P><FONT FACE=3D"Arial">This revised standard is being developed in =
English. In a translation, the number assigned to each term</FONT><U> =
<FONT FACE=3D"Arial">must</FONT></U><FONT FACE=3D"Arial"> be retained =
to meet the "structurally identical" requirement of clause 4.5 of =
the</FONT><I> <FONT FACE=3D"Arial">ISO/IEC Directives</FONT></I><FONT =
FACE=3D"Arial">. Variations from the alphabetic order of the language =
of translation should be explained in a Note, for example:</FONT></P>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">NOTE: The order of the terms =
corresponds to their order in the original English language version of =
this standard. </FONT>
</UL></UL>
<P><FONT FACE=3D"Arial">Draft note for the French translation:</FONT>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">NOTE: L'ordre des termes correspond =
=E0 leur ordre dans la version originale d'anglais de cette =
norme.</FONT>
</UL></UL>
<P><FONT FACE=3D"Arial">Draft note for the Russian translation:</FONT>
<UL><UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial =
CYR">&#1055;&#1056;&#1048;&#1052;&#1045;&#1063;&#1040;&#1053;&#1048;&#10=
45;: &#1055;&#1086;&#1088;&#1103;&#1076;&#1086;&#1082; =
&#1090;&#1077;&#1088;&#1084;&#1080;&#1085;&#1086;&#1074; =
&#1089;&#1086;&#1086;&#1090;&#1074;&#1077;&#1090;&#1089;&#1090;&#1074;&#=
1091;&#1077;&#1090; &#1080;&#1093; =
&#1087;&#1086;&#1088;&#1103;&#1076;&#1082;&#1091; &#1074; =
&#1086;&#1088;&#1080;&#1075;&#1080;&#1085;&#1072;&#1083;&#1100;&#1085;&#=
1086;&#1081; &#1074;&#1077;&#1088;&#1089;&#1080;&#1080; =
&#1101;&#1090;&#1086;&#1075;&#1086; =
&#1089;&#1090;&#1072;&#1085;&#1076;&#1072;&#1088;&#1090;&#1072; =
&#1085;&#1072; =
&#1040;&#1085;&#1075;&#1083;&#1080;&#1081;&#1089;&#1082;&#1086;&#1084; =
&#1103;&#1079;&#1099;&#1082;&#1077;.</FONT>
</P>
</UL></UL>
<P><U><B><FONT FACE=3D"Arial">4.7 narrative cultural =
specification</FONT></B></U>
<BR><FONT FACE=3D"Arial">CD2 EDITORIAL #83</FONT>
<BR><FONT FACE=3D"Arial">The definition for "</FONT><U><FONT =
FACE=3D"Arial">narrative cultural specification" was</FONT></U><FONT =
FACE=3D"Arial"> modified in response to CD1 Objection #9. The =
definition now reads:</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">Delete the phrase "pertaining to software use =
on computers". </FONT>
<BR><U><FONT FACE=3D"Arial">Rationale:</FONT></U>
<UL>
<P><FONT FACE=3D"Arial">(a)&nbsp;&nbsp;&nbsp;&nbsp; It could be =
misunderstood as limiting the information only to information about =
("pertaining to") the use of software on computers.</FONT></P>

<P><FONT FACE=3D"Arial">(b)&nbsp;&nbsp;&nbsp;&nbsp; It essentially =
repeats what the second sentence says better.</FONT>
</P>
</UL>
<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">5.4.1 Structure of the =
identifier</FONT></B></U></P>

<P><FONT FACE=3D"Arial">CD2 EDITORIAL #84</FONT>
<BR><FONT FACE=3D"Arial">Change the title of this clause to:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Structure of the identifiers</FONT>
<BR><FONT FACE=3D"Arial">Note that "identifiers" should not be =
capitalized.</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
There are two types of identifiers for registrations.</FONT>
</P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">5.4.2 Reference to an =
approved registration</FONT></B></U></P>

<P><FONT FACE=3D"Arial">CD2 EDITORIAL #85</FONT>
<BR><FONT FACE=3D"Arial">The final sentence is:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Examples are listed in clause 9.3.8. =
</FONT>
<BR><FONT FACE=3D"Arial">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.)</FONT></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">5.5 No modification nor =
deletion of registrations</FONT></B></U></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 EDITORIAL #86</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">The contents of an =
individual registration shall never be changed or deleted once it has =
been registered (except for name additions)...</FONT></P>

<P><FONT FACE=3D"Arial">Change "it has been registered" to "the =
application for registration has been approved".</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Rationale</FONT></U><FONT =
COLOR=3D"#000000" FACE=3D"Arial">: </FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">Incorrect grammar =
(plural/singular mismatch)</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">The point at which further =
changes are prohibited is when the application is approved. The =
rewording makes this clear.</FONT>
</P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">7.3 =
Identity</FONT></B></U></P>

<P><FONT FACE=3D"Arial">CD2 EDITORIAL #87</FONT>
<BR><FONT FACE=3D"Arial">Change the URL for</FONT><I> <FONT =
FACE=3D"Arial">Maintenance agencies and registration =
authorities</FONT></I><FONT FACE=3D"Arial"> from </FONT>
<BR><FONT FACE=3D"Arial"><A HREF=3D"http://www.iso.ch/mara" =
TARGET=3D"_blank">http://www.iso.ch/mara</A></FONT>
<BR><FONT FACE=3D"Arial">to</FONT>
<BR><FONT FACE=3D"Arial"><A HREF=3D"http://www.iso.org/mara" =
TARGET=3D"_blank">http://www.iso.org/mara</A></FONT>
<BR><FONT FACE=3D"Arial">Change the URL for</FONT><I> <FONT =
FACE=3D"Arial">Autorit=E9s de mise =E0 jour et organismes =
d'enregistrement,</FONT></I> <FONT FACE=3D"Arial">from</FONT>
<BR><FONT FACE=3D"Arial"><A HREF=3D"http://www.iso.ch/mara-fr" =
TARGET=3D"_blank">http://www.iso.ch/mara-fr</A></FONT>
<BR><FONT FACE=3D"Arial">to</FONT>
<BR><FONT FACE=3D"Arial"><A HREF=3D"http://www.iso.org/mara-fr" =
TARGET=3D"_blank">http://www.iso.org/mara-fr</A></FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
Although either URL works, ISO appears to prefer ".org" to =
".ch".</FONT>
<BR><FONT FACE=3D"Arial">&nbsp;</FONT>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">7.4 Registration =
Procedure</FONT></B></U></P>

<P><U><B><FONT FACE=3D"Arial">Item h</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 EDITORIAL #88</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&quot;to inform the =
appropriate Sponsoring Authority when a application does not comply to =
the rules.&quot;</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Problem and =
Action:</FONT></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">Grammar; &quot;...comply =
with the rules;&quot;</FONT>
</P>

<P><U><B><FONT FACE=3D"Arial">Item f</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 EDITORIAL #89</FONT>
<BR><FONT FACE=3D"Arial">The current text is identical to the text in =
the CD1 except that one change -- "proposal" to "application"- has been =
made:</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">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;</FONT></P>

<P><FONT FACE=3D"Arial">Split this excessively complex item into a new =
paragraph with two parts worded as follows:</FONT>
<BR><FONT FACE=3D"Arial">Following approval of an application for =
registration, the Registration Authority shall:</FONT>
<BR><FONT FACE=3D"Arial">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 ;</FONT></P>

<P><FONT FACE=3D"Arial">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;</FONT></P>

<P><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
Reduction of complexity. </FONT>
<BR><FONT FACE=3D"Arial">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").</FONT></P>

<P><U><B><FONT FACE=3D"Arial">Item i</FONT></B></U>
<BR><FONT FACE=3D"Arial">CD2 EDITORIAL #90</FONT>
<BR><FONT FACE=3D"Arial">In the title of this clause, change =
"Procedure" to "procedure".</FONT>
</P>

<P ALIGN=3DCENTER><B><FONT FACE=3D"Arial">8.1 Identity [of the =
Sponsoring Authority]</FONT></B></P>

<P><FONT FACE=3D"Arial">CD2 EDITORIAL #91</FONT>
<BR><FONT FACE=3D"Arial">Second paragraph:</FONT>
<BR><FONT FACE=3D"Arial">Sponsoring Authorities may submit applications =
for registration of the types Charmaps and Repertoiremaps to support =
their other Cultural Specifications.</FONT></P>

<P><FONT FACE=3D"Arial">Move this paragraph to Clause 8.2</FONT><I> =
<FONT FACE=3D"Arial">Responsibilities</FONT></I><FONT FACE=3D"Arial">, =
and insert it immediately after item (d).</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
This paragraph describes an action that the Sponsoring Authority may =
perform. It does not belong in a clause defining the Sponsoring =
Authority itself.</FONT></P>

<P><FONT FACE=3D"Arial">CD2 EDITORIAL #92</FONT>
<BR><FONT FACE=3D"Arial">Third paragraph:</FONT>
<BR><FONT FACE=3D"Arial">Current text of this paragraph:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">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.</FONT></P>

<P><U><FONT FACE=3D"Arial">Rationale for moving the =
paragraph:</FONT></U><FONT FACE=3D"Arial"> 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.</FONT></P>
<UL>
<P><FONT FACE=3D"Arial">1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Change "RA" to =
"Registration Authority" (two occurrences).</FONT>
</UL>
<P><U><FONT FACE=3D"Arial">Rationale:</FONT></U> <FONT =
FACE=3D"Arial">For consistency with "Sponsoring Authority/Authorities" =
in this paragraph.</FONT>
<UL>
<P><FONT FACE=3D"Arial">2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Change the =
phrase "other than Sponsoring Authorities" to "other than the =
Sponsoring Authorities as defined in clause 8.1."</FONT></P>
</UL>
<P><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
Current text lacks precision.</FONT>
<UL>
<P><FONT FACE=3D"Arial">3)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Delete the =
following text</FONT>
<UL>
<P><FONT FACE=3D"Arial">or applications from Sponsoring Authorities =
that they do not have the authority to register.</FONT>
</UL></UL>
<P><U><FONT FACE=3D"Arial">Rationale:</FONT></U>
<UL><UL><UL>
<P><FONT FACE=3D"Arial">(a)&nbsp;&nbsp;&nbsp;&nbsp; To what does "they" =
refer?</FONT>
<BR><FONT FACE=3D"Arial">(b)&nbsp;&nbsp;&nbsp;&nbsp; "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.</FONT></P>

<P><FONT FACE=3D"Arial">(c)&nbsp;&nbsp;&nbsp;&nbsp; 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.</FONT></P>
</UL></UL>
<P><FONT FACE=3D"Arial">4)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Change&nbsp; =
"eg" to "for example,"</FONT>
<BR><FONT FACE=3D"Arial">5)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Change the =
first comma after the first occurrence of "Sponsoring Authorities" to a =
full stop (because the remainder of the sentence has been =
deleted).</FONT></P>
</UL>
<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">8.2 =
Responsibilities</FONT></B></U></P>

<P><FONT FACE=3D"Arial">CD2 EDITORIAL #93</FONT>
<BR><FONT FACE=3D"Arial">Change "eg." to "for example,"</FONT>
</P>

<P><FONT FACE=3D"Arial">CD2 EDITORIAL #94</FONT>
<BR><U><B><FONT FACE=3D"Arial">Item b</FONT></B></U>
<BR><FONT FACE=3D"Arial">Change "an application" to =
"applications".</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
For consistency with other items, where the plural form "applications" =
is used.</FONT>
</P>

<P><FONT FACE=3D"Arial">CD2 EDITORIAL #95</FONT>
<BR><U><B><FONT FACE=3D"Arial">Item e</FONT></B></U>
<BR><FONT FACE=3D"Arial">Replace item e</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to forward to the Registration =
Authority those applications that have their support;</FONT>
<BR><FONT FACE=3D"Arial">with the following text:</FONT>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">to submit applications for the =
registration of Cultural Specifications to the Registration =
Authority;</FONT>
</UL></UL>
<P><U><FONT FACE=3D"Arial">Rationale:</FONT></U>
<UL>
<P><FONT FACE=3D"Arial">(a)&nbsp;&nbsp;&nbsp;&nbsp; "that have their =
support" is redundant. A Sponsoring Authority would not submit an =
application that did not have its approval.</FONT></P>

<P><FONT FACE=3D"Arial">(b)&nbsp;&nbsp;&nbsp;&nbsp; "their"</FONT> =
<FONT FACE=3D"Wingdings">&#224;</FONT><FONT FACE=3D"Arial"> "its" ("a =
Sponsoring Authority" is singular)</FONT>
</P>
</UL>
<P><FONT FACE=3D"Arial">CD2 EDITORIAL #96</FONT>
<BR><U><B><FONT FACE=3D"Arial">Item f</FONT></B></U>
<BR><FONT FACE=3D"Arial">Change this text:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">their respective countries or =
organizations.</FONT>
<BR><FONT FACE=3D"Arial">to</FONT>
<BR><FONT FACE=3D"Arial">its respective country, region, or =
organizations.</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
Grammar -- to agree with the implied "Sponsoring Authority" which is =
singular.</FONT>
<BR><FONT FACE=3D"Arial">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.)</FONT></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial"># The Joint Advisory =
Committee for ISO/IEC 15897</FONT></B></U></P>

<P><FONT FACE=3D"Arial">CD2 EDITORIAL #97</FONT>
<BR><FONT FACE=3D"Arial">Carry out the textual changes specified for =
clause 11 and then relocate the whole clause (including its heading) =
immediately after clause 8</FONT><I> <FONT FACE=3D"Arial">Sponsoring =
Authority.</FONT></I></P>

<P><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
The definition of the Joint Advisory Committee must be grouped with the =
definitions of all other functional agencies applicable to this =
standard.</FONT></P>

<P><FONT FACE=3D"Arial">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.</FONT></P>

<P ALIGN=3DCENTER><U><B><I><FONT FACE=3D"Arial">Clause 9.1 Types of =
cultural Specifications</FONT></I></B></U></P>

<P><FONT FACE=3D"Arial">CD2 EDITORIAL #98</FONT>
<BR><FONT FACE=3D"Arial">Capitalize "cultural" in the title of this =
clause.</FONT>
<BR><U><FONT FACE=3D"Arial">Explanation</FONT></U><FONT =
FACE=3D"Arial">: 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.</FONT></P>

<P ALIGN=3DCENTER><U><B><I><FONT FACE=3D"Arial">Clause 9.2 Relations =
between registration types</FONT></I></B></U></P>

<P><U><B><FONT FACE=3D"Arial">Clause 9.2.1, first =
sentence:</FONT></B></U>
<BR><FONT FACE=3D"Arial">CD2 EDITORIAL #99</FONT>
<BR><FONT FACE=3D"Arial">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".</FONT></P>

<P><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
The</FONT><I> <FONT FACE=3D"Arial">Procedures for the technical work of =
ISO/IEC JTC 1</FONT></I><FONT FACE=3D"Arial"> is the applicable =
authority. This is the relevant text from the</FONT><I> <FONT =
FACE=3D"Arial">Procedures</FONT></I><FONT FACE=3D"Arial">:</FONT></P>

<P><B><FONT SIZE=3D2 FACE=3D"Arial">7.9.1</FONT></B> <FONT SIZE=3D2 =
FACE=3D"Arial">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.</FONT></P>

<P ALIGN=3DCENTER><B><U><FONT FACE=3D"Arial">Clause 9.3 Rules for =
Cultural Specifications</FONT></U></B></P>

<P><B><U><FONT FACE=3D"Arial">Clause 9.3.5</FONT></U></B>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 EDITORIAL #100</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<UL><UL>
<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">The sources shall be =
delivered electronically, either via electronic mail or on a diskette, =
to the Registration Authority.</FONT></P>
</UL></UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial">Reword as:</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">either via electronic mail =
or on physical storage media</FONT><U></U>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Rationale</FONT></U><FONT =
COLOR=3D"#000000" FACE=3D"Arial">: Current wording is too restrictive =
and backward looking.</FONT>
</P>

<P><U><B><FONT FACE=3D"Arial">Clause 9.3.7</FONT></B></U>
<BR><FONT FACE=3D"Arial">CD2 EDITORIAL #101</FONT>
<BR><FONT FACE=3D"Arial">Change "all" to "All"</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
Orthographic conventions.</FONT>
</P>

<P><U><B><FONT FACE=3D"Arial">Clause 9.3.8</FONT></B></U>
<BR><FONT FACE=3D"Arial">CD2 EDITORIAL #102</FONT>
<BR><FONT FACE=3D"Arial">Current text of the 6<SUP>th</SUP> paragraph =
(between the two Notes) ends:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">... thus giving preference =
specifications from National Standardization Organizations.</FONT>
<BR><FONT FACE=3D"Arial">Insert "to" between "preference" and =
"specifications"</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale:</FONT></U><FONT FACE=3D"Arial"> =
Grammar.</FONT>
</P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">Clause 9.4 Contents of a =
Narrative Cultural Specification</FONT></B></U></P>

<P><FONT FACE=3D"Arial">CD2 EDITORIAL #103</FONT>
<BR><FONT FACE=3D"Arial">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).</FONT></P>

<P><U><B><FONT FACE=3D"Arial">Clause 1: Alphanumeric deterministic =
ordering</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 EDITORIAL #104</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<UL><UL>
<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">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?</FONT></P>
</UL></UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial">Rewrite as:</FONT>
<UL><UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial">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.</FONT></P>
</UL></UL>
<P><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Rationale:</FONT></U> =
<FONT COLOR=3D"#000000" FACE=3D"Arial">Grammar.</FONT>
</P>

<P><FONT FACE=3D"Arial">CD 2 EDITORIAL #105</FONT>
<BR><FONT FACE=3D"Arial">The title of this clause is inappropriate =
because its content may cover scripts that are not alphabets. New name =
should be:</FONT></P>

<P><FONT FACE=3D"Arial">Ordering of textual data</FONT>
</P>

<P><U><B><FONT FACE=3D"Arial">Clauses 7 through 32</FONT></B></U>
<BR><FONT FACE=3D"Arial">See Appendix Four for US technical and =
editorial comments on the optional (non-POSIX) clauses.</FONT>
</P>

<P ALIGN=3DCENTER><B><U><FONT FACE=3D"Arial">10 Appeal =
procedures</FONT></U></B></P>

<P><FONT FACE=3D"Arial">CD2 EDITORIAL #106</FONT>
<BR><FONT FACE=3D"Arial">Delete the first line of text:</FONT>
<BR><FONT FACE=3D"Arial">Appeal against the decision of the =
Registration Authority can be made as follows:</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
Redundant. The title of the clause says the same thing more =
succinctly.</FONT>
</P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">Clause =
11.2</FONT></B></U></P>

<P><U><B><FONT FACE=3D"Arial">First paragraph</FONT></B></U>
<BR><FONT FACE=3D"Arial">CD2 EDITORIAL #107</FONT>
<BR><FONT FACE=3D"Arial">Spelling of "subcommittee' still has to be =
corrected by inserting "t".</FONT>
</P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">Annex A&nbsp; Application =
form for a Cultural Specification</FONT></B></U></P>

<P><U><B><FONT FACE=3D"Arial">Introductory paragraph</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 EDITORIAL #108</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Please specify all =
data relevant for the Cultural Specification type, indicating =
non-available data by &quot;not available"...</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">Reword as: </FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">Please specify all data =
relevant for the Cultural Specification type, or enter &quot;not =
applicable&quot;...</FONT>
<BR><U><FONT COLOR=3D"#000000" =
FACE=3D"Arial">Rationale:</FONT></U><FONT COLOR=3D"#000000" =
FACE=3D"Arial"> Clarity.</FONT>
</P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">Annex D&nbsp; Sample =
Narrative Cultural Specification for Danish and =
Irish</FONT></B></U></P>

<P><FONT FACE=3D"Arial">CD2 EDITORIAL #109</FONT>
<BR><FONT FACE=3D"Arial">Change title of Annex D to:</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
FACE=3D"Arial">Examples of Narrative Cultural Specifications</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale:</FONT></U>
<UL>
<P><FONT FACE=3D"Arial">(a)&nbsp;&nbsp;&nbsp;&nbsp; These are =
"examples", not "samples". (For examples of use, see Annex B and Annex =
G in</FONT><I> <FONT FACE=3D"Arial">ISO/IEC Directives, Part 3 Rules =
for the structure and drafting of International =
Standards</FONT></I><FONT FACE=3D"Arial">)</FONT></P>

<P><FONT FACE=3D"Arial">(b)&nbsp;&nbsp;&nbsp;&nbsp; The examples are =
intended to show the content of narrative cultural specifications, =
without emphasis on language.</FONT></P>
</UL>
<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">Annex H&nbsp; Differences =
from ISO/IEC 15897:1999 and CEN ENV 12005:1996</FONT></B></U></P>

<P><U><B><FONT FACE=3D"Arial">H.1 Changes from ISO/IEC =
15897:1999</FONT></B></U>
<BR><FONT FACE=3D"Arial">CD2 EDITORIAL #110</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">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.</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">Reword as:</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">3. The text was revised to =
align with ISO/IEC 2375.</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Rationale: </FONT></U>
<UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial">(a)&nbsp;&nbsp;&nbsp;&nbsp; =
Grammar ("wording" is singular; "was built" not "was build")</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">(b)&nbsp;&nbsp;&nbsp;&nbsp; =
Removal of text that applies to the 1999 version of this =
standard.</FONT>
</P>
</UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 EDITORIAL #111</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">7. Some parts of =
the text was moved around, eg annex G which is now clause 9.4.</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">Reword as:</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">7. Some parts of the text =
were moved around. For example, the former Annex G is now clause =
9.4.</FONT>
<BR><U><FONT COLOR=3D"#000000" =
FACE=3D"Arial">Rationale:</FONT></U><FONT COLOR=3D"#000000" =
FACE=3D"Arial"> Grammar.</FONT>
</P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">End of Specific Editorial =
Comments</FONT></B></U></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">APPENDIX =
1</FONT></B></U></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">US comments on specific =
aspects of the text of clause 7.4</FONT></B></U></P>

<P><FONT FACE=3D"Arial">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.</FONT></P>

<P><U><B><FONT FACE=3D"Arial">Item c</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #112</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">to circulate =
applications to ISO/IEC JTC1/SC22 members, liaisons and the =
Registration Authority's Joint Advisory Group,...</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">Insert a reference =
identifying the clause where the Registration Authority's Joint =
Advisory Group is described in detail immediately after =
"Group".</FONT></P>

<P><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Rationale</FONT></U><FONT =
COLOR=3D"#000000" FACE=3D"Arial">: The RA-JAC has not yet been defined. =
</FONT>
</P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #113</FONT>
<BR><FONT FACE=3D"Arial">The text of item c, clause 4</FONT><I> <FONT =
FACE=3D"Arial">Registration Authority</FONT></I><FONT FACE=3D"Arial"> =
of the CD1 reads:</FONT>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">in the case of a POSIX Locale, to =
ascertain that the POSIX Locale and the corresponding Narrative =
Cultural Specification are not in contradiction</FONT></P>
</UL></UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">I</FONT><FONT FACE=3D"Arial">n CD1 =
Objection #12, the US asked:</FONT>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">What if the two do contradict each =
other? Suppose there is a &quot;foo&quot; POSIX locale definition, and =
a &quot;foo&quot; narrative cultural spec. Suppose the cultural spec =
includes &lt;a-acutein the character set list, but the locale does not =
include it in the &lt;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 &lt;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?</FONT></P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">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.</FONT></P>
</UL></UL>
<P><FONT FACE=3D"Arial">In the DoC, the Editor responded:</FONT>
<UL><UL>
<P><B><FONT FACE=3D"Courier">12. Noted</FONT></B><FONT =
FACE=3D"Courier">. 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.</FONT></P>
</UL></UL>
<P><FONT FACE=3D"Arial">In the CD2, the responsibility for resolving =
inconsistencies between a POSIX Locale and the corresponding Narrative =
Cultural Specification appears to have now been assigned</FONT><U> =
<FONT FACE=3D"Arial">entirely</FONT></U><FONT FACE=3D"Arial"> to the =
Sponsoring Authority (clause 8.2</FONT><I> <FONT =
FACE=3D"Arial">Responsibilities [of a Sponsoring =
Authority]</FONT></I><FONT FACE=3D"Arial">, item c).</FONT></P>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">in the case of a POSIX Locale, to =
ascertain that the POSIX Locale and the corresponding Narrative =
Cultural Specification are not in contradiction;</FONT></P>
</UL></UL>
<P><U><B><FONT FACE=3D"Arial">Item d</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #114</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<UL><UL>
<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">to forward the =
comments received to the Sponsoring Authority for possible integration =
in the final documents;</FONT>
</UL></UL>
<P><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Problem and =
Action:</FONT></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">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, </FONT></P>
<UL><UL>
<P><B><FONT FACE=3D"Arial">x.7 The Registration Authority shall inform =
the Sponsoring Authority of any changes needed to satisfy the concerns =
of the RA-JAC.</FONT></B></P>
</UL></UL>
<P><FONT FACE=3D"Arial">and, following review by the P-members of =
SC22,</FONT>
<UL><UL>
<P><B><FONT FACE=3D"Arial">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 &lt;x.8&gt; into the final =
registration.</FONT></B></P>
</UL></UL>
<P><U><B><FONT FACE=3D"Arial">Item e</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #115</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<UL><UL>
<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">in the case of =
comments, to optionally receive from the Sponsoring Authority revised =
applications addressing the comments received;</FONT></P>
</UL></UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial">Substitute this text for the =
current text:</FONT>
<UL><UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial">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;</FONT></P>
</UL></UL>
<P><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Rationale</FONT></U><FONT =
COLOR=3D"#000000" FACE=3D"Arial">:</FONT>
<UL>
<P><FONT COLOR=3D"#000000" =
FACE=3D"Arial">1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; There is no way to =
&quot;optionally receive&quot; something. Shouldn't this say =
&quot;...optionally accept&quot;? </FONT>
<BR><FONT COLOR=3D"#000000" =
FACE=3D"Arial">2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The "optionally" is =
perhaps intended to convey the fact that not every application will =
need to be revised in response to comments. </FONT></P>

<P><FONT COLOR=3D"#000000" =
FACE=3D"Arial">3)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "in the case of =
comments" is redundant.</FONT>
</P>
</UL>
<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">End of Appendix =
1</FONT></B></U></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">APPENDIX =
2</FONT></B></U></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">Rearrangement of Clause =
9</FONT></B></U><U><B><I> <FONT FACE=3D"Arial">Rules for =
Applications</FONT></I></B></U></P>

<P><FONT FACE=3D"Arial">To facilitate the use of ISO/IEC 15897, the US =
proposes that clause 9 be reorganized into six separate clauses dealing =
with these topics: </FONT></P>
<UL>
<P><FONT FACE=3D"Arial">1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Types and =
relationships of cultural specifications;</FONT>
<BR><FONT FACE=3D"Arial">2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Contents of a =
narrative cultural specification;</FONT>
<BR><FONT FACE=3D"Arial">3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Use of =
character names;</FONT>
<BR><FONT FACE=3D"Arial">4.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Requirements =
for applications;</FONT>
<BR><FONT FACE=3D"Arial">5.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Format of =
registration documents;</FONT>
<BR><FONT FACE=3D"Arial">6.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Specification =
of the token identifier;</FONT>
</P>
</UL>
<P><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">The very few pieces of text that =
were</FONT><U></U><U> <FONT FACE=3D"Helvetica">inserted</FONT></U><FONT =
FACE=3D"Arial"> or<STRIKE></STRIKE></FONT><STRIKE> <FONT =
FACE=3D"Helvetica">deleted</FONT></STRIKE> <FONT FACE=3D"Helvetica">for =
stylistic reasons</FONT><STRIKE><FONT =
FACE=3D"Helvetica"></FONT></STRIKE> <FONT FACE=3D"Arial">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.</FONT></P>

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

<P><FONT FACE=3D"Arial">Type 1 are for Narrative Cultural =
Specifications, further specified in clause 9.3.2.</FONT>
<BR><FONT FACE=3D"Arial">Types 2 and 3 are for POSIX specification of =
cultural conventions defined in ISO/IEC 9945-2.</FONT>
<BR><FONT FACE=3D"Arial">Type 4 is for Repertoiremaps defined in this =
International Standard (clause 9.3.9) and in ISO/IEC TR 14652.</FONT>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><B><FONT FACE=3D"Arial">[1st].2 Relations between registration types =
=3D 9.2 Relations between registration types</FONT></B>
<BR><STRIKE><FONT FACE=3D"Arial">The relation between the types is the =
following:</FONT></STRIKE>
<BR><FONT FACE=3D"Arial">Registration types are related as =
follows:</FONT>
<BR><B><FONT FACE=3D"Arial">[1st].2.1 Narrative Cultural =
Specification</FONT></B>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><B><FONT FACE=3D"Arial">[1st].2.2 POSIX Locale</FONT></B>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">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).</FONT></P>

<P><FONT FACE=3D"Arial">9.4 (part) If a POSIX locale is submitted, it =
is desirable that it be accompanied by a related narrative cultural =
specification.</FONT></P>

<P><B><FONT FACE=3D"Arial">[1st].2.3 POSIX Charmap</FONT></B>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><B><FONT FACE=3D"Arial">[1st].2.4 Repertoiremap</FONT></B>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><B><FONT FACE=3D"Arial">[1st].2.5 Other specifications</FONT></B>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">9.3.3 (part)The FDCC-set shall define all =
standard categories (for example by copying categories of a standard =
&quot;i18n&quot; FDCC-set; examples are given in annex F).</FONT></P>

<P><FONT FACE=3D"Arial">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.</FONT></P>
<UL><UL>
<P><FONT FACE=3D"Arial">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.</FONT></P>
</UL></UL>
<P><B><FONT FACE=3D"Arial">[2nd]. CONTENTS OF A NARRATIVE CULTURAL =
SPECIFICATION </FONT></B>
<BR><B><FONT FACE=3D"Arial">=3D 9.4 Contents of a Narrative Cultural =
Specification</FONT></B>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">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.</FONT></P>

<P><B><FONT FACE=3D"Arial">[2nd].1 Mandatory Clauses</FONT></B>
<BR><FONT FACE=3D"Arial">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:</FONT></P>

<P><U><B><I><FONT FACE=3D"Arial">Clause 1: Alphanumeric deterministic =
ordering</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><U><B><I><FONT FACE=3D"Arial">Clause 2: Classification of =
characters</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">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. </FONT></P>

<P><U><B><I><FONT FACE=3D"Arial">Clause 3: Numeric =
formatting</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">Here it is described how numbers are keyed in =
and formatted, including the format of the decimal point and the =
thousands separator.</FONT></P>

<P><U><B><I><FONT FACE=3D"Arial">Clause 4: Monetary =
formatting</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">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. </FONT></P>

<P><U><B><I><FONT FACE=3D"Arial">Clause 5: Date and time =
conventions</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><U><B><I><FONT FACE=3D"Arial">Clause 6: Affirmative and negative =
answers</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">Here the short notation for &quot;yes&quot; =
and &quot;no&quot; 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.</FONT></P>

<P><B><FONT FACE=3D"Arial">&nbsp;[2nd].2 Optional Clauses</FONT></B>
<BR><FONT FACE=3D"Arial">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:</FONT></P>
<UL><UL>
<P><FONT FACE=3D"Arial">NOTE: Further information about the categories, =
along with specific examples illustrating their use may be found =
in</FONT><STRIKE> <FONT FACE=3D"Arial">clause 9.4 and =
in</FONT></STRIKE><FONT FACE=3D"Arial"> the Nordic Cultural =
Requirements on Information Technology (Summary Report).</FONT></P>
</UL></UL>
<P><U><B><I><FONT FACE=3D"Arial">Clause 7: National or cultural =
Information Technology terminology</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">Here terminology for a language or culture can =
be listed, for example a translation of ISO terminology for Information =
Technologies.</FONT></P>

<P><U><B><I><FONT FACE=3D"Arial">Clause 8: National or cultural =
profiles of standards</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><U><B><I><FONT FACE=3D"Arial">Clause 9: Character set =
considerations</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">Here it can be described how characters are =
used in the culture, for example:</FONT>
<BR><FONT FACE=3D"Arial">- which characters are necessary to write a =
particular language,</FONT>
<BR><FONT FACE=3D"Arial">- which characters are used to give further =
precision in the language,</FONT>
<BR><FONT FACE=3D"Arial">- which characters are usually used in =
newspapers and books for writing of names and places,</FONT>
<BR><FONT FACE=3D"Arial">- which characters are used for historic =
writing of the language,</FONT>
<BR><FONT FACE=3D"Arial">- and which characters are used for other =
purposes.</FONT>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">9.3.2 (part) In clause 9 it is possible to give =
further information on characters classified in clause 2 =
(mandatory).</FONT>
<BR><U><B><I><FONT FACE=3D"Arial">Clause 10: Sorting and searching =
rules</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><U><B><I><FONT FACE=3D"Arial">Clause 11: Transformation of =
characters</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><U><B><I><FONT FACE=3D"Arial">Clause 12: Character =
properties</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">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.</FONT></P>

<P><U><B><I><FONT FACE=3D"Arial">Clause 13: Use of special =
characters</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><U><B><I><FONT FACE=3D"Arial">Clause 14: Character =
rendition</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">Special considerations about rendition such as =
what alternatives may be considered adequate, and acceptable glyphs, =
may be described in this clause.</FONT></P>

<P><U><B><I><FONT FACE=3D"Arial">Clause 15: Character =
inputting</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">A keyboard seldom has separate keys for all =
the characters needed. This clause is intended for description of keyboa=
rd inputting rules and other input methods.</FONT></P>

<P><U><B><I><FONT FACE=3D"Arial">Clause 16: Personal names =
rules</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">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. </FONT></P>

<P><U><B><I><FONT FACE=3D"Arial">Clause 17: =
Inflection</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><U><B><I><FONT FACE=3D"Arial">Clause 18: =
Hyphenation</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">Hyphenation rules can be described here, and =
also references to the specifications for a language may be done =
here.</FONT>
<BR><U><B><I><FONT FACE=3D"Arial">Clause 19: =
Spelling</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">This clause is for specification of spelling =
rules and spelling lists, or reference to orthographic =
documentation.</FONT>
<BR><U><B><I><FONT FACE=3D"Arial">Clause 20: Numbering, ordinals and =
measuring systems</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">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.</FONT></P>

<P><U><B><I><FONT FACE=3D"Arial">Clause 21: Monetary =
amounts</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">Here further considerations to clause 4 can be =
described, such as old currencies. </FONT>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><U><B><I><FONT FACE=3D"Arial">Clause 22: Date and =
time</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">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 &quot;half =
seven&quot; - what is then really meant - 06:30 as in Germany or =
Denmark, or 07:30 as in Britain?</FONT></P>

<P><FONT FACE=3D"Arial">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.</FONT></P>

<P><U><B><I><FONT FACE=3D"Arial">Clause 23: Coding of national =
entities</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">Also specifications should be given for =
identification of the whole culture, for example ISO country codes for =
a nation.</FONT></P>

<P><U><B><I><FONT FACE=3D"Arial">Clause 24: Telephone =
numbers</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">The formatting of telephone numbers, =
nationally and internationally.</FONT>
<BR><U><B><I><FONT FACE=3D"Arial">Clause 25: Mail =
addresses</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><U><B><I><FONT FACE=3D"Arial">Clause 26: Identification of persons =
and organizations</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><U><B><I><FONT FACE=3D"Arial">Clause 27: Electronic mail =
addresses</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">Cultural conventions for Internet and X.400 =
electronic addresses etc. may be described here.</FONT>
<BR><U><B><I><FONT FACE=3D"Arial">Clause 28: Payment account =
numbers</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">Cultural conventions for bank account numbers =
can be described here.</FONT>
<BR><U><B><I><FONT FACE=3D"Arial">Clause 29: Keyboard =
layout</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">Here the conventions for keyboard layout may =
be described.</FONT>
<BR><U><B><I><FONT FACE=3D"Arial">Clause 30: Man-machine =
dialogue</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">Considerations for how to localize products =
may be described here. </FONT>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><U><B><I><FONT FACE=3D"Arial">Clause 31: Paper =
formats</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><U><B><I><FONT FACE=3D"Arial">Clause 32: Typographical =
conventions</FONT></I></B></U>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

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

<P><B><FONT FACE=3D"Arial">[3rd]. USE OF CHARACTER NAMES</FONT></B>
<BR><FONT FACE=3D"Arial">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 &lt;&gt;, 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 &quot;escape_char&quot; followed by one or more spaces or =
tabs and then the escape character.</FONT></P>

<P><B><FONT FACE=3D"Arial">[4th]. REQUIREMENTS FOR =
APPLICATIONS</FONT></B>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">9.3.7 (part) If any of the</FONT><STRIKE> <FONT =
FACE=3D"Arial">above</FONT></STRIKE><FONT FACE=3D"Arial"> 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.</FONT></P>

<P><B><FONT FACE=3D"Arial">[4th].1 Required for All =
Applications</FONT></B>
<BR><FONT FACE=3D"Arial">9.3.7 The written Cultural Specification =
application shall contain information on the following items:</FONT>
<BR><FONT FACE=3D"Arial">1. Cultural Specification type number (as in =
9.1 above)</FONT>
<BR><FONT FACE=3D"Arial">2. Organization name of Sponsoring =
Authority</FONT>
<BR><FONT FACE=3D"Arial">3. Organization postal address</FONT>
<BR><FONT FACE=3D"Arial">4. Name of contact person</FONT>
<BR><FONT FACE=3D"Arial">5. Electronic mail address of the =
organization, or contact person</FONT>
<BR><FONT FACE=3D"Arial">6. Telephone number for the organization, in =
international format.</FONT>
<BR><FONT FACE=3D"Arial">7. Fax number for the organization, in =
international format.</FONT>
<BR><FONT FACE=3D"Arial">All applications shall contain information on =
these items:</FONT>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">13. Short name for Sponsoring Authority, for =
possible use in the token identifier. Blank if this is from a National =
Standardization Organization.</FONT></P>

<P><FONT FACE=3D"Arial">14. Revision number consisting of digits and =
zero or more full stops (&quot;.&quot;).</FONT>
<BR><FONT FACE=3D"Arial">15. Revision date in the format according to =
this example: &quot;1995-02-05&quot; meaning the 5th of February, =
1995.</FONT>
<BR><B><FONT FACE=3D"Arial">[4th].2 Required for Types 1, 2 and =
5</FONT></B>
<BR><FONT FACE=3D"Arial">9.3.7 (part) For Types 1, 2, and 5, Narrative =
Cultural Specifications, POSIX Locales, and FDCCsets and other formal =
descriptions of cultural conventions:</FONT></P>

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

<P><FONT FACE=3D"Arial">10. Suggested Charmap or Repertoiremap or other =
name</FONT>
</P>

<P><B><FONT FACE=3D"Arial">[5th]. FORMAT OF REGISTRATION =
DOCUMENTS</FONT></B>
<BR><B><FONT FACE=3D"Arial">[5th].1 General</FONT></B>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">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.</FONT></P>

<P><B><FONT FACE=3D"Arial">[5th].2 Narrative Cultural =
Specification</FONT></B>
<BR><FONT FACE=3D"Arial">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 &quot;Clause &quot;, 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).</FONT></P>

<P><FONT FACE=3D"Arial">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 &quot;=3D&gt; Clause &quot; =
followed by the clause number. A reference to another specification =
shall consist of the string &quot;=3D&gt; Spec. &quot;followed by the =
registration number of the specification and, optionally, the string =
&quot;Clause &quot; and a clause number.</FONT></P>

<P><B><FONT FACE=3D"Arial">[5th].3POSIX Locale and Charmap</FONT></B>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><B><FONT FACE=3D"Arial">[5th].4 Repertoiremap</FONT></B>
<BR><FONT FACE=3D"Arial">9.3.2 (part) The format of the Repertoiremap =
shall be conformant to clause 9.3.9.</FONT>
</P>

<P><B><FONT FACE=3D"Arial">[6th]. SPECIFICATION OF THE TOKEN =
IDENTIFIER</FONT></B>
<BR><FONT FACE=3D"Arial">Token Identifiers are assigned by the =
Registration Authority.</FONT>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">For Narrative Cultural Specifications, POSIX =
Locales and FDCC-sets the token identifier will be:</FONT>
<BR><FONT FACE=3D"Courier">8_9+11+12,13_14</FONT>
<BR><FONT FACE=3D"Arial">And for Charmaps and Repertoiremaps the token =
identifier will be:</FONT>
<BR><FONT FACE=3D"Courier">10+11+12,13_14</FONT>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">The HYPHEN character &quot;-&quot; may be =
substituted for the UNDERLINE character &quot;_&quot;, in order to =
align names with RFC 3066.</FONT>
<UL><UL>
<P><FONT FACE=3D"Arial">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 =
(/).</FONT></P>
</UL></UL>
<P><FONT FACE=3D"Arial">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.</FONT></P>
<UL><UL>
<P><FONT FACE=3D"Arial">NOTE: The version number may be used by the Spon=
soring 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.</FONT></P>
</UL></UL>
<P><FONT FACE=3D"Arial">EXAMPLE 1: _EU,CEN_3.5 for the CEN European =
POSIX Locale</FONT>
<BR><FONT FACE=3D"Arial">EXAMPLE 2: da_DK,_2.4 for the Danish Standards =
Danish POSIX Locale</FONT>
<BR><FONT FACE=3D"Arial">EXAMPLE 3: ISO_8859-1:1987,DS_1.0 for the DS =
Charmap for ISO 8859-1</FONT>
</P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">End of Appendix =
2</FONT></B></U></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">APPENDIX =
3</FONT></B></U></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">Technical and editorial =
comments on optional (non-POSIX) clauses</FONT></B></U></P>

<P><U><B><FONT FACE=3D"Arial">Clause 8: National or cultural profiles =
of standards (Optional)</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #116</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&quot;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.&quot;</FONT></P>

<P><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Problem and =
Action:</FONT></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">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.</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">Remove the sentence &quot;See =
the POSIX...&quot;</FONT>
</P>

<P><U><B><FONT FACE=3D"Arial">Clause 11: Transformation of characters =
(Optional, Not recommended)</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #117</FONT>
<BR><U><B><FONT FACE=3D"Arial">Current text</FONT></B></U>
<BR><FONT SIZE=3D2 FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">In CD1 Objection #49, the US proposed removal =
of this clause because:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">This is too vague to be useful, as =
the Danish example in Annex D illustrates.</FONT>
<BR><FONT FACE=3D"Arial">The Editor responded in the DoC:</FONT>
<UL><UL>
<P><B><FONT SIZE=3D2 FACE=3D"Arial">49.</FONT></B><FONT SIZE=3D2 =
FACE=3D"Arial"></FONT><B> <FONT SIZE=3D2 FACE=3D"Arial">Not =
accepted</FONT></B><FONT SIZE=3D2 FACE=3D"Arial">. There are already =
many quite elaborate transliteration specs in 14652 style.</FONT>
</UL></UL>
<P><FONT FACE=3D"Arial">The US recommends that this clause be annotated =
"Not recommended."</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale:</FONT></U><FONT FACE=3D"Arial"> =
The instructions on the content of this clause are too vague to be =
useful (as the Danish example in Annex D illustrates).</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #118</FONT>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><U><B><FONT FACE=3D"Arial">Clause 13: Use of special characters =
(Optional)</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #119</FONT>
<BR><FONT FACE=3D"Arial">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:</FONT></P>
<UL><UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">For quoting, the character pairs =
&lt;"&gt;&lt;"&gt;, &lt;=AB&gt;&lt;=BB&gt; and &lt;"&gt;&lt;"&gt;are =
used,; the first character in each pair is used to start a quote, and =
the last to end the quote.</FONT></P>
</UL></UL>
<P><FONT FACE=3D"Arial">CD2 TECHNICAL #120</FONT>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #121</FONT>
<BR><FONT FACE=3D"Arial">Delete this line:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">NUMBER SIGN &lt;#&gt; is seldomly =
used, and should be avoided.</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
Dictating whether a country or region should make use of NUMBER SIGN in =
its orthography is totally out of scope for this standard.</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 EDITORIAL #122</FONT>
<BR><FONT FACE=3D"Arial">The US notes that "seldomly" is grammatically =
incorrect. The correct usage is "seldom".</FONT>
</P>

<P><U><B><FONT FACE=3D"Arial">Clause 16: Personal name rules (Optional, =
Not recommended)</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #123</FONT>
<BR><U><FONT FACE=3D"Arial">Current text:</FONT></U>
<BR><FONT SIZE=3D2 FACE=3D"Arial">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.</FONT></P>

<P><U><FONT FACE=3D"Arial">Problem and Action as stated in CD1 =
OBJECTION #50:</FONT></U>
<BR><FONT FACE=3D"Arial">"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?"</FONT></P>

<P><FONT FACE=3D"Arial">The DoC was "Not accepted. see 33." (CD1 =
Objection #33 was a comment on the Danish example in Annex D.)</FONT>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">The US notes that the editor did correct =
"first" to "given" (as suggested in #33).</FONT>
</P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #124</FONT>
<BR><FONT FACE=3D"Arial">The US recommends that this clause be =
annotated "Not recommended".</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
It is questionable that the information requested here, which may =
include many exceptions, can be expressed in software.</FONT></P>

<P><U><B><FONT FACE=3D"Arial">Clause 17: Inflection (Optional, Not =
recommended)</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #125</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&quot;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.&quot;</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">Remove the sentence beginning =
&quot;Some common translation APIs...&quot; </FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Rationale:</FONT></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">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.</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #126</FONT>
<BR><FONT FACE=3D"Arial">The US recommends that this clause be =
annotated "Not recommended".</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale:</FONT></U><FONT FACE=3D"Arial"> =
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.</FONT></P>

<P><B><FONT FACE=3D"Arial">Clause 20: Numbering, ordinals, and =
measuring systems (Optional)</FONT></B>
<BR><FONT FACE=3D"Arial">CD2 EDITORIAL #127</FONT>
<BR><FONT FACE=3D"Arial">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 </FONT><FONT COLOR=3D"#000000" FACE=3D"Arial">"POSIX =
contains no information about how numbers are &quot;keyed =
in&quot;.</FONT></P>

<P><FONT FACE=3D"Arial">In case information about keying in is needed, =
the US provides the following replacement text:</FONT>
<UL><UL>
<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">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.</FONT></P>
</UL></UL>
<P><FONT FACE=3D"Arial">This replacement text also fixes these =
defects:</FONT>
<UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Arial">(a)&nbsp;&nbsp;&nbsp;&nbsp; =
corrects the erroneous plural "decimal points";</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">(b)&nbsp;&nbsp;&nbsp;&nbsp; =
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).</FONT></P>
</UL>
<P><B><FONT FACE=3D"Arial">Clause 22: Date and time (Optional, Not =
recommended)</FONT></B>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #128</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Current text:</FONT></U>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&quot;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 &quot;half seven&quot; - what is then really =
meant - 06:30 as in Germany or Denmark, or 07:30 as in =
Britain?&quot;</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">The U.S. still objects =
strongly to including time zone information in cultural narratives (as =
stated in CD1 Objection #51).</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">Remove the phrase =
&quot;...time zone names and daylight savings rules...&quot; </FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Additional =
Rationale:</FONT></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">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. </FONT></P>

<P><FONT FACE=3D"Arial">CD1 OBJECTION #51</FONT>
<BR><FONT FACE=3D"Arial">Section: Annex G, clause 22 (Date and =
time)</FONT>
<BR><U><FONT FACE=3D"Arial">Current text:</FONT></U>
<BR><FONT FACE=3D"Arial">Text is now in 9.4, clause 22</FONT>
<BR><FONT FACE=3D"Arial">"This is for considerations in excess of =
clause 5, such as non-POSIX date conventions, time zone names and =
daylight savings rules, . . ."</FONT></P>

<P><U><FONT FACE=3D"Arial">Problem and Action:</FONT></U>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">Remove this clause.</FONT>
<BR><B><FONT FACE=3D"Arial">51. Not accepted.</FONT></B> <FONT =
FACE=3D"Arial">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.</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #129</FONT>
<BR><FONT FACE=3D"Arial">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.)</FONT></P>

<P><FONT FACE=3D"Arial">We also note that "half seven" is British =
usage. English-speakers in other cultures (US and Australia, for =
example) say "half past seven."</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #130</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">If the phrase &quot;...time =
zone names and daylight savings rules...&quot; is not removed, then the =
US strongly recommends that this clause be annotated "Controversial" =
(rather than simply "Not recommended").</FONT></P>

<P><U><FONT COLOR=3D"#000000" FACE=3D"Arial">Rationale</FONT></U><FONT =
COLOR=3D"#000000" FACE=3D"Arial">: To agree with WG20's decision on =
time zone information in TR 14652.</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">If the phrase &quot;...time =
zone names and daylight savings rules...&quot; is removed as the US has =
requested,</FONT> <FONT FACE=3D"Arial">then this clause should be =
annotated "Not recommended".</FONT></P>

<P><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
Because there are problems with all aspects of the description.</FONT>
</P>

<P><U><B><FONT FACE=3D"Arial">Clause 23: Coding of national entities =
(Optional, Not recommended)</FONT></B></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #131</FONT>
<BR><FONT FACE=3D"Arial">The US recommends that this clause be =
annotated "Not recommended".</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale:</FONT></U><FONT FACE=3D"Arial"> =
The instructions on the content of this clause are too vague to be =
useful.</FONT>
</P>

<P><B><U><FONT FACE=3D"Arial">Clauses 26, 27, 28 and 30 (Optional, Not =
recommended)</FONT></U></B>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">CD2 TECHNICAL #132</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">26. Identification of =
persons and organizations</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">27. Electronic mail =
addresses</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">28. Payment account =
numbers</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">29. Man-machine =
dialogue</FONT>
<BR><FONT FACE=3D"Arial">The US recommends that these clauses be =
annotated "Not recommended".</FONT>
<BR><U><FONT FACE=3D"Arial">Rationale</FONT></U><FONT FACE=3D"Arial">: =
</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial">The definitions are =
vague, or contain information that is application-specific rather than =
culture-specific. </FONT></P>

<P ALIGN=3DCENTER><U><B><FONT COLOR=3D"#000000" FACE=3D"Arial">End of =
Appendix 3</FONT></B></U></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">APPENDIX =
4</FONT></B></U></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">US Comments on Annex =
D,</FONT></B></U><U><B><I> <FONT FACE=3D"Arial">Sample Narrative =
Cultural Specification for Danish and Irish</FONT></I></B></U></P>

<P><FONT FACE=3D"Arial">Objections specific to the Danish or Irish =
examples are listed here. </FONT>
<BR><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Arial">In N 957 Disposition of comments on CD of 15897 =
(that is, CD1), the Editor responded:</FONT>
<UL><UL>
<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">28-38. These =
comments will be relayed to the Danish member body for possible =
changes.</FONT>
</UL></UL>
<P><FONT FACE=3D"Arial">Comments 28-37 were not accepted for this =
reason.</FONT>
<UL><UL>
<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">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.</FONT></P>
</UL></UL>
<P><FONT FACE=3D"Arial">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.</FONT></P>

<P><FONT FACE=3D"Courier">CD1 OBJECTION #28</FONT>
<BR><FONT FACE=3D"Courier">Section: Annex D, Clause 7 (National or =
cultural Information Technology terminology)</FONT>
<BR><U><FONT FACE=3D"Courier">Current text:</FONT></U>
<BR><FONT FACE=3D"Courier">&quot;The official Information Technology =
terminology is &quot;Edb-ordbog&quot;, DS 2049-1970, Gjellerup, =
K=F8benhavn. A newer description can be found in Lars Frank: =
&quot;edb-ordbogen&quot;, Kommunetryk, K=F8benhavn =
1984.&quot;</FONT></P>

<P><U><FONT FACE=3D"Courier">Problem and Action:</FONT></U>
<BR><FONT FACE=3D"Courier">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.</FONT></P>

<P><FONT FACE=3D"Arial">Perhaps there are more recent IT vocabulary =
sources for Danish speakers that could be cited.</FONT>
</P>

<P><FONT COLOR=3D"#000000" FACE=3D"Courier New">CD2 TECHNICAL =
#133</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Courier New">Section: Annex D, =
Clause 11</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Courier New">Current =
text:</FONT></U>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;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:&quot;</FONT></P>

<P><U><FONT COLOR=3D"#000000" FACE=3D"Courier New">Problem and =
Action:</FONT></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Courier New">It still is not clear =
why the Danish Standards body wants to state that transliteration =
&quot;...is quite different from English&quot; without giving a full =
description, but that is their choice. However, do they really want to =
provide a list of &quot;fallback notation of *some* letters&quot; =
(emphasis added)? Wouldn't it be preferable to provide a full =
list?</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Courier New">Editorial: correct =
spelling of second use of &quot;transliterated&quot;.</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">The US previously commented =
on this clause as follows:</FONT>
<BR><FONT FACE=3D"Courier">CD1 OBJECTION #29</FONT>
<BR><FONT FACE=3D"Courier">Section: Annex D, Clause 11 (Transformation =
of characters)</FONT>
<BR><U><FONT FACE=3D"Courier">Current text:</FONT></U>
<BR><FONT FACE=3D"Courier">&quot;Transliteration of Cyrillic and Arabic =
is very different from English conventions.</FONT>
<BR><FONT FACE=3D"Courier">For a fallback notation of some letters, =
refer to the following table:</FONT>
<BR><FONT FACE=3D"Courier">original letter 2-char 1-char</FONT>
<BR><FONT FACE=3D"Courier">=C6 AE E</FONT>
<BR><FONT FACE=3D"Courier">=D8 OE Y</FONT>
<BR><FONT FACE=3D"Courier">=C5 AA O</FONT>
<BR><FONT FACE=3D"Courier">. . .&quot;</FONT>
<BR><U><FONT FACE=3D"Courier">Problem and Action:</FONT></U>
<BR><FONT FACE=3D"Courier">According to Annex G, this clause is for =
defining transliteration and transformations of characters =
(&quot;...for example transliteration rules between Latin, Greek and =
Cyrillic, or fallback notation for some frequent letters...&quot;) Note =
that this cultural specification simply says that &quot;Transliteration =
of Cyrillic and Arabic is very different from English conventions&quot; =
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 &quot;Transliteration =
of Cyrillic...&quot; therefore must be removed.</FONT></P>

<P><FONT FACE=3D"Courier">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?</FONT></P>

<P><FONT FACE=3D"Courier">More information is needed on fallbacks to =
make this clause useful.</FONT>
</P>

<P><FONT COLOR=3D"#000000" FACE=3D"Courier New">CD2 TECHNICAL =
#134</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Courier New">Section: Annex D, =
Clause 14 </FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Courier New">Current =
text:</FONT></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Courier New">&quot;The Danish =
letters &lt;=D8&gt; and &lt;=F8&gt; are often misprinted. . =
.&quot;</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Courier New">Problem and =
Action:</FONT></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Courier New">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.</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">The US previously commented =
on this clause as follows:</FONT>
<BR><FONT FACE=3D"Courier">CD1 OBJECTION #32</FONT>
<BR><FONT FACE=3D"Courier">Section: Annex D, Clause 14 (Character =
rendition)</FONT>
<BR><U><FONT FACE=3D"Courier">Current text:</FONT></U>
<BR><FONT FACE=3D"Courier">&quot;The Danish letters &lt;=D8and =
&lt;=F8are 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.&quot;</FONT></P>

<P><U><FONT FACE=3D"Courier">Problem and Action:</FONT></U>
<BR><FONT FACE=3D"Courier">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?</FONT></P>

<P><FONT FACE=3D"Courier">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?</FONT></P>

<P><FONT FACE=3D"Courier">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.</FONT></P>

<P><FONT FACE=3D"Courier New">CD2 TECHNICAL #135</FONT>
<BR><FONT FACE=3D"Courier New">Section: Annex D, Clause 15 (Character =
inputting)</FONT>
<BR><U><FONT FACE=3D"Courier New">Current text:</FONT></U>
<BR><FONT FACE=3D"Courier New">&quot;A proposed general input method is =
included in DS/ISO/IEC 9945-1 annex F.&quot;</FONT>
<BR><U><FONT FACE=3D"Courier New">Problem and Action:</FONT></U>
<BR><FONT FACE=3D"Courier New">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.</FONT></P>

<P><FONT FACE=3D"Courier New">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):</FONT></P>

<P><FONT FACE=3D"Courier New">&quot;For input, if the character name is =
undefined in the current charmap file, the data shall be left untouched =
(including the &lt;intro&gt; character) and the behavior is =
implementation defined.&quot;</FONT></P>

<P><FONT FACE=3D"Courier New">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.</FONT></P>

<P><FONT FACE=3D"Courier">CD1 OBJECTION #33</FONT>
<BR><FONT FACE=3D"Courier">Section: Annex D, Clause 16 (Personal names =
rules)</FONT>
<BR><U><FONT FACE=3D"Courier">Current text:</FONT></U>
<BR><FONT FACE=3D"Courier">&quot;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 &quot;du&quot;, and the more formal &quot;De&quot; =
is becoming more common. The family name is never spelt in capital =
letters only,. . .&quot;</FONT></P>

<P><U><FONT FACE=3D"Courier">Problem and Action:</FONT></U>
<BR><FONT FACE=3D"Courier">This information is vague or useless. How =
would a software engineer use the information that &quot;People are =
mostly addressed by voice by their first name&quot; (which, by the way, =
should be their &quot;given name&quot;, not their &quot;first =
name&quot;)? The fact that &quot;De&quot; is &quot;becoming more =
common&quot; tells an engineer nothing concrete and so is useless. =
These sentences should be removed.</FONT></P>

<P><FONT FACE=3D"Arial">The US notes that "full first name" has been =
changed to "full first given name" in CD2 15897.</FONT>
</P>

<P><FONT FACE=3D"Courier">CD1 OBJECTION #34 (re Danish example)</FONT>
<BR><FONT FACE=3D"Courier">Section: Annex D, Clause 17 =
(Inflection)</FONT>
<BR><U><FONT FACE=3D"Courier">Current text:</FONT></U>
<BR><FONT FACE=3D"Courier">&quot;The Danish grammar is defined in =
&quot;Retskrivningsordbogen&quot;. Danish has more inflections than =
English, for example nouns will have 8 forms based on =
indefinite/definite, singularis/pluralis and =
nominative+others/genitive.&quot;</FONT></P>

<P><U><FONT FACE=3D"Courier">Problem and Action:</FONT></U>
<BR><FONT FACE=3D"Courier">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?</FONT></P>

<P><FONT FACE=3D"Courier">This example simply illustrates why an =
earlier OBJECTION calls for removing this clause all together.</FONT>
<BR><U><FONT FACE=3D"Arial">Re Irish example:</FONT></U>
<BR><FONT FACE=3D"Arial">The Irish example gives a minimal description =
of the complex inflection of Irish Gaelic, and refers the user to =
specific grammar books.</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Courier New">CD2 TECHNICAL =
#136</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Courier New">Section: Annex D, =
Clause 23</FONT>
<BR><U><FONT COLOR=3D"#000000" FACE=3D"Courier New">Current =
text:</FONT></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Courier New">&quot;...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)...&quot;</FONT></P>

<P><U><FONT COLOR=3D"#000000" FACE=3D"Courier New">Problem and =
Action:</FONT></U>
<BR><FONT COLOR=3D"#000000" FACE=3D"Courier New">It's curious that =
Denmark wants to use a seven-year-old population figure. According to =
Statistics Denmark 2002 (<A HREF=3D"http://www.dst.dk/imf" =
TARGET=3D"_blank">http://www.dst.dk/imf</A>), the current population is =
5,4 million (rounded up from 5,374 million).</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Courier New">The Danish Standards =
organization may wish to update its information.</FONT>
</P>

<P><FONT FACE=3D"Courier">CD1 OBJECTION #35</FONT>
<BR><FONT FACE=3D"Courier">Section: Annex D, Clause 23 (Coding of =
national entities)</FONT>
<BR><U><FONT FACE=3D"Courier">Problem and Action:</FONT></U>
<BR><FONT FACE=3D"Courier">An earlier OBJECTION describes why this =
clause should be removed. The information here is such a random =
collection of factoids that it is useless.</FONT></P>

<P><FONT FACE=3D"Courier">CD1 OBJECTION #37</FONT>
<BR><FONT FACE=3D"Courier">Section: Annex D, Clause 27 (Electronic mail =
addresses) and Clause 28 (Payment account numbers)</FONT>
<BR><U><FONT FACE=3D"Courier">Problem and Action:</FONT></U>
<BR><FONT FACE=3D"Courier">Remove these sections, as explained in an =
earlier OBJECTION. These are not cultural-specific.</FONT>
</P>

<P><FONT FACE=3D"Arial">CD2 TECHNICAL #137</FONT>
<BR><FONT FACE=3D"Arial">Section: Clause 28 (Payment account =
numbers)</FONT>
<BR><FONT FACE=3D"Arial">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?</FONT></P>

<P><FONT FACE=3D"Arial">The textual description of the structure of =
numbering for Danish Postal Giro accounts does not agree with the =
example. It is true that there are 7 digits in the example, but there =
is also a hyphen. Why is the hyphen not mentioned in the textual =
description? Is it always positioned between the 3<SUP>rd</SUP> and =
4<SUP>th</SUP> digits?</FONT></P>

<P><FONT FACE=3D"Courier">CD1 OBJECTION #38</FONT>
<BR><FONT FACE=3D"Courier">Section: Annex D, Clause 30 (Man-machine =
dialogue)</FONT>
<BR><U><FONT FACE=3D"Courier">Problem and Action:</FONT></U>
<BR><FONT FACE=3D"Courier">Remove this section, as explained in an =
earlier OBJECTION. This is too vague to be useful.</FONT>
<BR><B><FONT FACE=3D"Courier">38. See response 23.</FONT></B>
<BR><FONT FACE=3D"Arial">The Editor's disposition on US comment 23 =
was:</FONT>
<UL><UL>
<P><B><FONT SIZE=3D2 FACE=3D"Arial">23. Not accepted.</FONT></B> <FONT =
SIZE=3D2 FACE=3D"Arial">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.</FONT></P>
</UL></UL>
<P><FONT FACE=3D"Arial">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."</FONT></P>

<P ALIGN=3DCENTER><U><B><FONT FACE=3D"Arial">End of US =
comments</FONT></B></U></P>
<BR>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C2D113.9B6FE2A0--