Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/Updates/17.mm

Text File | 1991-03-27 | 15KB | 392 lines

.\" Uses -mm macros
.ds Rh P1003.17 - Name Space/Directory Services (plus 1224/1224.1 Object Management)
.ds Au Mark Hazzard <[e-mail]>
.ds Dt January 7-11, 1991
.ds Lo New Orleans, LA
.ds Ed Jeffrey S. Haemer <[e-mail]>
.ds Wd U\s-3SENIX\s0 Standards Watchdog Committee
.if '\*(Su'' \{\
.ds Su the \*(Dt meeting in \*(Lo:
.\}
.if n \{\
.tm Subject: Standards Update, \*(Rh
.tm From: \*(Ed
.tm Reply-To: [e-mail]
.tm Organization: \*(Wd
.tm
.\}
.S 12
.TL
An Update on U\s-3NIX\s0\u\s-41\s0\d-Related Standards Activities
.FS 1.
UNIX\u\(rg\d is a Registered Trademark of UNIX System Laboratories
in the United States and other countries.
.FE
.nr :p 1
.sp
\*(Rh
.AF "\*(Ed, Report Editor"
.AU "\*(Wd"
.MT 4
.if n \{\
.nh
.na
.\}
.PF "'\*(DT Standards Update'     '\Objects'"
\*(DT
.P
[Editor's note:
``Object'' and ``objection'' have the same root word.
What follows are three distinct viewpoints
on \s-1TCOS\s0'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.]
.P
\fB\*(Au\fP reports on \*(Su
.HU "Introduction"
New Orleans was busy for the P1003.17 \(em Name Space/Directory Services group.
It was our first meeting as an ``official'' \s-1POSIX\s0 ``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.
.P
As I stated last time,
our group is currently in the process of ``\s-1POSIX\s0izing'' \s-1XDS\s0.
This means reworking \s-1XDS\s0
to conform to \s-1POSIX\s0 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 ``\fIvery\fP preliminary pre-draft,''
and is intended to be a baseline from which a working draft can be built.
.HU "Language Independent Specification"
A good deal of time was spent on \s-1LIS\s0 issues,
both in our working sessions
and in the joint working sessions with P1224
on common Object Management \s-1API\s0 issues.
We were able to produce complete \s-1LIS\s0s
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,
\s-1XOM\s0 (Object Management)
and \s-1XDS\s0 (Directory Services),
are required to form a single \s-1API\s0 to directory services.
X\s-1OM\s0 is also used by the \s-1API\s0 to X.400.
.HU "Test Assertions
Several group members had a bunch of fun
finding out how to write test assertions for the C-language binding
of our \s-1API\s0.
We even got together with some P1224 folks,
and worked on \s-1TA\s0s for \s-1OM\s0.
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 \s-1TA\s0s
is not an well-understood art,
and what everyone seems to be doing
is looking at what everyone else is doing.
.P
Where do \s-1TA\s0s 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 \s+2LARGE\s0 customers,
like the \s-1U.S.\s0 Government
Everyone else (users)
just wants to buy documentation on a certified \s-1API\s0.
We wanted to make it \fIreally\fP easy for the \s-1IEEE\s0 to print
``with'' and ``without'' versions of the standard.
.HU "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
(\s-1PAR\s0)
for our common \s-1OM API\s0,
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 \s-1IEEE\s0 \s-1PAR\s0dom:
``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.
.P
Flush with success,
the group decided to tackle the Scope section of the \s-1PAR\s0,
which probably constitutes its only real ``meat.''
After considerable debate the group came up with these three sentences:
.sp
.in +5
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.
.in -5
.P
The words did not come without a little pain.
The base document (\s-1XOM\s0) was produced with specific targets in mind,
namely the \s-1ASN\s0.1-encoded objects and attributes
defined in the \s-1XDS\s0 and X.400 specifications.
It defines an \s-1API\s0
for manipulation of those objects across the \s-1API\s0,
but doesn't define the objects themselves.
The object definitions are provided in the ``primary'' standard
(either \s-1XDS\s0 or X.400)
in a set of \s-1ASN\s0.1 constructs called a ``package.''
.P
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 \s-1API\s0 (package)
and have been hard-wired into the object manager.
.P
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.
.P
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 \s-1XDS\s0 or X.400 \s-1API\s0s 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 \s-1API\s0s
that depended on it.
.P
Getting back to the \s-1PAR\s0.
The group agreed
that the words in the scope addressed the immediate issue
of getting an \s-1OM\s0 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.
.P
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.
.P
In any case,
the \s-1OM PAR\s0 was blessed by the Distributed Services Steering Committee
and was forwarded to the \s-1TCOS\s0 \s-1SEC\s0 for further scrutiny.
.HU "Summary"
So,
that's a peek at what's going on in \s-1P1003.17\s0.
We can expect more of the same next time.
We'll review our progress on \s-1LIS\s0,
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 \s-1API\s0 to object management.
Maybe we'll see you in Chicago.
.sp 2
.P
.ds Au "Scott Guthery <[e-mail]>
\fB\*(Au\fP reports on \*(Su
.HU "Here Come the Objects"
.P
X.400 (P1224) and Directory Services (P1003.17)
have as their base documents \s-1X/O\s0pen documents,
which in turn share an \s-1X/O\s0pen Object Management specification.
At the just-concluded New Orleans \s-1POSIX\s0 meeting
a Project Authorization Request (\s-1PAR\s0)
for a \s-1POSIX\s0 Object Management standard was formulated.
Here is the scope of the \s-1PAR\s0:
.P
.in +5
The standard will define
an \s-1ASN\s0.1 Object Management (\s-1OM\s0) Application Program Interface
(\s-1API\s0)
for use in conjunction with but otherwise independent of
the X.400 and Directory Service (\s-1DS\s0) \s-1API\s0's,
which are currently being standardized.
An application must be able to link and use
multiple implementations of this \s-1API\s0.
This standard will provide language independent specification
and ``C'' language bindings.
.in -5
.P
``What does that mean?''
you may ask yourself.
Based on discussions during the formation of this \s-1PAR\s0
this is my understanding:
.P
The first sentence means that
object classes will be hard-wired into the \s-1OM\s0
and that the object managers being considered
will only instantiate X.400 and \s-1DS\s0 classes.
Further,
only vendors of standard-conforming software
will be able to add classes to the \s-1OM\s0;
there will be no provision on the standard interface for doing so.
Finally,
an \s-1OM\s0 will manage only instances of classes (objects)
that are hard-wired into itself.
Not surprisingly,
this requires the second sentence.
.P
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 \s-1ASN\s0.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.
.P
The third sentence is boilerplate.
.P
A couple of things bother me about this agenda.
First, I don't like to see classes of users
\(em 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)
\(em institutionalized in a standard.
.P
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).
.P
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?
.P
\&``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 \s-1RS\s0232) 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.
.P
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 \s-1PAR\s0.
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.
.P
As they say in Norway,
there's owls in the bushes.
.sp 2
.P
.ds Au Enzo Signore <[e-mail]>
\fB\*(Au\fP reports on \*(Su
.P
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.
.P
Since a package is another way of representing a protocol
(a set of \s-1ASN\s0.1 productions)
the addition of another package to the \s-1API\s0
or the addition of new classes to the provided \s-1API\s0
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 \s-1ASN\s0.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 \s-1OM\s0 representation of an object,
even though it follows the \s-1ASN\s0.1 skeleton,
does not allow the service to generate a unique \s-1ASN\s0.1 production.
Said in different words,
even if the client application defines a new object class
with some attributes
(lets say of primitive types
\(em booleans, integers, etc.)
the sole object table does not allow the service to generate \s-1ASN\s0.1,
since all the context-specific tags and
the notion of \s-1SEQ\s0 vs \s-1SET\s0 are missing.
.P
Therefore, designing such a new interface will:
.P
.AL
.LI
prove wrong when the protocol cannot be extended
.LI
be excessively complex to define because of \s-1OM\s0 design
.LI
require overly sophisticated machinery in the service to
be able to deal with generic and extensible object definitions.
.LE