Subject: N 3922-Disposition of Comments Report for SC 22 N 3666, ISO/IEC F CD 15897, Information technology - Procedures for registration of cultura l elements (Revision of ISO/IEC 15897: 1999)

From: Sally Seitz <[email-masked]>
Date: Tue, 2 Aug 2005 12:26:01 -0400

ISO/IEC JTC 1/SC22

Programming languages, their environments and system software interfaces

Secretariat:  U.S.A.  (ANSI)

ISO/IEC JTC 1/SC22 N3922

TITLE:

Disposition of Comments Report for SC 22 N 3666, ISO/IEC FCD 15897,
Information technology - Procedures for registration of cultural elements
(Revision of ISO/IEC 15897: 1999)

DATE ASSIGNED:

2005-08-02

SOURCE:

Project Editor (K. Simmonesen)

BACKWARD POINTER:

DOCUMENT TYPE:

Disposition of Comments Report

PROJECT NUMBER:

STATUS:

This document has been prepared in response to SC 22 N 3666.  

ACTION IDENTIFIER:

FYI

DUE DATE:

DISTRIBUTION:

Text

CROSS REFERENCE:

N3666

DISTRIBUTION FORM:

Def

Address reply to:

ISO/IEC JTC 1/SC22 Secretariat

Sally Seitz

ANSI

25 West 43rd Street

New York, NY  10036

Telephone:  (212) 642-4918

Fax:             (212) 840-2298

Email:  [email-masked] <mailto:[email-masked]> 

_____________End of cover sheet, beginning of document______________

                                            ISO/IEC JTC1/SC22/ N3922

                                                          2005-05-29

Title: Disposition of comments on FCD 15897

Source: Keld Simonsen, project editor

The ballotted document is SC22 N3586.

SC22 N3666 reflects the outcome of the ballot.

In addition late comments were received from Canada, and Ireland, which WG20

agreed to take into consideration in this disposition of comments.

All comments taken into account, 8 NBs voted in favour, (2 with comments),

and 4 voted against.  With this disposition of comments, one negative vote

was changed to an affirmative vote (USA).

Comments:

Comments from ITTF will be accomodated by the editor.

The occurrances of the words "shall have" and "shall be" will be changed to

"has" and "is" respectively in Clause 1 "Scope".

Canada:

> 10.2.2 Replace "hall" by "shall"

Response: Accepted. See also US comment 145

> Section 11 should contain, as the last item: Miscelleaneous requirements

> not covered elsewhere, as a hint for future i18n developments

Response: Not accepted, a registry should not be open ended.

If Canada has specific i18n items  not covered, that should be

specified as a new clause, and they are welcome to propose an amendment

to the standard. 

Ireland:

Comment accompanying the negative vote from Ireland:

> The contents of this document do not reflect a great many changes agreed
to be made

> to the draft before it was processed, and accordingly the draft cannot be
accepted.

Response: noted, this will be addressed under the comments from the USA.

Japan:

> Japan sees no necessity of this standard. In addition to that, Japan takes
it inappropriate

> to register cultural elements in terms of the methods described in ISO/IEC
TR 14652,

> which has many technically controversial items.

Response: The comment is noted.

Netherlands:

> We consider our objections to the previous draft (N 3523) not sufficiently
accomodated.

Response: Noted. The reference to CEN/TC304 will be removed. see also US
comment 28.

Norway:

> We propose that a script identifier from ISO 15924 be added in the
identifiers

> for Narrative Cultural Specifications, POSIX locales and other relevant
places.

> This is meant to address cultures that use multiple scripts, eg Cyrillic
and

> Latin scripts in Serbia.

Response: Accepted. The comment is accomodated by adding the following text
in 13.7:

", possibly also including script identifiers as specified in ISO 15924,

preceded by a hyphen.

NOTE: Guidance on the use of ISO 639, ISO 3166 and ISO 15924 codes for the
creation

of extended language codes can be found in RFC 3066."

A normative reference to ISO 15924 will be added.

USA:

> Subject: US Comments on FCD Text for the Revision of ISO/IEC 15897

> From: INCITS/L2

> Date: 2003-08-27

> Status: For the consideration of ISO/IEC JTC 1/SC 22/WG 20

> 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))

> * N1010 US comments on the CD2 ballot of ISO/IEC 15897 2003-01-29

> * N1020, Final Disposition of Comments, 15897 CD2, dated 2003-03-03

> * N1021, Text of ISO/IEC 15897 for FCD ballot, dated 2003-05-27

> ISO/IEC documents

> ISO/IEC Directives, Part 2, Rules for the structure and drafting of
International Standards. 4th.ed. 2001.

> JTC 1 Directives: ISO/IEC JTC 1. Procedures for the technical work of
ISO/IEC JTC 1. Last Modified: 02/24/2000 07:43:19.
http://www.jtc1.org/directives/main.htm

> Notation:

> A substantial number of the US comments on the first and second CDs 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 N1021. If text from
an earlier comment is quoted, the original number of the comment (as it
appeared in the relevant WG20 document) is shown, with the prefix "CD1" or
"CD2" to distinguish it from comments on the text of the FCD.

> Organization:

> US comments on the FCD consist of: 

> * general comments on technical issues and on editorial issues;

> * technical comments on specific clauses; and,

> * editorial comments on specific clauses

> Numbering of US comments on the FCD is continuous.

> GENERAL COMMENTS ON TECHNICAL ISSUES

> FCD General Comment #1 - Technical issue: On use of TR 14652 

> In the DoC on [CD2] General Comment #1, the Editor wrote:

> Partially accepted. It is not the intention to reference TR 14652
normatively

> in 15897.  However, agreement was reached in JTC1 to publish TR 14652

> as a TR type 1.  Controversies have been resolved as documented in TR
14652,

> but it is noted that there were issues with a number of specifications. 

> The publication of 14652 has as a Type 1 TR is for JTC 1 to gather
experience

> with the specification and possibly at a later time determine whether

> a specification based on the TR can be published as an International

> Standard. Non-normative reference of TR 14652 in 15897 thus enables JTC 1

> to collect experience with it. 15897 even allows specifications in
freeform

> notation and nonstandard machine readable formats, so it should also

> allow something that has been approved in JTC 1 as a TR type 1.

> Reference to TR 14652 "controversial" clauses will only be mentioned
alongside

> other non-normative machine readable formats.

> The US notes that TR14652 will not be referenced normatively in 15897, and
that references to clauses of TR 14652 that are labeled "controversial" will
only be included alongside other non-normative machine-readable formats.
Examples of such other formats are SGML and XML.

Response: noted.

> FCD 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.

> DoC on CD2 N1020

> Accepted in principle.

> There is a review and comment process in the registration standard, that

> ensures a fair process, and this is being enhanced as described elsewhere

> in these Disposition of Comments. The US should note that the Disposition
of

> Comments was produced by the WG20, and not solely by the editor.

> See FCD TECHNICAL COMMENTS #97, and  #102 to #106.

Response: the response is recorded with the specific US comments

> FCD General Comment #3 - Technical issue: Technical changes must be
justified

> The US has noticed a number of significant technical differences between
the CD2 and FCD texts, without corresponding NSB comments or WG resolutions
to justify them. Such changes are unacceptable, and must be removed. For
specifics, see these Technical Comments: 13a, 24, 35, 36, 40, 43, 48, 52,
53, 58, 67, 74, 82, 85, 88, 91, 92, 93, 102, 103, 104, 122.

Response: The response is recorded with the specific US comments

About unsubstantiated changes, the US acknowledges that the remarks on

unsubstantiated changes was a misunderstanding.

GENERAL COMMENTS ON EDITORIAL ISSUES

> FCD General Comment #4 - Editorial issue: Lack of Change Markers

> The unsubstantiated changes to the FCD text (see FCD General Comment #3)
were not apparent to reviewers because the Editor chose not to indicate
where changes to the text were made. Detecting the differences between the
CD2 and FCD texts required very careful comparison of the two texts, which
was extremely time-consuming.

Response: accepted in principle. The editor could have provided a
supplementary text

for the FCD ballot indicating changes if that had been requested. Change
markers

will be included in the future drafts.

> FCD General Comment #5 - Editorial Issue: Poor Organization

> In the DoC on [CD2] General Comment #3 summarizing the need for improved
organization, the Editor wrote:

> Accepted in principle.

> CD2 did a lot of restructuring based on the input in WG20 N945R,

> but not all changes suggested. As this point will be dealt with

> in the US comments below, the reponse will be noted there, and 

> not be dealt with further here.

> It is unfortunate that the reorganization suggested in Appendix 2 has not
been incorporated into the FCD (except for the addition of various headings
suggested there).

Response: noted. The editing was done with guidance from the US members of
the

editing group, but the restructuring that was offered, was not

in accordance with the decisions in the dispositon of comments for the FCD,
as it made

some normative text into informative text.

> FCD General Comment US#6 - Editorial Issue: Uncaught errors

> CD2 General Comment US#4 commented on the need to use the spell-checking
and grammar-checking features of modern word-processing software in
preparing ballot documents. The Editor accepted this recommendation.
However, N1020 contains a number of uncaught errors that suggest failure to
spell-check the document before it was submitted for distribution.

> The Editor also failed to verify all the URLs in the FCD (see the specific
technical comment on the Introduction for details).

Response: Noted. The document was spellchecked. URLs were checked, but
indeed there are URLs

that do not work currently in the document.

> FCD General Comment US #7 - 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.)."

> DoC on CD2 N1020

> Accepted: It was clarified that this applies to the ISO clauses, and not
to the

> narrative sepecifications.

> Any errors in capitalization of clause titles in the FCD will appear as
editorial comments on the individual clauses.

Response: Noted. This check was done by the editor, if there are still
errors, they

will be dealt with as noted in the response to US comments further below.

> End of General Comments

> SPECIFIC TECHNICAL COMMENTS

> Title

> FCD TECHNICAL #8

> The title of this standard is 

> Information technology - Procedures for registration of cultural elements

> but in clause 3 Terms and definitions "cultural element:" is defined as a
synonym for "cultural convention".

> Shouldn't the preferred term be used in the title?

> Note: There are 16 occurrences of "cultural convention" in the FCD, but
only 5 occurrences of "cultural element" (ignoring use in titles of
referenced documents).

Response: Not accepted, due to consistency with the title of the

existing standard the title is retained.

Explanation of the reuse of the title will be given in a note in clause 1
scope.

Wording "NOTE The title of this International Standard contains the term
"cultural

elements".

The preferred term in this International Standard is "cultural conventions",

but the term "cultural elements" is retained in the title for consistency

with earlier versions of this International Standard."

> Foreword

> FCD TECHNICAL:#9

> Second paragraph:

> International Standards are drafted in accordance with the rules given in
the ISO/IEC Directives, Part 3.

> Change "3" to "2".

> Rationale: Part 3, published in 1997, has been superseded by Part 2,
published in 2001.

Response: Accepted

> FCD TECHNICAL #10 

> Critical issue: Must be resolved to the satisfaction of the US to reverse
vote

> DoC on US CD2 TECHNICAL #5 which requested deletion of "and
repertoiremaps".

> Accepted in principle. However, repertoiremaps are a normative part of
15897

> itself and will be registerable as such. The sentence will be reworded to:

> This International Standard registers amongst other items

> Narrative Cultural Specifications and repertoiremaps as defined in this

> International Standard, POSIX Locales and POSIX Charmaps as defined in

> ISO/IEC 9945 "POSIX", and other machine parsable cultural specifications

> such as ISO/IEC TR 14652 FDCC-sets, charmaps and repertoiremaps, and

> cultural specifications in SGML.

> The second-last paragraph of the Foreword in  the FCD conforms to the
wording given in the DoC on the US comment CD2 TECHNICAL #5, augmented by
text in response to a comment from Germany. It reads:

> This International Standard registers amongst other items Narrative
Cultural Specifications and repertoiremaps as defined in this International
Standard, POSIX Locales and POSIX Charmaps as defined in ISO/IEC 9945
"POSIX", and other machine parsable cultural specifications such as ISO/IEC
TR 14652 FDCC-sets, charmaps and repertoiremaps, and cultural specifications
in SGML or XML.

> Change 

>  repertoiremaps as defined in this International Standard,

> to

>           repertoiremaps,

> Rationale:

> (a) This FCD is for a procedural standard not a technical standard (as
differentiated in JTC 1 Directives, clause 17.4.1);

> (b) This FCD does contain a detailed description (in clause 11.1) of the
layout and content of the Narrative Cultural Specification, The content of
the Narrative Cultural Specification is free text, so no technical
specification is needed for the Narrative Cultural Specification.

> (c) The technical specifications for the content of the repertoiremap are
defined by a separate national, regional, or international standard. This
FCD contains only information on how a repertoiremap that is included in an
application for registration must be formatted (clause 12). 

Response: accepted.

> Introduction

> FCD TECHNICAL #11

> Critical issue (ISO requirement): Must be met to satisfy the US and to
reverse vote

> There is a conflict between DoC on US CD2 TECHNICAL #7 and resulting text
in FCD.

> The DoC on US CD2 TECHNICAL #7 was "Partly accepted", but no change to the
text was made to address the concern expressed in US CD2 TECHNICAL #7:

> 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".

> The only difference between the CD2 text:

> 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/).

> and the FCD text:

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

> is that "network, at" has been changed to "Internet, via", but this was in
response to an entirely different comment, US CD2 EDITORIAL #80.

> Furthermore, the ISO URL http://www.iso.org/mara/ specified in the FCD
text produces the error message: Sorry, the URL you've requested doesn't
exist on this server. 

> Delete both URLs as was recommended in CD2 TECHNICAL #7.

> Rationale:

> (a) ISO has decreed that the actual URLs of registration agencies shall
NOT be included in International Standards. This decision was made when
ISO/IEC 2375 was under development. Therefore, http://www.dkuug.dk/cultreg/)
must be deleted to conform to ISO's decision.

> (b) Preference is being given to the English language list. ISO maintains
equivalent lists in English and French.

> (c) Unnecessary repetition of information available elsewhere in the FCD
can result in errors as in this case;

Response: accepted in principle. The text will remove the references to
urls, and say

it will be freely available on the internet, see clause 6.3.

> FCD TECHNICAL #12

> Critical issue (ISO requirement): Must be met to satisfy the US and to
reverse vote

> In the DoC on US CD2 TECHNICAL #7, the Editor asserted that the dkuug.dk
URL should be mentioned here because "The ISO URLs are hard to browse as
they produce some big lists."

> This is a specious argument. Only a totally naïve browser user would
scroll down through the list of maintenance agencies and registration
authorities. Using the browser's "find" capability to search for "15897"
takes one straight to the entry for the 15897 Registration Authority.

Response: Noted. The requirement for reversal of vote is withdrawn by the
US.

> 1 Scope

> FCD TECHNICAL #13a

> Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote

> CD2, 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.

> FCD, First paragraph, middle sentence:

