RE: extending existing object classes vs deriving new classes

[[e-mail]]

Hello,

Let me try to address your questions to the best of my knowledge.

To start with, there can be multiple interpretations of the standard
in this respect. So, I am proposing the way "I interpret this issue
from the standard".

I feel that we cannot CHANGE the objectClass or Attribute definitions
as mandated in the standard. You can derive your own private SUBCLASS
for your own attributes to be added in the schema. Further, in
your application, you need to have mechanisms to accomodate BOTH
type of objects i.e. objects with standard object classes and 
objects with non-standard object classes. You can say that this 
is the COST you need to pay for accomodating your own derivatives
from standard schema.


> One of our goals is for our DSA to support as many DUAs as possible.

Are you developing a DSA ?? In that case you need to be very flexible
in terms of schema definitions. Normally, in DSA, the schema definition
is defined through some propritory mechanisms and does not assume any
standard or nonStandard schema. Of course, standard schama is 
normally provided as part of default installation. But, I think if
a customer wants then he can create a nonStandard (i.e. private) 
schema which will be closed for access by any intruder.

> If we extend, other DUAs will query our DSA and get an ASN.1 encoded
> object that will have strange attributes.  However, the DUA will know
> about the object class.  Thus, it's possible that the DUA will simply
> skip the unknown attribute while displaying the other ones.  However,
> we are not sure if this is allowed by the standard.  After all, 
> Application Process has an object identifier and that in itself might
> carry the object semantics for some DUAs.  

No. MyApplicationProcess is the correct approach....

> On the other hand, if we derive, we are afraid that the DUA might not
> be able to find out that MyApplication Process is just a derivation of
> Application Process and then reject the whole object class.  We are
> not sure how polymorphism works in the directory or how DUAs find
> about new object semantics when using the 1993 extensions. 

This can easily be done in the initial handshake mechanism i.e.
immediately after bind.


Praveen Gupta
Hughes software system, New Delhi.