Re: Net::LDAP::schema brokenness

[Kurt D. Z. <Ku...@Op...>]

Edited for clarity:

At 10:54 AM 1/29/01 -0800, Kurt D. Zeilenga wrote:
>My suggestion is to have three routines:
>
>subschema( targetDN ) which reads the subschema contained in the
>entry (or subentry) named by the targetDN.  This would do a base
>search of the targetDN with the filter (objectClass=subschema) and
>specifically request the return of attribute types describing
>the schema elements.
>
>subschemasubentry( targetDN ) which returns the DN contained
>as a value of the subschemaSubentry attribute type within
>the entry (or subentry) named by the targetDN. Would return error
>if multiple values of subschemasubentry exist (subschemasubentry
>is a single valued attributed type).
>
>schema( DN ) [named this for historical purposes] which is
>a basically a shortcut for
>        subschema( subschemasubentry( targetDN ) )
>
>Note this would return an error if the root DSE subschemasubentry
>contained multiple values.  This is a FEATURE as the user needs
>to select the correct one manually to obtain the appropriate
>schema.
>
>Kurt
>
>
>At 06:02 PM 1/29/01 +0000, Chris Ridd wrote:
>>I think the schema method of the Net::LDAP class is fairly broken. It isn't
>>documented, either :-)
>>
>>Here's my take on the existing behaviour:
>>
>>schema ( [ dn => DN ] )
>>
>>DN is an optional distinguished name. If not present, the method will use a
>>random DN from the Root DSE's subschemaSubentry attribute. If this
>>attribute is not present, the method will try <cn=schema>.
>>
>>It then tries to do a base object search of that DN with a filter of
>>(objectClass=*).
>>
>>However, this is useless if you specify the DN, because the schema object
>>can only be constructed if the search requests some operational attributes.
>>
>>This is also useless if you don't specify the DN and there is a
>>subschemaSubentry attribute in the root DSE, because the filter is wrong
>>(see RFC 2251 section 3.2.2, last para.)
>>
>>It's probably also useless in the <cn=schema> case, though that case seems
>>to be a band-aid for broken versions of a particular server (Netscape?) and
>>so all bets are probably off on that one's behaviour ;-)
>>
>>So the code's kind of trying to do two different things (reading a subentry
>>and reading an entry) and failing at both.
>>
>>Here's what I think this code should do.
>>
>>schema ( [ dn => DN ] )
>>
>>        If a DN is passed, return a Net::LDAP::Schema object using the subschema
>>retrieved from the objectClasses and attributeTypes operational attributes
>>from that entry (specifically entry, *not* subentry.)
>>
>>        If a DN is not specified, return a Net::LDAP::Schema object using the
>>objectClasses and attributeTypes held in the subentry (again, specifically
>>subentry, *not* entry) referenced by one of the values from the Root DSE's
>>subschemaSubentry attribute. If the Root DSE doesn't contain a
>>subschemaSubentry attribute, try using the DN of <cn=schema> for
>>compatibility with some broken directory servers.
>>
>>I'm attaching some diffs against Net::LDAP 0.20 which implements this
>>behaviour. The line offsets are probably a bit out too because I've been
>>experimenting with some other local changes. Sigh. Anyway, sorry it isn't
>>against a clean 0.22, but the guts of the change are:
>>
>>In schema() add a $filter variable and set it depending on the existence of
>>$arg{'dn'};
>>
>>In schema() set the attrs array when reading the subschema to include the
>>necessary operational attributes;
>>
>>In root_dse() set the attrs array when reading the Root DSE to include all
>>the standard (RFC 2251) operational attributes.
>>
>>I suppose I must get around to installing 0.22 at some point :-)
>>
>>Cheers,
>>
>>Chris