[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: objectclass modifications
Jim Thanks - I understand this.
I think we are both agreeing that additional attributes can be dealt
with by other means and by subclassing or by Aux/content rules.
It is of major concern - and should be to ALL directory vendors - that
once someone modifies TOP - that any seamless interoperation is totally
destroyed. For instance if I added a CompanyNameCustmerID to Top it
means that ALL locality country, device, org, etc objects in the whole
directory environment (clients and servers) must recognise and support
this.
I think its reasonable to say the most of the directory vendors in the
market place respect the uniqueness of TOP and the implications of
modifying it. I would also think that some vendors have coded TOP to be
as standard. ie an Abstract OC.
IMHO it seems quite pointless to standardise on a directory protocol eg
LDAP - and then make a mess of the foundation object structure from
which every directory entry is derived. ie what the point of a standard
protocol for directory information if the information structure base
line is non standard..
Oh well - :-) All I can say is WHY?
Perhaps this is another question that should go in the Customers RFT/Is
ie.
Does your product support LDAP V3?
Does your product support the standard structural definition of TOP?
regards alan
> -----Original Message-----
> From: Jim Sermersheim
> Sent: Wednesday, May 26, 1999 4:54 AM
> To: Alan.Lloyd@OpenDirectory.com.au; ietf-ldapext@netscape.com
> Subject: 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