> The cultural specifications may include freeform Narrative Cultural
Specifications as defined in the International Standard, Repertoiremaps as
defined in this International Standard, POSIX Locales and Charmaps
conforming to ISO/IEC 9945, and other machine-parsable specifications such
as FDCC-sets, repertoiremaps and charmaps following the recommendations of
ISO/IEC TR 14652, and cultural specifications in SGML and XML.

> Changes between CD2 and FCD and sources for the changes are:

> 1. "narrative cultural specifications" capitalized, "conventions" dropped.
(Source: None, but required for consistency)

> 2. "as defined in the International Standard" added. (Source: None)

> 3. "Repertoiremaps as defined in this International Standard" added.
(Source: DoC on US TECHNICAL #9, but it conflicts with DoC on US GENERAL
TECHNICAL #1)

> 4. "9945-2" changed to "9945" (Source: US CD2 TECHNICAL #8. DoC:
Accepted.)

> 5. "other machine-parsable specifications such as" added. (Source: None)

> 6. "cultural specifications in" added. (Source: None)

> 7. "and XML" added. (Source: Germany, Technical Comments, 1st Accepted.)

Response: Accepted in principle. Items 2, 6 and 7 has been addressed by

rewording of the paragraph. First comma replaced by "and".

The first occurance on "as defined in the International Standard" is
deleted.

"in SGML" -> formatted using SGML or"

The WG20 Editing Group agreed on the following rewording of the paragraph
for the FDIS

(rewording includes responding to US comment 13b):

"The cultural specifications may include freeform Narrative Cultural
Specifications and

Repertoiremaps as described in this International Standard, POSIX Locales
and Charmaps

conforming to ISO/IEC 9945, and other machine-parsable specifications such
as

FDCC-sets, repertoiremaps and charmaps following the recommendations of

ISO/IEC TR 14652, and cultural specifications formatted using SGML or XML.

> FCD TECHNICAL #13b

> Change "as defined in the International Standard" to "as described in this
International Standard"

> Rationale: As given in FCD TECHNICAL #10 above.

Response: accept. This relates to the second occurrance on repertoiremaps.

> FCD TECHNICAL #14

> Critical issue: Must be resolved to the satisfaction of the US to reverse
vote

> Delete "Repertoiremaps as defined in this International Standard,"

> Rationale: 

> 1. Reason for addition given in DoC on US TECHNICAL #9 "Repertoiremaps are
defined normatively in IS 15897" conflicts with statement in DoC on US
GENERAL TECHNICAL #1. The general statement should be generally applicable.

> 2. As given in FCD TECHNICAL #10 on "and repertoiremaps as defined" above.

Repsonse: comment withdrawn from the US.

> FCD TECHNICAL #15

> Critical issue: Must be resolved to the satisfaction of the US to reverse
vote

> Delete

> other machine-parsable specifications such as FDCC-sets, repertoiremaps
and charmaps following the recommendations of ISO/IEC TR 14652, and cultural
specifications in SGML and XML.

> and substitute:

> other machine processable specifications following the recommendations of
ISO/IEC TR 14652, SGML or XML.

> Rationale:

> 1. Portions of FCD text not justified by NSB comments or DoC. Substitute
text is modeled on DoC on US CD2 TECHNICAL #6.

> 2. Distinction made between ISO/IEC TR 14652 and SGML and XML conflicts
with DoC on US GENERAL COMMENT #1.

Response: Accepted in principle. The US was satisfied by the rewording

agreed upon by the editing group in US comment number 13a.

> 2 Normative references

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

> DoC on  CD2 TECHNICAL #14

> Aceepted in principle. The newest standards will be cited, but some older

> standards will be cited also, as some registrations refer to the old
standards.

> See FCD TECHNICAL comment on Clause 12 Format of a Repertoiremap.

> FCD TECHNICAL #16

> ISO 3166 (all parts), Codes for the representation of names of countries.

> Cited title does not match the title of this standard now shown in the
online ISO Catalogue:

> Codes for the representation of names of countries and their subdivisions.

Response: accepted.

> FCD TECHNICAL #17

> ISO/IEC 8824:1990.

> N1021 includes these citations: 

> ISO/IEC 8824:1990, Information technology - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1).

> ISO/IEC 8825:1990, Information technology - Open System Interconnection -
Specification of Basic Encoding Rules for Abstract Syntax Notation One
(ASN.1).

> Update these two citations to agree with the relevant parts of the 1998
editions of these ASN.1 standards.

> Rationale: See entries for these standards in the ISO Catalogue.

> Note that Open Systems Interconnection is no longer in the titles.

Response: accepted - titles will be changed to current titles.

> 3 Terms and definitions

> FCD TECHNICAL #18

> Critical issue: Must be resolved to the satisfaction of the US to reverse
vote

> Inadequate application of Accepted CD2 comments:

> In CD2 comments on clauses 3.1 and 3.3 (CD2 TECHNICAL #15 AND #16), the US
requested that the references to clauses in the superseded edition of
ISO/IEC 9945 be replaced with those from the 2003 edition. Instead of
supplying the relevant clauses, the Editor substituted the descriptive
phrase from the comment for the (now obsolete) reference to a clause of the
POSIX standard. 

> It is hard to understand how the Editor could have so severely
misinterpreted what should be done. Throughout its comments, the US
explicitly identifies replacement text by the instructions "Delete ... and
substitute ..." or "Change ... to ..." This pattern of wording was not used
in CD2 TECHNICAL #15 AND #16.

> The US did not have access to the 2003 edition of the POSIX standard, only
to the version on The Open Group's Web site (which does not show clause
numbering). Had we been able to identify the specific clause number to be
substituted, we would have given the precise replacement text in each of our
comments.

> A definition must be as precise as possible, and all definitions must be
mutually consistent. Rather than substituting "the locale section" for
"clause 2.5" and "the Character Set section" for "clause 2.4", the Editor
should have demonstrated due diligence by determining the proper clause to
cite in each case. We assumed that the Editor (who is also the WG20 liaison
to SC 22/WG 15) would be able to identify the appropriate clauses. If in
doubt as to the intent of these comments, he should have consulted the US
National Body for guidance.

Response: accepted in principle. There are no clause numbers in the new
9945, only

section names.  Thus the references are as precise as they can be.
References will

be reworded to include the section name; for example, see the section named
"Locale".

> FCD TECHNICAL #19

> Critical issue: Must be resolved to the satisfaction of the US to reverse
vote

> 3.1 locale

> CD2 TECHNICAL #15

> CD2 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.

> FCD text reads:

> The definition of the subset of a user's information technology
environment that depends on language, territory, or other cultural customs.
See the locale section of the ISO/IEC 9945-1:2002 POSIX standard for a
specification of the locale file format.

> Cite the exact clause or clauses of ISO/IEC 9945 where the locale file
format is specified.

> Rationale: For consistency with other definitions. 

Response: accepted in principle. see response to US number 18.

> FCD TECHNICAL #20

> Critical issue: Must be resolved to the satisfaction of the US to reverse
vote

> 3.3 charmap

> The definition of charmap in the FCD says:

> See the Character Set section of the ISO/IEC 9945-1:2002 POSIX standard
for a description of the POSIX Charmap file format, ...

> as a result of the application of US comment CD2 TECHNICAL #16:

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

> In implementing the DoC, the Editor substituted the phrase "the Character
Set section" for the obsolete reference "clause 2.4.":

> Restated comment: Cite the exact clause or clauses of the 2003 edition of
ISO/IEC 9945 where the POSIX charmap file format is specified.

> Rationale: For consistency with other definitions.

Response: accepted in principle. see response to US number 18.

> FCD TECHNICAL #21

> The definition of charmap in the FCD reads:

> A text file describing a coded character set. See the Character Set
section of the ISO/IEC 9945-1:2002 POSIX standard for a description of the
POSIX Charmap file format, and clause 5 of ISO/IEC TR 14652 for the
description of an enhanced charmap.

> Delete the second clause of the second sentence:

> , and clause 5 of ISO/IEC TR 14652 for the description of an enhanced
charmap.

> so that the definition reads:

> A text file describing a coded character set. See clause [number of the
clause for the Character Set section] of the ISO/IEC 9945-1:2002 POSIX
standard for a description of the POSIX Charmap file format.

> Number of the clause of ISO/IEC 9945-1:2002 that deals with Character Sets
to be supplied by the Editor (See the comments FCD TECHNICAL #18 and #20).

> Rationale: 

> The element Terms and definitions is one of the technical normative
elements of a standard (ISO/IEC Directives: Part 2, clause 6.3). Because
this is normative text, items in the bibliography, which is a supplementary
informative element (ibid, clause 6.4), cannot be included. The text
referring to "ISO/IEC TR 14652" must be deleted.

Response: accepted in principle. see response to US number 18. The reference
to TR 14652 will be deleted.

> 3.6 cultural element

> FCD TECHNICAL #22

> DoC on US CD2 TECHNICAL #18:

> Accepted. It [cultural element] will be defined as a synonym for "cultural
convention".

> Text of clause 3.6 in FCD:

> 3.6

> cultural element

> A synonym for a cultural convention.

> Delete clause 3.6, and renumber the following clauses 3.7 to 3.11 as 3.6
to 3.10.

> In clause 3.6, add "cultural element" (in regular typeface) on a separate
line between the preferred term "cultural convention" and the definition.

> Rationale: See example in ISO/IEC Directives: Part 2, clause C.3.3. This
clause dictates that synonyms are not treated as independent terms, but are
included in the clause that defines the preferred term.

Response: accepted.

> 3.7 cultural specification

> CD2 TECHNICAL #17 

> Insert the following text between "Repertoiremap" and the comma which
follows it:(except an ISO/IEC TR 14652 Repertoiremap)

>  DoC on CD2 TECHNICAL #17 states:

> Partially accpeted, as in the response to US comment 9.

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

>  Text of DoC on US comment #9 reads:

> Partially accepted, as noted in the response to US comment 1.
Repertoiremaps

> are defined normatively in IS 15897 so they will be mentioned after the

> Narrative cultural specifications, and once more with 14652, but the

> text will indicate that the 14652 registration is with the same status

> as SGML and XML specifications, as other machine prossesble
specifications.

> Definition of cultural specification in FCD reads:

> Either a Narrative Cultural Specification, a POSIX Locale, a FDCC-set, a
POSIX Charmap, an ISO/IEC 15897 Repertoiremap, an ISO/IEC TR 14652
Repertoiremap, or other machine-processable description of cultural
conventions such as ISO/IEC TR 14652 FDCC-sets, Charmaps or Repertoiremaps,
or cultural specifications in SGML or XML.

> FCD TECHNICAL #23

> Critical issue: Must be resolved to the satisfaction of the US to reverse
vote

> Delete "an ISO/IEC 15897 Repertoiremap"

> Rationale: 

> 1. This FCD does not include a specification for a repertoiremap. Clause
12 merely defines the format of a repertoiremap. ISO/IEC 15897 is a
procedural standard; the specification of a repertoiremap must come from a
technical standard.

> 2. See also US comments on Foreword and Introduction.

Response: accepted in principle. The wording will be changed to "a
Repertoiremap".

> FCD TECHNICAL #24

> Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote

> Insert "Charmap, a" between "14652" and "Repertoiremap"

> Rationale: Restores text of CD2. (Removal of this normative text was not
proposed in any NSB comment.)

Response: accepted in principle. The text "ISO/IEC 15897 Repertoiremap, an
ISO/IEC TR 14652 "

will be deleted.  The change was done to not reference 14652 things in a
normative

category, and TR 14652 charmaps are now referenced on level with XML. 

Based on the changes resulting form the DoC on US comments #23 and #24,

The definition of "cultural specification" now  is:

Either a Narrative Cultural Specification, a POSIX Locale, a POSIX

Charmap, a Repertoiremap, or other machine-processable description of

cultural conventions such as ISO/IEC TR 14652 FDCC-sets, Charmaps or 

Repertoiremaps, or cultural specifications in SGML or XML.

> 6.3 Identity [of the Registration Authority]

> FCD TECHNICAL #25

> Critical issue (ISO requirement): Must be met to satisfy the US and to
reverse vote

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

> DoC on US CD2 TECHNICAL #21

> Not accepted. See response to US comment 7.

> DoC on US CD2 TECHNICAL #7 states:

> Partly accepted. It does not hurt, and helps the reader that the dkuug.dk
URL

> is mentioned in the specification. The ISO URLs are hard to browse

> as they produce some big lists.

> The US reiterates CD2 TECHNICAL #21.

> Rationale: See FCD TECHNICAL #11 comment on Introduction. The Editor is
refusing to obey an editorial decision of ISO.

Response: Withdrawn by the US. 

> 7.1 Identity [of the Sponsoring Authority]

> List of who may submit applications for registration now is:

> a) Any Member Body of ISO/IEC JTC1, for applications limited to the
territory or territories for which they have authority;

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

> b) CEN/TC304 for applications related to the region of Europe;

> c) ISO/IEC JTC 1 and its Subcommittees and Working Groups, for any
applications;

> FCD TECHNICAL #26

>  CD2 TECHNICAL #24 proposed the inclusion of liaisons in the equivalent of
item (a). The DoC on CD2 TECHNICAL #24 stated: Liaisons do not have any
authority, and will not be included.

> This disposition conflicts with the provisions of clause 3.3.4.2 of the
JTC 1 Directives, where Category A liaisons are defined as:

> Organizations which make an effective contribution to and participate
actively in the work of JTC 1 or its SCs for most of the questions dealt
with by the committee.

> and Category C liaisons are defined as:

> Organizations which make an effective technical contribution and
participate actively at the WG or project level of JTC 1 or its SCs.

Response: Not accepted. Withdrawn by the US.

> FCD TECHNICAL #27

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

> The wording of item b does not agree with CEN's categories for membership
and participation in technical work:

> * CEN National Members are "the national standards bodies of <list>". ..."
The Members develop and vote for the ratification of European Standards."

> Source: http://www.cenorm.be/aboutcen/whatis/membership/members.htm

> * Associates are "broad-based European organizations representing
particular sectors of industry as well as consumers, workers, and small and
medium-sized enterprises. ... They participate in the General Assembly
(without voting rights), the Administrative Board when policy matters are
being discussed, the Technical Board and any other technical body."

> Source: http://www.cenorm.be/aboutcen/whatis/membership/associates.htm

> * Affiliates are "the national standards bodies of Central and Eastern
European countries which can in principle become members of the Union or
EFTA, and which therefore can become full National Members of CEN on
fulfilment of certain criteria, most importantly the adoption of European
Standards as national standards. 

> They may participate in the General Assembly and in technical bodies. "

> Source: http://www.cenorm.be/aboutcen/whatis/membership/affiliates.htm

> Make the following changes to item (b):

> Delete:

> Any Member Body or Associated Member Body

> and substitute:

> Any National Member, Associate, or Affiliate

> Rationale: To agree with current CEN terminology. The US assumes that
"Associate" is meant by "Associated Member Body". The US sees no reason to
exclude CEN Affiliates, which are national standards bodies and would
therefore be eligible under item (a) in any case.

Response: accepted.

> FCD TECHNICAL #28

> The Netherlands commented on CD2:

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

> and the Editor replied in the DoC (N 1020):

