From rinehuls@Radix.Net Tue Aug 10 18:34:26 1999 Received: from mail1.radix.net (mail1.radix.net [209.48.224.31]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id SAA15131; Tue, 10 Aug 1999 18:34:25 +0200 (CEST) (envelope-from rinehuls@Radix.Net) Received: from saltmine.radix.net (saltmine.radix.net [209.48.224.40]) by mail1.radix.net (8.9.3/8.9.3) with SMTP id MAA27974; Tue, 10 Aug 1999 12:34:50 -0400 (EDT) Date: Tue, 10 Aug 1999 12:34:48 -0400 (EDT) From: William Rinehuls To: sc22info@dkuug.dk cc: keld simonsen Subject: SC22 N2971 - Comments Disposition for Registration of PDAM2 to 9945-2: POSIX Shell and Utilities Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII _____________________ beginning of title page _________________________ ISO/IEC JTC 1/SC22 Programming languages, their environments and system software interfaces Secretariat: U.S.A. (ANSI) ISO/IEC JTC 1/SC22 N2971 TITLE: Disposition of Comments Report for PDAM Registration of PDAM2 to ISO/IEC 9945-2 - Information technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities DATE ASSIGNED: 1999-08-10 SOURCE: Secretariat, ISO/IEC JTC 1/SC22 BACKWARD POINTER: N/A DOCUMENT TYPE: Disposition of Comments Report PROJECT NUMBER: JTC 1.22.41 STATUS: N/A ACTION IDENTIFIER: FYI DUE DATE: N/A DISTRIBUTION: Text CROSS REFERENCE: N2156 DISTRIBUTION FORM: Def Address reply to: ISO/IEC JTC 1/SC22 Secretariat William C. Rinehuls 8457 Rushing Creek Court Springfield, VA 22153 USA Telephone: +1 (703) 912-9680 Fax: +1 (703) 912-2973 email: rinehuls@radix.net _____________ end of title page; beginning of report ____________________ Disposition of Comments on PDAM Registration for: PDAM2 to ISO 9945-2: Information technology - Portable Operating System Interface (POSIX), Part 2: Shell and Utilities - Amendment 2 Recommendation: Danish Standards voted "No" to this ballot and raised a number of issues with the DS ballot on SC22 N2054 DAM on POSIX Shell and Utilities .2b/D11. These issues have been raised in the WG15 meetings directly, and were discussed at length in the May 1996 WG15 meeting (Copenhagen). The issues raised by Danish Standards are addressed below, point by point, making reference to the relevant text from ISO/IEC SC22/WG15 N640, the document used to facilitate discussion in Copenhagen in May 1996. Not all Danish objections have been addressed and accepted. WG15 recommends that Draft 12 of POSIX.2b be forwarded for PDAM ballot. 1. Page 7, line 82: Extended identifiers. A number of documents have been presented. WG15 liaison statement N283 to WG20 have been approved. WG20 has made a recommendation that DS can support in N420. Response: N283, N420 Deal with issues surrounding the use of characters beyond the portable character set in identifiers in the little languages. Don Cragun (Chair POSIX.2) has prepared a detailed report commenting on the commercial and technical infeasibility of this request. Please see WG15 TAG N573 (An annex to WG15 N640 as presented in Copenhagen, May 1996). 2. Page 10, line 185: Substitute We believe 1003.2/D8 section 2.5.2.2 has the most recent text. Response: Accept. 3. Page 10, line 190: replace-after A number of documents have been presented, the most recent is from CEN including the "reorder-after" description in N566 annex E. Response: N566 Discusses the "replace-after" proposal. This can be accomplished by an awk script, which was prepared by POSIX.2 working group members, is published, and will further be added to the rationale for POSIX.2b. Adding this to the specification would reduce ballot consensus. 4. ISO 646 invariant support Page 12, line 263: Page 17, line 1: Page 19, line 2: Page 19, line 7: Page 120, line 21: Page 120, line 26: The DS input is N416. Response: N416 Discusses support for ISO 646 Invariant characters. (i) With respect to regular expression support, this was personally discussed with the Head of Delegation for Denmark at the October 1994 PASC meeting, and demonstrated why this destroys an already ambiguous RE grammar. It was agreed by all that this should be put off to a future amendment of POSIX.2 where a group of experts in internationalized regular expressions could address this properly. (ii) With respect to meta-characters in other utilities, the proposals handle things differently for different utilities, and introduce grammar inconsistencies that can confuse readers of the document, and certainly will reduce ballot concensus. (iii) As this proposal is designed to address what appears to be a singular historical problem, and all other issues where character set does impact POSIX.2 have been addressed in the forward-looking ISO 10646 direction, and the proposal is not grounded in historical practice, the proposal is not being adopted into POSIX.2b. 5. N441: character concepts in POSIX standards This paper recommends multibyte characters as the general coded character set type. Response: N441 Discusses character concepts in POSIX standards. The POSIX.2 working group is in complete agreement with the discussion and believe that the POSIX.2b draft is consistent with the discussion. 6. N558: In response to AI 9410-27, 9 issues are listed. Proposals include reference to CEN registry. In response to AI 9410-35, 5 comments were listed. Proposed are: 1. repertoiremap as in CEN registry 2. comments in localedef collating weight statements 3. use repertoiremaps with locales and charmaps Response: N558 Discusses repertoiremap issues and localdef collating weight comments. POSIX.2 believes that POSIX.2b Draft 12 addresses all the concerns raised by Denmark according to Danish proposals. 7. N561: Proposes new utilities for i. compression, ala "gzip" ii. editing, a better utility than "vi" iii. versioning, ala "sccs" Response: N561 Proposes new utilities for inclusion in POSIX.2b. See responses in WG15 N614, and the US Member Body Action Item Report for the May 1996 WG15 meeting (Copenhagen), in response to AI 9510-19 (WG15 N643). Essentially, there is no one willing to undertake the work of specifying these utilities, but the IEEE SEC would entertain PARs in these areas subject to concerns raised in WG15 N614. 8. In addition we ask for support for language dependent character conversion and transliteration faclities. Response: Complete proposal was requested and has not been received. 9. We need support for character code switching mechanisms for charmap or better a encoding definition file, for IS 2022 support. Response: Not accepted. Until complete proposals are forthcoming or direct participation from internationalization experts is available the IEEE POSIX.2 working group felt they would lose ballot concensus. 10. We need support for symbolic ellipses in the locale. A proposal was included in the DS comments on the DIS ballot on ISO/IEC 9945-1. Response: An awk script that fulfills this requirement has been supplied by the POSIX.2 working group. It will be added to the rationale discussion. 11. We need support for hexadecimal symbolic elipses in the locale and charmaps. Response: Not accepted. Until complete proposals are forthcoming or direct participation from internationalization experts is available the IEEE POSIX.2 working group felt they would lose ballot concensus. 12. The document sould be aligned as much as possible with the specification standard ISO/IEC 14652, currently at CD stage. Response: ISO/IEC 14652 is an enhanced definition of locales, charmaps, and repertoiremaps, created by SC22 WG20. The POSIX.2 working group will review this document with respect to aligning the POSIX.2b draft with it. Editorial comments ================== Danish Standards has the following editorial comments on the P103.2b/D11 document. @ 2.2 c 1 2.2.3.201 The SC2 name is "UTF-8" with a hyphen. Please refer to the standard, it has recently been approved as an IS. Response: Accepted. @ 2.4 c 2 We do not see what the revised wording accomplishes, what it says is that you can have names like or but that was already the case. See our comments on the localedef utility. Response: 2.4 c 2 discussion will be addressed with 4.35 o 6 below. @ 2.4 o 3 2.4.1 WIDTH, WIDTH_VARIABLE, WIDTH_DEFAULT statements should be in the locale definition, as it is not coded related, but character related. For example the character is present in a number of coded character sets, including IS 10656, JIS X0208, GB2312 and KSC 5601. So this is independent of coding and a property of an abstract character, and the right place is then in the locale, possibly in LC_CTYPE. The WIDTH etc can also be used to represent fonts, and then it should be the same regardless of the coded character set, for example an in ASCII or ISO 8859-1 or ISO 8859-2 has the same properties in the Helvetica font. Response: For a given code set, POSIX.2 does not understand how different locales would assign different widths to a given codeset point. Therefore, POSIX.2 believes it would be appropriate to specify the widths in the charmap file once for each codeset, rather than repeatedly in each locale that refers to the codeset. @ 2.5 o 4 2.5.2.2.4 - we do not understand why coding of NUL was retained, as the standard should cater for other languages than C, and not impose C ideosyncraziees on the other languages. Response: 2.5 o 4 If this objection were accepted the POSIX locale defined in POSIX.1 and POSIX.2 would nolonger be a superset or compatible with the C locale defined by the ISO C standard. Since that is the basis for all locale work in POSIX.1 and POSIX.2, the POSIX.2 working group will not be able to make the suggested change. @ 2.8 o 5 line 379: The range experssion should not be dependent on the collation element order, but rather the result of the comparison using the relevant collation. Using the collating element order is not proper, and confusing to users that only has expectations as defiend by the collation rules. Response: 2.8 o 5 This is an issue concerning range expressions within regular expressions. This is an open issue under discussion and will not be closed during the POSIX.2b ballot period. See above disussion under N416. @ 4.35 o 6 line 1102: We should use the repertoiremap files as requested by WG20, Denmark and Canada, and defined by CEN and X/Open. The repertoiremap files should be used on the localedef command line to in a well-defined way be able to use locales and charmaps using diferent symbolic character notations. Two new options are proposed: -l repertoire_name Specify the name of a repertoiremap for mapping the locale symbolic character names to IS 10646 -r repertoire_name Specify the name of a repertoiremap for mapping the charmap symbolic character names to IS 10646 The -u option should be removed as the above covers the same functionality in a much more well defined way, and as much data for this is available. A naming conviention should be introduced to reference standard locales, charmaps and repertoiremaps from the international cultural conventions registry, for example introduced by the three letters "std". Response: 4.35 o 6 The POSIX.2 working group understands the issue of repertoire maps as opposed to the alternative presented in Draft 11. The committee is discussing this issue with members of the ballotting group and other i18n experts, and a decision will be made and presented in Draft 12. The committee would like to thank the Danish HoD for his explanation of the repertoire map issue at the St. Petersburg meeting. @ 4.48 o 7 Line 2150: the name should be "codeset" not "charset" - we are talking about coded character sets, not the character sets which is without coding, acording to SC2 terminology. Line 2155: plese do not use the term "ISO-IR" as this means ISO International Registry , as done in ISO 2375, and what you refer to on the following is not IS 2375 entries. For example UTF-8 is not in the IS 2375 registry. If you use just "ISO" or "ISO/IEC" or "IS" it would be fine. We would suggest that you use a notation as close as possible to the ISO naming, for example "ISO 8859- 1:1987" - not just spaces. It would be preferrable that such an item could be specified as just one token in a shell command line, and it is proposed to use for . Alignment with the forthcoming international registry that includes POSIX charmaps is requested. Please use "UTF-8" instead of "UTF8", and please specify wheather it is UCS2 or UCS4, and possibly also the endianness, not just ISO 10646. Response: 4.48 o 7 This issue is editorial and will be fixed in Draft 12. @ D.1 c 8 Annex D: a new RFC is available in RFC 1521 Response: D.1 c 8 This issue is editorial and will be fixed in Draft 12. _________________________ end of SC22 N2971 ___________________________