Standards Update, NIST Shell-and-Tools FIPS Workshop

[Shane P. McCarron]

Submitted-by: ahby at bungia.bungia.mn.org (Shane P. McCarron)

In article <13137 at cs.utexas.edu> domo at tsa.co.uk writes:
>Submitted-by: domo at tsa.co.uk (Dominic Dunlop)
>
>While we can wish for an ideal world where standards committees are
>always able quickly to reach a broad consensus based on well-tried
>existing practice, and can deliver a well-rounded document to an
>accepting and grateful public, we have to concern ourself with real
>life.

Dominic says that we have to concern ourselves with real life.  Real life 
is that POSIX.2 Draft 9 is an immature document.  Making it a
procurement specification means that system vendors will have to do a
lot of work that they will, to some extent, just throw away later.
Moreover, this work will be duplicated by every system vendor wanting
to sell into that market.  Also, since there are organizations like
the Open Software Foundation and UNIX System Laboratories producing
reference implementations of the operating system, these vendors could
have not done the work themselves at all!

This economy is development is something that must be taken into
account by the US government, and in fact by any organization
specifying procurement requirements.  These organizations want to
procure something TODAY!  They want it to look like a standard
implementation, but they would probably be just as happy if the
applications that they really need ran.  MS-DOS is not a standard, but
it runs flight-simulator and Lotus.  That's enough for most people.

What we, as people involved in the standardization process, have to do
is work with the Federal government and other organizations to help
them understand the folly of prematurely pointing to standards.  Those
standards are, for the most part, build upon existing practice.  When
organizations go to put together a procurement specification, they
need to know what components of that standard are stable and represent
existing practice that is available to them TODAY.  If they use that
as the basis of their procurement they will have an Open Systems
solution that they can actually get their hands on.  Further, that
solution will be upwardly compatible with the final standard because
it is a proper subset of the functionality in that standard.

A example of reasonable subsetting from Draft 9 would be system limits
like LINEMAX.  In POSIX.2 this is specified as being something like
4k (I can't remember).  Anyway, the limit is supposed to apply to any
utility that reads lines of input from the user or from text files.
No system in the world that is shipping today supports this limit in
every system utility.  It is an ideal goal that the companies represented 
by the participants in POSIX.2 have agreed to move to over time.  Producing 
a standard is just that: an agreement that all of "this" existing practice 
is pretty good, and here are the areas in which we agree that it should be
better defined or enhanced to make the functionality maximally
advantageous for application developers and end users.  This is a very
important point, and tends to be lost on casual observers of
standardization efforts.

>And I think that requiring conformance to a draft standard is a whole
>lot better than not requiring conformance to anything in particular.
>Sure, it will be annoying and painful to convert later when the real
>thing comes along.  And it will cost real money.  But it will cost a
>whole lot less money in total than -- say -- implementing using a
>proprietary environment now, and switching to an official POSIX.2 when
>it comes along.  Yes, the up-front costs may be higher because a draft
>9-conforming environment is likely to be more or less custom-built (or
>at least, suppliers are liable to try to stick you for the costs of a
>fully custom job, even if such costs are not justified).  But the
>downstream costs, including the costs of any draft-to-final conversion,
>are likely to be way lower.

Well, it depends.  The cost to the system vendor will be lower, but
not to the end user.  Any functionality that user took advantage of
that was not represented in the final standard will suddenly become
non-portable.  Worse yet, it may become unavailable.  From a system
vendors perspective, they may have to support some strange
functioanlity or system limits because the draft standard required
them to, some agency took advantage of it, and now they are stuck.
They have to support thios non-portable functionality forever, as well
as the real standard.  This is not at all the goal of standardization,
and should not be the goal of the agencies procuring systems.

Standing on my soap-box again for a minute, we have to keep the
overall goal of open systems in sight.  That goal is that the
application developers of the world are given a guaranteed base on
which they can develop portable applications that can interoperate
with one another.  This means having a steady functional migration
which NEVER capriciously breaks compatability.  This may mean that in
the short term new, exciting functionality is not introduced to the
disadvantage of existing practice.  This is the price we pay for
keeping the application developers interested in open systems.  The
personal productivity application base is just coming available for
open systems platforms in ways that are attractive to the casual
computer user.  We CANNOT abdicate our responsibility to retain that
extremely hard-won base of applications by allowing radical change in the
definition of the system.  If we do that, we might as well go and buy DOS.

Shane P. McCarron
Secretary, IEEE TCOS-SS
-- 
Shane P. McCarron				Phone: +1 612-224-9239
Project Manager					Internet: ahby at bungia.mn.org


Volume-Number: Volume 21, Number 189