Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.28/text0039.txt

Text File | 1992-08-17 | 16.6 KB | 332 lines

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

Kevin Lewis <[e-mail]> reports on the April
8-12, 1992 meeting in Dallas, TX:

POSIX.0: Guide to Open Systems Environments.AU "Stephe Walli

[Warning - Profiles are poorly understood, ill-defined specifications
that are being drafted as full standards in various corners of the
standards community. If at first the article seems twisty and
convoluted, that is because the topic is twisty and convoluted, mired
in a lot of historical context. The article presents the historical
context for profiling activities, and the traps lying in wait for
unsuspecting applications developers. It finishes with a few
recommendations. --poster ]

Profiles are the latest confusion to appear on the open systems
standards scene. They are supposed to define a view on one or more
standards in a coherent way to fulfill a general need. This need may
be something like: ``a programming platform for general multi-user,
multi- processing business applications''; or maybe:  ``supercomputing
applications typically require the following services''. This seems
reasonable. It also seems to feel right. So what happened?

In the Beginning ...

The POSIX.1 (ISO/IEC 9945-1:1990 == IEEE Std. 1003.1-1990) standard
standing alone is not enough. By its own definition, it requires C
language support. This can be either Common Usage C or Standard C
(ISO/IEC 9899:1989 == ANSI X3.159-1989). These two standards
together provide a reasonable programming environment. They are not
complete, there are many things missing. To move the standard
forward, things were left out that were too contentious at the time.
It was better to have a some kind of standard than none at all.

POSIX.1 also has optional functionality. Some of this functionality
is called out by ``Big-O'' options, such as {NGROUPS_MAX},
{_POSIX_JOB_CONTROL}, or {_POSIX_CHOWN_RESTRICTED}. These are
implementation level options, and a vendor could choose to not
implement them and still be conforming. There are other named
options, such as {_POSIX_NO_TRUNC}, and {_POSIX_SAVED_IDS}, which may
or may not be implemented. A strictly conforming application should
never count on such functionality being present.

Using this simple model, the National Institute of Standards and
Technology (NIST) created the U.S. government procurement document,
FIPS PUB 151-1. In it, NIST specified what options and limits must be
supported from POSIX.1, and how the C language support should be done.
The intent was to provide as functional a platform as possible by
mandating as much of the POSIX.1 standard as possible. Something upon
which U.S. government applications developers could depend. Simple.

A long time ago, relatively speaking, X/Open was formed. It described
a collection of specifications that all of its member vendor
organizations would adhere to. Thereby it provided a Common
Application Environment (CAE) for applications portability. This
specification of a platforms functionality was written down in the
X/Open Portability Guide (XPG). They have made a point of adopting
POSIX standard interfaces where possible, moving away from the
original SVID definitions. Perhaps not complete, but still relatively
simple. Both FIPS and the X/Open XPG feel kind of like something you,
as an applications developer, might want to point to when describing
the environment you want.

Now let's move on to where things start getting messy. A number of
things start happening in parallel, which means the confusion factor
goes up exponentially. POSIX began doing some things. ISO was doing
others. The industry consortia were doing something else. And
remember, the industry consortia are the ones backed by vendor money,
and have a stake in selling you their solution. Industry consortia
= A vendor once removed.

POSIX

A few years ago, at the beginning of the Great Project Proliferation
in POSIX, two projects began which would develop Applications
Environment Profiles (AEPs) for Supercomputing (POSIX.10) and
Transaction Processing (POSIX.11). The intent was to describe how to
use POSIX in building applications in these two particular domains. In
the last two years, two more AEP projects developed in POSIX, one for
Real-time applications (POSIX.13) and one for Multi-processor
applications (POSIX.14).

These last two are illustrative of many of the problems encountered.
The POSIX.4 (Real-time) and POSIX.4a (Threads) standards will become
addendums to the POSIX.1 base standard. All function interfaces
defined by POSIX.4 and POSIX.4a will need to be provided by future
implementations of POSIX.1, although they may be just stubs returning
ENOSUPPORT (or some such), if the implementation does not support the
added functionality. This functionality will be called out by named
options. Hmmmm. Getting a little muddy.

POSIX.13 and POSIX.14 would hopefully define an applications domain
that must be provided by an implementation, for the appropriate class
of applications. By pointing at the appropriate base standards and
choosing options, we can clearly define the requirements of a class of
real-time or multi-processing applications. It is unclear whether the
base standards are POSIX.1, POSIX.4, and POSIX.4a, or some future, as
yet completed ISO/IEC 9945-1:2001.

