pc@hillside.co.uk (Peter Collinson) (06/24/91)
Submitted-by: pc@hillside.co.uk (Peter Collinson)
USENIX Standards Watchdog Committee
Stephen R. Walli <stephe@usenix.org>, Report Editor
Report on POSIX.17 - Name Space/Directory Services
Mark Hazzard <markh@rsvl.unisys.com> reports on the meeting
in Chicago, Illinois:
Summary
The POSIX.17 group is generating a user to directory services API, for
example an API to an X.500 Directory User Agent (DUA). We are
referring to a network idea of a directory, not the ``file which
contains file entries'' defined in POSIX.1. It is not limited to just
the X.500 functionality. We are using XAPIA - X/Open's Directory
Services specification (XDS) as a basis for work. XDS is an object
oriented interface and requires a companion specification for object
management (XOM).
XOM is a stand-alone specification with general applicability beyond
the API to directory services. It will be used by IEEE 1224.1 (X.400
API) and possibly other POSIX groups, and is being standardized by
IEEE 1224.
We made significant progress on a third draft of the document in
Chicago, with the language independent specification work still to be
done. We hope to mock ballot the document sometime after the July
working group meeting. POSIX.12 (Protocol Independent Interfaces) and
POSIX.17 worked together this week and arrived at a number of
scenarios for coordinating the work. POSIX.17 is taking steps to
determine if their work overlaps with the proposed work of certain
ISO/SC21 (OSI) working groups.
Status
Commitment within the group remains adequate, but there's more than
enough work to go around.
Chris Harding, our Technical Editor (from X/Open), brought a second
draft of the specification to the meeting. We made significant
progress towards producing a third draft with emphasis on format
cleanup, model, overview sections and test assertions.
The ``homework'' assignments on Language Independent Specification
(LIS) weren't completed and additional work on LIS was put on hold
until the outcome of the SEC meeting. There seemed to be some
confusion as to the applicability of the LIS requirement for POSIX.17
and other Distributed Services APIs. The SEC reaffirmed the LIS
requirement. The LIS work was reassigned to the Technical Editor.
The big debate on generalizing the Object Management API never
materialized. (Refer to the three snitch reports on the New Orleans
1991 meeting.) I strongly suspect this was largely due to the absence
of Scott ``Owls in the bushes'' Guthrey at the Chicago meeting.
Requirements from POSIX.12
The group met with POSIX.12 (Protocol Independent Interfaces) to get
their requirements for the POSIX.17 API. They expressed the desire
(necessity?) to:
- access existing directory services (e.g. DNS) via the
POSIX.17 API
- map the existing BSD API (e.g. gethostbyname,
getservbyname, etc.) onto the POSIX.17 API.
We discussed at length how these and other requirements should best be
met, and produced three different scenarios describing relationships
between the user application, the directory API(s), the directory
service(s) and the transport service (accessed via POSIX.12's
Simplified Network Interface).
In the first scenario, the transport provider (SNI) would talk
directly to all directory services e.g. DNS, X.500, etc. Each
directory service resolver would be accessed through its native
interface, of which POSIX.17 would be just another API.
In scenario two, POSIX.17 would be the only API and would be used to
access all directory services. To access a non- X.500 DUA, the
underlying implementation might have to translate POSIX.17 calls into
the appropriate format and invoke the corresponding resolver.
In the final scenario, POSIX.17 would again be the only API, but only
one resolver (X.500 DUA) would be used to query a single composite
information base (DIB) containing information on all objects (e.g.
DNS Resource Records and X.500 Distinguished Names).
In each of the scenarios, impact to the POSIX.17 API will be minimal.
However, significant impact is anticipated for the underlying
implementation and directory information base.
We discussed the relative merits of each and decided that at some
future time a single API, resolver (agent), directory service and
information base just might be the best for POSIX systems. We also
recognized that POSIX systems will need to interoperate with non-POSIX
systems for the foreseeable future, and that fact won't be lost on
implementors.
Live long and prosper! or Extending the life of our standard
The base document defines both the API and the collection of objects
managed through the API, called a ``package.''
We believe that packages will be much more dynamic than the API
itself, and could be unbundled from the API to give the API greater
stability. We actioned the Distributed Services Steering Committee
(DSSC) to recommend a common solution, as this problem is shared by
other networking groups. We expect the DSSC to take this issue up in
Santa Clara.
Mock Ballot
We decided to try to mock ballot our document sometime after the July
meeting. After reaching agreement on the minimum document content for
mock ballot, we assigned actions to get this work done. We wish to
solicit input on requirements and feedback on our LIS and Test
Assertion work.
Is SC21 doing APIs too?
With the granting of any IEEE project request (PAR) comes a
responsibility to coordinate with other de jure standards bodies, the
list of which is included on the PAR itself. In fulfilling this
obligation, the group has learned (and dutifully reported to the SEC)
that ISO SC21 is considering working on APIs to OSI application level
services. This work has a potential to overlap the SC22 supported work
being done by IEEE TCOS/POSIX (e.g. POSIX.17, P1224, P1238).
In Closing ...
The group made good solid progress in Chicago, and our document is
beginning to ``flesh out.'' We think we understand what's required for
test assertions and language independence, and have done several
things to make the base document more readable. If we can maintain
``critical mass'' within the group, we have a good chance of going to
mock ballot yet this year. There's a lot of work to do, so if anyone
out there can make it to Santa Clara in July ...
Volume-Number: Volume 24, Number 17