Subject: SC22 N2971 - Comments Disposition for Registration of PDAM2 to 9945-2: POSIX Shell and Utilities

From: William Rinehuls <[email-masked]>
Date: Tue, 10 Aug 1999 12:34:48 -0400 (EDT)

_____________________ 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:  [email-masked]

_____________ 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 <Uxxxx> or <Uxxxxxxxx> 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 <double width A> 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 <a> 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 <underscore> for <space>. 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 ___________________________