Subject: Schema evolution

From: "Ashish Kolli" <[email-masked]>
Date: Thu, 19 Aug 1999 09:01:08 -0700

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

---

From: "Alexis Bor" <[email-masked]>
Date: Thu, 19 Aug 1999 12:34:55 -0400

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:[email-masked]]
Sent: Thursday, August 19, 1999 12:01 PM
To: [email-masked]
Subject: Schema evolution

Hi,

regards,

Ashish Kolli
OiD Group

---

From: [email-masked] (David Boreham)
Date: Thu, 19 Aug 1999 09:46:04 -0700

$0.02/wo:

1. Don't. (add new object classes to hold the new attributes instead).
2. If you have to (sometimes the case), think very hard before
doing it. 
3. When you do, never make a change which is not backwards
compatible (e.g. never _remove_ an attribute from a class,
never change an attribute from optional to required).
4. Make sure everyone knows you did it.

A. When you design schema in the first place, beware
of backing yourself into a corner in the future.
Particularly, avoid "required" attributes if you possibly can.

---

From: "MIRCEA PANA" <[email-masked]>
Date: Thu, 19 Aug 1999 14:22:13 -0400

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.

---

From: "Alexis Bor" <[email-masked]>
Date: Thu, 19 Aug 1999 14:32:49 -0400

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:[email-masked]]
Sent: Thursday, August 19, 1999 2:22 PM
To: [email-masked]
Cc: 'Ashish Kolli'; [email-masked]
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.

---

From: Christine Won-Yoon <[email-masked]>
Date: Thu, 19 Aug 1999 14:37:49 -0400

Ashish,

RFC 2252 (LDAP-v3: Attrbiute Syntax Definitions) states that
'An object class definition should not be changed without having a new
identifier assigned to it' in 4.4.  It seems that this sentence suggests
STRONGLY NOT to modify existing schema elements.

Christine Won-Yoon

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 19 Aug 1999 11:46:38 -0700

>the standardization organizations to somebody else?

Obtain a private enterprise OID from IANA or other registrant.

>2. Is there any ARC that is reserved for private use (like the class A network

Well, you could use OIDs under "1.1" as the ISO Registration Authority
is retired... (it's not explicitly set aside for this purpose).

However, obtaining an private enterprise OID is easy and free:
  http://www.isi.edu/cgi-bin/iana/enterprise.pl

(and, yes, they are not just for SNMP).

>attributes, etc. will not conflict with public names in the future?

You should prefix names with something that is unlikely to conflict.
This will likely keep your names from conflicting with any names used
in standard track specifications.  However, it will not keep you from
conflictly globally.... that's what OIDs are for.

>Attachment Converted: "c:\home\kurt\data files\eudora\attach\mpana.vcf"
>

---

From: "Alexis Bor" <[email-masked]>
Date: Thu, 19 Aug 1999 15:00:53 -0400

Kurt,
I believe that the ISO arc is not terminated.  I believe that people with
OIDs from that arc still have valid arcs and can continue to use them.

When the joint ISO-CCITT arc was built, ANSI sent a letter out telling
people what their new OID is, but also said that you may continue to use the
old one.  I was on the registration authority committee, so I am certain
that the letter went out with the suggestion to start using the new arc, but
not forcing people to stop using the old one.

-- Alexis

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Thursday, August 19, 1999 2:47 PM
To: MIRCEA PANA
Cc: [email-masked]; 'Ashish Kolli';
[email-masked]
Subject: Re: Schema evolution

scope.
our
should

network

---

From: "David Chadwick" <[email-masked]>
Date: Fri, 20 Aug 1999 17:15:25 +0100

Date forwarded: 	Thu, 19 Aug 1999 08:57:25 -0700 (PDT)
From:           	"Ashish Kolli" <[email-masked]>
To:             	<[email-masked]>
Subject:        	Schema evolution
Date sent:      	Thu, 19 Aug 1999 09:01:08 -0700
Forwarded by:   	[email-masked]

> 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).

Ashish

We have already been around this loop once a few months back, 
when someone noted that Microsoft had redefined top (by adding 
dozens of extra attributes).
I understand MS now plan to fix this bug in a future release of AD.
The answer to your second way is quite clear - DONT DO IT

David

> Is the latter method a "well-accepted" way
> of supporting schema evolution?
> 
> 
> regards,
> 
> Ashish Kolli
> OiD Group
> 
> 

***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
*NEW* Email [email-masked] *NEW*
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************