Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.15/text0003.txt

Internet Message Format | 1989-01-17 | 22.6 KB

From: Shane P. McCarron <[e-mail]>

[ This report was commissioned by the USENIX Association.  -mod ]

           An update on UNIX Standards Activities

                       August 1, 1988

           Shane P. McCarron, NAPS International

This is the third in a series of reports on standards bodies
relating to the Unix community.  Before I start, I would
like to take a couple lines to thank all of those readers
who were kind enough to drop me a line of either criticism
or encouragement; both are greatly appreciated.  In the
future please feel free not only to comment on the articles
here, but also on standards issues.  I am more than happy to
try and answer any of your questions either individually or
through this column.

To business: the most important item to report (from my
perspective) is that the Usenix Association has formed a
Standards Watchdog Committee.  The charter of this group is
to keep an eye on as many of the standards efforts as
possible, and report the progress of those efforts back to
the membership.  In addition, the group will be looking for
important or contentious decisions, and trying to determine
a Usenix position where it seems appropriate.  The group
will also be looking to you, the members, for input.
Everyone has opinions, and the Watchdog Committee, through
its standards committee representatives, can serve as a
channel to get your ideas to the appropriate groups or can
put you in contact with the appropriate people.  For more
information, please contact:

          John S. Quarterman
          Texas Internet Consulting
          701 Brazos, Suite 500
          Austin, TX  78701
          [phone]
          [e-mail], uunet!usenix!jsq

As always, the standards bodies have been pretty busy during
the  past  quarter.  Busy, that is, in standards body terms.
There is often a great deal of heat, but very little  light.
I have remarked in the past that these committees can take a
long time to complete things.  In some future issue, maybe I
will  take  a few inches and sketch out how a full standards
working group meeting really goes :-).  Not this time though
- there is too much real news to get to:

P1003.0 - The POSIX Open Systems Environment Guide

The IEEE 1003.0 working group met on July 12 & 13,  1988  in
Denver,  Colorado.   The purpose of this meeting was to have


                           - 2 -

the group members, who  had  volunteered  during  the  March
meeting  to  work  on  certain  portions (sub-groups) of the
POSIX Open Systems Environment guide document, present their
material  for  review  and  critique  by the group. This was
accomplished on day 1 and the morning of  day  2.  The  sub-
groups that were discussed included:

       1.  Operating System

       2.  Database Management

       3.  Data Interchange

       4.  Network Services

       5.  User Interface

       6.  Languages

       7.  Graphics

The remainder of the meeting focused on goals and objectives
for  the next meeting in October. There was strong consensus
within the group that the next goal should be a  very  rough
draft  document.  Volunteers were assigned to each sub-group
above with the purpose of putting into  narrative  form  the
material  that  had  been presented. It was also agreed that
distribution of this draft  prior  to  the  October  meeting
would  be  essential  in  order  to  allow  for  good,  well
thought-out discussion during the meeting.

The group has targeted October, 1989 as a goal for beginning
the  balloting  process.   This is aggressive, but possible,
assuming that the effort between meetings can be  maintained
at its present level.

Overall, the meeting was very productive and is drawing more
participation  from  a  good  cross-section  of  vendors and
users.

P1003.1

The big news this month is, of course,  that  as  of  August
22nd the POSIX System Services Interface standard is finally
complete.  By the time you read  this  final  drafts  should
have  been  circulated  to  all  of  the POSIX working group
members, and copies of that draft should be  available  from
the IEEE office in New York.  While you can obtain a copy of
the final draft now, you would do well to wait for a  couple
of  months  and  pick  up  a real, hard-bound version of the
standard from the IEEE.  To order a copy of the final draft,


                           - 3 -

contact:

          IEEE Standards Office
          345 E. 47th St.
          New York, NY  10017
          [phone]

Since the  last  installment  in  this  series,  the  1003.1
standard  has  gone  through not one, and not two, but three
more  recirculations.   As  you  may  remember,  the  second
recirculation  was  scheduled  to  take place in May, and it
did.  This one went as well as expected, and generated  some
excellent  feedback.   The  changes  from that recirculation
were assembled and sent back  to  the  balloting  group  for
review   at   the   end  of  June.   As  a  result  of  that
recirculation, there were yet more changes to the  standard,
and  those changes had to be recirculated as well. The final
recirculation took place at the end of July,  and  generated
no  substantial  changes.   At  that  point the standard was
released to the Technical Editor for final copy editing, and
has  now been balloted on and approved by the IEEE Standards
Board!

This is actually good and bad.   It  is  good  for  all  the
reasons  you  would suppose.  It is bad because the standard
is not perfect; there are things that  shouldn't  be  in  it
that  are  (e.g.  some  weird  timezone stuff and read() and
write() functions that allow broken  behavior),  and  things
which  should  be  in  it  but  are  not (like seekdir() and
telldir()).  Even though the standard  is  not  perfect,  at
least  we  now  have  a  foundation  upon  which  additional
documents can be based.  In the future this standard will be
extended  and  revised,  but  for  now  (in combination with
Standard C), it's the best thing  we  have  for  application
portability.

