Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.23/text0020.txt

Text File | 1991-06-15 | 13.7 KB | 279 lines

Submitted-by: [e-mail] (Peter Collinson)

An Update on UNIX-Related Standards Activities

P1003.17 - Name Space/Directory Services (plus 1224/1224.1 Object Management)

USENIX Standards Watchdog Committee
Jeffrey S. Haemer <[e-mail]>, Report Editor


March 26, 1991

[Editor's note: ``Object'' and ``objection'' have the same root word.
What follows are three distinct viewpoints on TCOS's object-management
activities.  The first is Mark Hazzard's overview of 1003.17, The
second is Scott Guthery's critique of the object management work,
currently being jointly done by 1003.17 and 1224, the third is Enzo
Signore's rebuttal of Scott's position.  After you read them, you
might want to let the committees, know how you feel, either directly,
or through Peter Collinson, the new Usenix Institutional
Representative.]

Mark Hazzard <[e-mail]> reports on the January 7-11, 1991
meeting in New Orleans, LA:

Introduction

New Orleans was busy for the P1003.17 - Name Space/Directory Services
group.  It was our first meeting as an ``official'' POSIX ``dot''
working group, and seemed to build on the momentum gained in the
previous meeting.  A good turnout from the old ``core'' group, coupled
with the infusion of ``new blood'' from the x/Open base-document
development team, seemed to provide the right chemistry for some
dynamic interchange and good solid progress.

As I stated last time, our group is currently in the process of
``POSIXizing'' XDS.  This means reworking XDS to conform to POSIX
style, content, and format requirements.  Much of this is busy-work,
that falls largely on the shoulders of our (overworked) Technical
Editor.  A first cut at the new format will be included with the first
mailings.  It can be best characterized as a ``very preliminary
pre-draft,'' and is intended to be a baseline from which a working
draft can be built.

Language Independent Specification

A good deal of time was spent on LIS issues, both in our working
sessions and in the joint working sessions with P1224 on common Object
Management API issues.  We were able to produce complete LISs for
several functions and their data types, by building on the homework
done by group members between meeting cycles.  Readers may want to
review the complicated discussion from last time on how and why two
specifications, XOM (Object Management) and XDS (Directory Services),
are required to form a single API to directory services.  XOM is also
used by the API to X.400.

Test Assertions

Several group members had a bunch of fun finding out how to write test
assertions for the C-language binding of our API.  We even got together
with some P1224 folks, and worked on TAs for OM.  We managed to write a
few assertions and uncover some issues along the way.  We also agreed
to use identical conventions in .17 and P1224.  During the process, we
discovered that writing TAs is not an well-understood art, and what
everyone seems to be doing is looking at what everyone else is doing.

Where do TAs go?  They could be included with the function
specification (possibly less work) or lumped together into a separate
chapter or annex (possibly more work).  We've opted for the lump.  The
rationale for this seemingly irrational decision is documentation page
count ($$$).  We figured that the only people who really care about
test assertions (besides us standards types) are vendors, test suite
writers, certification labs, and a few LARGE customers, like the U.S.
Government Everyone else (users) just wants to buy documentation on a
certified API.  We wanted to make it really easy for the IEEE to print
``with'' and ``without'' versions of the standard.

Object Management

``Object'' and ``management'' are two intensely overloaded words.  Used
together, the two can instill fear in even the most seasoned hack.
While conjuring up a name to put on the Project Authorization Request
(PAR) for our common OM API, the combined talent of the .17 and 1224
groups decided that the best defense was a good offense and selected
what may be the most offensive project title in the history of IEEE
PARdom: ``Standard for Common ASN.1 Object Management API for X.400 and
Directory Services APIs.'' If approved, it should get a number like
P1224.1 or something like that.

Flush with success, the group decided to tackle the Scope section of the
PAR, which probably constitutes its only real ``meat.'' After
considerable debate the group came up with these three sentences:

     The standard will define an ASN.1 Object Management (OM)
     Application Program Interface (API) for use with, but otherwise
     independent of, the X.400 and Directory Service (DS) API's, which
     are currently being standardized.  An application must be able to
     link and use multiple implementations of this API.  This standard
     will provide language independent specification and ``C'' language
     bindings.

The words did not come without a little pain.  The base document (XOM)
was produced with specific targets in mind, namely the ASN.1-encoded
objects and attributes defined in the XDS and X.400 specifications.  It
defines an API for manipulation of those objects across the API, but
doesn't define the objects themselves.  The object definitions are
provided in the ``primary'' standard (either XDS or X.400) in a set of
ASN.1 constructs called a ``package.''

In an accompanying article, Scott Guthery, a group member from the user
community, expresses concern that there is no mechanism in the base
document for extending existing objects or adding new ones.  This is
because the object definitions are well-defined within the context of
their API (package) and have been hard-wired into the object manager.

Vendors can provide value added to extensions their products, but users
cannot.  Further, a user who purchases a product from one vendor that
uses a (non-standard) extended package will have no guarantee that it
will work with an object manager from another vendor.  With the ability
to modify or create new packages in a standardized way, these problems
could be avoided.

Counter-arguments primarily addressed practical limitations to the
scope, and the technical infeasibility of dynamically altering packages
(which are really protocols).  See Enzo Signore's accompanying article
for a brief summary.  The ability to extend an object package is not
required for basic interoperability or portability for XDS or X.400 APIs
as currently specified.  A general-purpose, user-extensible object
management facility may be useful, but might be technically infeasible
(or at least very difficult).  It would almost certainly delay
acceptance of APIs that depended on it.

Getting back to the PAR.  The group agreed that the words in the scope
addressed the immediate issue of getting an OM specification out so that
P1003.17 and P1224 could continue.  At the same time, the scope doesn't
shut the door on a more general-purpose object manager, if it's deemed
necessary and do-able.

