Re: Abstract object class

[Erik Skovgaard <eskovgaard@geotrain.com>]

Ed,

I fully agree with you.

I recently worked on a schema for a large bank that required separate
Object Class definitions for customers, employees, partners and
consultants/contractors.  I *could* have managed with a set of Aux. Obj.
Classes and some content rules, but the particular product did not allow me
to specify more than one content rule per Structural Obj. Class per DSA.
The problem got worse when we decided to shadow naming contexts all over
the place.

As I see it, the development is towards a sharing of directory entries
across enterprise boundaries and the need for communicating *all* schema
elements in a standardized fashion will only get more pressing.  With the
growth in PKI deployments out there, it is not just a future requirement,
either.

This is where I think the multi-master replication will meet major
obstacles and I would suggest attacking the single-master problem first.

Cheers,                  ....Erik.
--------------------------------------
Erik Skovgaard
GeoTrain Corp.
Enterprise Directory Engineering
http://www.geotrain.com

At 10:20 98/11/05 -0700, Ed Reed wrote:
>As LDAP becomes distributed, and as the namespaces LDAP servers
>are interconnected, it's obvious that different administrative domains
>will need to manage the schema over their own portion of the namespace
>independently of one another.
>
>It's further clear that servers which hold replicas of namespaces need to 
>be able to handle each of their schemae separately, else we wind up
>with the silly situation that rules today - that schema are server based,
>instead of being aligned with the namespaces to which they apply.
>
>I believe that we must, collectively, resolve to move schema definitions
>into subentries subordinate to naming context roots within the namespace,
>and that NDS, X.500, LDAP, and ADS must all do so.
>
>Note that even within administrative domains (corporations, for instance)
>it's vital that departments and org units within the larger namingContext
>have their own schema - it's unreasonable for the software purchased
>by Sales in NYC to extend the schema for Engineering in Denver when
>they have separate internal administrative domains with separate
>administrators and namespaces.  But both still reside within the larger
>corporate namingContext, and may need to be subject to a common
>organizational schema onto which their schema extensions are laid.
>
>This overlay approach was codified in X.500's content rules in 1993.
>
>I'm not entirely sure that's the most effective way to do it, but it does
>duck several of the "what do I do with my OIDs when I've added
>another attribute to the inetOrgPerson object class definition" questions.
>
>It is clear, though, that applications which need to be schema aware
>require a means to read the schema definition which governs entries
>in a particular portion of the namespace, so APIs which read schema
>need to include a context parameter to specify which portion of the
>namespace the schema enquiry or modification applies to.
>
>Ed
>
>----------------------
>Ed Reed, Technologist
>Novell, Inc.
>+1 801 861-3320
>
>>>> K. Senthil Kumar <senthil_k1@catsglobal.com> 11/04/1998 06:26:30 >>>
>
>hi everybody!
>	can a Directory Server suppport more than schema? say for example in
>different namespace by having directory entry of subschema class. And I
>also want to know whether it is mandatory for all objectclass to be
>derived from top class.
>
>thanks
>Senthil Kumar
>
>
>
>