In the mean time, the .1 working group has  not  been  idle.
Although  the initial work on the Services Interace standard
was completed some months ago, there are always new areas to
work in. I gave a detailed description of these new areas in
the April update;  the  following  is  only  information  on
developments where they occured:

Clean Up

There  are  some  issues  that  were  not  handled  to   the
satisfaction  of  the  working group in the first cut of the
standard.  A small group is working on sifting  through  the
unresolved  balloting  objections  (there  were several) and
identifying  those  items  that  can  be  rectified  through
modification to the standard.  It turns out that many of the


                           - 4 -

unresolved objections were very reasonable items,  but  were
introduced  too  late  in  the  process  to be placed in the
standard.  Those items will be looked at and possibly  added
to the standard in a supplement.

Language Independent Description

While little progress has been made in this area by  the  .1
working  group, it turns out that there has been quite a bit
of  work  done  by  other  working  groups   and   technical
committees.    The   /usr/group   technical   committee   on
Supercomputing,  in  particular,  has  produced  a   Fortran
language  description  of  the .1 interface.  In the process
they have come up with a number of items that can be used by
the   .1   people  to  develop  their  language  independent
description.

Terminal Interface Extensions

The  Working  Group  looked  at  the  various   requirements
necessary  for  a  terminal  interface  standard (a terminal
interface standard is something like the Terminal  Interface
Extensions  in  the  SVID,  better know as curses/terminfo).
The group determined that there is little or no way to get a
single interface standard that will satisfy the needs of the
entire community.  Those people with bit mapped displays can
do things better, and we should let them.  Those people with
block mode terminals have special needs that should not have
to  be  addressed by Joe Portable Application.  The majority
of users that we are trying to satisfy, those with character
based  terminals,  have  well defined needs that are already
being addressed by existing practice.

What's the solution?  Well, none was really proposed, but  I
would  guess  that  the  people  in the bit mapped world are
going to care a lot more about Open  Look  and  Presentation
Manager (bite my tongue) than they are about something based
on terminfo or termcap.  For the other  90  percent  of  the
Unix  using  community,  while  terminfo/termcap may be what
they are used to seeing, it is hardly attractive  enough  to
make  them  sit  up  and  take notice.  They are looking for
flashier, better, faster applications, and  the  traditional
interface  is  not  going  to  be  enough.   For application
developers, the functionality  which  can  be  achieved  via
terminfo  is  fine  but  hardly  adequate  for  building the
products that the user community is coming to expect.

I would guess that the POSIX committees will settle on  some
subset  of  the terminfo interface as the standard, and that
no one will use  it.   Sure,  it  will  be  on  every  POSIX
conformant  system,  but who cares?  It is a lame interface,


                           - 5 -

and someone will come up with a better one soon enough.

New Archive Format

As I mentioned previously, the ISO has asked P1003.1 to come
up  with  a  new  archive  format  that  will  not  have the
deficiencies of tar or cpio and will be  able  to  take  the
security concerns of the P1003.6 group into consideration (I
assume  that  by  this  they  mean  access  control   lists,
mandatory  access  controls, and the like).  Little was done
on this topic between meetings, but at the July meeting  the
committee  discussed  ways to extend the cpio archive format
to  take  these  things  into  consideration.    While   the
technical details of this extension are clear, they are also
boring.  Suffice it to say that the filename  field  in  the
archive  can  be extended through a kludge and that it would
be backward compatible.

This met with mixed reactions, and I believe that in the end
it  will  not  be used.  This discussion (popularly known as
Tar Wars) has been very religious  and  contentious,  and  I
don't  think  that  a format based on either will be able to
get popular support from the working group.  There is now  a
small  group  of people (from both camps) working on another
new format, and I am certain that they  will  come  up  with
something for the October meeting.

P1003.2 - Shell and Tools Interface

This group is actually  a  little  bit  ahead  of  schedule.
Forget all the nasty things I have said about their schedule
being too tight and optimistic - they are actually going  to
do  it!   You're not as impressed as I am, I can tell.  Some
people are just never satisfied.  Okay, here's some evidence
for you:

Functionality was frozen at the March meeting.   This  means
that  no  additional  commands or concepts could be added to
the standard.  It also means that the working group  members
were  free  to  concentrate  on  the  content  of the draft,
instead of looking at new proposals for additional  commands
all of the time.  This has turned out to be very profitable;
the draft has been cleaned up to the point where it  can  be
submitted  (to  the  working and corresponding groups) for a
mock ballot in September.  A mock ballot is just  that  -  a
process  during  which the draft is picked apart as it would
be in the balloting process, with changes submitted  through
formal   balloting  objections.   This  may  seem  a  little
excessive, but it has proven effective in the past.


                           - 6 -

