Standards Update, IEEE 1003.2: Shell and Utilities

[Randall Atkinson]

Submitted-by: randall at Virginia.EDU (Randall Atkinson)

In article <1991Jun12.034606.16284 at uunet.uu.net>, 
	Peter Collinson <pc at hillside.co.uk> writes:

>There was a problem with the Draft 11 distribution. POSIX.2 is now
>over 900 pages. It's balloting period was 30 days, although with a
>mailing lead it was about 6 weeks.  Due to postal services, some
>members of the balloting group only received their ballot copies two
>weeks prior to the closing deadline. Hal Jespersen was as
>accommodating as he could be on the deadline, but the extent of these
>submissions was definitely affected.  The question rears its head
>again.  Should we be balloting POSIX standards the same as we ballot
>smaller hardware standards?

  This is a very real problem.  I ended up abstaining on both the
Ada-bindings and Threads ballots because I didn't have sufficient time
to review the lengthy &/or complex ballots in the time allotted.

  It seems to me that the SEC should consider mandating that future
ballots for the POSIX arena have a longer minimum balloting period
than the IEEE requires.  This would not conflict with the IEEE
requirements and would get better standards in the final result.

>New PARs
>
>The Project Management Committee (PMC) has recommended the proposed
>PAR (Project Authorization Request) for 1003.2b be split into two
>parts. One part will cover extensions and new requests from other
>groups, such as the tar, cpio and new pax file formats from POSIX.1
>(Kernel) and utilities from POSIX.4 (Realtime) and POSIX.6
>(Security).  The timing and alignment issues with the ISO 9945-2
>balloting process will be covered by the other part.
>
>The scope of this second PAR is restricted to standardization of
>existing industry practice. The group does not want to get into
>designing new utilities.

  Such a scope is the only appropriate one.  In particular the
experience of other standards (e.g. ISO Network Protocol
interoperability problems) have made it clear that it is best to
standardise only existing practice and let there be actual implemented
experience with new utlitites or features before putting them in the
standard.

  I am glad to see this made explicit in the POSIX.2b PAR as it has
been an ongoing concern of mine (in particular with regard to
windowing interfaces that there isn't enough experience with).

>There is also concern over draft stability when discussing the
>commands to access the features from the POSIX.4 and POSIX.6
>standards. How mature does the feature have to be before the POSIX.2
>group goes to the effort of defining a command interface to it ?


It seems to me that if a draft hasn't even reached balloting that
it is not sufficiently stable for the POSIX.2 WG to make much effort
devising a suitable command interface for it.  There have been a lot
of cases where changes occurred in balloting as well, so it might
not even be stable enough at ballot-time.

>Discussion

>Richard Hart from POSIX.7 (System Administration) presented the syntax
>for a new printing command based on the MIT/Athena Palladium network
>printing services. Everyone in the POSIX.2 group agreed that the
>proposed syntax was awkward.

The posted examples are pursuasive.  The printing commands should all
be based on widespread existing practice in UN*X systems.  The MIT/Athena
Palladium services are not widespread enough to justify their adoption.

>Requests for technology
>
>There is an opportunity now to propose a new archive format.  

Why is yet another archive format needed ??


Volume-Number: Volume 23, Number 103