Re: Adding new objects to the directory

["John H. Dale" <[e-mail]>]

> 	
> >> 	When I add an object to the directory, I find that I have to
> >> set the objectclass attribute to include all the members of the object
> >> class hierarchy. Is this a bug or a feature of the standard?
> >
> >If it is not a feature, then this would be a serious bug of the standard!
> >The whole purpose of object hierarchy is to allow future extensions.
> 	
> I think that there is a misunderstanding here. I agree that the objectclass
> attribute should contain the list of all objectclasses in the full
> hierarchy. However, when a new object is created, what has to go in the
> objectclass attribute on the 'add' call? What happens if I don't put all
> the superior object classes in this attribute list? I can see a number of
> options:
> 
> 1)	The 'add' request fails with some error (e.g. I set the objectclass
> attribute to have only the value 'organizationalPerson').
> 
> 2)	The DSA silently adds all missing objectclass values (e.g. Person
> in the case above)
> 
> 3)	The objectclass attribute only contains organizationalPerson. However
> this possibility is excluded by the standard.
> 
> Currently, quipu takes approach 2 above. However, all the attributes
> supplied in the add *must* be in one of the object classes listed, and *not*
> in the (implicit) superior classes.
> 
> Even the 92 drafts that I have are silent on this issue. They do note that
> the objectclass 'top' need not explicitly appear in the objectclass attribute.
> 
> Philip
> 
> 
The X.501 (9595-1) clause 9.3.3 has been amended (DR:006, technical
corrigendum 1) by having the following statement added:

"All values of the ObjectClass attribute are provided by the user
when the entry is created."

Does this preclude option 2 above?  It might be interpreted that way.

I'm not too bothered by the requirement that you must specify person
when you add an organizationalPerson, since that is part of the
definition of the organizationalPerson object class.  
However, on some DSAs, you can implement organizationalPerson
only as an "unregistered object class" that is a subclass of
both organizationalPerson and another objectClass, such as quipuObject.
Thus, the amended standard seems to require you to specify 'quipuObject'
when you add the entry.  I think there would be fewer interoperability
problems if the standard allowed the DSA to add the object classes
as necessary to conform to the structure rules, as long as no
MUST CONTAINS were missing.

I don't know what 1992 says on this point.  The problem is much worse 
in 1988 than 1992 because 1992 recognizes the concept of operational 
attributes and handles them differently.  Content rules also help.
I'm not alone in think that we need some sort of systematic look at 
supporting operational attributes in 1988 edition systems.  
I think the adjustments needed would be minor and would not cause 
interoperability problems.  However, there might not be much interest
in working on this problem, since there is an increasing push toward
92 systems.
-- 
John H. Dale  fax [phone]  COS, 8260 Willow Oaks Corporate Dr.,
[e-mail] tel [phone]  Suite 700, Fairfax, VA  22031