re:extending existing object classes vs deriving new classes

"peter (p.w.) whittaker" <pww@bnr.ca> Wed, 22 February 1995 21:56 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01319; 22 Feb 95 16:56 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01315; 22 Feb 95 16:56 EST
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa15610; 22 Feb 95 16:56 EST
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.00779-0@haig.cs.ucl.ac.uk>; Wed, 22 Feb 1995 20:39:43 +0000
Received: from x400gate.bnr.ca by bells.cs.ucl.ac.uk with Internet SMTP id <g.18278-0@bells.cs.ucl.ac.uk>; Wed, 22 Feb 1995 20:39:26 +0000
X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 22 Feb 1995 15:37:27 -0500
X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 22 Feb 1995 15:36:07 -0500
X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 22 Feb 1995 11:14:00 -0500
Date: Wed, 22 Feb 1995 11:14:00 -0500
X400-Originator: /dd.id=1660747/g=peter/i=pw/s=whittaker/@bnr.ca
X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; bcars735.b.497:22.01.95.20.36.07]
X400-Content-Type: P2-1984 (2)
Content-Identifier: re:extending ...
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "peter (p.w.) whittaker" <pww@bnr.ca>
X-Orig-Sender: "peter (p.w.) whittaker" <pww@bnr.ca>
Message-ID: <"19499 Wed Feb 22 15:36:12 1995"@bnr.ca>
To: lpc@sware.com
Cc: osi-ds@cs.ucl.ac.uk
Subject: re:extending existing object classes vs deriving new classes

In message "extending existing object classes vs deriving new classes", 
'luis' writes:
>We are defining a new X.500 schema that among other things will
>include unix administration support.  We still haven't decided about
>the DSA implementation, that is, we still have the option to implement
>our own DSA which could have our view of the directory schema. Of
>course, whatever we do will be X.500 compliant.
>
>While discussing the information that we would need to store/retrieve
>in the directory, we have hit an impasse in deciding if we should
>extend standard object classes with new attributes or derive new
>objects from the standard object classes.

Luis, the problem is not publication of object classes:  it is
publication of attribute types and syntaxes.  To put it very glibly (and
mostly correctly, see below), other DUAs and DSAs don't care how you get
an attribute into an entry:  they care about the attribute's definition
and syntax.

To put it little more completely....

You actually have three problems:

    A) defining new attribute types with appropriate syntaxes to hold
    the data of interest to you

    B) entering these into your Directory schema 

    C) making these known to "other" DUAs

When it comes to (A), you'll have to decide what information is of use
to you, how it will be used, whether existing standard (X.500) or
published pilot (i.e.  Internet pilot) attribute types will satisfy your
needs, define syntaxes, etc.  Once you've done that, move on to (B)....

Your particular question, (B), is the easy part.  I'll take the liberty
of rephrasing the question:  "how do I tell my DSAs that my attribute types
are allowed in certain types of entries in my DIT?".  There are two
choices:

    1) auxiliary object classes:  define a new object class for each
    set of attributes of interest to you;  when configuring your DSA,
    add the appropriate auxiliary OCs to the each entry:  this will permit
    each entry to receive the desired attribute types.

    B) 1993 content rules:  define contect rules which apply to appropriate
    DIT entries which specify that these entries may contain (or must contain)
    the attribute types of interest.

(1) is easier, partly because 1993 implementations are still rare, mostly
because it is easier to write the ASN.1 for a new object class than for
a new content rule (not much, but a little).

As mentioned above, other DSAs and DUAs don't care how you define your
schema in order to add the relevant attributes to your DIT entries.  The
reason for this is that DUAs and other DSAs accessing your DIT access
attributes within each entry, and generally do not work with object
classes (save perhaps as filters) or with content rules:  your DSA is
the one responsible for managing schema in your portion of the DIT, and
is the only DSA which cares how you manage your schema.

(This is only untrue when replicating information, in which case you'll
have to replicate your schema management system; in the case of (B),
content rules, the DISP and DOP may take care of this automatically by
replicating the appropriate administrative subentry information, I'd
have to check the docs; in the case of (1), the fact that replicated
entries have auxiliary object classes will be replicated along with the
rest of the replicated entries:  you'll have to communicate the
auxiliary object class definitions to the remote DSA administrator when
you discuss your replication agreement.)

The tricky part is (C):  publishing your attribute definitions.  This is
the part that interests you the most, and the part with which I can be
least helpful (I can tell you that 1988 systems will have to obtain your
defitions in an out-of-band manner requiring human intervention;  1993
systems may have to do so, or they may be able to use the 1993 schema
publication mechanisms:  this is left as an exercise for the reader :->).

>Does anybody know about any other sources that talk about the
>new extensions to X.500 (1993) for schema support other than
>the X.500 document itself or Sara Radicati's X.500 book?

I heartily recommend

    X.500:  Understanding the Directory
    Author: David Chadwick
    ISBN 0 412 43020 7
    Publisher: Chapman & Hall

pww

Peter Whittaker      [~~~~~~~~~~~~~~~~~~~~~~~~~~]   X.500 DS Specialist
pww@entrust.com      [                          ]   NT Secure Networks
Ph: +1 613 765 2064  [                          ]   P.O. Box 3511, Station C
FAX:+1 613 765 3520  [__________________________]   Ottawa, Canada, K1Y 4H7