> Noted. No acction taken, pending the determination of the future status of
TC304.

> As of June 2002, CEN TC304 was declared dormant by BT/TCMG on behalf of BT
except for 3 specific work items. For details, see
http://www.cenorm.be/isss/Projects/CDSG/docs/CDSG03_03BTres12_2002.pdf

> The 3 specific work items were described in Programming for Cultural
Diversity Consensus-Building (dated 2002-08-14 and available as SC22/WG20
N974), page 49:

> As it stands, the only definite ongoing work would be the three following
work items, and their remaining life cycle is very short, as they are near
their completion stages:

> 1. European Fallback Rules (ch. to TR) 26.10.2

> 2. European extension to ISO repertoire of OCR-B (EN) (built on Test
results) 26.15

> 3. Revision work on EN 1923 (Inclusion of euro sign and missing European
letters in new TS 1923)

> TC 304 no longer appears in the CEN pull-down lists of Technical
Committees. (http://www.cenorm.be/standardization/tech_bodies/cen_tcs.htm ,
last updated 2003-05-12). All of the other CEN/ISSS Technical Committees (as
listed at http://www.cenorm.be/isss/TC/Default.htm, last update 2003-07-04)
appear on the pull-down lists.

> Given these developments, the US supports the comment of the Netherlands.

Response: accepted.

> 7.2 Responsibilities [of the Sponsoring Authority]

> Item c

> FCD TECHNICAL #29

> c) in the case of a POSIX Locale or Narrative Cultural Specification, to
ensure that Narrative Cultural Specification and the derived POSIX Locale
are not in contradiction.

> Relocate this item in clause 13 Rules for Cultural Specifications as
follows:

> Delete item c) of clause 7.2 and redesignate remaining items of clause 7.2
as c) through g).

> Insert a new clause between clauses 13.3 and 13.4. The new clause is
designated 13.4; existing clauses 13.4 to 13.7 are redesignated 13.5 to
13.8. Text of the new clause:

> If an application for registration includes a POSIX Locale as well as a
Narrative Cultural Specification, the POSIX Locale shall not contradict the
Narrative Cultural Specification.

> Rationale: This is a rule for the Cultural Specification, so it belongs in
clause 13. Three bodies have responsibility for seeing that the rules for
Cultural Specifications are obeyed: (1) the Sponsoring Authority which
submits the application for registration, and (2) the Registration Authority
and (3) the RA-JAC which both review applications.

> * The responsibility of the Sponsoring Authority is specified in item b
which references clause 13.

> * The requirements for review by the Registration Authority is specified
in clause 15.5 which references various parts of clause 13.

> * The requirements for review by the RA-JAC are specified in clause 15.6.

> Note: Relocating item c to clause 13 will satisfy the US concerns
expressed in CD1 TECHNICAL #113.

Response: accepted in principle. Response to US comment 32 addresses this.

> Item d

> FCD TECHNICAL #30

> DoC ON CD2 TECHNICAL #26

> Accepted in principle. The copyright may be retained, but the rights on
copying

> and modification needs to be relinguished. See also German comments.

> Item (d) in the FCD now is:

> d) if any material in an application is under copyright, to assure that
free distribution of the Cultural Specification is permitted.

> Unacceptable wording. The Sponsoring Authority must supply a document in
which the copyright holder grants permission for the inclusion of its
copyrighted material in the Cultural Specification and the distribution of
the copyrighted material as part of the Cultural Specification. Furthermore
(in accordance with the German comment), there should be no payment due to
the copyright holder when the material under copyright is distributed.

> Rationale: 

> 1. Agreement with ISO/IEC 2375:2003.

> 2. To protect JTC 1 from accusations of copyright infringement, there must
always be documented permission from the copyright holder for the use and
distribution of copyrighted material included in a registered cultural
specification.

> Note: Some of the registrations in
http://anubis.dkuug.dk/cultreg/registrations/chreg.htm appear to come from
copyrighted sources.

> German comment from N 1020

> >  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)

> Accepted, will be changed to allow the free distribution of the
specification,

> with words as in annex A.

> Both are needed. (a) Written permission to redistribute copyrighted
material. (b) Ability to redistribute the copyrighted material without
having to pay a fee to the copyright holder.

Response: accepted in principle. The US will work with the editor on

wordings to address both requirements.

> 8.2 Responsibilities

> FCD TECHNICAL #31

> Text of item (b):

> b) if any material in a Cultural Specification is under copyright, to
assure that free distribution of the Cultural Specification is permitted;

> Inadequate wording. See also CD2 TECHNICAL #26

> # Copyright clearance

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

> Weakened in Editor's rewording. Source of Information is now responsible
for obtaining the copyright clearance. Sponsoring Authority is responsible
for making sure that any copyrighted material in an application is
accompanied by documented clearance for use and reproduction.

Response: Accepted in principle, see response to US comment 30.

> CD2 clause 9 Rules for applications

> FCD TECHNICAL #32

> Critical issue: Must be resolved to the satisfaction of the US to reverse
vote

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

> DoC on CD2 N1020

> The response to this is recorded in Appendix 2.

> The DoC on  Appendix 2 (in N 1020) was only:

> Accepted in principle. Headings will be added.

> The US considers this to be an inadequate response. Appendix 2 should have
been "Accepted" (not ignored via "Accepted in Principle") because it is
better organized than the existing clauses.

Response: accepted in princple. The US NB will work with the editor to
complete the 

reorganization in accordance with the suggestions made in

US comments to CD2 appendix 2 in WG20 N1020.

> FCD clause 9 The Registration Authority's Joint Advisory Committee

> Clause 9.1 Membership

> FCD TECHNICAL #33

> Critical issue: Must be resolved to the satisfaction of the US to reverse
vote

> Was CD2 TECHNICAL #58, item 2

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

> DoC on CD2 TECHNICAL #58

> Accepted in principle. The title will be changed. The obligation of the
JAC to

> respond to RA will be worded in another way to emphasis

> this as an obligation of the JAC.

> FCD text:

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

> Delete this text (last paragraph of clause 9.1).

> Rationale: 

> 1. The paragraph is in the wrong place. Rewording it does not correct the
error.

> 2. The information also appears in clause 15.13 (which is the correct
place for it).

Response: accepted.

> Clause 9.2 Appointment

> Clause 9.2, first paragraph

> FCD TECHNICAL #34

> Critical issue: Must be resolved to the satisfaction of the US to reverse
vote

> FCD text: (unchanged from CD2):

> The subcommittee responsible for maintaining this standard shall appoint
the members of the RA-JAC, except for the RA representative, which is
appointed by the RA.

> US request in CD2 TECHNICAL #60 to delete "except for the RA
representative, which is appointed by the RA" was rejected.

> Not accepted. It is normal that an organization, such as the RA,

> appoints its own representative. "except for the representative

> of the RA" will be added to the second sentence.

> The text in the first paragraph of clause 9.2 of the FCD is unacceptable
to the US unless "except for the RA representative, which is appointed by
the RA" is deleted.

> Rationale: It is unclear whether the representative of the Registration
Authority (RA) is appointed by SC22 (based on a nomination by the RA), or
whether the person responsible for the maintenance of the Registry is ex
officio the representative of the RA.

> This issue should be clarified, so that the text can reflect the decisions
of JTC 1 and SC22.

> In the absence of authoritative information, the phrase "except for the RA
representative, which is appointed by the RA." should be deleted.

> Since the text is unchanged from the CD2, these additional reasons still
apply:

> 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:2003. 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".

Response: withdrawn by the US.

> Clause 9.2, second paragraph

> FCD TECHNICAL #35

> Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote

> FCD text:

> The subcommittee responsible for maintaining this standard shall appoint
or confirm the members of the RA-JAC at its plenary meetings, except for the
representative of the RA.

> Delete the comma following "meetings" and the final clause of the
paragraph:

>          except for the representative of the RA

> Rationale: Addition of the final clause not supported by a NB comment.

> Note: The US notes that the Editor also changed "meeting" to "meetings".
The US has no objection to this editorial change (although singular is also
permissible English usage here, implying "each of" its plenary meetings). 

Response: withdrawn by the US.

> Clause 9.3 Responsibilities

> FCD TECHNICAL #36

> Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote

> In CD2 TECHNICAL #63, the US proposed substitution of the following text,
which was Accepted:

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

> Although the text supplied by the US was "Accepted" the Editor made the
following changes:

> 1. Omitted the final sentence: 

> In addition, the RA-JAC may added comments to a registration.

> 2. Added another item (not justified by NSB comment nor WG 20 resolution):

> to submit comments, that four fifths of the RA-JAC agree upon, to a
registration for publication together with the registration 

> The final sentence in the text proposed in CD2 TECHNICAL #63 has a
grammatical error, and should have been:

> In addition, the RA-JAC may add comments to a registration.

Response: accepted in principle. In addition a text is added in 15.13 to
require a four/fifths majority

for such comments.

> Clause 10.1 Types of Cultural Specifications

> first paragraph:

> FCD TECHNICAL #37

> Item 4 in the list reads:

> 4. POSIX Repertoiremap

> Delete "POSIX"

> Rationale: POSIX has never defined repertoiremaps, so wording is
incorrect.

Response: accepted.

>  FCD TECHNICAL #38 -- #40

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

> DoC on CD2 N1020

> Not accepted. See response to US comment 1. The reference to 14652 

> repertoiremaps will

> be put in a note, saying that this format is equivalent to 15897
repertoiremaps.

> Corresponding text in FCD (clause 10.1, paragraph 4 and accompanying note)
reads:

> Type 4 is for Repertoiremaps defined in this International Standard
(clause 12).

> Note: As far as Repertoiremaps according to ISO/IEC TR 14652 is also in
accordance with clause 12, these can also be registered as Type 4.

Response: there is no US comments 38.

> FCD TECHNICAL #39

> Critical issue: Must be resolved to the satisfaction of the US to reverse
vote

> Delete

> defined in this International Standard (clause 12)

> and add a second sentence:

> Clause 12 defines the format of a repertoiremap included in an application
for cultural registration.

> Rationale: This FCD is for a procedural standard, which cannot define
technical specifications for a repertoiremap.

Response: accepted

> FCD TECHNICAL #40

> Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote

> Remove the note.

> Rationale:

> 1. The note is redundant because any repertoiremap that is part of an
application for registration, whether it is created according to ISO/IEC TR
14562 or not, must conform to clause 12.

> 2. The note is unsubstantiated as it was not specified in US comment CD2
TECHNICAL #29.

> Note: The layout of the note does not conform to ISO/IEC Directives: Part
2, clause 6.5.1.

Response: partially accepted, this was specified as response in CD2 US
comment 29.

the layout will be corrected as requested.

> 10.2 Relations between registration types

> FCD TECHNICAL #41

> Critical issue: Must be resolved to the satisfaction of the US to reverse
vote

> CD2 TECHNICAL #30

> CD2 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.

> DoC on CD2 N1020

> Partially accepted. Repertoiremaps ar a part of this standard. See

> also response to US comment 1. Wording of "one or more" will be added.

> Corresponding text in FCD (clause 10.2.2) reads:

> The POSIX locale hall specify appropriate aspects of a Narrative Cultural
Specification in formal POSIX syntax. The POSIX Locale shall refer to the
ISO/IEC 15897 Repertoiremap being used, and should also list one or more
POSIX Charmaps that it can use.

> Revise the second sentence as follows:

> The POSIX Locale should list one or more POSIX Charmaps that it can use.

> Rationale: 

> ISO/IEC 15897 is a procedural standard, so cannot specify the technical
details of a repertoiremap. (Clause 12 describes only the layout for a
repertoiremap included in an application for registration.)Note: The
typographical error in clause 10.2.2 is addressed in a separate editorial
comment.

Response: accepted in principle. Text will be changed to:

"The POSIX locale shall specify appropriate aspects of a Narrative Cultural

Specification in formal POSIX syntax. The POSIX locale shall refer to either

one or more POSIX charmaps it can use, or to a Repertoiremap."

> Clause 10.2.3

> FCD TECHNICAL #42

> Delete:

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

> and substitute:

> A POSIX Charmap may refer to POSIX locales, Narrative Cultural
specifications, or Repertoiremaps that it uses, but such references are not
required."

> Rationale:

> The second sentence in the current FCD text requires that a repertoiremap
be identified in a POSIX charmap registration. This is incorrect, since (a)
POSIX does not define repertoiremaps, and (b) this procedural standard can
only describe the format of repertoiremaps.

Response: accepted.

> Clause 10.2.4

> FCD TECHNICAL #43

> Critical issue: Must be resolved to the satisfaction of the US to reverse
vote

> Current text:

> The ISO/IEC 15897 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.

> Corresponding text in CD2:

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

> Remove "ISO/IEC 15897"Rationale:

> 1. This standard is a procedural standard and so cannot specify the
technical details for a repertoiremap.

> 2. The addition of "ISO/IEC 15897" is unsubstantiated by any NB comment.
The WG 20 decision on the disposition of CD2 General Comment #1 does not
apply here because this clause deals only with repertoiremaps.

Response: accepted.

> Clause 10.2.5

> FCD TECHNICAL #44 -- #45

> DoC on CD2 TECHNICAL #31

> Partially accepted. See response to US comment 1. The reference for 

> repertoiremaps will be clarified to mean the 15897 repertoiremap.

> The first "shall" will be changed to "may".

> Corresponding text in FCD (clause 10.2.5) reads:

> 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 may refer to a corresponding Narrative Cultural
Specification. In case of a TR 14652 FDCC-set it shall refer to the ISO/IEC
15897 Repertoiremap being used, and should also list one or more Charmaps
that can be used.

> FCD TECHNICAL #44

> Critical issue: Must be resolved to the satisfaction of the US to reverse
vote

> Delete the sentence:

> In case of a TR 14652 FDCC-set it shall refer to the ISO/IEC 15897
Repertoiremap being used, and should also list one or more Charmaps that can
be used.

> and substitute:

> A TR 14652 FDCC-set may refer to the Repertoiremap being used, and should
also list one or more Charmaps that can be used.

>  Rationale: 

> 1. ISO/IEC 15897 is a procedural standard, so cannot specify the technical
details of a  repertoiremap.

> 2. Stylistic improvements to clarify instruction.

Response: accepted.

> FCD TECHNICAL #45

> Critical issue: Must be resolved to the satisfaction of the US to reverse
vote

> ERROR: In the first sentence, the second (not the first) "shall" has been
changed to "may".

> To reduce the complexity of this sentence, the US proposes that this
sentence be reworded as follows:

> Some aspects of a Narrative Cultural Specification may be specified in
formal syntax as a TR 14652 FDCC-set, or other machine-parsable cultural
specification, which shall refer to the corresponding Narrative Cultural
Specification.

> Rationale: As currently worded, it is unclear as to what the referent of
"it" is.

Response: accepted in principle, "shall" is changed to "may" in the last
dependent

clause, that is "...  which may refer to ...".

> Clause 10.2.6

> FCD TECHNICAL #46

> Critical issue: Must be resolved to the satisfaction of the US to reverse
vote

