RE: Schema evolution

[Alexis Bor <alexis.bor@directoryworks.com>]

As far as using an OID - I would strongly recommend getting one from a
registration authority, such as ANSI, or from someone who has one can issue
you one below their registered number.  It is a small price to pay for
guaranteed uniqueness.

I don't believe that there are local private ones that you can use.

As far as assuring unique names in the future, you can take a few
precautions that might make the odds lower, but not eliminate them.  The one
that I find works best is to add a prefix to every custom attribute and
object class that is unique - like the initials of your company.  For
example the attribute building would be called acmeBuilding if your company
was acme.  However, this really points out why in the X.500 world it was
very important to refer to attributes and object classes with OIDs and not
by their name - at least on the wire.  That has always been a frustration
and concern for me in many of my deployments.  It is so easy in LDAP to have
two attributes with the same name have different meanings, depending on
which LDAP server you connect to.

-- Alexis

-----Original Message-----
From: MIRCEA PANA [mailto:mpana@newbridge.com]
Sent: Thursday, August 19, 1999 2:22 PM
To: alexis.bor@directoryworks.com
Cc: 'Ashish Kolli'; ietf-ldapext@netscape.com
Subject: Re: Schema evolution


Right, but are there any rules for defining schema additions with local
scope.
We have requirements for new object class, attribute etc. definitions for
our
directory services only (nobody outside our company would need them).We
should
not need to register OID.s publicly.
We found issues like:
1. How can we make sure the OID.s we define internaly will not be asigned by
the standardization organizations to somebody else?
2. Is there any ARC that is reserved for private use (like the class A
network
10.0.0.0 in TCP/IP)?
3. How can we make sure that the nameswe chose for the object classes
attributes, etc. will not conflict with public names in the future?

Thanks,
Mircea.



Alexis Bor wrote:

> I don't think that you want to start adding additional optional attributes
> to well known object classes.  Even as a formal evolution to an object
> class, it will cause confusion and potentially break existing systems.  I
> think that you are better off with an auxiliary object class, as far as a
> local decision to extend.
>
> But you do raise a good question, what would be the process and issues to
> adding an attribute to an already well known and used object class, such
as
> organizationalUnit.  I think that there would be some very severe concern
> over doing this and potentially lots of heated debate.
>
> -- Alexis
>
> -----Original Message-----
> From: Ashish Kolli [mailto:akolli@us.oracle.com]
> Sent: Thursday, August 19, 1999 12:01 PM
> To: ietf-ldapext@netscape.com
> Subject: Schema evolution
>
> Hi,
>
> As LDAP centric applications evolve, there will definitely be a need to
> support slight changes in the schema.
> One well known way to do it is to create auxiliary object classes and add
> them onto existing entries in the DIT. Another way to do it is to provide
> limited support of extending the existing schema in the directory (like
> adding additional optional attributes to an objectclass). Is the latter
> method a "well-accepted" way of supporting schema evolution?
>
> regards,
>
> Ashish Kolli
> OiD Group