[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: objectclass modifications
Right, Aux classes should be used when they can. The situation that seems to need a solution is the case where optional attributes get added to an object class high in the class hierarchy. Typically, someone will add some optionals to Top so that every existing entry as well as any future entry, can now include this attribute. Niether the use of aux classes nor subclassing can replace this.
X.501 has DIT content rules. LDAP supports a ditContentRules operational attribute in the subschema entry. Using this, one can effectively add to the definition of an objectclass. The DIT content rules only apply to a single indicated objectclass though. They aren't inherited by subclasses (see 12.7.1 of X.501).
Jim
>>> Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> 5/25/99 1:20:04 AM >>>
Yes - LDAP servers are a major problem in this area - and the fact that
one must replicate everything to every where if one wants to have an
authenticated system comprising of two or more LDAP (non X.500) servers.
Also - by redefining TOP in this way - IMHO - it is a sure way to make
sure that total incompatability is achieved with any directory service.
This is because such definitions make every object in the universe
having to import and support what ever attribute has been deemed
appropriate by the respective organisation. TOP is really the Top of an
object class specification for ANY subordinate refinement - that is why
it just has the OC attribute. A better solution to the issue of adding a
bundle of attributes to TOP is to define an Aux OC and just add the
attrs to that and to add this to what ever entry you like.
Hopefully the implementation will migrate to that.
Directories are about Object oriented systems that have the mechanisms
to enforce a doctrine on the Object schema - which in most cases is
standard - and such doctrine is enforced when loading the directory
through LDAP/LDIF or DSP/DISP.. throw that doctrine away and a mess
happens....
The solution - well either the non standard approach will fall to bits
because it does not work well or it will become the "standard"
or when integrated with standard systems, the customers will have an
additional cost in integration effort and operational processes and make
noises about that to the respective suppliers.
Customers want system to interoperate at the communications and
information levels - Its hardly a marketing thrust to say that at the
very top point of information structural specification - that a product
is non standard!
regards alan
regards alan
> -----Original Message-----
> From: Jim Sermersheim
> Sent: Tuesday, May 25, 1999 9:43 AM
> To: ietf-ldapext@netscape.com
> Subject: objectclass modifications
>
> Hi all.
>
> I'm a little worried about what will happen when we actually try to
> share data between LDAP servers. The reason is, some deployments have
> modified well known objectclsases (like "top" for example) to include
> additional optional attributes. I can see this leading to schema
> violation errors when trying to import LDIF information.
>
> X.501 (section 14.5) says:
> "The definition of information objects such as object classes,
> attribute types, matching rules and name forms which have been
> registered (i.e. assigned a name of type object identifier) are static
> and cannot be modified. Changes to the semantics of such information
> objects requires the assignment of new object identifiers."
>
> RFC2251 reflects this with somewhat looser language in 4.4:
> "An objectclass definition should not be changed without having a new
> identifier assigned to it".
>
> Some servers allow this to happen, some even include modifications to
> standardized objectclasses in their preconfigured schema. They don't
> require the name nor the OID to change.
>
> I see a couple problems dealing with replication and data sharing. A
> server which imports LDIF, might look at object class oids when
> determining whether to add the objectclass to its schema. If the oid
> exits in its schema, it will not add the objectclass. This could
> cause schema violations. Other servers may not allow objectclass
> modifications.
>
> I really don't know how other servers import schema, nor how many
> allow objectclass modifications. Does anyone else see this as a
> potential problem and/or want to talk about solutions?
>
> Jim