> Text in FCD (clause 10.2.6) reads:

> 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 ISO/IEC 15897 Repertoiremap being used, and
may refer to the FDCC-set or the Narrative Cultural Specifications using it.

> Delete the second sentence:

> In case of a Charmap it shall refer to the ISO/IEC 15897 Repertoiremap
being used, and may refer to the FDCC-set or the Narrative Cultural
Specifications using it.

> and substitute:

> A Charmap may refer to the Repertoiremap being used, and may refer to the
FDCC-set or the Narrative Cultural Specifications using the Charmap.

> Rationale: 

> 1. ISO/IEC 15897 is a procedural standard, so cannot specify the technical
details of a repertoiremap.

> 2. Since Repertoiremaps are only a controversial part of ISO/IEC14652,
it's incorrect to require that a Charmap "shall refer to the [ISO/IEC 15897]
Repertoiremap being used."

> 3. Consistent with the corresponding text of CD2, clause 9.2.6.

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

> 4. Stylistic improvements to clarify instruction. Also corrects absence of
a comma between "Charmap" and "it".

Response: accepted.

> Clause 11

> FCD TECHNICAL #47

> In response to US CD1 OBJECTION #22, the Editor incorporated the text of
Annex G into CD2 clause 9.4, including the duplicative list of items (that
are listed and described in more detail elsewhere in the standard).

> US comment CD2 TECHNICAL #34 explained:

> The intent of the US comment [CD1 #22] was to eliminate double look-up.
Instead of checking Annex G, the user must now check clause 9.4. The problem
persists.

> The DoC on this comment was::

> Accepted in principle. The US NB is invited to provide revised

> text for the consideration of the editor.

> In Appendix 2 of the US comments on CD2, the US provided substitute text
that eliminated the problem. The DoC on  Appendix 2 (in N 1020) was:

> Accepted in principle. Headings will be added.

> Since the Editor invited the US to supply text to fix the problem, but did
not use the text that was supplied, the US can only assume that the proposed
text was overlooked. We therefore describe the necessary changes here:

> Delete the first two paragraphs of Clause 11 and their dependent lists.

> Rationale: Repeats information available in more detail in the same
clause.

Response: accepted in principle, see response to US comment 32.

> Clause 11.1 Contents of Narrative Cultural Specification

> Introductory paragraph, first and second sentences:

> Although the text proposed by the US was accepted in the DoC (N1020),
different text appears in the FCD:

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

> FCD TECHNICAL #48

> Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote

> Delete the following cases of added text: that were not in the US-supplied
text that was Accepted. They are unsubstantiated by any other NSB comment or
a WG20 resolution.

> (a) "Guidelines for"

> Rationale: Redundant.

> (b) "informally"

> Rationale: Inappropriate. This text is normative, so is hardly informal.

Response: accepted. Additionally clause 11.1 will be marked as 

Informative, which was its intent, as it was derived from informative Annex
G.

> FCD TECHNCIAL #49

> "clause" is missing from the end of the first sentence.

> Rationale: Appears in Accepted text.

Response: accepted. "in the following" will be changed to "in this clause"

> FCD TECHNCIAL #50

> In the second sentence, delete:

> The information

> and substitute

> The specification

> Rationale: "specification" appears in Accepted text. "information builds
on information" is not satisfactory.

Response: accepted

> FCD TECHNCIAL #51

> Critical issue (ISO requirement): Must be met to satisfy the US and to
reverse vote

> New clause: Mandatory clauses

> Insert a new subclause numbered 11.1.1, with the heading "Mandatory
clauses", between the Note and the heading "Clause 1: Alphanumeric
deterministic ordering".

> Text of subclause:

> The format of a Narrative Cultural Specification shall contain the clauses
(numbered 1-6) specified below. These clauses are POSIX categories. The
Narrative Cultural Specification should be accompanied by a corresponding
POSIX Locale specification. 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:

> Rationale: Corresponds to heading "Optional clauses" called for according
to ISO Directives (see New clause: Optional clauses below).

Response: accepted.

> FCD TECHNCIAL #52

> Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote

> Clause 3: Numeric formatting

> Current text:

> This clause describes how numbers are formatted (for input and output),
including the format of the decimal point and the thousands gouping
separator. The specification is intended to be used by all programs that
produce numbers, including table generating programs where multiple numbers
are displayed together, and the specification is also meant for numbers that
do not have fractions. Special considerations for how numbers should be
formatted in narrative text and other numeric formatting that cannot be
handled by the POSIX standard may be specified in Clause 20. This is a POSIX
category.

> All of the text between the first and last sentences is new in the FCD. In
its comments on CD2, the Netherlands NB asked for more explanatory text for
this and other clauses, and that comment was accepted with the note:

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

> Accepted in principle. "Deterministic ordering" and other possibly

> unclear terms will be will be explained more fully. ...

> Remove the sentence:

> The specification is intended to be used by all programs that produce
numbers, including table generating programs where multiple numbers are
displayed together, and the specification is also meant for numbers that do
not have fractions.

> Rationale:

> That DoC does not support the new, detailed description of how this clause
supports the definition of numeric formatting. There is no agreement within
WG20, for example, that this clause is intended for table generating
programs, or that it is meant for numbers that do not have fractions. 

Response: accepted.

> FCD TECHNCIAL #53

> Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote

> Clause 5: Date and time conventions

> Current text, fifth and sixth sentences:

> 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,
and the abbreviated date formats should be of constant length for them to be
used in lists. The long formats should be usable in narrative text such as
letters. 

> Remove these two sentences.

> Rationale:

> Addition of the text has not been sanctioned by any NSB comment or WG20
resolution.

Response: withdrawn by the US. The text was added to accomodate comments
from The Netherlands.

> FCD TECHNCIAL #54

> Critical issue (ISO requirement): Must be met to satisfy the US and to
reverse vote

> New clause: Optional clauses

> Delete the sentence:

> The following clauses are not directly related to POSIX Locales, and they
are optional:

> preceding "Clause 7: National or cultural Information Technology
terminology".

> In its place, insert a new subclause numbered 11.1.2, with the heading
"Optional clauses", above "Clause 7: National or cultural Information
Technology terminology".

> Text of subclause:

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

> Rationale: 

> 1. The boldface sentence is a hanging paragraph which "should be avoided
since reference to them is ambiguous." (ISO/IEC Directives, Part 2, clause
5.2.4)

> 2. From US CD2 TECHNICAL #48

> The US notes that the optional nature of these data elements ("Clauses")
has been specified immediately before Clause 7. We prefer the approach used
in Appendix 2, where the required and optional data elements ("Clauses") are
separated into distinct numbered clauses. The US preference is also in
accordance with the ISO/IEC Directives regarding the need for the explicit
numbered references for the text of a standard.

Response: accepted.

> Clause 8: National or cultural profiles of standards

> FCD TECHNICAL #55

> 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..."

> DoC on CD2 TECHNICAL #116

> Partly accepted. The 1993 standard will be referenced.

> FCD text:

> In this clause profiles of standards can be listed, for example, OSI
national profiles, or profiles of the POSIX standards. See the POSIX ISO/IEC
9945-2:1993 standard Annex G for an example.

>  Remove this sentence.

> See the POSIX ISO/IEC 9945-2:1993 standard Annex G for an example.

> Rationale:

> 1. The 1993 edition is obsolete, and the material in Annex G is not
included in the new POSIX standard, so references to this must not be cited
in normative text.

> 2. Because the 1993 edition is obsolete, it cannot be obtained from ISO,
so it is a disservice to the users of this standard to cite it.

Response: not accepted. It is permissable to refence older standards, 

this is done by referencing the standard by year of publication.

Note that clause 11.1 is now informative only.

> Clause 10: Sorting and searching rules

> FCD TECHNICAL #56

> CD2 text:

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

> FCD text:

> This clause is for specifying sorting and searching rules that cannot be
specified with POSIX specifications, such as ISO/IEC 14651 specifications,
non-deterministic ordering, pre-handling and post-handling of records, such
as how to split a record into sorting fields, and rules for common words
like a, the which may be ignored when comparing or searching. Also sound
based matching rules may be described here. What can be accomplished
deterministically with POSIX should be described in clause 1.

> The FCD text has not been sanctioned by any NSB comment or WG20
resolutions, so the CD2 text must be restored.

Response: withdrawn by the US. The text was added to accomodate comments
from The Netherlands.

> Clause 11: Transformation of characters

> FCD TECHNICAL #57

> The DoC on US CD1 Objection #49 (requesting removal of this clause) was:

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

> In CD2 TECHNICAL #118, the US commented:

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

> DoC on CD2 TECHNICAL #118

> Accepted. A reference will be given.

> FCD text:

> This clause describes transliterations and transformations of characters,
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. Examples of
transliteration and fallback specifications in a syntax described in an
earlier draft of ISO/IEC TR 14652 may be found in the bibilographic
reference 4.

> The US recommends that Clause 11 Transformation of characters be annotated
"Not recommended."

> Rationale:

> 1. The justification for the DoC on US CD1 Objection #49 is false. No
elaborate transliteration specs "in 14652 style" have been shown to exist.

> 2. Inclusion of item 4 in the bibliography is not warranted because the
examples cited do not provide the required model for what should be in this
clause.

Response: not accepted. The examples specified do give specifications

of transliteration and fallbacks.

> Clause 13: Use of special characters

> FCD text:

> This clause describes the use of special characters, that is characters
that are not letters, ideographics or syllables or other characters used to
write words of a language, digits or control characters. Examples of special
characters are quotation marks, abbreviation marks, and punctuation marks.
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.

> Corresponding CD2 text:

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

> US CD2 TECHNICAL #120 stated:

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

> The DoC on US CD2 TECHNICAL #120 was merely:

> Accepted.

> FCD TECHNICAL #58

> Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote

> The following changes were made to the text of Clause 13 between the CD2
and the FCD:

> 1. Here use of special characters was changed to This clause describes the
use of special characters 

> This change was in response to US comment CD2 EDITORIAL #103 which was
Accepted.

> 2. The following text was added: 

> that is characters that are not letters, ideographics or syllables or
other characters used to write words of a language, digits or control
characters.

> To be added to the FCD, the new wording should have been included in the
DoC, and should have represented either a recommendation from a National
Body or wording formulated at the WG20 meeting in February. None of these
requirements were met.

Response: withdrawn by the US. The text was added to accomodate comments
from The Netherlands.

> FCD TECHNICAL #59

> Omit "control characters" from the current definition of "special
characters."

> Rationale: Control characters are a feature of information technology, not
a feature of writing systems (which the other listed items appear to be).

> Note: If control characters are also to be excluded, they should be listed
separately, and it should be explained why they are excluded. (Perhaps
because world-wide interoperability of information technology requires the
use of control characters defined in culturally-neutral International
Standards.)

Response: accepted in princple. The sentence is rewritten to clarify that
special

charcters exclude control characters. See also comment 60.

> first sentence

> FCD TECHNICAL #60

> Insert "or that are not" between "language," and "digits", so that the
sentence reads:

> This clause describes the use of special characters, that is characters
that are not letters, ideographics or syllables or other characters used to
write words of a language, or that are not digits ...

> Rationale: As currently written, the "other characters" that are excluded
are those "used to write ... digits or control characters." The intent is to
exclude the digits themselves (Re control characters, see preceding
comment.)

Response: accepted.

> third sentence

> FCD TECHNICAL #61

> Lack of clarity in the sentence:

> 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