Assuming that all goes well, and  the  objections  from  the
mock  ballot  are resolved at the October meeting, the group
could go to a full ballot  as  early  as  January.   A  less
optimistic scenario shows the group working on resolution of
the mock ballot for two full meetings, with the real  ballot
occuring  in February or March.  Either way, the group is on
schedule for a full use standard before the end of 1989.

In addition  to  this  good  news,  there  were  a  few  key
decisions made at the July meeting:

This side of the Tar Wars is apparently at  an  end.   There
were  two  aspects  to  the war - user/program interface and
actual archive format.
 The interface side of it seems to have been settled by  the
introduction  of  a command called pax (latin for peace :-).
This command will be able to read and write  both  types  of
archives  and  has  an  interface that is acceptable to both
camps.  While this has not been agreed upon by the balloting
group,  or  even by the full working group, the interface is
pretty familiar, and I believe  it  will  be  approved  with
little change.

The group also concentrated on  trying  to  remove  anything
that  might  be considered implementation dependent from the
draft.  This included removing the octal modes  from  chmod,
and  the  signal numbers from trap and kill.  In their place
go all of the mnemonic command line arguments that have been
in  those commands all along, but aren't used by anyone.  As
a committee member I can see what they are trying to do, and
even  agree  with it.  As a user, however, I wish they would
have placed requirements that, say, kill -9 would always map
to  SIGKILL.  At least that way I wouldn't have to fix every
shell script I have ever written.

P1003.3 - Testing and Verification

This working group is progressing well on their verification
standard for 1003.1.  They are planning to have a version to
ballot in January or February of 1989.  That would make  the
standard  available  just  about  the  time  that  the major
vendors are finishing their .1 conformant implementations.

The group has also started supplying liason people  to  each
of  the  other  working  groups.   These  people, with their
experience writing a testing standard for  .1,  are  proving
very valuable in designing testable standards.

New POSIX Work Items


                           - 7 -

In addition to all of the committees you have heard about in
past   articles,  there  were  several  new  working  groups
proposed to the P1003 steering committee:

System Administration

The committee recognizes the need for a  standard  interface
to  many  of the system administration utilities that we are
plagued with.  While there  was  a  considerable  amount  of
skepticism   exhibited   from   the  members,  the  steering
committee has agreed to let work  progress  on  this  topic.
Consequently,  a  PAR was filed by Steve Carter of Bellcore,
and the new working group will start meeting in October.

This  group  has  a  lot  of  work  ahead  of   them;    The
difficulties of designing standard interfaces to things like
fsck and fsdb may prove impossible.  Also,  from  an  system
implementor   standpoint,   I   would   hate   to  have  the
administrative functions I can provide limited by  something
that  a  standards  committee  is going to generate based on
existing practice.  This is not an area in which there is  a
huge  body  of existing applications, so implementors should
be allowed to innovate and improve if they like.

On the other hand, the  computer  users  of  the  world  are
probably  pretty sick of having to learn a new way to enable
printers on every system they purchase.  For  those  people,
having  a standard is going to be a big win.  This is one of
those times when  the  saying  "be  careful  what  you  wish
for..." comes into play.  The ultimate, generic system admin
interface may prove to be so restricted or  brain-dead  that
it  is of no use to anyone.  The .1 standard was nearly that
way.

Networking

Another new working group will be focusing on  the  services
and  service  interfaces  for  a  networked POSIX conformant
system.  While the exact charter and goals of this group are
not  fully  established,  what they are not trying to do is.
They are not trying to  overlap  the  work  of  the  ISO-OSI
committees,  nor  are they trying to supplant the work being
done by IEEE 802.  Their plan is to spend two years defining
the  services and service protocols, and maybe an additional
year defining interfaces to those protocols.

User Interface Commands

If you have looked closely at the 1003.1 and  .2  standards,
you  will  notice  that  there  is nothing in either of them
about User Interface.  Well, you're not alone,  and  someone


                           - 8 -

is  finally  going to do something about it.  A sub-group of
the Shell and Tools committee has beenformed to  codify  the
interface  of  many  of  the  classic Unix commands (vi, ed,
etc...).  In addition, the group will be defining  the  user
interface  aspects  of  those  commands  already  in  the .2
standard which have traditionally  had  user  interfaces  as
well as their programmatic ones.

This group is going to work somewhat in  a  vacuum  -  since
there  is  no  standard  for  terminal  interface,  the user
interfaces  defined  are  not   going   to   have   a   way,
programmatically, of being put on the screen.  Terminfo will
of  course  work  for  this,  but  it  is  not  a  standard.
Hopefully   the  .1  committee  can  get  a  supplement  out
regarding this before the .2  sub-group  finishes  its  work
describing the utilities.

