Re: [ldap] Re: Version of Netscape Directory Service portocol

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 04:15 AM 5/18/00 -0600, Natarajan SK wrote:
>Makes sense. From this and from what Roger wrote early on , we can assume that a regular search of the rootDSE ( without any attributeDescriptionList ) should not return any attributes 

No.  There is nothing in the specification that restricts
root DSE may contain other attributes.  In fact, our server
returns some non-operational attributes (such as objectclass).

>( Would this lead to any problems ? If already existing clients have assumed that the attributes are returned without attributeDescriptions, we might have a problem ).

A client failure to adhere to specifications has/does/will lead to
a problem with that client.  There are servers which properly
implement this aspect of the root DSE for quite some time...
and more and more will be "corrected" over time.

>   I see a catch in this. 
>  If already existing clients have assumed that some basic rootDSE attrs. are returned without needing to state the attributeDescription they might crib if further 
>( corrected ) implementations of the server do not return these attributes implicitly.

They crib yesterday and today with correct implementations.

> However if the server does not correct this behaviour, later on when a lot of operational attributes/values are added to the rootDSE, there would be unnecessary network traffic in the form of needless rootDSE attributes. 

>  What would be suggested ?

For them to implement the spec.

>Another thing in the same context is :
>   RFC 2251 (section 3.4 )states that rootDSE "attributes are
>   retrievable if a client performs a base object search of the root
>   with filter '(objectClass=*)' "  Wouldn't it be enough to do a base search of the root to understand that it is the DSA which is being queried.

Yes.  I personally think that the filter is more of an example than
a restriction. It's my opinion that the specification does not
disallow other filters, or other operations upon the root DSE
(such as compare and modify).  However, some servers do not support
this (some do).  This is an area in which additional clarification
may be specification.

>Then the filter could have been saved to assert what value of what attribute it is that I'm seeking using an attributeValueAssertion. Under the present approach a multivalued attribute having a huge no. of values cannot be queried for a particular value without also getting all of the other unnecessary values.

Which is why compare operations upon the root DSE should be supported.

>And all this because the filter has been taken away when it need not have been.

A filter doesn't (yet, see matched values extensions) limit the
attributes nor values returned.

>
>Natarajan
>  
>
>S.K.Natarajan
>Ph. no. 91-80-572-1856/58 Extn. 2213
>Fx 91-80-572-1870
>
>
>>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 05/18/00 02:39PM >>>
>At 12:10 AM 5/18/00 -0600, Natarajan SK wrote:
>>Something still stranger ( or maybe I'm missing something ) is that I used to think operational attributes are not returned in search results unless explicitly stated.  RFC 2252 states rootDSE attributes as operational attributes (which means they shouldn't be returned in ordinary searches). 
>
>Yes. As any given entry may have many operational attributes, some
>with a large number of values, "they are not to be returned unless
>in search results unless explicitly requested by name."  This
>makes sense especially for the root DSE and other such entries.
>
>> However in two different ldap v3 servers I've seen...
>>that rootDSE attributes(the same which are deemed in rfc 2252
>> as operational) are returned without explicitly needing to state the
>> attributes. This goes against rfc2251.  So my guess is either the
>> specification is flawed or the implementation of the ldap servers is flawed.
>
>The implementation.  RFC 2251 is quite clear on the matter.
>
>It has been suggested by some that an exception should be allowed
>for the Root DSE.  I would argue that such is inappropriate as
>the Root DSE is quite likely to hold many of the operational
>values which may have large number of values (though I hope
>some, like supportedLDAPversion, only has a two or three :-).
>
>As raised by Roger, there is no specification for the
>structural objectclass of the root DSE.  The E in DSE stands
>for Entry and entries must be of a structural object class.
>However, this underspecification is a minor flaw which isn't
>breaking anything and can easily be resolved through clarification
>in LDAPv3bis documents.
>
>Note, however, that the existance of an objectclass doesn't help
>much as no objectclass is likely to list all the possible operational
>attributes that may be in the rootDSE.  This is not a problem,
>clients which need operational attributes have apriori knowledge
>of such attributes (their implementor read RFC 2251-56).  And a
>browser which really wanted to know everything it could, could
>get everything by requesting each and every operational attribute
>type (as listed in the controlling subschema).  (This is what
>such a browser would have to do to find operational attributes
>of any other entry, the root DSE shouldn't be special in this
>regard)
>
>Kurt
>
>