> 1. Should number signs in general be avoided? Or is the issue that there
are culture-specific signs used to represent the word "number" (for example,
# in the U.S.), and the number sign appropriate to a particular culture
should be used?

> 2. The US believes that "pilcrow sign" here should be "signs for
paragraphs and sections." There is no question about what a pilcrow sign is,
but different cultures use the pilcrow sign for different purposes, and the
same applies to the section sign.

> 3. Should division signs in general be avoided? Or is the issue that there
are culture-specific division signs, and the division sign appropriate to a
particular culture should be used? (Given the international use of
mathematics, the US questions the assertion that "division signs are not
used in documents in several cultures.")

> Proposed substitute text:

> Information about culture-specific signs, and what should be avoided, may
also be included in Clause 13; for example the preferred abbreviation for
"number", the signs used to indicate a paragraph and a section in text, and
the preferred sign used to indicate division.

> Rationale: Clarity.

Response: accepted.

> Clause 16: Personal name rules

> FCD TECHNCIAL #62

> CD2 TECHNICAL #123 protested the defective DoC on  CD Objection #50. The
DoC on US CD2 TECHNICAL #123 was:

> Not accepted. Issues like this can be addressed with TR 14652 technology.

> The US reinstates its objection.

> Rationale: 

> 1. No evidence is presented that TR 14652 can be used to solve the
questions posed in CD1 OBJECTION #50. The Editor has justified his "Not
accepted" decision on CD2 TECHNICAL #123 with an unsupported assertion. This
is unacceptable.

> 2. The DoC on CD Objection #50 remains defective. The Editor failed to
respond to the questions raised by the US in this comment.

Response: Noted.

> FCD TECHNICAL #63

> In CD2 TECHNICAL #124, the US recommended that this clause be annotated
"Not recommended".

> DoC on CD2 TECHNICAL #124,

> Not accepted. Issues like this can be addressed with TR 14652 technology.

> Defective disposition. The US repeats its recommendation that this clause
be annotated "Not recommended".

> Rationale: No evidence is presented that TR 14652 can be used to solve
this problem. The Editor has justified his "Not accepted" decision with an
unsupported assertion. This is unacceptable.

Response: noted.

> Clause 17: Inflection

> FCD TECHNICAL #64

> FCD text:

> Languages vary much with respect to inflection, that is different forms of
a word depending of the context. In this clause the rules can be described
or referenced. Some common localization APIs today take some aspects of this
into account, for example the UNIX gettext() functions deal with
singular/plural forms of nouns.

> In CD2 TECHNICAL #125, the US requested: 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.

> DoC on CD2 TECHNICAL #125

> Not accepted. Other software may have the ability to handle inflection.

> Defective disposition. The US repeats its requirement to remove the
sentence beginning "Some common translation APIs..." 

> Rationale: No evidence is presented of software that has the ability to
handle inflection. The Editor has justified his "Not accepted" decision with
an unsupported speculation. This is unacceptable.

Response: Accepted. The last sentence will be removed.

> FCD TECHNICAL #65

> In CD2 TECHNICAL #126, the US recommended 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.

> DoC on CD2 TECHNICAL #126

> Not accepted. Software is being produced to take account of this, for
example translation software.

> The US repeats its recommendation that this clause be annotated "Not
recommended".

> Rationale: No substantive evidence supporting the Editor's assertion about
translation software is presented. The disposition is defective.

Response: noted.

> Clause 22: Date and time

> FCD TECHNICAL #66

> In the FCD, the normative text of Clause 22 has been substantially
modified:

> This is for considerations in excess of clause 5, such as non-POSIX date
conventions, time zone names and daylight savings rules, week numbering,
national holidays, further date formatting rules in excess of the
possibilities of the POSIX standard, preferably also with a description of
the field of use for the format, such as in narrative text, in letters, in
contracts, in formal documents; and other ways that time may be expressed,
like the British "half seven", which means 07:30 or 19:30, where "halb
sieben" means 06:30 or 18:30 in Germany.

> The normative text of Clause 22 in the CD2 (in clause 9.4) was identical
to the informative text in ISO/IEC 15897:1999 and CD1 of the revision
(Clause 22: Date and time in the informative Annexes F and G, respectively).

> 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 US objects to these unsubstantiated modifications (see FCD TECHNICAL
#67 below), and continues to object to the inclusion of time zones and
daylight savings rules for the reasons given in CD1 OBJECTION #51 and CD2
TECHNICAL #128 and #130. There is a new problem with inclusion of the "half
seven/halb sieben" example in the normative FCD text (see FCD TECHNICAL #69
below).

> The US proposes new text that resolves all these issues, while preserving
the examples:

> Clause 22: Date and time

> This clause is for date and time conventions which are not accommodated by
clause 5, that is, other ways in which time may be expressed beyond POSIX
date and time conventions. Such conventions should preferably be augmented
by a description of the field or fields where the convention is used.

> NOTE 1: Date and time conventions that are not specified by POSIX include
time zone names, daylight savings rules, week numbering, national holidays,
and colloquial expressions. Examples of colloquial expressions are the
British "half seven," which means 07:30 or 19:30, and the German "halb
sieben" (literally, "half seven") which means 06:30 or 18:30.

> NOTE 2: Fields of use include narrative text, letters, and legal documents
such as contracts.

> Rationale: The statement of requirements (which is normative) must be
separate from specific cases and examples (which are informative). The
specific cases and examples in Clause 22 provide additional information
intended to assist the understanding or use of Clause 22. This conforms to
the definition of "supplementary elements" which are defined as informative
(ISO/IEC Directives, Part 2, clause 3.7.2). Therefore this information,
which is part of the text, must appear as notes or examples (ISO/IEC
Directives, Part 2, clause 6.5.1).

> Note: The literal translation of "halb sieben" has been added to make the
cultural differences in meaning apparent to a reader unfamiliar with German.

Response: accepted.

> FCD TECHNICAL #67

> Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote

> In the FCD, the normative text of Clause 22 has been substantially
modified :

> This is for considerations in excess of clause 5, such as non-POSIX date
conventions, time zone names and daylight savings rules, week numbering,
national holidays, further date formatting rules in excess of the
possibilities of the POSIX standard, preferably also with a description of
the field of use for the format, such as in narrative text, in letters, in
contracts, in formal documents; and other ways that time may be expressed,
like the British "half seven", which means 07:30 or 19:30, where "halb
sieben" means 06:30 or 18:30 in Germany.

> Remove the following text from FCD, Clause 22:

> week numbering, national holidays, further date formatting rules in excess
of the possibilities of the POSIX standard, preferably also with a
description of the field of use for the format, such as in narrative text,
in letters, in contracts, in formal documents;

> to yield:

> This is for considerations in excess of clause 5, such as non-POSIX date
conventions, time zone names and daylight savings rules, and other ways that
time may be expressed, like the British "half seven", which means 07:30 or
19:30, where "halb sieben" means 06:30 or 18:30 in Germany.

> Compare the resulting text with the corresponding normative text in CD2
(clause 9.4). This text in CD2 is identical to the informative text in Annex
F of ISO/IEC 15897:1999 and Annex G of CD1 15897.

> 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?

> Rationale: 

> 1. These substantive changes to normative text are not specified in any NB
comments on CD2, nor in the DoC on CD2 (WG 20 N1020). See Details below.

> 2. The overall scope of this clause;

> for considerations in excess of clause 5, such as non-POSIX date
conventions,

> is unnecessarily repeated in the phrase:

> further date formatting rules in excess of the possibilities of the POSIX
standard,

> Details: 

> Comments on CD2 were made by Germany, Japan, Netherlands, UK, and USA.

> Germany and the U.S. commented on CD2 clause 9.4 Contents of a Narrative
Cultural Specification. Japan, Netherlands, and UK did not comment on the
clause.

> Germany's comments did not apply to Clause 22: Date and time. The US
comments on Clause 22 were: (a) a request to remove the entire clause (CD2
TECHNICAL #128); (b) the defective discussion of "half seven"/"halb sieben"
(CD2 TECHNICAL #129), and (c) marking Clause 22 as "controversial" if it was
not removed (CD2 TECHNICAL #130).

> US comments CD2 TECHNICAL #128 and #130 were not accepted in the
Disposition of Comments. The DoC on CD2 TECHNICAL #129 was:

> Accepted. Changed to: Other ways that time can be expressed.

> which sanctions the addition of "other ways that time may be expressed".

Response: Withdrawn by the US. This text was introduced in response to the
Netherlands CD2 comments.

> FCD TECHNICAL #68

> [CD1] OBJECTION #51

> Section: Annex G, Clause 22 (Date and time)

> CD1 text:

> "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.

> CD2 TECHNICAL #128

> CD2 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.

> In CD2 TECHNICAL #128, the U.S. still objected strongly to including time
zone information in cultural narratives (as stated in CD1 Objection #51),
and requested that the phrase "...time zone names and daylight savings
rules..." be removed. The US also objected:

> Also, time zone information in a locale or cultural narrative was labeled
[as] controversial in TR 14652, and it is incorrect to elevate it to
normative status in this standard.

> DoC on CD2 TECHNICAL #128

> Not accepted. This spec is also in currently approved IS 15897,

> so there is no new elevation. See also response to US comment 1.

> and (on quoted CD1 OBJECTION #51)

> Not accepted. It is a cultural convention what the timezone is called,

> and it is not unfeasible to specify even the most complicated time zone

> rules, eg for USA.

> Then CD2 TECHNICAL #130 applies. See FCD TECHNICAL #70 below.

Response: withdrawn by the US.

> FCD TECHNICAL # 69

> FCD text after application of FCD TECHNICAL #67 reads:

> This is for considerations in excess of clause 5, such as non-POSIX date
conventions, time zone names and daylight savings rules, and other ways that
time may be expressed, like the British "half seven", which means 07:30 or
19:30, where "halb sieben" means 06:30 or 18:30 in Germany.

> Examples do not belong in normative text. Delete the following two pieces
of text.

> 1. Delete this text: (including the trailing comma and space):

> time zone names and daylight savings rules, 

> 2. Delete this text (including the preceding comma and space):

> , like the British "half seven", which means 07:30 or 19:30, where "halb
sieben" means 06:30 or 18:30 in Germany

> Rationale: Notes and examples are informative elements (ISO/IEC
Directives, Part 2, clause 6.5.1).

> Note: The US considers "non-POSIX date conventions" to be an amplification
of the definition in the preceding clause, and therefore retention of this
phrase in normative text is appropriate.

Response: accepted in principle, as response to US comment 66 was accepted.

> FCD TECHNICAL #70

> Critical issue: Must be resolved to the satisfaction of the US to reverse
vote

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

> DoC on CD2 TECHNICAL #130

> Not accepted. The time zone names and daylight saving rules clause was
already present in the first edition of IS 15897. The clause is not not here
breacause of 14652 but reflects that timezone issues are a cultural issue.  

> The US request to remove "...time zone names and daylight savings
rules..." in CD2 TECHNICAL #128 was "Not accepted". The US therefore
strongly recommends that this clause be annotated "Controversial". The US
also recommends the addition of a note to explain the annotation.

> NOTE Clause 4.7 LC_TIME in ISO/IEC TR 14652 is labeled "Controversial" for
two reasons which are documented in clause D.2, item 7 of ISO/IEC TR 14652.

> Rationale: Defective DoCs.

> The DoC on CD2 TECHNICAL #130 states:

> The time zone names and daylight saving rules clause was already present
in the first edition of IS 15897.

> DoC on CD2 TECHNICAL #128 states:

> This spec is also in currently approved IS 15897, so there is no new
elevation.

> The relevant text in Annex F (informative) of International Standard
ISO/IEC 15897:1999 is:

> 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
expression like "half seven" - what is then really meant - 06:30 as in
Germany or Denmark, or 07:30 as in Britain?

> The important thing about this text is that it appears in informative
annexes in ISO/iEC 15897:1999 (Annex F) and CD1 15897 (Annex G). The
comparable text in CD2 (clause 9.4) and this FCD is normative, so there has
been an elevation. Because this text remains normative, it is essential that
users be warned about problems have been identified with respect to time
zone information in a locale or cultural narrative. 

respronse: accepted in principle. This text is now informative.

> FCD TECHNICAL #71

> Clauses 23, 26, 27, 28 and 30

> In CD2 TECHNICAL #131 and #132, the US recommended that these clauses be
annotated "Not recommended" because the definitions are "too vague to be
useful", or "contain information that is application-specific rather than
culture-specific "

> The DoC on these comments was:

> Not accepted. There need not be any specific format for this, as it is
freeform.

> The US reiterates its recommendation to annotate these clauses "Not
recommended".

> Rationale: The DoCs are non-responsive. The US was not objecting to the
format for the information (it is freeform). The US was objecting to the
fact that the text of each of these clauses does a poor job of explaining
what information should be included when the clause is included in a
Cultural Narrative Specification.

Response: not accepted, but note that this clause is now informative text.

> Clause 12 Format of a Repertoiremap

> FCD 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, defined with a line for each character 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. An escape character can be used to escape the syntactical
meaning of the following character, so that the following character is
included literally. The default escape character for the Repertoiremap is
the reverse solidus (\). The escape character for the Repertoiremap 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.

> FCD TECHNICAL #72

> >From the DoC on US CD2 TECHNICAL OBJECTION #44

>  (b) For the POSIX 1993 spec, this will still be referenced in the
standard,

> and thus references can be retained.

> Delete the sentence:

> It is recommended to use, whenever possible, character names specified in
ISO/IEC 9945-2:1993 Annex G.

> Rationale:

> 1. International Standard ISO/IEC 9945 has been revised and most of the
character names in Annex G of ISO/IEC 9945-2:1993 have been eliminated.

> 2. ISO/IEC 9945-2:1993 is obsolete and no longer available from ISO. It is
ridiculous to recommend use of a document that is both obsolete and
unavailable.

Response: accpeted in principle. Moved to a note, worded as follows:

"Chraracter names as specified in ISO/IEC 9945-2:1993 annnex G may be used,

many of the charmap registrations do so."

> FCD TECHNICAL #73

> >From the DoC on US CD2 TECHNICAL OBJECTION #44

> (c) The definition here of the escape character is for the specific

> 15897 repertoiremap format, (and not the charmap format). If there is no

> specification for redefining the escape character, this is not possible

> according to this spec, so these wordings are needed.

> Delete these sentences:

> The default escape character for the Repertoiremap is the reverse solidus
(\). The escape character for the Repertoiremap 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.

> Rationale: 

> 1. This is the wrong place for this information. The specification for how
to redefine the escape sequence does not belong in this procedural standard
but in the technical standard that specifies a particular repertoiremap
syntax.

> 2. There is more than one convention for redefining the escape sequence
for a repertoiremap. It is wrong to describe only one (especially when there
was no consensus on its technical suitability).

Response: not accepted. However, "The repertoiremap" will be changed to

"a Repertoiremap", 3 times. 

> FCD TECHNICAL #74

> Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote

> 4th and 5th sentences:

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

> Although the changes made to these sentences were not requested in NSB
comments or WG2 decisions, the substitution of "shall be" for "are"
[separated] and "should be" [preceded] is correct.

> Change:

>          are each surrounded by

> to

>          shall each be surrounded by

> Rationale: Consistency.

Response: accepted.

> Clause 13 Rules for Cultural Specifications

> Clause 13.2.2 

> 13.2.2 Format of a POSIX Locale or Charmap

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

> FCD TECHNICAL #75

> Critical issue: Must be resolved to the satisfaction of the US to reverse
vote

> Item (b) in US comment CD2 TECHNICAL #35 on the two lasts paragraph of CD2
clause 9.3.2, stated:

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

> The DoC on US comment CD2 TECHNICAL #35 was:

> Partly accepted. The repertoiremap is an integral part of this

> standard, and needed and already present in the 1st edition,

> so it cannot be removed. The posix locale and charmap specs

> will be updated.

> Delete the comma and this text:

> or for POSIX Locales the technique specified in Annex E

> Rationale: Annex E is normative. It is adding normative capabilities to
POSIX without the knowledge or consent of the authors of ISO/IEC 9945 or the
National Bodies active in WG15.

> See also FCD TECHNICAL comments on Annexes E and F below. 

Response: accpted in principle. The text is reworded as follows:

Locales which are otherwise conformant to ISO/IEC 9945, 

but which make use of the extention technique defined in annex E,

are also permissable for registration.

> Clause 13.2.3

> FCD TECHNICAL #76

> FCD, clause13.2.3 Format of a Repertoiremap

> If a Repertoiremap is included in a registration, it shall follow the
format described in

> clause 12.

> CD2, clause 9.3.2, last paragraph:

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

> Item (c) in US comment CD2 TECHNICAL #35 on  CD2 clause 9.3.2 stated:

> As noted before, the TR 14652 Repertoiremap is controversial and shall not
be a normative part of this standard.

> The DoC on US comment CD2 TECHNICAL #35 was:

> Partly accepted. The repertoiremap is an integral part of this

> standard, and needed and already present in the 1st edition,

> so it cannot be removed. The posix locale and charmap specs

> will be updated.

> It is unclear which standard is being referred to in the DoC. If "this
standard" refers to ISO/IEC 15897, the text addressing the format for a
repertoiremap has not been proposed for removal. FCD clause 12 is almost
identical to clause 6.9 if the first edition (1999),. The US was objecting
to the repertoiremap in TR 14652. TR 14652 is not a standard, and was not
published until 2001 (i.e., after the first edition of ISO/IEC 15897).

> The US has no objection to the rewording of clause 13.2.3

Response: noted

> Clause 13.4

> FCD TECHNICAL #77

> Clause 13.4, first sentence:

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

> Delete "(ISO 2375 registration number 6)".

> Rationale: The 1991 edition of ISO/IEC 646 is cited in clause 2 Normative
references. Furthermore:

> (a) There is no explicit registration for the 1991 version of ISO/IEC 646
in the ISO/IEC 2375 Registry.

> (b) ISO-IR 6 designates ISO 646, USA Version X3.4 - 1968.

> Citing the registration number is potentially confusing to users who are
unaware of the relationship between US ASCII and the IRV of ISO/IEC 646.

Response: accepted

> Clause 13.4, second sentence

> FCD TECHNICAL #78

> Clause 13.4, second sentence:

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

> US CD2 TECHNICAL OBJECTION #37 requested removal of this sentence. The DoC
on US CD2 TECHNICAL OBJECTION #37 was:

> Not accepted. Non-invariant ASCII characters is still a problem, even in

> 2003, in everyday places in a number of places, including Denmark and
Korea.

> Delete this sentence (for the following new reason):

> This sentence conflicts with the specification in the preceding sentence
for use of "ISO/IEC 646 International Reference Version".

> 1. In the IRV of ISO/IEC 646, the options for the non-invariant characters
have been exercised (ECMA-006, clause 1.2). Thus, the IRV has a completely
invariant content, and the non-invariant characters do not present a
problem.

> Reference:
http://www.ecma-international.org/publications/standards/ECMA-006.HTM

> 2. There seems to be confusion between the occurrence of non-invariant
ASCII characters in very old legacy data (which causes difficulties in their
correct interpretation) and what is being specified here: use of a
particular character set to specify rules for the documentation of cultural
elements. Roman Czyborra (see Background information below) says that
national variants of ASCII fell out of use because ISO/IEC 8859-1 provided a
more interoperable standard.

> The US also notes that both the 1993 and 2003 versions of the POSIX
standards allow all graphic characters in ISO 646 IRV. Given the need of
POSIX implementers for registered cultural conventions, it would be a major
disservice to the POSIX community if ISO/IEC 15897 disallowed some of the
characters that are valid for POSIX.

> Background information:

> ASCII and its national variants were declared international standard ISO
646 in 1972. Back then, the socialist countries managed to substitute the
international currency sign EUR for ASCII's capitalist dollar sign $ in the
first international reference version ISO-646-IRV but this was revised in
1991 and now ISO-646-IRV is a synonym for ISO-646-US or US-ASCII as it is
used in the core Internet protocols. ISO-646's national variants have fallen
out of use because of their obvious problems and because the 8bit ASCII
extension ISO-8859-1 has offered a more interoperable standard.

> Source: Czyborra, Roman. Good ole' ASCII.
http://czyborra.com/charsets/iso646.html

Response: not accepted. WG20 could not reach consensus to make the proposed
change.

> FCD TECHNICAL #79

> Critical issue: Must be resolved to the satisfaction of the US to reverse
vote

> Clause 13.4, last sentence:

> If characters outside ISO/IEC 646 International Reference Version are
needed, character names defined in a ISO/IEC 15897 Repertoiremap shall be
used.

> Delete

> an ISO/IEC 15897 Repertoiremap

> and substitute:

>          a repertoiremap formatted according to clause 12.

> Rationale: 

> 1. This FCD does not include a specification for a repertoiremap. Clause
12 merely defines the format of a repertoiremap. ISO/IEC 15897 is a
procedural standard; the specification of a repertoiremap must come from a
technical standard.

> 2. See also US comments on Foreword and Introduction.

Response: accepted.

> Clause 13.7, third paragraph

> FCD text:

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

> 10. Suggested Charmap or ISO/IEC 15897 Repertoiremap or other name

> FCD TECHNICAL #80

> Critical issue: Must be resolved to the satisfaction of the US to reverse
vote

> Delete the second occurrence of "POSIX" so that the text reads:

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

> Rationale: POSIX does not and never has defined repertoiremaps.

> Note: POSIX is defined solely by the normative references to the four
parts of International Standard ISO/IEC 9945.in clause 2 of the FCD.

response: accepted

> FCD TECHNICAL #81

> Critical issue: Must be resolved to the satisfaction of the US to reverse
vote

> In CD2 TECHNICAL #40, the US requested addition of:

> A TR 14652 Repertoiremap shall not be used.

> The DoC on this US comment was:

> Partially accepted. See response to US comment 1. The reference for
repertoiremaps will be clarified to mean the 15897 repertoiremap.

> Delete

> "ISO/IEC 15897"

> Rationale: 

> 1. This clause describes the content of the application form. The wording
on the application form (see Annex A) is:

> 10. Charmap, Repertoiremap or Machine-parsable coded character set name:

> 2. This FCD does not include a specification for a repertoiremap. Clause
12 merely defines the format of a repertoiremap. ISO/IEC 15897 is a
procedural standard; the specification of a repertoiremap must come from a
technical standard.

> 3. See also US comments on Foreword and Introduction.

Response: accepted

> Clause 14 Specification of the token identifier

> FCD TECHNICAL #82

> Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote

> Clause 14, first paragraph

> The last sentence reads:

> The maximum lenght of a token identifier is 200 characters.

> This sentence does not appear in the CD2. It has not been sanctioned by an
NSB comment nor by WG20 consensus. It must be removed.

Response: Withdrawn by the US, because it was an error. The text was
introduced as a

response to CD2 US comment 19.

> Clause 14, third and sixth paragraphs

> FCD TECHNICAL #83

> 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?

> DoC on  CD2 TECHNICAL #43:

> Accepted. National Body is intended.

> Correction has only been made to 3rd paragraph. In 6th paragraph
(immediately above NOTE 2), change "National Standardization Organizations"
to "National Bodies".

Response: accepted

> Clauses 15 and 16

> Was New clauses on Registration procedures

> FCD TECHNICAL #84

> >From CD2 TECHNICAL #49

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

> DoC on  US CD2 TECHNICAL #49

> Accepted, as noted in US comment 50 and 51.

> Conflict between this DoC and the disposition of US comment #50 which was
"Accepted in principle".

Response: noted.

> Clause 15 Initial registration procedures

> DoC on US CD2 TECHNICAL #50

> Accepted in princple. What is technical will be clarified as only

> technical requirements needed for registration, such as conforming to
syntax

> and administrative issues.

> Clause 15.2

> Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote

> FCD TECHNICAL #85

> The Sponsoring Authority shall submit an application and associated
proposed token identifiers for registration of a cultural specification to
the Registration Authority.

> Unsubstantiated changes to US text which was Accepted:

> "an application for registration" --> "an application and associated
proposed token identifiers for registration"

> Delete "and associated proposed token identifiers".

> Rationale: Proposed token identifiers are just one component of an
application. There is no need to note them separately here. 

Response: accepted

> Clause 15.3

> FCD TECHNICAL #86

> First item:

> The applicant is a Sponsoring Authority as identified in clause 7. The RA
shall reject applications for registrations which come from sources other
than the Sponsoring Authorities as defined in clause 7, or applications for
registrations that the Sponsoring Authority does not have to authority to
submit according to clause 7.1 or clause 7.2 item e. The Registration
Authority may refer the applicant to an appropriate Sponsoring Authority if
one can be identified.

> Changes to US text:

> , or applications for registrations that the Sponsoring Authority does not
have to authority to submit according to clause 7.1 or clause 7.2 item e.

> Delete

> or clause 7.2 item e

> Rationale: Clause 7.2 item e describes the components of an application
for registration. Therefore, it belongs in clause 15.4. It does not have to
do with whether an applicant may submit an application , i.e., is recognized
as a legitimate Sponsoring Authority.

Response: accepted.

> FCD TECHNICAL #87

> Second item:

> The proposed cultural specification is not identical to one already
registered.

> Omitted (justifiably) by the Editor. Text should have been "is identical".
Add correctly worded item in the position shown in CD2 TECHNICAL #50:

> -- The proposed cultural specification is identical to one already
registered.

Response: accepted in principle. Text added:

"The proposed cultural specification is not identical to one already
registered."

The following paragraph will be changed from "this requirement" to "either
of these

requirements".

> Clause 15.4

> FCD TECHNICAL #88

> Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote

> - The application for registration is in the proper syntax of the type of
the Cultural specification, See clause 13.2, 13.3, 13.4 and 13,5.

> Not part of US text.

Response: accepted in principle.

The change was done as a consequence of the CD2 response to US comment 50. 

13,5 will be deleted.

Clause changed to clauses.

A new paragraph will be added with the following words:

The format of the application conforms to clause 13.5.

> Clause 15.5

> FCD TECHNICAL #89

> Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote

> FCD, clause 15.5, first sentence:

> The Registration Authority shall submit the application to the RA-JAC for
review for syntactical and administrative requirements required for the
registration. 

> Changes to US text:

> "for the technical review" --> "for review for syntactical and
administrative requirements required for the registration".

> Change back to original text.

> Rationale: 

> 1. The RA-JAC is not responsible for ensuring that an application for
registration meets the administrative requirements.

> 2. The Editor has provided no explanation of why "technical" should be
replaced by "syntactical", and whether there is a difference between the two
terms.

The Response: partially accepted. The text "and administrative" will be
deleted.

The editors explanation for the use of the word "syntactical" was accptable
to the US.

> FCD TECHNICAL #90

> Delete the four items in clause 15.5 (which duplicate those in clause
15.4) and substitute these two items:

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

Response: Accepted. The text will be changed with substitution of

"technical" to "syntactical" and the clause number will be 13.7.

>  Clause 15.6

> FCD TECHNICAL #91

> Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote

> The RA-JAC shall report the results of its evaluation for formal
registration requirements within 30 days to the Registration Authority and
shall describe any formal concerns with the proposed registration.

> Changes to US text:

> "evaluation" --> "evaluation for formal registration requirements:

> no time specified --> "within 30 days"

> "technical concerns" --> "formal concerns"

Response: Withdrawn by the US.

The editors explanation for the change was accptable to the US.

> Clause 15.7

> FCD TECHNICAL #92

> Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote

> The Registration Authority shall inform the Sponsoring Authority of any
changes needed to satisfy the concerns on formal registration requirements
of the RA-JAC.

> Changes to US text::

> "concerns" --> "concerns on formal registration requirements"

> Delete "on formal registration requirements".

> Rationale: It would be necessary to define the "formal registration
requirements".

Response: accepted in principle. "formal" will be deleted here and in 15.6.

15.7 will be reworded to: " concerns of the RA-JAC regarding registration

requirements." 

> Clause 15.8

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

> Changes to US text::

> "its review" --> "its review for formal errors"

> "the application" ==> "the application with the proposed token
identifiers"

> "standard" --> "standard and to the RA-JAC"

> FCD TECHNICAL #93

> Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote

> Delete "for formal errors"

> Rationale: 

> 1. Redundant. The items being reviewed are defined in detail in preceding
clauses.

> 2. Would require the definition of what constitutes a "formal error".

Response: accepted in principle. "formal" changed to "syntactical and
administrative".

> FCD TECHNICAL #94

> Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote

> Delete "with the proposed token identifiers".

> Rationale: Confusing. The wording "application with the proposed token
identifiers" suggests that there is an application without the proposed
token identifiers that is not circulated to members and liaison
organizations.

Response: accepted in principle. Change "with" to "and".

> FCD TECHNICAL #95

> Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote

> Delete "and to the RA-JAC".

> Rationale: The RA-JAC has just seen the application. It does not need to
see it again.

Response: Withdrawn by the US.

> FCD TECHNICAL #96

> shall circulate the application to the members and liaison organizations 

> Why should the applications for registration be circulated to the liaison
organizations when they are unable to act as a Sponsoring Authority? (See
FCD TECHNICAL #26)

Response: withdrawn by US.

> Clauses 15.9 and 15.10

> FCD TECHNICAL #97

> Text proposed by the US in CD2 TECHNICAL 50:

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

> FCD text:

> 15.9 The Registration Authority shall forward all comments received
according to clause 15.8 to the Sponsoring Authority for possible
integration in the final registration by the Sponsoring Authority.

> 15.10 If the Sponsoring Authority revises the application, the
Registration Authority shall ascertain that the revised application complies
to the syntactical and administrative requirements listed in clause 15.4.

> CD2 TECHNCIAL #114 and #115 addressed the same issue in items e and f in
clause 7.4 (now transferred to clause 15).

> DoC on CD2 TECHNICAL #114 stated:

> No change. The intent is that the SA is the authority over its
application,

> and that nothing can be registered against the will of the SA.

> DoC on CD2 TECHNICAL #115 stated:

> Partially accepted. Wording will be changed, but the RA will have no say

> about whether the changes are acceptable.

> The question here is: who is responsible for resolving review comments
made by P-members about an application for registration? ISO operates by
consensus. All parties must be involved in deciding whether a comment is
justified.

> 1. The Registration Authority must review the comments The Registration
Authority will reject any comments that it considers in error. The
Registration Authority may consult with the RA-JAC about questionable
comments.

> 2. Any comments that would prevent registration must be forwarded to the
Sponsoring Authority for action. The Sponsoring Authority will either
explain why the comment is wrong (registration can proceed) or will submit a
replacement application if the comment is justified.

> Replace clauses 15.9 and 15.10 with the following clauses:

> 15.9 The Registration Authority shall consider all comments received from
the subcommittee review (clause 15.8). The Registration Authority may
request the RA-JAC to provide expert technical advice on comments.

> 15.10 The Registration Authority shall forward any comments that prevent
approval of the application for registration to the Sponsoring Authority for
a response.

> 15.10.1 If the review comment is in error, the Sponsoring Authority shall
submit an explanation of why it is in error to the Registration Authority.

> 15.10.2 If the review comment is justified, the Sponsoring Authority shall
either request withdrawal of the application (see clause 20.1) or submit a
corrected application, A corrected application shall be subjected to the
procedures specified in clauses 15 and 16 as though it was a new
application.

> Rationale:

> 1. The new clauses describe the consensus procedure.

> 2. FCD clause 15.10 is inadequate. An application for registration is
subjected to review by both the Registration Authority (clauses 15.3 and
15.4) and by the RA-JAC (clause 15.5). A replacement application should be
subjected to the same procedure.

Response: Accepted in principle. The wordings of 15.9 and 15.10 is replaced
as follows:

(1) Replace current 15.9 with the wording of the proposed 15.10:

15.9 The Registration Authority shall forward any comments that prevent
approval of the application for registration to the Sponsoring Authority for
a response.

(2) Replace current 15.10 with the merged wording from the proposed 15.10.1
and 15.10.2:

15.10 If the review comment is in error, the Sponsoring Authority shall
submit an explanation of why it is in error to the Registration Authority.
If the review comment is justified, the Sponsoring Authority shall either
request withdrawal of the application (see clause 20.1) or submit a
corrected application, A corrected application shall be subjected to the
procedures specified in clauses 15 and 16 as though it was a new
application.

> Clause 15.13

> FCD TECHNICAL #98

> The Registration Authority shall request the RA-JAC to provide expert
advice on technical comments. The Registration Authority may attach comments
from the RA-JAC as described in clause 9.3 item e with the final
registration.

> Modification of part of US clause x.9. Modifications are editorial in
nature.

Response: noted. No change necessary.

> Clause 16 Processing of an approved application

> Initial sentence:

> FCD TECHNICAL #99

> Following completion of approval of an application for registration, the
Registration Authority shall:

> Delete this sentence.

> Rationale: This is a hanging paragraph which "should be avoided since
reference to them is ambiguous." (ISO/IEC Directives, Part 2, clause 5.2.4)

Response: accepted in principle. However, the sentence will be completed
with: "the actions

listed in this clause".

> Clause 16.1

> FCD TECHNICAL #100

> The US notes the addition of "numeric" identifiers to make the distinction
from alphanumeric token identifiers.

Response: noted.

> 17.1 Appeals against rejection 

> Initial sentence:

> FCD TECHNICAL #101

> Appeal against the decision of the Registration Authority can be made as
follows:

> Delete this sentence.

> Rationale: This is a hanging paragraph which "should be avoided since
reference to them is ambiguous." (ISO/IEC Directives, Part 2, clause 5.2.4)

Response: accected in principle. The sentence is reworded with:

shall be made according to the procedures in this clause.

> Clause 17.1

> FCD TECHNICAL #102

> Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote

> FCD text:

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

> Change by Editor to Accepted US text:

>          "technical or administrative" --> "syntactical or administrative"

> Change back to original text.

> Rationale: The Editor has provided no explanation of why "technical"
should be replaced by "syntactical", and whether there is a difference
between the two terms.

Response: Withdrawn by the US. See response to US comment 89.

> New clause (numbered 17.2) Appeals against registration

> FCD TECHNICAL #103

> Critical issue: Must be resolved to the satisfaction of the US to reverse
vote

> This new clause parallels clause 15.1 Appeals against registration in
ISO/IEC 2375:2003.

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

> DoC on CD2 N1020

> Not accepted. NBs can comment on the application, but the SA will have the
final 

> word.

> This clause is necessary. All corrections to an application or to an
existing registration should be supplied by the Sponsoring Authority, but
the Sponsoring Authority should NOT have the "final word". This clause is
intended to prevent erroneous information from being included in the
Registry.

> In addition, this member body right WAS specified in N 849, the CD 15897.
Clause 7.2 states:

> A Member Body of the JTC 1 subcommittee responsible for the maintaining of
this International Standard may object to a forthcoming publication of a
registration by the Registration Authority, but solely on the ground that
the requirements in Clause 6 are not met.

> The normative text of this clause was eliminated from CD2 15897 (N 987)
without authorization to do so via a NB comment (see DoC on CD 15897, N
957).

> To restore this member body right:

> 1) Renumber clauses 17.2 through 17.4 as 17.3 through 17.5.

> 2) Insert clause 17.2 Appeals against registration with the following text
and numbering:

> <begin text>

> 17.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.

> 17.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
clause 15.

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

> Rationale: 

> ISO operates by consensus. All parties must be involved in deciding
whether something is correct.

> With regard to item 3, there is no harm in questioning the correctness of
supplied cultural information. The Sponsoring Authority would be responsible
for determining whether there is an error, and correcting the application if
that proves to be the case.

> Note: Rationale applies also to 17.4 Resolution of an appeal.

Response: Accepted in principle. The text proposed by the US will be used
with

the following changes: "technical" is changed to "syntactical" and

Item 3) will be deleted.

> 17.4 Resolution of an appeal

> FCD TECHNICAL #104

> Critical issue: Must be resolved to the satisfaction of the US to reverse
vote

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

> DoC on  CD2 TECHNICAL #55

> Not accepted. See response to US comment 53.

> Text of response to US comment #53:

> Not accepted. NBs can comment on the application, but the SA will have the
final 

> word.

> This clause is necessary. All corrections to an application or to an
existing registration should be supplied by the Sponsoring Authority, but
the Sponsoring Authority should NOT have the "final word". This clause is
intended to prevent erroneous information from being included in the
Registry.

> As noted above in the technical comment on proposed clause 17.2, the
normative text of clause 7.2 of CD 15897 was not carried over to CD2 15897
(N 987) although there was no NB comment requesting removal of this text
(see DoC on CD 15897, N 957).

> To remedy this improper action:

> 1) Renumber clause 17.4.3 as 17.4.4.

> 2) Insert the following text as clause 17.4.3 with the heading Appeals
against registration:

> <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
17.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>

Response: Accepted in principle. The text and renumbering proposed

by the US will be used with the following changes to the first sentence: 

"the appeal" changed to "an appeal against registration".

"technically" is changed to "syntactically" and ", Item 3)" will be deleted.

Delete from "If the appeal.." to end of text.

In 17.4.2 change "the appeal" to "an appeal against registration" and
"technically" to "syntactically".

> FCD clause 17.4.3

> If four-fifths of the members of the RA-JAC cannot agree on how to resolve
an appeal, then the appeal shall be submitted by the Registration Authority
within 90 days after the receipt of an appeal to the P-members of the JTC 1
subcommittee responsible for the maintaining of this International Standard,
to decide according to its voting procedures.

> CD2 TECHNICAL #56 requested two changes to CD2 clause 10.4.3:

> FCD TECHNICAL #105

> Critical issue (ISO procedures): Must be met to satisfy the US and to
reverse vote

> 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.)

> DoC on  CD2 TECHNICAL #56

> Not accepted. SC22 may have additional procedures beyond the JTC 1
procedures.

> This is an unjustified and unsubstantiated rejection. The rationale
describes SC22 procedures.

Response: accpeted.

> FCD TECHNICAL #106

> Critical issue (ISO procedures): Must be met to satisfy the US and to
reverse vote

> CD2 TECHNICAL #56 (part):

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

> DoC on  CD2 TECHNICAL #56

> Not accepted. SC22 may have additional procedures beyond the JTC 1
procedures.

> This is an unjustified rejection.

> The Editor is attempting to justify his improper rejection by describing
an imaginary situation. SC22 does not have any additional procedures.

> SC22 is subordinate to JTC1, so it operates according to the Procedures
for the technical work of ISO/IEC JTC 1 (i.e., the JTC 1 Directives). In the
unlikely event that SC22 devised some additional procedures, this standard
could be revised AT THAT TIME to specify use of the new procedures.

> Note: The JTC 1 Directives are referenced in clause 13.1.

> or one of the approved document formats of ISO/IEC JTC 1, as noted in the
JTC 1 directives, Annex H.4.

Response: accepted.

> Clause: 18 Revisions

> FCD TECHNICAL #107

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

> When a new registration application is based on an existing registration,
either by the same Sponsoring Authority, or another Sponsoring Authority,
then the Registration Authority shall create a new registration. The
Registration Authority shall also add cross-reference notes to the two
registrations.

> Number the two paragraphs as clause 18.1 and 18.2 respectively.

> Rationale: ISO/IEC Directives, Part 2, Clause 5.2.4.

Response: accepted.

> 19 Addition of token identifiers to an existing registration 

> FCD TECHNICAL #108

> CD2 TECHNICAL #66 requested:

> Add a new clause with the title:

> Additions to an existing registration

> Proposed heading was Accepted, but the Editor made this change:

>          Additions --> Addition of token identifiers

> The US has no objection since the text deals with the addition of token
identifiers.

> Text is as supplied except that "new" was added before "application".

Response: noted.

> FCD TECHNICAL #109

> CD2 TECHNICAL #66 also requested:

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

> Text has not been supplied.

Response: noted. See also respose to US comment 116.

> Clause: 20 Withdrawal

> Initial paragraphs:

> FCD TECHNICAL #110

> 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 of an existing registration that it has
sponsored. Parts may be withdrawn only by withdrawing the whole
registration, and then registering the parts in question according to the
rules defined in this International Standard.

> A declaration of withdrawal may, but need not, be accompanied by a
statement of the reasons for the withdrawal.

> Clause number omitted. Text modified with addition of rules about parts.

Response: accepted. clause numbers will be added.

> FCD TECHNICAL #111

> Move the following text to a new clause (see below):

> Parts may be withdrawn only by withdrawing the whole registration, and
then registering the parts in question according to the rules defined in
this International Standard.

> and substitute a reference:

> Procedures on withdrawal of parts of a registration or application are
specified in clause 20.3.

Response: Accepted.

> Clause 20.1

> FCD TECHNICAL #112

> When the Registration Authority is notified, it shall take no further
action to process the application.

> If the application for registration is being circulated for comment
according to clause 15.8, the Registration Authority shall notify the
members of the subcommittee that the application has been withdrawn by the
Sponsoring Authority.

> Number these clauses as 20.1.1 and 20.1.2.

> Rationale: ISO/IEC Directives, Part 2, clause 5.2.

Response: accepted

> Clause 20.2

> FCD TECHNICAL #113

> After withdrawal, the registration shall remain in the register and
continue to be identified by the allocated numeric identifier and token
identifiers.

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

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

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

> First paragraph:

> The US notes that "and token identifiers" was added.

Response: noted.

> FCD TECHNICAL #114

> Delete the second paragraph of clause 20.2.

> Rationale: Duplicates next paragraph, except for "was withdrawn" rather
than "has been withdrawn". "was withdrawn" is preferable.

Response: accepted.

> FCD TECHNICAL #115

> Number these clauses as 20.2.1, 20.2.2, 20.2.3.

> Rationale: ISO/IEC Directives, Part 2, clause 5.2.

Response: accepted.

> New clause [ 20.3 proposed] Procedures for parts

> FCD TECHNICAL #116

> Add a new clause with title "Procedures for parts"

> Add a new subclause numbered 20.3.1 with title "Parts of an existing
registration" and the following text:

> Part of an existing registration cannot be withdrawn or modified. To
change a part (either to add a part, modify an existing part, or withdraw a
part), the whole registration must be withdrawn, and a revision submitted as
a new application for registration.

> Add a new subclause numbered 20.3.2 with title "Parts of an existing
application" and the following text:

> Part of an existing application cannot be withdrawn or modified. To change
a part (either to add a part, modify a part, or withdraw a part), the whole
application must be withdrawn, and resubmitted after revision.

> Rationale: Separates rules for existing registration and unapproved
application. Clarifies what constitutes a change to a part.

Response: accepted.

> FCD TECHNICAL #117

> Add a reference to this clause 20 from clause 4.5 No modification nor
deletion of registrations, worded as follows:

> Withdrawal of part of an existing registration is prohibited by clause
20.3.1.

> Rationale: Pointer from definition to procedures for complying with the
definition.

Response: acepted.

> Annex C External References to Cultural Specifications

> C.4 Transfer Syntax

> FCD TECHNICAL #118

> CD2 TECHNICAL OBJECTION #70 proposed changing 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. 

> DoC  on CD2 TECHNICAL OBJECTION #70

> Not accepted. Other character encodings than UTF-8 needs to be supported.

> Change the text as follows:

> When transferring the contents of a registry entry over a network, the
UTF-8 form of ISO/IEC 10646 shall be preferred for data encoding.
Alternatively, transfer syntaxes as defined in ISO/IEC 2022 may be used.

> 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
preferred when transferring the contents of an entry over the network.

Response: accepted.

> Annex D Example Narrative Cultural Specifications

> FCD TECHNICAL #119

> The title of the Annex does not match the title specified in the DoC
(N1020):

> Accepted. The title will be "Sample narrative cutltural specifiaction"

> and some interoductory text that this just an example and not something
that

> is in the registry.

> Furthermore, the final "s" in "Specifications" is smaller than the rest of
the word. it is unclear whether the word is intended to be singular or
plural.

> The US proposes that the FCD title be retained, but modified slightly by
the addition of "of a" and changing "Specifications" to "Specification" so
that it reads:

> Example of a Narrative Cultural Specification

> Rationale: Better style.

Response: accepted.

> FCD TECHNICAL #120

> General comments on CD2 Annex D 

> 2. Defective or outdated information (CD2 TECHNICAL #72)

> 3. Concerns about status of examples (CD2 TECHNICAL #73)

> The DoC on CD2 TECHNICAL #72 stated:

> Not accepted. We should respect the information from the national

> bodies that provided this text. Text may be outdated as the standard

> ages, so it is natural that some information is out of date.

> The US is still concerned about the existence of obsolete information in
examples, but recognizes that the Danish NB is responsible for the content
of this Annex .

Response: noted.

> FCD TECHNICAL #121

> The CD2 DoC on US Comments on CD2, Annex D, Sample Narrative Cultural
Specification for Danish and Irish (Appendix 3 of WG 20 document N1010)
included the following:

> All of the comments in this appendix are not accepted. These comments will
be relayed to the Danish member body for possible changes.

> Has this been done? If it has been done, has there been a response from
Dansk Standard? If it has not been done, why not?

Respnse: The Danish NB has been contacted, and will review the draft FDIS
text,

and may suggest further corrections to the contents of Annex D.

> FCD TECHNICAL #122

> The US notes that although the DoC on CD2 TECHNICAL #72 stated:

> ... We should respect the information from the national bodies that
provided this text. ...

> and the DoC on Appendix 3 of WG 20 document N1010 stated:

> All of the comments in this appendix are not accepted. These comments will
be relayed to the Danish member body for possible changes.

> changes have been made to Clause 11 and Clause 22 of Annex D without any
documented input from Dansk Standard.

Response: Noted.

> FCD TECHNICAL #123

> The date of the example in Annex D is 2002-10-08

> Source: Dansk Standard, date: 2002-10-08, version: 2.5

> but the text of FCD clause 22 mentions "2003":

> The timezone is UTC+0100 in the winter, UTC+0200 in the summer. The
daylight savings period currently (2003) changes by one hour the last Sunday
in March at 02:00, and back again by one hour the last Sunday in October at
03:00. This may change in the future. There is no official names for the
timezones.

> The CD2 text has "1995".

> Why is there a difference between the publication date of the Narrative
Cultural Specification used as the example and dated information in it? 

Response: noted, refer to US comment 121.

> Clause 15

> FCD TECHNICAL #124

> The FCD text of Clause 15 in the example of a Narrative Cultural
Specification reads:

> A proposed general input method is included in DS/ISO/IEC 9945-1 annex F.

> This is a reference to the 1991 edition of ISO/IEC 9945-1, which was
adopted as a Danish national standard designated DS/ISO/IEC 9945-1:1991.

> Problems with this clause that should be communicated to Dansk Standard:

> 1. The reference to "annex F" should be changed to "Annex E". There is no
Annex F in ISO/IEC 9945-1, and so not in DS/ ISO/IEC 9945-1 either.

> 2. The reference is obsolete. DS/ISO/IEC 9945-1:1991 was withdrawn by
Dansk Standard on 1997-09-24.

> Source: Result of search for Document ID "9945" on Dansk Standard Web site
http://www.en.ds.dk/ The same search on http://www.ds.dk/ (in Danish)
returns the same result.

> Note: Even ISO/IEC 15897:1999 refers to a standard that had already been
withdrawn when the first version of this International Standard was
published.

Response: noted, refer to US comment 121.

> FCD TECHNICAL #125

> The US thanks the Irish NB for responding to the US comments on the Irish
example.

Response: noted.

> Annexes E and F

> * Annex E, "reorder-after" construct in POSIX LC_COLLATE

> * Annex F Information on "reorder-after" construct in LC_COLLATE)

> FCD TECHNICAL #126

> Critical issue: Must be resolved to the satisfaction of the US to reverse
vote

> 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).

> DoC on CD2 TECHNICAL #75

> Not accepted. These specifications relate also to POSIX locales and not
just to

> 14651.

> Remove both Annex E and Annex F.

> Rationale:

> 1. The Editor has failed to address the following US concern:

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

> 2. This FCD is for a procedural standard, so it cannot define normative
syntactic additions that apply to the technical content of ISO/IEC 9945.

> 3. ISO/IEC 9945 is the responsibility of SC 22/WG 15. Such additions must
be made through a revision of ISO/IEC 9945.

Response: Accepted in principle. Text added in the beginning of annex E:

This is an extension technique for use with locale which are otherwise
compliant with

ISO/IEC 9945. This extension technique may be used in registration
applications

according to this International Standard."

Title changed to "... construct in LC_COLLATE".  These changes meet the US
concerns

about adding normative capabilities to POSIX in this standard.

> Clause E.3 Example of "reorder-after"

> FCD TECHNICAL #127

> DoC on  CD2 TECHNICAL #76

> Not accepted. <AA> and <aa> stands for Å and å respectiviely.There is no
defiency. This will be clarified.

> The US appreciates that, despite this DoC, some of its comments have been
incorporated into Annex E of the FCD.

> item 5

> FCD text begins:

> 5. A complete example for Danish using characters from ISO/IEC 10646 is
included in Annex G.1. For the sequence:

> and continues after the sequence:

> the example reordering in E.3.1 gives:

> Delete 

>          E.3.1

> and substitute:

>          Annex G.1.

> Rationale: Clause E.3.1 does not exist. The US presumes that the intended
reference is to Annex G.1.

Response: accepted.

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

> H.2 Changes from CEN ENV 12005:1996

> FCD OBSERVATION #128

> The second paragraph of clause H.2 states that references are to the 1999
edition of ISO/IEC 15897. Clause H.2 describes a stable situation. Changes
to clause designations are not needed.

Response: noted.

> Bibliography

> FCD TECHNICAL #129

> 4th citation (incorrectly numbered "3"):

> CEN ENV 13710:2000, European Ordering Rules

> Incomplete title. Full title is:

> European Ordering Rules - Ordering of characters from the Latin, Greek and
Cyrillic scripts

> Rationale: Information from CEN document catalogue
http://www.cenorm.be/catweb/35.040.htm

Response: accepted.

> FCD TECHNICAL #130

> Should this more recent CEN standard

> CR 14400:2001 European ordering rules - Ordering for Latin, Greek,
Cyrillic, Georgian and Armenian scripts

> be substituted for CEN ENV 13710:2000?

> Note: CEN ENV 13710:2000  is given as an example in clause 11.1 Contents
of Narrative Cultural Specification, [NCS] Clause 1: Alphanumeric
deterministic ordering.

Response: accepted.

> End of Specific Technical Comments

> SPECIFIC EDITORIAL COMMENTS

> Introduction

> first paragraph, last sentence

> FCD text:

> This edition adds of the International Standard adds support for
registering specifications meant for machine processing such as ISO/IEC TR
14652 specifications, SGML and XML, it enlarges the group of organizations
that may be Sponsoring Authorities, and an effort has been done to align it
with the registration procedures of ISO/IEC 2375.

> Corresponding CD2 text:

> This edition of the International Standard adds support for ISO/IEC TR
14652, SGML and other techniques meant for machine processing, and enlarges
the group of organizations that may be Sponsoring Authorities.

> FCD EDITORIAL #131

> Delete

> "This edition adds of the International Standard adds support for
registering..."

> and substitute:

> "This edition of the International Standard adds support for
registering..."

> Rationale: Grammar 

Response: Accepted.

> FCD EDITORIAL #132

> Change "done" to "made".

> Rationale: Style.

Response: Accepted.

> FCD EDITORIAL #133

> The sentence is now excessively long, and ought to be split in two. The
preceding corrections have been applied to the following proposed text.

> This edition of the International Standard adds support for registering
specifications meant for machine processing, such as ISO/IEC TR 14652
specifications, SGML and XML, and also enlarges the group of organizations
that may be Sponsoring Authorities. An effort has been made to align the
registration procedures of this standard with those of ISO/IEC 2375.

Response: Accepted in principle. Text ", and also" will be changed to ".
It".

> 2 Normative references

> FCD EDITORIAL #134

> Insert blank line between entries for ISO 4217 and ISO 8601/

Response: Accepted

> 3 Terms and definitions 

> FCD EDITORIAL #135

> Critical issue: Must be resolved to the satisfaction of the US to reverse
vote

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

> ??????????: ??????? ???????? ????????????? ?? ??????? ? ????????????
?????? ????? ????????? ?? ?????????? ?????.

> DoC on CD2 EDITORIAL #82

> Not accepted. ISO 2382 does it this way.

> ISO/IEC 2382 is an independent terminology standard (published in multiple
parts) that defines the vocabulary of the field designated variously as
information technology (parts published since 1990), information processing
systems (parts published 1986-89), and data processing (parts published up
to 1985). For such a standard, the ISO/IEC Directives, Part 2 says that a
classified arrangement is preferable (clause C.2.1, first paragraph).

> Using ISO/IEC 2382 as a model for this standard's short clause on terms
and definitions is totally inappropriate, and potentially confusing to
users. 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.

Response: withdrwan by the US, because of potential for introducing errors
of

cross-references with the renumbering.

> FCD EDITORIAL #136

> Rationale: ISO/IEC Directives: Part 2, clause C.3.3 states that a
definition must begin with a lower case letter "except for any capital
letters required by the normal written form in running text".

> Note: Clauses 3.10 and 3.11 are correct.

Response: Accepted.

> FCD EDITORIAL #137

> In all clauses (3.1 to 3.11), delete the trailing full-stop (period).

> Rationale: ISO/IEC Directives: Part 2, clause C.3.3 states that a
definition "shall not be followed by a full-stop".

Response: Withdrawn by the US. Some definitions contain multiple sentences.

> 3.7 cultural specification

> FCD EDITORIAL #138

> "...such as ...XML."

> Phrase is partly duplicative with respect to TR 14652.

Response: Accepted. See also response to US comment 23 and 24.

> 7.1 Identity [of the Sponsoring Authority]

> FCD EDITORIAL #139

> If CEN TC 304 is retained as one of the organizations which may function
as a Sponsoring Authority:

> 1. Change designation of second-last item from "b" to "c".

> 2. Change designation of last item from  "c" to "d".

Response: Moot. See response to US comment 28.

> FCD EDITORIAL #140

> At the end of the last item, change trailing semi-colon to full-stop
(period).

Response: Accepted.

> 7.2 Responsibilities [of the Sponsoring Authority]

> FCD EDITORIAL #141

> The text which was accepted was further modified by the Editor to reflect
the content of a new clause, 8 Source of Information, added in response to
US comment #27. Item (a) in the FCD now is:

> a) to receive applications concerning Cultural Specifications from a
Source of Information, such as organizations, firms or experts, operating in
the area over which the Sponsoring Authority has jurisdiction.

> Delete the comma following "Information" and this text (including the
trailing comma):

> such as organizations, firms or experts, 

> and substitute

>          (see clause 8)

> Rationale: This clause now refers to the Source of Information. The Source
of Information is defined in clause 8. It is inappropriate to define it here
as well.

Response: Accepted.

> 8.1 Identity [of Source of Information]

> Text: of new clause in FCD:

> The Source of Information is an organization or person that has authored
the Cultural Specification.

> FCD EDITORIAL #142

> Change

> an organization or person that has authored

> to

> the organization or individual responsible for

> Rationale: 

> 1. Consistency with the comparable clause, 7 Owner of Origin, in ISO/IEC
2375:2003.

> 2. Clarifies that the Source of Information is responsible for the content
of the Cultural Specification.

> Note: The US considers that "organization or individual" adequately covers
the phrase "organizations, firms or experts" proposed for deletion from
clause 7.2, item (a).

Response: Accepted.

> 8.2 Responsibilities

> FCD EDITORIAL #143

> Line 1: Change "Source of information" to Source of Information".

> Rationale: Consistency.

Response: Accepted.

> Clause 10.2 Relations between registration types

> FCD EDITORIAL #144

> Insert the following text as a second paragraph. 

> The POSIX Locale shall define all standard categories. Individual
categories may be copied from another Locale. See Annex G for examples.

> Rationale: Brings together all requirements for a POSIX Locale in one
place in the standard.

Response: Withdrawn by the US.

> FCD EDITORIAL #145

> Change "hall" to "shall".

> Rationale: Correction of typo.

Response: accepted.

> Clause 10.2.4

> FCD EDITORIAL #146

> Critical issue: Must be resolved to the satisfaction of the US to reverse
vote

> Current text:

> The ISO/IEC 15897 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.

> Change the initial "The" to "A"

> Rationale: To reflect the rewording of clause 10.2.3.

Response: accepted. Note: Rationale applies to 10.2.4, not 10.2.3.

> Clause 10.2.5

> FCD             EDITORIAL #147

> Delete the first sentence:

> 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 may refer to a corresponding Narrative Cultural
Specification.

> and substitute:

> A TR 14652 FDCC-set or other machine-parsable cultural specification shall
specify in formal syntax some aspects of a Narrative Cultural Specification,
and may refer to a corresponding Narrative Cultural Specification. 

> Rationale: Stylistic improvements to clarify instruction.

Response: See US comments 44 and 45.

> FCD EDITORIAL #148

> Insert the following text as a second paragraph. 

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

> Rationale: Brings together all requirements for an FDCC-set in one place
in the standard.

Response: See US comments 44 and 45.

> Clause 10.2.6

> FCD EDITORIAL #149

> In the first sentences, change "In case" to "In the case".

> Rationale: Proper English usage, and consistency with rewording requested
in FCD TECHNICAL #46 .

Response: accepted

> Clause 11.1 Contents of Narrative Cultural Specification

> FCD EDITORIAL #150

> Insert "a" between "of" and "Narrative".

Response: accepted

> Clause 3: Numeric formatting

> FCD EDITORIAL #151

> Delete "gouping" [sic]

> Rationale:

> 1. Does not appear in the US text which was accepted in the DoC.

> 2. "Grouping" is redundant and confusing. The word "separator" implies
grouping.

Response: accepted

> Clause 20: Numbering, ordinals, and measuring systems

> FCD EDITORIAL #152

> 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).

