RE: Abstract object class

[Paul Leach <paulle@microsoft.com>]

> -----Original Message-----
> From: Erik Skovgaard [mailto:eskovgaard@geotrain.com]
> Sent: Thursday, November 05, 1998 2:54 PM
> To: Paul Leach; 'Ed Reed'; senthil_k1@catsglobal.com;
> ietf-ldapext@netscape.com
> Cc: osidirectory@az05.bull.com
> Subject: RE: Abstract object class
> 
> 
> Paul,
> 
> At 10:52 98/11/05 -0800, Paul Leach wrote:
> >I agree with the problem statement. I don't agree with the proposed
> >solution.
> >
> >There is something fundamentally conceptually wrong with the 
> picture that
> >two objects with objClass=foo have different schema. What is 
> the objClass
> 
> I think what we are talking about here is the same Structural 
> Object Class,
> but the required attributes may change between, say entries 
> for employees,
> customers, partners and consultants/contractors.  The proper way to
> implement this would be to define the appropriate Axiliary 
> Object Classes
> and by using Content Rules configure the appropriate 
> combination of Object
> Classes.
> 
> I think what Ed was pointing out (if I understood him 
> corectly), is that
> there is no formal way to publish Content Rules.
> 
> >good for if it doesn't identify the schema?
> 
> It does, but since you are likely to need a private schema for an
> organization in addition to the standard schema, the current 
> way to do this
> is to define several Object Classes.

That isn't what I understood Ed to be saying. If I understood Him, he was
proposing that the same Object Class with the same OID refer to different
schema in different NCs.

> >
> >There are a couple of ways to approach the problem that I 
> think are better
> >than having (potentially) different schema at each NC for 
> the same class.
> >
> >1. Make the class be a DN. Then the engineering department 
> and the sales
> >department can create enmtries with
> >objClass="CN=foo,OU=Eng,DC=SomeCorp,DC=com" and
> >objClass="CN=foo,OU=Sales,DC=SomeCorp,DC=com" and they won't 
> conflict.
> 
> I am not sure I see why the current OID scheme is any worse 
> than what you
> are proposing.  In the Directory, we tend to have entries for "real"
> objects and they have a directory name.  Object Class 
> definitions have OIDs
> and they are also understood by the existing X.500 implementations.

How would I have the same OID refer to different schema? If an OID only
refers

> 
> I also do not like the name forms you are proposing.  Tying DNs to DNS
> names imposes some rather severe restrictions on the 
> directory names. 

Any DN would work; I just used the DC= forms as an example. Both forms are
legal. You may have objections to the DC= form, but it's orthogonal to this
issue. Let's not muddy the waters.
> >
> >2. Make schema immutable, but subclassing and auxiliary classing more
> >flexible. Then the sales and engineering departments can 
> have their own
> >classes, while the fact that there is a class in common 
> won't get lost.
> 
> I think that is the intent.  Being able to understand a subset of the
> information (as a client) even though the complete schema is 
> not known is
> certainly desirable to me.  Using Inheritance and Auxiliary 
> Object Classes
> together with a prudent selection of standard Structural 
> Object Classes
> will ensure that.

That's not what I understood Ed to be proposing. If it was, then there's no
problem. I agree with your summary. And I prefer solution #2 to #1 anyway.

Paul