That's perplexing enough. Now consider the following. POSIX.6
(Security), POSIX.8 (Transparent File Access), POSIX.12 (Protocol
Independent Interfaces), POSIX.15 (Batch), and POSIX.17 (Directory
Services) functions will all be grafted onto POSIX.1, with options, as
they are approved. All of these base API standards, some of which are
nothing more than option-labelled ``diffs'' to POSIX.1 (i.e. POSIX.8),
will somehow be fit together into one BIG book. (And people thought
POSIX.2 was big!)

Remember, all of the function interfaces will need to be provided by
an implementation, even if only as stubs because the ``option'' is not
provided by the implementation. A portable application will spend all
of its start-up time querying sysconf() to determine if the underlying
support is present. Profiles, which strategic management believes will
provide some wonderful shorthand notation to discuss procurement
packages with vendors, will do nothing for the applications developers
actually writing applications.

Application Environment Profiles

I made reference to AEPs defining an environment that must be provided
by an implementation to support an application domain. This is another
source of confusion. Are we specifying an application domain where
the implementation supports far more?  It likely does anyway, but in a
non- standard fashion. Or are we specifying a ``platform''
environment, so it provides a broad base of functionality typically
required by an application domain. I believe this ambiguity lies at
the heart of the ``sub-setting'' problem between POSIX.1 and POSIX.13.

The ``sub-setting'' argument arises because the real-time AEP
(POSIX.13) wants the ability to call out parts of POSIX.1 as options,
(e.g. the file system.) Some people feel this is a horrible idea,
since POSIX.1 specifies a good general purpose base upon which to
build applications. The profile specifiers however don't need the rest
of the standard to describe their application domain. This has been a
constant source of argument and confusion in the POSIX world. What can
a profile point to, and how?

And then there are other specifications, outside of POSIX and TCOS,
that would be obvious to include in certain application domain
profiles. The POSIX.14 Multi-processing AEP would like to point the
X3 parallel language extensions work. The IEEE has no problem with
pointing to other specifications, even incomplete early drafts such is
the case here. It might even be an algorithm in a textbook.

If the point is to define a standards based environment, why would
anyone want a profile standard to point to an indeterminate draft of a
standard which is very unstable, even once it is mature enough to
ballot?  De facto specifications from vendors and vendor consortia
(such as PostScript or OSF/Motif) are more stable than this!

ISO, on the other hand, has very strict rules about what can be
pointed to in a profile. This leads us to another fine source of
information and confusion. Let's look at ISO's contribution.

ISO and the OSI Stack

ISO has a little more experience with profiles, or maybe one should
say longer experience. If I understand things correctly [salt
warning]:

   - The ISO SC21 working groups defined the now famous seven layer
     stack. This was an anticipatory model, telling us how things
     should/would be done in the future, rather than one cluttered by
     implementations.

   - Vendors were somewhat horrified when governments started leaning
     in this well defined, robust direction. They still wanted to be
     able to play in the lucrative government sandbox. They started
     demonstrating how, if you interpret things in one light, their
     product fits the model here, or really fulfills these two layers
     together over there, and so on. The stack mutated a little.

   - The wonderful situation arose, that it was now possible to draw
     an entire path through the stack, top to bottom which wouldn't
     communicate with another line through the stack. People even
     gave this a name: conforming incompatible implementations.

   - The procurement agencies weren't too thrilled by this turn of
     events, and profiles were born. U.S. GOSIP (Government OSI
     Profile) specified a known implementable path through the maze,
     and they used this for procurement specifications to ensure that
     one government OSI installation could communicate with another.

So we now have this concept of a profile. Choose a set of API and
protocol specifications that will work together, to form the OSI
communications models. ISO even developed a document specifying how to
do this. Technical Report 10000 (TR10000, or TR10K) defines a set of
rules for how to define an OSI profile.

TR10K has very strict ideas about how OSI profiles are to be
constructed, what they can point to and how. Profiles can only point
to ISO standards (or other ISO profiles), if they are to have
normative weight. Otherwise, the references are just informative.

Chaos Sets In ...

When the full complexity of this profiling problem began to appear, a
number of different working groups began investigating the problem
from various angles.

The profiling groups within POSIX were identifying problems as they
built their drafts almost from the time they started meeting. The
groups operated fairly autonomously, however, and initially never got
together.

Appeals were made to the POSIX.0 working group for help. The POSIX.0
Guide to Open Systems Environments defines a model for how strategic
management views standards being used, identifies many standards and
where they fit into the model, and even has a couple of chapters on
profiling activities and how they should be done. The POSIX.0 working
group argued, however, that it was not responsible for setting
profiling policy. Go figure.