> DoC on CD2 N1020

> Noted. No such text is needed.

> While the US considers that its proposed text to be better stylistically
than the current text in the FCD, the defects noted in CD2 EDITORIAL #127
have been corrected.

> Clause 13 Rules for Cultural Specifications

Response: Noted.

> FCD EDITORIAL #153

> Change title of the clause to: 

> Format of registration documents

> Rationale: This clause describes the formats of the various documents that
make up a registration for a cultural specification.

Response: Not accepted.

> 13.1

> FCD EDITORIAL #154

> US comment CD2 TECHNICAL #33 on clause 9.3.1 was accepted. Corresponding
text in FCD reads:

> An application for registration of a Cultural Specification shall be
submitted as a Text File. A Narrative Cultural Specification may
alternatively be submitted on paper, preferably A4, or one of the approved
document formats of ISO/IEC JTC 1, as noted in the JTC 1 directives, Annex
H.4.

> Change "directives" to "Directives".

> Rationale: JTC 1 practice (see, for example: clause 7.4.2.3.10 of the JTC
1 Directives).

Response: Accepted.

> Clause 14 Specification of the token identifier

> Clause 14, first paragraph

> FCD EDITORIAL #155

> The last sentence reads:

> The maximum lenght of a token identifier is 200 characters.

> "length" is misspelled.

