From keld Thu Jan 28 18:07:19 1999 Received: (from keld@localhost) by dkuug.dk (8.8.7/8.8.7) id SAA10870 for sc22wg15; Thu, 28 Jan 1999 18:07:19 +0100 (CET) (envelope-from keld) Date: Thu, 28 Jan 1999 18:07:19 +0100 (CET) From: Keld J|rn Simonsen Message-Id: <199901281707.SAA10870@dkuug.dk> To: sc22wg15 Subject: ds response to draft doc on .2b DS comments to editors draft disposition of comments: basically OK, just add the wording on transliteration and what was agreed in 1003.2b suwg group in recent meetings. I would like to hear Stephes respones to this. Keld > ISO/IEC JTC1/SC22/WG15 N754 > > Ladies and Gentlemen, > > The following is the proposed disposition of comments on POSIX.2b. > Denmark had substantial comments. These have been discussed a year > ago (May 1996) at the WG15 meeting hosted in Copenhagen. > While many items have been accepted, not all of their objections > have been removed. > > I appreciate that Denmark may wish to further discuss these > issues in a Project Editting meeting. I am open to suggestions as > to whether we attempt a conference call with the chair of POSIX.2 > (Don Cragun), myself and interested parties this week while people > are in Cornwall Ontario, or whether interested parties wish to > have an electronic mail meeting. I will abide by the wishes of WG15. > > Sincerely, > Stephen R. Walli > ----------------------------------------------------------------------- > Stephen R. Walli http://www.OpenNT.com Softway Systems Inc. > stephe@softway.com +1 519 571 0427 > > > WG15 N754 > 21 October, 1997 > > 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). OK, for now. > > 2. Page 10, line 185: Substitute > We believe 1003.2/D8 section 2.5.2.2 has the most recent text. > > Response: > Accept. OK. > 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. OK, for now. > 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. OK, for now. > > 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. OK. > 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. OK, as modified per 1003.2b suwg discussion in New Orleans. > 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. OK, this is on DS to then initiate PARs. > > 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. A complete proposal has been recieved and discussed, see suwg Miami 1998 meeting, the most recent developments are as specified in FCD2 14652, SC22 N2869 in the LC_CTYPE category. > 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. A complete proposal is included in FCD2 14652, SC22 N2869 in section 5 charmaps. > 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. OK, for now. > 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. OK, for now. > 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. OK for now, we may reconsider this as part of the PDAM ballot. > > 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. OK, for now, would probably need to be revisited in PDAM ballot. > @ 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. OK for now. > @ 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. OK for now. > @ 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. OK, see also suwg discussion of Jan 1999 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. OK. > @ 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. > OK.