[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
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
begin:vcard
n:Pana;Mircea
tel;pager:+1-613-364-1385
tel;fax:+1-613-591-3680
tel;work:+1-613-599-3600 x6907
x-mozilla-html:TRUE
url:http://www.newbridge.com
org:Newbridge Networks;Messaging and Directory Systems
version:2.1
email;internet:mpana@newbridge.com
title:Systems Architect
adr;quoted-printable:;;PO Box. 13600.=0D=0A600 March Road;Kanata;Ontario;K2E 2E6;Canada
fn:Mircea Pana
end:vcard