From owner-sc22docs@open-std.org Tue Aug 2 18:30:25 2005 Return-Path: X-Original-To: sc22docs-domo1 Delivered-To: sc22docs-domo1@open-std.org Received: by open-std.org (Postfix, from userid 521) id 9DCB413AC9; Tue, 2 Aug 2005 18:30:24 +0200 (CET DST) X-Original-To: sc22info@open-std.org Delivered-To: sc22docs@open-std.org Received: from email1.ansi.org (outbound.ansi.org [12.15.192.5]) by open-std.org (Postfix) with ESMTP id 1DA2A12E3C for ; Tue, 2 Aug 2005 18:30:12 +0200 (CET DST) Received: by rpb2.nycrnybb.ispnetinc.net with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Aug 2005 12:26:02 -0400 Message-ID: From: Sally Seitz To: sc22info@open-std.org 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) Date: Tue, 2 Aug 2005 12:26:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5977E.DF1ADBC0" Sender: owner-sc22docs@open-std.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5977E.DF1ADBC0 Content-Type: text/plain; charset="iso-8859-1" ISO/IEC JTC 1/SC22 Programming languages, their environments and system software interfaces Secretariat: U.S.A. (ANSI) ISO/IEC JTC 1/SC22 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: sseitz@ansi.org _____________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 ". ..." 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. > > - 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. > > > 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 . 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 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: > > 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 . > 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. > > 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: > > 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. > > 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) > > 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. > > 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: > > 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. > 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. and 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 ------_=_NextPart_001_01C5977E.DF1ADBC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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:          &n= bsp;  (212) 840-2298

Email:  sseitz@ansi.org

 

_____________End of cover sheet, beginning = of document______________

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ISO/IEC = JTC1/SC22/ N3922

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

=A0

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

If Canada has specific i18n items=A0 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:<= /font>

 

> 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.=A0 However, agreement was reached in JTC1 to = publish TR 14652

> as a TR type 1.=A0 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=A0 #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=A0 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

>=A0 repertoiremaps as defined in this International = Standard,

> to

>=A0 =A0=A0=A0=A0=A0=A0=A0 = =A0repertoiremaps,

> 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=EFve = 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=A0 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.=A0 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)

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

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

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

> >=A0 Annex A:

> >

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

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

> -=A0=A0=A0=A0=A0=A0 to determine whether an application = for registration meets the technical requirements of clause 9;

> -=A0=A0=A0=A0=A0=A0 to provide expert technical advice on = comments if requested by the Registration Authority;

> -=A0=A0=A0=A0=A0=A0 to consider and vote on appeals = received by the Registration Authority;

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

 

>=A0 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 layo= ut 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.

>=A0 Rationale:

> 1. ISO/IEC 15897 is a procedural standard, so cannot = specify the technical details of a=A0 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 "...=A0 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=A0 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.

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

> 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

>=A0 (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:

> =A0=A0=A0=A0=A0=A0=A0=A0 are each surrounded = by

> to

> =A0=A0=A0=A0=A0=A0=A0=A0 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=A0 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 € 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:

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

 

>=A0 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" =3D=3D> "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:

> =A0=A0=A0=A0=A0=A0=A0=A0 "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=A0 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)=A0=A0=A0=A0=A0 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=A0 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)=A0=A0=A0=A0=A0 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=A0 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:

> =A0=A0=A0=A0=A0=A0=A0=A0 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=A0 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".=A0 = 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=A0 CD2 TECHNICAL #76

> Not accepted. <AA> and <aa> stands for =C5 and = =E5 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

> =A0=A0=A0=A0=A0=A0=A0=A0 = E.3.1

> and substitute:

> =A0=A0=A0=A0=A0=A0=A0=A0 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=A0 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 =E0 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=A0 "c" = to "d".

=A0

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

> =A0=A0=A0=A0=A0=A0=A0=A0 (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 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 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=A0 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=A0 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=3D3066

 

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<= /p>

Phone: (212) 642-4918

Fax: (212) 840-2298

 

------_=_NextPart_001_01C5977E.DF1ADBC0--