Response: Accepted.

> 15 Initial registration procedures

> Clause 15.3

> FCD EDITORIAL #156

> If the application fails to meet this requirement, the application shall
be rejected.

> Change "this requirement" to "either of these requirements"

> When requested by the RA, the RA-JAC may provide an opinion on whether an
application satisfies this requirement.

> Change "this requirement" to "these requirements"

> Rationale: Required grammatical change if additional item is added.

Response: accepted.

> FCD EDITORIAL #157

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

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

Response: accepted.

> Clause 15.4

> FCD EDITORIAL #158

> Bullets missing from items in clause 15.4.

Response: Accepted.

> Clause 15.5 

> FCD EDITORIAL #159

> Bullets missing from items in clause 15.5.

Response: Accepted.

> Clause 15.6

> FCD EDITORIAL #160

> three-month information and comment period

> Delete "three-month" and insert "of 90 days" after "period".

> Rationale: Consistency with other periods expressed as number of days.

Response: Accepted. (for clause 15.8)

> 16 Processing of an approved application

> Clause 16.1

> FCD EDITORIAL #161

> Bullets missing from items in clause 16.1.

Response: Accepted.

> Clause 16.6

> FCD EDITORIAL #162

> The Registration Authority shall announce publication of the registration
to subcommittee responsible for maintaining this standard.

