Net::LDAP::schema brokenness

[Chris R. <chr...@me...>]

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