WG15 TAG N586
							      SC22/WG15 N639

	 U.S. Position on Forwarding the X/Open Single UNIX Spec to ISO
			(WG15 Action Item 9510-12)

	The X/Open Single UNIX Specification is an excellent
	specification that well serves its community, and demonstrates
	the strengths of taking ISO standards developed in a well
	balanced open-to-all process and incorporating them into more
	programmer friendly reference documents.  The coverage by ISO
	standards is high (80% -- see below).

	Having carefully reviewed WG15 N622, the U.S. member body
	believes that an ISO specification should not be forthcoming to
	align with the Single UNIX Specification for the following
	reasons:

	1. X/Open has historically aligned itself with the ISO
	specifications supporting applications source-code portability,
	notably ISO C, POSIX-1, POSIX-2, POSIX-1g (sockets and TLI).
	This ``pull'' from X/Open continues.  The current efforts of its
	base working group (responsible for the Single UNIX
	Specification) incorporate POSIX-1b and POSIX-1c.  This is a
	good model for building industry specifications from
	international standards -- a stable standard that has had input
	from a large balanced community is quickly incorporated into an
	industry specification and ratified by the technical vendor
	community that supports that industry consortia.

	2. The Single UNIX Specification is a moving target, i.e. the
	current efforts to integrate POSIX-1b and POSIX-1c. (This work
	is expected to be completed in 1996.)  It needs to be a document
	that can move quickly to support the community that has to the
	present paid for its development and maintenance.

	3. The Single UNIX Specification is maintained by a small group
	of vendors that spend high-entry costs to participate in the
	base working group.  This is not the balanced ballot group
	approach, open to all, used within the IEEE to produce the
	current POSIX standards adopted by ISO WG15.

	4. The coverage of ISO C with its addendums, POSIX-1, POSIX-2 is
	almost 70% of the system interfaces and libraries in the System
	Interfaces and Headers Issue 4, Version 2. The coverage rises to
	80% if one conservatively ``removes'' from the System Interfaces
	and Headers Issue 4, Version 2:

	   a. XPG4 Base interfaces already marked as TO BE WITHDRAWN. (2)
	   b. XPG4 Base Encryption functions with export restrictions (3).
	   c. XPG4 Base regular expression interfaces marked TBW (6).
	   d. XPG4 Base functions with analogs in POSIX-1b that already
	      point to POSIX-1b as the way to write applications that are
	      more portable (10)
	   e. X/Open UNIX Extension functions marked TBW (4).
	   f. X/Open UNIX Extension functions covered in POSIX-1g (7)
	   g. X/Open UNIX Extension functions with analogs in POSIX-1b (4).
	   h. X/Open UNIX Extension functions that are directly replacable
	      with existing POSIX-1 and ISO C functions (29).
	   i. X/Open UNIX Extension functions overlapping XPG4 Base functions (2).
	   j. X/Open UNIX Extension functions providing alternate signal
	      mechanisms (8)
	   k. X/Open UNIX Extension functions that imply a implementation
	      rather than an interface (1).

	The coverage in the Commands and Utilities is as good. There are
	57 more utilities specified in the Commands and Utilities Issue
	4, Version 2 than the 114 in POSIX-2, i.e. POSIX-2 represents
	67% of the X/Open spec. We quickly arrive at 82% by ``removing''
	from the count:

	   a. The sccs commands (10) as this will only provoke version
	      control wars and POSIX has already determined this is a ``no
	      win'' situation. Also these tools are NOT required to be
	      implemented to conform to the XPG4 Commands and Utilities
	      V2 component.
	   b. Optional tools that cannot be used portably (X/Open's words) (1).
	   c. Tools directly covered by other POSIX-2 commands (3).
	   d. Tools with patent problems (3).
	   e. Archive tools directly covered by other POSIX-2 tools (2).
	   f. Tools already marked WITHDRAWN (5).
	   g. Tools that X/Open has deemed possibly unsupportable (8).

	The Network Services Issue 4 specification directly maps POSIX-1g.

	The *NEW* Xcurses Issue 4 specification demonstrates the
	difference between X/Open's specification creation process
	versus the IEEE standards creation process.  This specification
	represented one vendor's take on how the historical curses()
	library (as captured in XPG3) should be updated for colour, and
	wide-characters, and other good concepts, based on *their*
	working model. A specification was built.  The base working
	group, exhausted from the huge effort of building the rest of
	the Single UNIX Specification, ``passed'' the document as
	complete and ready.  It turns out there were a huge number of
	flaws.	They are now, 18 months after the completion of the
	Single UNIX Specification, revisiting this Xcurses specification
	to correct it.

	5. There were 171 interfaces added as the X/Open UNIX Extension
	feature group to the System Interfaces and Headers, Issue 4
	specification.	These interfaces were added through a unique
	survey method that scanned a lot existing historic UNIX
	applications for the interfaces that they used, and added them
	to the X/Open specification regardless of conflicts or
	duplication.

	[Section 1.3.5, X/Open UNIX Extension, System Headers and
	Interfaces Issue 4, Version 2, p.4.]

	      This document includes interfaces that had not previously
	      been adopted by X/Open.  These are now included to provide
	      portability for applications originally written to be
	      compiled on [traditional] UNIX and UNIX-based operating
	      systems.

	This is where a lot of the duplication noted elsewhere came into
	the spec. Essentially, these interfaces were added to the
	specification at a single point in that specification's
	development (after they had already aligned with the forward
	looking ISO POSIX and C documents) to allow a collection of
	*existing* historic UNIX applications to be ported to machines
	sporting an X/Open brand.  A number of these interfaces, hastily
	added under this ``existing applications use it'' requirement,
	are not as well specified as interfaces described in the ISO
	standards such that they could be implemented directly from the
	specification.	Indeed, the entire context [sic] of the context
	interfaces (makecontext(), setcontext(), etc.) is missing.

	6. A number of countries whose governments procure against ISO
	   specifications want to procure against XPG4 brands for a number
	   of reasons.
	-- A rich portability environment specification.
	-- That portability environment specification is aligned with
	   recognised ISO specifications.
	-- There is a branding programme for implementations that claim
	   to conform to the specifications.
	-- Large number of implementations carry the brand.
	-- Branded systems are required to pass rigorous test suites as
	   part of the branding process.
	-- The brand is a warranty of conformance regardless of test suite
	   results.

	Many such governments believe there is a problem with procuring
	against X/Open brands, and wish to somehow incorporate the
	Single UNIX Specification into an ISO standard, such that they
	can procure it. This is not necessary:

	(i)  Approximately 80% of the content of these X/Open
	specifications align with the same ISO standards in which the
	procurement agency is interested.

	(ii)  If the government has no recognised certification
	programme for the ISO standards (similar to the U.S. NIST FIPS
	151-2 and FIPS 169 programmes), then there is no reason that the
	X/Open brand certificate could not be used as the validation
	criteria for the *ISO* standards, e.g. a procurement bid request
	requires conformance to ISO C, ISO POSIX-1, ISO POSIX-2
	standards, and the validation criteria the bidder uses to
	demonstrate conformance to these ISO standards is the XPG4 Base
	95 or UNIX 95 (which ever is appropriate) brand certificates

	Even the U.S. government, which has inhouse certification
	programmes, is beginning to use this approach as it recognises
	the alignment of the X/Open specifications with ISO C and POSIX
	standards, and the alignment of X/Open brand certificates with
	systems that have appropriate FIPS certificates.

	7.  It is unclear how any method could be used to bring forward
	either the Single UNIX Specification in its entirety, or some
	subset of differences around which there may be consensus, in
	such a way as to not confuse the programming and procuring
	communities, and forever set-up a confusing set of integration
	problems.

	To bring forward the Single UNIX Specification in its entirety,
	(even if the ISO community was willing to ``replace'' ISO POSIX
	*AND* ISO C with the X/Open specification) is unacceptable due
	to problems that exist in the X/Open specification, (such as a
	lack of technical completeness in some newly added interfaces,
	e.g. makecontext(), and conflicts between the ISO C MSE and the
	Single UNIX Spec.)

	The existing model of X/Open quickly incorporating ISO standards
	that have been carefully built into their specifications when
	appropriate, supplementing the ISO interfaces with others of
	interest to X/Open's paying community is a good one.  It has
	resulted in a support for these ISO standards (if not a
	recognition) that has benefitted both groups.  The reverse is
	not true.  Quickly pulling X/Open's Single UNIX Specification
	into ISO will not have a positive effect on the X/Open
	specification and its maintenance, or the ISO POSIX and C
	standards.