From NickS@webvangroup.com Fri Feb 23 18:25:14 2001 Received: from hq-exchange-01.isrworld.com (ws-63-203-255-102.webvangroup.com [63.203.255.102]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id SAA92874 for ; Fri, 23 Feb 2001 18:25:13 +0100 (CET) (envelope-from NickS@webvangroup.com) Received: by hq-exchange-01.isrworld.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Feb 2001 09:25:07 -0800 Message-ID: From: "Stoughton, Nick" To: "'sc22wg15@dkuug.dk'" Cc: "'swalli@microsoft.com'" Subject: Re: POSIX.2b ISO Editing meeting Date: Fri, 23 Feb 2001 09:25:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C09DBD.8EE50F50" 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_000_01C09DBD.8EE50F50 Content-Type: text/plain; charset="iso-8859-1" Please note that the Toll Free number is not accessible from everywhere in the world; outside of the US you should use 1-650-627-3700. The details again: Meeting Start Date March 06,2001 Start Time (hh:mm): 07:00 AM Pacific Time Meeting ID: 4459 -- Nick Stoughton Webvan Group Inc Usenix Standards Liaison 650 627 3277 510 366 6176 (cell) ------_=_NextPart_000_01C09DBD.8EE50F50 Content-Type: text/plain; name="n3047.txt" Content-Disposition: attachment; filename="n3047.txt" Content-Transfer-Encoding: quoted-printable >From rinehuls@Radix.Net Wed Dec 15 00:30:29 1999 Received: from mail1.radix.net (mail1.radix.net [207.192.128.31]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id AAA59279; Wed, 15 Dec 1999 00:30:29 +0100 (CET) (envelope-from rinehuls@Radix.Net) Received: from saltmine.radix.net (saltmine.radix.net [207.192.128.40]) by mail1.radix.net (8.9.3/8.9.3) with SMTP id SAA10762; Tue, 14 Dec 1999 18:32:12 -0500 (EST) Date: Tue, 14 Dec 1999 18:32:09 -0500 (EST) From: William Rinehuls Reply-To: William Rinehuls To: sc22info@dkuug.dk cc: keld simonsen Subject: SC22 N3047 - Vote Summary on Approval of FPDAM2 to IS 9945-1: = POSIX Shell and Utilities Message-ID: = MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=3DUS-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 N3047 TITLE: Summary of Voting on FPDAM Ballot for FPDAM2 to ISO/IEC 9945-2: Information technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities DATE ASSIGNED: 19199-12-13 SOURCE: Secretariat, ISO/IEC JTC 1/SC22 BACKWARD POINTER: N/A DOCUMENT TYPE: Summary of Voting PROJECT NUMBER: JTC 1.22.41 STATUS: WG15 is requested to prepare a Disposition of Comments Report and make = a recommendation on the further processing of the FPDAM. ACTION IDENTIFIER: FYI to SC22 Member Bodies ACT to WG15 DUE DATE: N/A DISTRIBUTION: Text CROSS REFERENCE: N2972 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 overall summary ____________ SUMMARY OF VOTING ON Letter Ballot Reference No: SC22 N2972 Circulated by: JTC 1/SC22 Circulation Date: 1999-08-10 Closing Date: 1999-12-10 SUBJECT: FPDAM Ballot for FPDAM 2 to ISO/IEC 9945-2: Information technology - Portable Operating System Interface (POSIX) - = Part 2: Shell and Utilities ------------------------------------------------------------------------= The following responses have been received on the subject of approval: "P" Members supporting approval without comments 10 "P" Members supporting approval with comments 1 "P" Members not supporting approval 2 "P" Members abstaining 1 "P" Members not voting 7 "O" Members supporting approval without comments 1 ---------------------------------------------------------------------- Secretariat Action: The comments accompanying the negative votes from Norway and Japan are attached. The comment accompanying the affirmative vote from the United States of America was: "The draft of the document used for the FPDAM 2 ballot should be the same P1003.2b document that is submitted to the IEEE Standards Board in order to maintain the agreed upon synchronization." WG15 is requested to prepare a Disposition of Comments Report and make = a recommendation on the further processing of the FPDAM. ________ end of overall summary; beginning of detail summary __________ ISO/IEC JTC1/SC22 LETTER BALLOT SUMMARY =20 PROJECT NO: JTC 1.22.41 SUBJECT: FPDAM Ballot for FPDAM2 to ISO/IEC 9945-2: Information technology - Portable Operating System Interface (POSIX) - = Part 2: Shell and Utilities Reference Document No: N2972 Ballot Document No: N2972 Circulation Date: 1999-08-10 Closing Date: 1999-12-10 =20 Circulated To: SC22 P, O, L Circulated By: Secretariat SUMMARY OF VOTING AND COMMENTS RECEIVED Approve Disapprove Abstain Comments Not Voting 'P' Members Austria ( ) ( ) ( ) ( ) (X) Belgium (X) ( ) ( ) ( ) ( ) Brazil ( ) ( ) ( ) ( ) (X) =20 Canada (X) ( ) ( ) ( ) ( ) China ( ) ( ) ( ) ( ) (X) Czech Republic (X) ( ) ( ) ( ) ( ) Denmark (X) ( ) ( ) ( ) ( ) Egypt ( ) ( ) ( ) ( ) (X) Finland (X) ( ) ( ) ( ) ( ) France ( ) ( ) (X) ( ) ( ) Germany (X) ( ) ( ) ( ) ( ) Ireland (X) ( ) ( ) ( ) ( ) Japan ( ) (X) ( ) (X) ( ) Netherlands (X) ( ) ( ) ( ) ( ) Norway ( ) (X) ( ) (X) ( ) Romania ( ) ( ) ( ) ( ) (X) Russian Federation (X) ( ) ( ) ( ) ( ) Slovenia ( ) ( ) ( ) ( ) (X) UK (X) ( ) ( ) ( ) ( ) Ukraine ( ) ( ) ( ) ( ) (X) USA (X) ( ) ( ) (X) ( ) 'O' Members Voting Korea Republic (X) ( ) ( ) ( ) ( ) ______ end of detail summary; beginning of Norway comments ____________ From: Ulf Leirstein Subject: Norwegian vote on N2972 Norway vote NO to this document. The following are the Norwegian comments accompanying the Norwegian negative vote on SC22 N2972, POSIX-2 PDAM (.2b) 1. General comments: NOR.1 The disposition of comments in N2971 has not been implemented fully, as the accepted Danish comment on "substitute" has not been implemented. The text that was proposed and accepted (possibly = 1003.2/D8 section 2.5.2.2) has not been incorporated in the PDAM. 2. Technical comments NOR.2 There should be a repertoiremap description file format, to describe which repertoire is covered and how symbolic character names relate to IS 10646. This file describes the concept of character repertoire of SC2 and lists abstract characters, (not encoded characters as in charmaps). This concept is used in the cultural = registry=20 of ISO/IEC 15897 adn in PDTR 14652 and also (without the specific name = of repertoire map) in The Open Group registry.The concept of charmaps = using IS 10646 position values should be removed thruout, eg in 2.4.1. NOR.3 The specification should be aligned with the specifications in = PDTR=20 14652. NOR.4 WIDTH, WIDTH_VARIABLE, WIDTH_DEFAULT statements sould be localetd in the locale definition, as they are related to abstract characters. Abstract characters are defined in IS 10646, and a number of attributes to the abstract characters are also defined here, including WIDTH attributes. Thus for an abstract character, with double width, this has the width 2 regardless of the encoding, be it in IS 10646 or a national double-byte encoding. The LC_CTYPE category should be practically identical for all locales so there is no overhead in doing this once = and for all in a standard locale, that then others can refer to. As the WIDTH attribute is an attribute of an abstract character and not = related to encodeing, it is a big architectural mistake to move it into the encoding specification of the charmap, and destroying the principle of making locales contain all encoding independent information. NOR.5 2.5.2.2.4 The coding of NUL should be removed as a requirement, = as=20 this requirement has been removed in the new C standard. NOR.6 4.35 We should use the repertoiremap files as requested in NOR.2 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 convention should be introduced to reference standard locales, = charmaps and repertoiremaps from the international cultural conventions registry, for example introduced by the three letters "std". NOR.7 Line 1915: the name should be "codeset" not "charset" - we are talking=20 about coded character sets, not the character sets which is without coding, acording to SC2 terminology. NOR-8 Line 1921: Please use "UTF-8" instead of "UTF8", also other places, as this is the officual name in IS 10646. NOR.9 P 288 line 633ff: please change "glyph" to "anstract character" as = glyph=20 means something else in ISO (=3Dshape) NOR.10 Please change all references to IEEE std's to corresponding ISO/IEC=20 standards. End of comments @ D.1 c 8 Annex D: a new RFC is available in RFC 1521 ____ end of Norway comments; beginning of Japan comments = ________________ ISO/IEC Vote on PDAM2 to IS 9945-2 Date of Circulation: 1999-08-10 Closing date for voting: 1999-11-10 =20 Reference number: ISO/IEC JTC 1/SC22 N2972 ------------------------------------------------------------------------= P-members have an obligation to vote ------------------------------------------------------------------------= ISO/IEC JTC 1/SC22 Title: Programming languages, their environments and system software interfaces Secretariat: U.S.A. (ANSI) ------------------------------------------------------------------------= Please send this form, duly completed, to the secretariat indicated = above. ------------------------------------------------------------------------= CD: PDAM2 to ISO/IEC 9945-2 TITLE: PDAM2 to ISO/IEC 9945-2: Information technology - Portable Operating System Interface (POSIX) - Part 2: Shell and = Utilities ------------------------------------------------------------------------= - Please put an "X" in the appropriate box(es) Approval of the draft: _____ as presented _____ with comments as given below (use separate page if necessary) _____ general _____ technical _____ editorial __X__ Disapproval of the draft for reasons below (use separate page as annex, if necessary) __X__ Acceptance of these reasons and appropriate changes in = the text will change our vote to apoproval. _____ Abstention (for reasons below) ------------------------------------------------------------------------= - P-member voting JAPAN Date: 99-12-10 Signature (if mailed) ________________________________________________________________________= _ Japan will change it position from disapproval to approval if the syntax to define user defined character mapping in the localedef utility, that will be referred to by wctrans() and towctrans() functions specified by the ISO/IEC 9899 (C language) Amendment 1, will be added. The initial Japanese proposal on this issue, contributed in 1996 was as follows: | [Attachment: LC_CTYPE extension proposal for locale-specific = character mapping] | | | Source: Japan | | Title: Japanese proposal to POSIX.2b on LC_CTYPE extension for | locale-specific character mapping | | Status: Japanese position | | Short description: | Japan proposes that LC_CTYPE locale definition should be | extended to allow locale-specific character mappings | to be specified. This extension is necessary to implement | wctrans() and towctrans() functions in ISO C amendment | on a POSIX conforming system. | | Text of contribution: | | = ------------------------------------------------------------------------= ---- | [Note: The page numbers refer to the ones of P1003.2/D10.] | | Sect 2.5 (Locale) PROPOSAL. Page 8-9,12: | | Problem: | The LC_CTYPE (2.5.2.1) locale definition should be enhanced to = allow | user-specified additional character mapping, similar in the = concept | to the user-specified additional character class. In the = Amendment | of ISO C standard, extended character mapping functions | (wctrans/towctrans) are specified. The following proposed = extension | will serve for the machinery to define locale specific character | mappings used by the functions. Without having this extension, | POSIX conforming systems need to have their own extensions to | implement ISO C Amendment specifications. | | Proposal:[LC_CTYPE extension for specifying character mapping] | | The proposed extension for character mapping is similar to the = extension | of character class, which is already specified in .2b draft. | New keyword 'charconv' is introduced to define locale-specific | character mappings instead of 'charclass' keyword for character = class. | The way of defining character mapping is not extended with this = proposal. | The same specification for toupper/tolower mapping can be used = for | locale-specific character mappings. | | EXAMPLE: | | LC_CTYPE | | # define the names of locale-specific character mappings | charconv tojkata;tojhira | | # tojkata: hiragana =3D> katakana mapping | tojkata (,);(,);\ | .....definition..... | | # tojhira: katakana =3D> hiragana mapping | tojhira (,);(,);\ | .....definition..... | | END LC_CTYPE | | [Proposed extension to .2b text] | | [Page 8] | =3D> 2.5.2.1 LC_CTYPE. Add the following keyword items after the item | labeled tolower: | | charconv Define one or more locale-specific character mapping = names as | strings separated by semicolons. Each named character = mapping | can then be defined subsequently in the LC_CTYPE = definition. | A character mapping name shall consist of at least one = and at | most fourteen bytes of alphanumeric characters from the | portable filename character set. The first character of = a | character mapping name cannot be a digit. The name = cannot | match any of the LC_CTYPE keywords defined in this = standard. | | charconv-name | Define the named locale-specific character mapping. | In the POSIX Locale, the locale-specific named = character | mapping need not exist. | | If a mapping name is defined by a charconv keyword, but = no | character mappings are subsequently assigned to it, = this | is not an error; it shall represent a mapping without = any | character pairs belonging to it. | | [Page 12] | =3D> 2.5.3.1 Locale Lexical Conventions. Add the following token = description: | | CHARCONV A string of alphanumeric characters from the portable | character set, the first of which shall not be a digit, | consisting of at least one and at most fourteen bytes, | and optionally surrounded by double-quotes. | | [Page 12] | =3D> 2.5.3.2 Locale Grammar. Modify the ctype_keyword and = charconv_keyword | descriptions as follows: | | ctype_keyword : charclass_keyword charclass_list EOL | | charwidth_keyword charclass_list EOL | | defwidth_keyword defwidth_value EOL | | charconv_keyword charconv_list EOL | | 'charclass' charclass_namelist EOL | | 'charconv' charconv_namelist EOL | ; | | charconv_namelist : charconv_namelist ';' CHARCONV | | CHARCONV | ; | | charconv_keyword : 'toupper' | 'tolower' | | CHARCONV | ; | ___________________________ end of SC22 N3047 _______________________ ------_=_NextPart_000_01C09DBD.8EE50F50--