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

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

Another viewpoint I have is that Standard Operational attributes to my knowledge is intended only for entries in the DIT. The server would look up the Standard operational attrs in the entry and take action. Since the rootDSE has nothing to do with the DIT per se and is only a way of knowing what services or capabilities exist on the DSA, my suggestion would be to free the LDAP operational attributes ( as against the Standard Operational attributes and as defined in rfc 2252 ) from the restriction of not returning values unless explicitly stated.
  In simpler words, we could say that if the Operational attributes are Standard, their values are not returned unless explicitly asked for and if the Operational attributes are LDAP Operational attrs. , we allow return of values without needing to be explicit.

Natarajan

S.K.Natarajan
Ph. no. 91-80-572-1856/58 Extn. 2213
Fx 91-80-572-1870


>>> "Roger Harrison" <RHARRISON@novell.com> 05/18/00 12:23PM >>>
This is an interesting question.  Based on my reading of RFC2251 and RFC2252, I think that it is improper behavior to return attributes that are defined to be operational (such as supportedControl and supportedExtension) without explicitly asking for them.

I think that the behavior of returning operational attributes in a root DSE query with an empty attribute list arose from the fact that a root DSE search is NOT a "normal" LDAP search.  You are already having to perform a special search request to get the root DSE in the first place, so adding an additional requirement to request the information by name is somewhat onerous. 

I don't think that the root DSE has an object class, so there's no way to read schema to find out what attributes would be available from the root DSE.  Even if it did, the root DSE holds the subschema subentry, so you'd have to first read the subschemaSubentry attribute from the rootDSE to get the location of the subschema subentry.  Then you'd have to read the subschema subentry to find out what attribute types might be in the root DSE. Then you'd have to read the root DSE again to get the values for the attributes. This seems like a lot of work to get information that you could have simply read.  It's even possible that the rootDSE wouldn't have a subschema subentry if the server doesn't master any entries and doesn't know the locations of schema information (RFC 2251 section 3.4)

On the other hand, RFC 2251 makes it clear that operational attributes must not be returned unless explicitly asked for, and RFCs 2251 and 2252 clearly list operational attributes at least some LDAP servers return on a root DSE query with an empty attribute list.

So was it intended that, when querying the root DSE, an exception be made to the RFC 2251 restriction that operational attributes not be returned unless explicitly listed?  If not, how does one divine the list of attribute types allowed in the root DSE if it doesn't have a defined object class?

Roger

>>> "Natarajan SK" <sknatarajan@novell.com> 05/18/00 12:11AM >>>
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).  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.
 

S.K.Natarajan
Ph. no. 91-80-572-1856/58 Extn. 2213
Fx 91-80-572-1870


>>> "Darryl C Price" <darrylp@earthlink.net> 05/19/00 10:25AM >>>
rootDSE attributes ARE operational in  that they are used by the server to
administer the directory system itself.  You are right, however.  This is
not explicitly stated in RFC 2251

--Darryl


----- Original Message -----
From: Natarajan SK <sknatarajan@novell.com>
To: Naveen C <CNaveen@novell.com>; <Kurt@OpenLDAP.org>
Cc: <ernest@cs.umb.edu>; <darrylp@earthlink.net>; <ldap@umich.edu>
Sent: Wednesday, May 17, 2000 10:45 PM
Subject: [ldap] Re: Version of Netscape Directory Service portocol


> Hi Kurt,
>                I looked up RFC 2251 and it does not mention the rootDSE
attributes as operational. Also I tried searching for rootDSE attributes and
both Netscape Directory Server and NDS return all rootDSE attributes (except
altServer, which I think does not exist )without my needing to mention
attributes specifically.  Are you sure (most ) rootDSE attributes are
operational.
>
> Regards,
> 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 10:53AM >>>
> At 10:40 PM 5/17/00 -0600, Naveen C wrote:
> >The information server aquires is from an entry called Directory Specific
Entry which is unique for each ldap server.  If supported ldapversions is
removed from the request it will return some more information like
extensions , controls and some other info which is supported by this ldap
server.
>
> Note that most attributes you'll find in the Root DSE are
> operational.  Per LDAPv3 specs, the attributes should only
> be returned if explicitly requested by the client.  Some
> servers don't implement this requirement for the Root DSE,
> but many do.  Your mileage may vary.
>
> Kurt
>
>
> ---
> You are currently subscribed to ldap@umich.edu as:
[sknatarajan@novell.com] 
> To unsubscribe send email to ldap-request@umich.edu with the word
UNSUBSCRIBE as the SUBJECT of the message.
>
>
>