Subject: root dse search

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 14 Mar 2001 15:19:47 -0800

The RFC 2251, 3.4 statement:
   These attributes are retrievable if a client performs a base
   object search of the root with filter "(objectClass=*)", however
   they are subject to access control restrictions.

has been interpreted by some that the these attributes are not
subject to other restrictions.  It is clear that there are quite
a few other restrictions which are or may be placed upon these
attributes, including:
  - administrative limits,
  - applicability to client's context (certain SASL mechanisms,
    controls, and extensions may only be visible when available),
  - restrictions imposed by search controls, and
  - basic attribute usage semantics (including restrictions upon
    the return of operational attributes).

A simple clarifying replacement would be:
   These attributes are retrievable if a client performs a base
   object search of the root with filter "(objectClass=*)", however
   they are subject to access control and other restrictions.

However, I have also noticed that this statement has also been
interpreted by some that no other filters may not be used.  Some
implementations appear to ignore the filter completely
(returning the root DSE even when the filter clear doesn't
match).

Hence, I suggest this statement be replaced with:
   These attributes are retrievable if a client performs a base
   object search of the root DSE with a matching filter such as
   (objectClass=*).  These attributes, like other attributes,
   are subject to access control and other restrictions.

It might also be appropriate to reinterate the 4.5.1 statement
in regards to semantics of operational attributes as well:
  Furthermore, servers will not return operational attributes
  unless they are listed by name (see Section 4.5.1).

I also note that implementations may support operations upon
the Root DSE, so the additional of the following might be
appropriate as well:
  Implementations may support additional operations (e.g.
  compare, modify) upon the root DSE.

Kurt

---

From: Steve Miller <[email-masked]>
Date: Thu, 15 Mar 2001 11:45:46 -0500

>    are subject to access control and other restrictions.

In terms of ease of interoperability, it may be easier to retain the
specific statement '...with filter (objectclass=*)...' instead of
'...such as (objectclass=*)...'. This makes it simpler to setup ACIs,
for example to allow anonymous access to read 'supportedSASLMechanisms'
as specified in RFC2831/RFC2829. (Having just done this on our
implementation!) Otherwise, you would either need to allow access to
more attributes, or the client would have to know or determine which
particular attribute to use in the filter. And it also preserves
backwards compatibility with clients that currently use
'(objectclass=*)'.

Otherwise, new text looks fine.

Steve

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 15 Mar 2001 10:41:30 -0800

>backwards compatibility with clients that currently use

 From this I gather you believe the RFC 2251 text:
   These attributes are retrievable if a client performs a base
   object search of the root with filter "(objectClass=*), ...

is somehow to be interpreted as only allowing a "list" (search
with (objectClass=*)) operation upon the root DSE.

I stated a number of reasons why I believe this
interpretation is not well founded in my post
"filter (root dse search)".  I'll add another here:

Like in DAP, I believe it was intended that all DSEs in
the server be visible through LDAP including the root DSE.
This includes not only the "list" operation, but other
searches, compare, modify, and other applicable operations.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 15 Mar 2001 11:50:52 -0800

>with (objectClass=*)) operation upon the root DSE.

s/list/read/

>searches, compare, modify, and other applicable operations.

s/list/read/

sorry for any confusion.