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

["Natarajan SK" <sknatarajan@novell.com>]

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

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. 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. And all this because the filter has been taken away when it need not have been.

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