After much pain and gnashing of teeth by the four POSIX profiling
groups, a TCOS steering committee was formed to help solve the
problems they had been having for about two years at this point. The
group is made up officially of one member from each of the working
groups defining profiles, and a few members of POSIX.0. Really.

The Profiling Steering Committee has been meeting for a year now. They
were immediately lost in a forest of liaison points, and information
gathering, trying to determine what the state of profiling in the
world. Now to my poor naive way of thinking, someone is not doing
their job here. If the POSIX.0 members of the PSC did not already have
all of the profiling documents that could be found, upon what is the
profiling material in POSIX.0 based?  Conversely, if they did have the
profiling information and experience, then why has it taken a year to
define a set of rules by which IEEE POSIX working groups should be
defining profiles?

And even with a Profiling Steering Committee, they were so busy
investigating what everyone else was doing, no one noticed that the
POSIX.13 Real-time profiles were in ballot. Takes your breath away.

On the ISO front, things aren't much better. True to their
anticipatory nature of late, a few different groups have been formed
to investigate and comment upon something which doesn't yet exist.
Technical Specification Group 1 (TSG1) has taken a kick at the cat.

The Special Group on Functional Specifications (SGFS) is also giving
it a try. SGFS is attempting to take the TR10K document and modify it
in a couple of places so as to make it applicable to the functional
API standards, such as POSIX.

The European Workshop on Open Systems (EWOS), a CEN/CENELEC sponsored
body, has set-up a working group to investigate a Common Application
Environment (CAE). This work may be the most pertinent to date.
There are people in this working group that have actually spent time
attempting to specify real profiles in the commercial world. X/Open
is involved in the work, lending its experience with defining
specifications such as XPG3.

The EWOS work attempts to define a method of investigating the user
requirements, building up the definitions and interfaces
(informational rather than actual programming interfaces), and only as
the very last step investigating how standards might be applied to the
requirements model.

I was careful in the last paragraph to not say what type of profile
was being defined. There is still a lot of discussion with respect to
what is an application environment profile, versus a platform
environment profile, and there is even a new concept of a component
profile. There is grey, and then there are shades of grey.

Wrap Up

> GET SENSE
I SEE NO SENSE HERE.
> XYZZY
XYZZY DOES NOT WORK HERE.
> DROP THE BIRD

Where do we go from here?

Profiles are poorly defined specifications (despite the many attempts
at writing rules for their creation,) based for the most part on
unstable documents in ballot, and there is no real experience at
defining and implementing formal profiles in the open systems world.
(The OSI profiles appear to be a well defined, well structured set of
specifications which developed after there was experience with the
stack - not before.)

Why do people feel that these documents should be standards?  Why
build castles on foundations of sand?  We do NOT know what shape some
of the key standards will be in, until they finish ballot. Simply
pointing to an interim draft of a document in ballot, (even if the
IEEE is willing to archive the draft,) is silly.

The point is to specify an environment (application specific or not)
which applications developers can count on. These environment
specifications are supposed to be standards based. That's the whole
point!  The draft documents in ballot will change. Saying we'll modify
the profile standard later, when the base documents complete ballot is
naive!  People will have used it in procurements. Applications will
have been written. What if the functionality in the base standard is
gone? Or mutated so as to be useless to the profile? What's the rush
for a useless standard?

There is the desire to specify how a set of standards can be used
together to define a known environment to solve a set of applications
portability problems. The simple extremes of a single standard profile
(FIPS PUB 151-1), or a suite of specifications (X/Open's Portability
Guide), have proven to be useful. It is useful for people to put down
on paper the definition of a set of requirements for a particular
applications domain, as is described by documents like the EWOS CAE
working group's work. This should be done in a less formal way.

The Paul Masson Method should be applied. (We will define no standard
before its time.) Make the profiling work either ``guidelines'' or
``recommended practices'' at the IEEE level, or ``technical reports''
at the ISO level. Until people have REAL experience putting these
complex, subtle API definitions together with appropriate other
functional and language standards, many of which are still in ballot or
under definition, profiles should not be given the weight of full
standards.

If you're an application developer, get involved. Follow the POSIX
mailings. Determine what your national standards organisation is
doing. Ask questions, or make yourself heard through your
institutional representatives to POSIX. (USENIX, EurOpen, Uniforum,
DECUS, CUG, and SHARE are all represented in IEEE TCOS. X/Open, Unix
International, and the OSF are also present.)

Before some strategic thinking manager above you makes the decision
for you, you should fully appreciate the enormity of the confusion
being unleashed on you as you quietly contemplate that POSIX.1 and
ANSI C are probably useful afterall.

Volume-Number: Volume 28, Number 31