From hlj@posix Thu May 14 20:20:53 1992 Received: from netcomsv.netcom.com by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA04781; Thu, 14 May 92 20:20:53 +0200 Received: from posix.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA01139; Thu, 14 May 92 11:19:23 PDT Received: by posix.COM (smail2.5) id AA29856; 14 May 92 10:56:26 PDT (Thu) Subject: 9945-2 futures annex To: sc22wg15@dkuug.dk Date: Thu, 14 May 92 10:56:24 PDT From: Hal Jespersen Organization: POSIX Software Group, 447 Lakeview Way, Redwood City, CA 94062 Phone: +1 (415) 364-3410 FAX: +1 (415) 364-4498 X-Mailer: ELM [version 2.2 PL0] Message-Id: <9205141056.AA29852@posix.COM> X-Charset: ASCII X-Char-Esc: 29 As part of the disposition of comments to 9945-2 and its CD Amendment 1, I was asked to add an annex describing what work was being considered for the next revision. Here it is. Please send me comments or corrections by 1 July 1992. Thanks, Hal Jespersen, WG15 Project Editor POSIX Software Group 447 Lakeview Way Redwood City, CA 94062 Phone: +1 (415) 364-3410 FAX: +1 (415) 364-4498 Email: hlj@posix.COM Annex H (informative) Proposals for Future Revisions This informative annex describes modifications and enhancements that have been proposed for the next revision of this standard. Comments on this list and specific proposals are solicited; at the time of publication, not all of the items have initial proposals under consideration. See the Introduction to this standard for information on participating in future work in these areas. The following clauses describe the five major areas of work currently authorized for the next revision of this standard. NOTE: At the time of publication, it is not known whether this revision will be the first full International Standard (i.e., a reballoting of a document as DIS 9945-2.2) or the second. JTC1/SC22/WG15 has stated its preference for the latter, elevating DIS 9945-2 to be an International Standard as quickly as possible; this would allow the following development to be undertaken in parallel with the six-month balloting period of the first IS. H.1 Resolve International Comments to DIS 9945-2 There were a number of comments from SC22 member bodies that were deferred for consideration in the next revision. They are summarized here, in no specific order: (1) Provisions should be made to allow characters beyond those in the portable character set in user-supplied identifiers for the shell, awk, bc, lex, make, and yacc. A proposal has been made by Denmark to extend the locale definition to specify the set of identifier characters for all programming languages. (2) The LC_CTYPE (2.5.2.1) locale definition should be enhanced to allow user-specified additional character classes, similar in concept to the proposed C Standard {8} Multibyte Support Extension (MSE) is_wctype() function. (3) The LC_COLLATE (2.5.2.2) locale definition should be enhanced to allow user-specified names for collation weights. A proposal from Japan is expected in this area. (4) The collation substitute facility, removed from 2.5.2.2 in an early draft, should be restored. (5) A facility should be added to allow simple modifications to existing locale collation definitions. A proposal for such a replace_after keyword in LC_COLLATE is being developed by Denmark. (6) The specific encoding and collation requirements for the character NUL should be removed. (7) The support of state-dependent (shift encoding) character sets should be addressed fully. See descriptions of these in 2.4. If such character encodings are supported, it is expected that this will impact 2.4 (charmap), 2.5 (locale definition), 2.8 (regular expressions), and the comm, cut, diff, grep, head, join, paste, and tail utilities. A proposal from Japan is expected in this area. (8) The definition of column position (see 2.2.2.31) relies on the implementation's knowledge of the integral width of the characters. The charmap (2.4) or LC_CTYPE (2.5.2.1) locale definitions should be enhanced to allow application specification of these widths. A proposal from Japan is expected in this area. (9) A utility (or feature of another utility, such as tr) should be provided that converts between character sets encodings based on two charmap files. A proposal from Denmark is expected in this area. (10) The date utility should allow width specifications for its fields, similar to those in the printf() function. (11) The file utility should allow user-specified algorithms for file type recognition, similar to those used in the historical /etc/magic file. (12) The pax utility should provide a new file interchange format, in addition to cpio and ustar, that allows extended characters in file, user, and group names. Rules should be given for the cases where an archived name cannot be represented by the local character set in the file system. NOTE: The example Danish Profile annex contains a feature that implements a form of this proposal. It is not clear whether this is the solution that will be selected for the next revision. (13) The uuencode utility should support the BASE64-encoding specified in the MIME-RFC currently under consideration for Internet use. The uudecode utility should allow the user to override the output file name that is embedded in the file. Both utilities should be moved from Section 5 to Section 4. (14) The functions in Annex B that use the C-language char type should be modified to allow wide character (wchar_t) encodings, as suggested by the proposed MSE amendment to the C Standard {8}. A proposal from Japan is expected in this area. H.2 Resolve Interpretation Requests and Correct Technical Defects Issues resulting from requests for interpretation (through either the IEEE or ISO/IEC processes) will be resolved. The clarity, accuracy, and precision of the language in the standard will be improved, correcting technical defects found in implementing systems, test suites, or applications based on the standard. Specific proposals are sought for this area. H.3 Revise Granularity of Options Some of the groups producing functional standards (profiles) based on POSIX.2 desire finer granularity in groupings of optional utilities and features. For example, the 72 utilities in Section 4 may be too many for some profiles to require. Specific proposals are sought for this area. H.4 Support Features of 9945-1 Revision There is a desire to incorporate interfaces associated with new facilities being produced for the next revision of POSIX.1 {9} (POSIX.1a), such as symbolic links. NOTE: Extended or supplementary shell and utility features based on POSIX.1a interfaces will be included as normative parts of POSIX.2 only if schedules can be arranged so that the POSIX.1a supplement is available for citation as a normative reference at the time of approval of the next revision of this standard. H.5 Reorganize 9945-1 and 9945-2 Material The Document Structure Plan for the ISO/IEC 9945 standards has proposed a reorganization of material between 9945-1 and 9945-2. The following changes are being considered, assuming that mutually acceptable approval schedules are possible (i.e., these sections will be removed from future revisions of POSIX.2 only when other approved POSIX standards have incorporated them): (1) Move the cpio and ustar file format descriptions from 9945-1 Section 10 to the 9945-2 pax utility. (2) Remove 9945-2 Section 7 and move the APIs [system(), regcomp(), etc.] from Annex B to the language-independent version of 9945-1 and its corresponding language-binding standards. (3) Move the language-dependent development utilities in Annexes A and C to other standards related to those programming languages.