[Date Prev][Date Next]
Re: schema check
> At 01:19 AM 2002-01-12, Pierangelo Masarati wrote:
> >> This alternative approach may make checking system schema easier.
> >But this means each monitor entry should have a special STRUCTURAL
> >objectclass; maybe this might be 'subentry' ?
> The idea here would be that each monitor entry would have
> a specific objectClass appropriate for what it was
> representing, e.g.: monitorConnection, monitorListener,
> monitorBackend, monitorDatabase, etc.. Each would
> STRUCTURAL and SUP monitor and defined in monitor.schema.
OK; it sounds like odd defining all these objectclasses to fetch
things that are already well separated by subtrees; however I
understand one might want to get stuff about connections by searching
'cn=Monitor' with subtree scope.
> This facilitates system schema checks as all would be
> subclasses of monitor.
> You should NOT use subentry here. Subentries are very special
> administrative entries. See draft-zeilenga-ldap-subentry-xx.txt
> and X.501.
> Also, don't use LDAPsubentry. This has been withdrawn
> from IETF consideration.
I see. I already changed all the occurrences of 'LDAPsubentry'
in 'monitor'; this on turn has been added to schema_prep.c; I'll
see about schema and so. Is it OK if I add OIDs to the FAQ-o-Matic?