RE: Schema evolution

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

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:Kurt@OpenLDAP.Org]
Sent: Thursday, August 19, 1999 2:47 PM
To: MIRCEA PANA
Cc: alexis.bor@directoryworks.com; 'Ashish Kolli';
ietf-ldapext@netscape.com
Subject: Re: Schema evolution


At 02:22 PM 8/19/99 -0400, MIRCEA PANA wrote:
>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?

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
>10.0.0.0 in TCP/IP)?

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

>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?

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.

>
>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
>
>Attachment Converted: "c:\home\kurt\data files\eudora\attach\mpana.vcf"
>