I expect this will get sorted out after our next meeting in Chicago, but
if this continues to be an area of high controversy, you'll see the
topic resurface in my future reports.

In any case, the OM PAR was blessed by the Distributed Services Steering
Committee and was forwarded to the TCOS SEC for further scrutiny.

Summary

So, that's a peek at what's going on in P1003.17.  We can expect more of
the same next time.  We'll review our progress on LIS, probably do more
test assertions, and generally begin to add some flesh to the document
skeleton.  We plan to meet with P1224 for a day to continue our co-
development effort on common API to object management.  Maybe we'll see
you in Chicago.

------------------------------------------------------
Scott Guthery <[e-mail]> reports on the January 7-11, 1991
meeting in New Orleans, LA:

Here Come the Objects

X.400 (P1224) and Directory Services (P1003.17) have as their base
documents X/Open documents, which in turn share an X/Open Object
Management specification.  At the just-concluded New Orleans POSIX
meeting a Project Authorization Request (PAR) for a POSIX Object
Management standard was formulated.  Here is the scope of the PAR:

     The standard will define an ASN.1 Object Management (OM)
     Application Program Interface (API) for use in conjunction with but
     otherwise independent of the X.400 and Directory Service (DS)
     API's, which are currently being standardized.  An application must
     be able to link and use multiple implementations of this API.  This
     standard will provide language independent specification and ``C''
     language bindings.

``What does that mean?'' you may ask yourself.  Based on discussions
during the formation of this PAR this is my understanding:

The first sentence means that object classes will be hard-wired into the
OM and that the object managers being considered will only instantiate
X.400 and DS classes.  Further, only vendors of standard-conforming
software will be able to add classes to the OM; there will be no
provision on the standard interface for doing so.  Finally, an OM will
manage only instances of classes (objects) that are hard-wired into
itself.  Not surprisingly, this requires the second sentence.

The second sentence means that while the vendors are willing to agree on
the interface they are not prepared to agree on standards for objects
themselves (even though they are all ASN.1-based).  That is, vendor A's
objects cannot be managed by vendor B's object manager and vice-versa.
Objects themselves, as manipulated by the object manager, are to be
proprietary.  This is primarily because many of the vendors have already
written object management software and the software that uses it, and
are primarily interested in formulating a standard to which they can,
after-the-fact, claim conformance.

The third sentence is boilerplate.

A couple of things bother me about this agenda.  First, I don't like to
see classes of users - privileged vendors who can define new classes
vs.  unwashed end-users who can only use what they're given (or, more
properly what they buy) - institutionalized in a standard.

Second, and really more bothersome because I suspect the first one will
work itself out naturally, is the ``requirement'' for multiple,
concurrently executing but not interoperating standard-conforming
subsystems.  My belief is that we should talk this one out carefully,
make darn sure we all know exactly what we are talking about, insure we
are talking about the same thing and convince ourselves it's something
we want to enshrine in a standard (whew).

Isn't one purpose of a standard interoperation?  If interoperation is
left as an impedance-matching exercise for the user is there really a
useful standard in play at all even if the user can use a single
interface on which to do the required impedance-matching?  Might the
jaundiced eye view this as a truck-sized hole through which vendors can
drive claims to standard-compliance while exhibiting little-to-no
effective standard-conformance behavior?

``Link and use multiple implementations'' isn't good enough.  Indeed,
it's a bad idea.  To me, it's analogous to a hardware standard (like
RS232) specifying little more than that implementations "use blue
wires." I have to string a different set of blue wire for each vendor
whose devices I purchase.  And, what's worse, it's up to me to somehow
get the information off one vendor's wires and onto another vendor's
wires if I want the two vendors' devices to cooperate.  The standard
says something like ``You get the information out at the end, which
shall have 1/2 inch of bare wire.'' Frankly, being able to buy blue
wire in bulk is little consolation for the trouble that I have to go
to to make the whole mess work.

Of course, what I'm being invited to do is buy devices from only one
vendor, which is, I suspect, exactly what the vendors had in mind when
they put that ``requirement'' in the PAR.  As an historical note, the
second sentence originally started off ``Users require that ...'' until
one of the few users around the table pointed out that single-source
and vendor lock-in was not high on his list of requirements at all and
expressed surprise that the standards process was or could be used to
encourage it.

As they say in Norway, there's owls in the bushes.

---------------------------------------------------------------------

Enzo Signore <[e-mail]> reports on the January 7-11, 1991
meeting in New Orleans, LA:

Scott Guthery doesn't like the proposed 1003.17/1224 approach to Object
Management.  I do.  Here's a summary of why I think Scott's objections
miss the mark.

Since a package is another way of representing a protocol (a set of
ASN.1 productions) the addition of another package to the API or the
addition of new classes to the provided API implies defining extensions
to the protocol.  Aside from the feasibility of doing so, it would
require the underlying service to be able to interpret the additional
ASN.1 properly and to be able to encode and decode it.  Unfortunately,
it is not possible to do so in an implementation-independent way, since
the OM representation of an object, even though it follows the ASN.1
skeleton, does not allow the service to generate a unique ASN.1
production.  Said in different words, even if the client application
defines a new object class with some attributes (lets say of primitive
types - booleans, integers, etc.) the sole object table does not allow
the service to generate ASN.1, since all the context-specific tags and
the notion of SEQ vs SET are missing.

Therefore, designing such a new interface will:

  1.  prove wrong when the protocol cannot be extended

  2.  be excessively complex to define because of OM design

  3.  require overly sophisticated machinery in the service to be able
      to deal with generic and extensible object definitions.



Volume-Number: Volume 23, Number 21