X/Open

The X/Open group is just about to release version 3  of  the
X/Open Portability Guide.  This set of manuals is a must for
any application developer or system implementor planning  on
marketing  products in Europe.  Version 3 will encompass all
of the .1 standard, but will not contain any  of  the  items
proposed  in  the latest drafts of .2 - that document is too
immature.  The XPG also has language  definitions,  database
interface  specifications,  and  many  other  things  that a
growing programmer needs in the Unix world.

NBS - Federal Information Processing Standard

I have written about this in each issue of this report,  and
each  time  I  say  that it is almost here.  Well, I am done
making predictions.  The federal  government  has  a  shield
that  my  crystal  ball  just  refuses to penetrate.  I have
heard recently that the FIPS for the .1 standard  is  within
the  Commerce  department  somewhere,  but  I have no proof.
When it does finally come out, it will be based on a version
of the standard that is almost a year out of date.  Draft 12
of the .1 standard resembles the final standard about like a
caterpillar   resembles   a   butterfly.    This   is   very
unfortunate, as the vendors that are serious  about  selling
computers  to  the feds are going to have to conform to that
standard, and not the real one.  Note that while the NBS did
try  to  jump  the  gun  a  little  bit,  they forced the .1
committee  to  work  harder  and  faster.    Without   their
encouragement   the   standard  may  well  never  have  been
finished.

Of course, the NBS has indicated that they will start making
the FIPS conform to the final standard just as soon as it is


                           - 9 -

out (now, that means).  But, given the  amount  of  time  it
took  them  to  get the first standard out the door, I'm not
holding my breath.  It could be deep into 1989 before we see
a   revised   FIPS   hit  the  Federal  Register's  list  of
announcements.

In the mean time, the NBS is proceeding in its specification
of  other interim FIPS.  Just until there are real standards
in these areas, of course, we are going to see FIPS on Shell
and  Tools,  User Interface, System Administration, Terminal
Interface Extensions, and probably  shoe  lacing.   The  NBS
people  are  very  busy  cranking out standards that federal
government  departments  can  cite   when   generating   bid
requests.    Unfortunately,   in   those   cases  where  the
committees aren't far enough along yet, these standards  are
going to be based on the SVID.  And if the SVID is used as a
base document by the Feds, you can be sure that it will also
be  used  by  any standards committees that come along later
and  want  to  "codify  existing  practice".   Just  another
example  of  the  Federal  Government  guiding the standards
community.

The NBS is putting on a series of  workshops  this  fall  to
address  some  of  these  issues,  and  get  input  from the
community.  The first  of  these  workshops,  a  seminar  on
"POSIX  and other Application Portability Profile Standards"
will be September 22nd and 23rd.  For more information,  you
should  contact  Debbie Jackson at [phone].  She will
be happy to send you registration materials, as well as give
you  information  about future workshops being put on by the
National Bureau of Standards.

X3J11 - ANSI C Language Standard

This standard is pretty important to everyone  in  the  Unix
community.   Unfortunately,  that means that everyone has to
get involved in the development of it, and that takes  time.
The document has now entered its third public comment period
(July  1st  ->  August  31st).   From  what  I  gather,  the
committee  will  be  very  reluctant  (read  "it  will never
happen") to make any substantive changes to the standard  as
a  result  of  this  period.   What  they are looking for is
affirmation from the public that the changes made  in  round
two   were  adequate  to  remove  most  of  the  outstanding
objections.

The good news here is that the "noalias"  keyword  has  been
removed  from the draft.  This was a very contentious issue,
and was introduced very late in the  process.   In  simplest
terms,  noalias  would  allow the programmer to specify that
the program, for that statement, would do  exactly  what  it


                           - 10 -

was  supposed  to do.  Pretty silly, when you get right down
to it.  Anyway, its gone now - like a bad dream.

In addition, a number of simple editorial changes were made.
Most  of these are transparent, and just made the standard a
little more readable.  Unfortunately, it is still a standard
written  by  programmers,  for  programmers, and is a little
hard to read.  There is even rumor  of  a  x3speak  program,
like  the  valspeak of a few years ago, about to come out in
comp.sources.misc.  This would take any prose and render  it
senseless  through  the  addition of legalese.  My advice to
future readers of the standard is this:  Don't go  into  the
water  alone.   Use  the  buddy  system, and take a readers'
guide with you.

Assuming all goes well at the September meeting, the ANSI  C
Language Standard should be published later this year.

Well, that's about it for this month.  Remember, keep  those
cards and letters coming to:

          Shane P. McCarron
          NAPS International
          117 Mackubin St.
          Suite 6
          St. Paul, MN  55102
          [phone]
          [e-mail]


Volume-Number: Volume 15, Number 4