> Insert "the" between "to" and "subcommittee".

> Note: This omission was in the text supplied by the US,

Response: Accepted.

> 17 Appeal procedures

> FCD EDITORIAL #163

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

> DoC on  CD2 EDITORIAL #106:

> Not accepted. The text is introductory, and does not harm.

> Not only is this line redundant, it is a hanging paragraph which. "should
be avoided since reference to them is ambiguous." (ISO/IEC Directives, Part
2, clause 5.2.4)

Response: Accomodated by resolution of US comment 101

> Clause E.3 Example of "reorder-after"

> FCD EDITORIAL #164

> This clause ends with a note:

> Note: The characters on the last line are the following, with UCS short
identifiers:

> Make the following changes:

> 1. Delete "Note:" and substitute "NOTE".

> 2. Indent the note (including the UCS short identifiers).

> Rationale: ISO/IEC Directives, Part 2, clause 6.5.1. The last paragraph of
this clause states:

> In drafts, all lines of a note or example shall be inset from the margin
or shall be set in smaller type, so that its extent can be determined.

Response: accepted

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

> H.1 Changes from ISO/IEC 15897:1999, item 3

> FCD EDITORIAL #165

> FCD text:

> 3. The text was revised to align with the new ISO/IEC 2375 International
Standard, which the original wordings in the CEN ENV 12005 was built from.

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

> DoC on CD2 EDITORIAL #110

> Accepted in principle, but the history will be retained.

> Reword as:

> 3. The text was revised to align with International Standard ISO/IEC
2375:2003.

> Rationale: 

> 1. ISO/IEC 2375 now has a publication date.

> 2. The assertion that CEN ENV 12005 is based upon the "new ISO/IEC 2375"
is impossible because of the dates of publication. CEN ENV 12005 was
published in 1996, the new edition of ISO/IEC 2375 was not published until
seven years later. Furthermore, the lack of parallelism between ISO/IEC
2375:2003 (as of its FCD stage) and ISO/IEC 15897:1999 (which was
fast-tracked from CEN ENV 12005) is recorded in WG20 document N945R.

> Note: If CEN ENV 12005 was based upon an earlier edition of ISO/IEC 2375,
this information belongs in clause H.2, where CEN ENV 12005 is discussed.

Response: Accepted.

> Bibliography

> FCD EDITORIAL #166

> Citation 3: Add the URL for the RFC:
http://www.ietf.org/rfc/rfc3066.txt?number=3066

Response: Withdrawn by the US.

> FCD EDITORIAL #167

> Change the number of the 4th citation from "3" to "4".

Response: Accepted.

> FCD EDITORIAL #168

> Change the number of the last citation from "4" to "5".

Response: Accepted.

> End of Specific Editorial Comments

> End of US Comments

With these dispositions of comments the US changes its vote on FCD 15897

from "no" to "yes".

Sally Seitz

Program Manager

ANSI

25 West 43rd Street

New York, NY 10036

Phone: (212) 642-4918

Fax: (212) 840-2298