Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.30/text0009.txt

Text File | 1993-03-11 | 8.0 KB | 182 lines

Submitted-by: [e-mail] (Stephen Walli)

David Rowley <[e-mail]> reports on the October 19-23 meeting in
Utrecht, NL:

Summary

The grand moment has arrived, we have a final POSIX.2 Standard:

        IEEE Std 1003.2-1992

Approved by the IEEE Standards Board on September the 17th, 1992,
POSIX.2-1992 is the culmination of over five years of the working
group's efforts.  The standard consists of both the ``Dot 2 Classic''
and ``Dot 2a'' components, previously balloted as separate standards.
The IEEE Standard (based on the new Draft 12) is identical (at least
from a technical standpoint) to the draft ISO standard, ISO/IEC DIS
9945- 2:1992

NIST continues to work on the draft of a new FIPS (Federal Information
Processing Standard) for POSIX.2, expected in final form by early 1993.

POSIX.2b work continues to proceed, incorporating symbolic link
support within a number of utilities, a new PAX archive format, and
addresses a number of international concerns regarding locales.  The
PAX format is still based on the old but standard ISO 1001 tape format.

Test assertion work nears completion.  The POSIX.2 assertions have
almost full coverage, and will go to ballot again in December.  The
POSIX.2a test assertion work is going well, with almost all assertions
complete, including vi.  These will be folded in to the next draft of
the POSIX.2 test assertions.

The test assertion work for POSIX.2 will be renamed P2003.2 instead of
the current P1003.3.2.

Background

A brief POSIX.2 project description:

   - The base utilities of the POSIX.2 standard deal with the basic
     shell programming language and a set of utilities required for
     the portability of shell scripts.  It excludes most features that
     might be considered interactive.  POSIX.2 also standardizes
     command-line and function interfaces related to certain POSIX.2
     utilities (e.g., popen(), regular expressions, etc.). This part
     of POSIX.2, which was developed first, is sometimes known as
     ``Dot 2 Classic.''

   - the User Portability Utilities Option or UPUO, is an option in
     the base standard (previously known as POSIX.2a).  It
     standardizes commands, such as vi, that might not appear in shell
     scripts, but are important enough that users must learn them on
     any real system.

     Some utilities have both interactive and non-interactive
     features.  In such cases, the UPUO defines extensions from the
     base POSIX.2 utility.  Features used both interactively and in
     scripts tend to be defined in the base utility.

   - POSIX.2b is a project which covers extensions and new requests
     from other groups, such as a new file format for PAX and
     extensions for symbolic links.  It also includes resolution of
     items arising from comments by ISO Working Group 15.

POSIX.2 is equivalent to the International Standards Organization's
ISO DIS 9945-2 -- the second volume of the proposed ISO three-volume
POSIX standard.

Publishing

Now that the Standard has been approved by the IEEE, everyone is
anxiously awaiting the final published volumes.  They will be printed
on A4 paper in two volumes: the core standard (Sections 1-7), and the
annexes.  The set should be available from the IEEE sometime in the
March 1993 timeframe at a total page count of around 1300 pages.

POSIX.2 FIPS

NIST (National Institute of Standards and Technology) is still
preparing the draft FIPS (Federal Information Processing Standard) for
POSIX.2.  The goal of the FIPS is to directly adopt, rather than
adapt, POSIX.2 as a procurement standard.  The selection of options and
extensions will be left to the procurement officer.  This will lead to
even greater use of the standard, due to the flexibility this offers
the agencies wishing to reference POSIX.2.

NIST Draft Request for Test Technology

NIST has issued a draft of a Request for Test Technology.  NIST is
seeking candidate test suites from which to select one test suite to
measure conformance to the proposed POSIX.2 FIPS.  It must be based on
TET (Test Environment Toolkit from OSF-UI-X/Open), cover all
assertions from POSIX.3.2, and satisfy the general test method
requirements specified in POSIX.3.  The suite must also be commercially
available (either now or in the future).  The full RFTT is due out
early in the new year.

X/Open Request for Proposal

X/Open is in the final stages of signing the contract for the
Integrator they have chosen for their combined POSIX.2/XPG4 Commands
and Utilities test suite, to be integrated into a future release of
VSX (Validation Suite for XPG).  The Integrator will likely be
publicly announced before the end of the year.  Work is to start early
in 1993, and should result in a suite being publicly available early
in 1994.

Test Assertion Group Name Change

The IEEE is in the process of renaming the test suite working groups
to a parallel numbering system to P1003.  As of March 1993, the
POSIX.2 test methods work will be numbered P2003.2.  This should ease
the confusion of many similar sounding working groups containing
numerous dots and digits.

The ballot for Draft 8 of the POSIX.2 test assertions starts December
6th and ends January 6th.  Some ballot resolution will be attempted at
the January POSIX in New Orleans (the 11th to the 15th).  Draft 8
includes assertions for all utilities except those from Section 5 of
POSIX.2 (the User Portability Utilities Option, formerly POSIX.2a).
These missing assertions will be included for the full re-ballot,
Draft 9, expected sometime in March 1993.

POSIX.2b

The current draft of POSIX.2b, Draft 4 - August 1992, includes a
number of extensions and additional utilities.  The BASE64 encoding
from MIME (Multipurpose Internet Mail Extensions, RFC 1341) has been
incorporated into uuencode/uudecode. The ``iconv'' utility for
character set conversion has been added from XPG4. Print field widths
have been added to the ``date'' command.  Support for symbolic links
has also been added to a number of utilities.

Locales

A proposal from Thomas Plum regarding a new locale specification
format from P. J. Plauger was discussed.  Although the format has some
interesting features, the codeset specific nature of the format limits
its usefulness, and was deemed dangerous in a POSIX environment.  A
liaison statement to WG14(C), WG20 (Internationalization) and WG21
(C++) will be drafted by the Chair.

Yoichi Suehiro (DEC Japan) made a proposal to extend LC_TYPE to handle
user-definable character conversions and user-definable character
classes.  These were both felt not to be within the scope of POSIX.2,
but may be reconsidered at a later date.

Extensions to LC_TYPE were approved to specify the display/print
widths of characters in the locale.  This information will be
specified by using the keywords ``width1'', ``width2'', etc.  There
will also be a ``default width'' keyword which specifies the default
width occupied by all characters not specifically mentioned in one of
the ``width'' classes.

``era_d_t_fmt'' had accidentally been left out of the LC_CTIME
category.  This will be corrected through POSIX.2b.


There was a long discussion on multibyte and stateful encodings and
the need for coordination between ISO 9945-1 and ISO 9945-2.  This
will be discussed further in subsequent meetings.

New PAX File Format

The request for alternate PAX format proposals generated only a few
pointers to other file formats, particularly the MIME standard (RFC
1341).  Mark Brown has volunteered to write up a rough draft of a
MIME-based PAX format to be discussed in New Orleans.  Other than
that, the group continues to work with ISO 1001.  The group has also
agreed to adopt Gary Miller's (IBM Austin) new File System Safe UTF
(UCS Transformation Format) which specifically stays away from the
codepoints representing the ASCII ``/'' character and null bytes.

Character set conversions issues within the PAX format can now be
handled in a generic, systemwide manner given that the ``iconv''
utility has been added to the standard.  This should result in a much
more useful and consistent system for the user.

Volume-Number: Volume 30, Number 10