filter (RE: root dse search)

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

I'm going to break my reply in two as to separate two issues:
        - the filter
        - other restrictions
with the root dse.  This message responds to the filter portion
of your reply.

At 03:56 PM 3/15/01 +1100, Ramsay, Ron wrote:
>The filter (objectClass=*) was meant to be special and to indicate that
>retrieving the root DSE was intended.

Unlike subschema, I note that the empty DN and base scope
is enough to indicate a read of the root DSE.  If there was
some need for a special filter, I would expect an RFC 2119
imperative requiring it as was done with subschema entries
(3.2.2).

I find the text:
   These attributes are retrievable if a client performs a
   base object search of the root with filter "(objectClass=*)"

just saying how a client might read the root DSE.  I don't
find as saying this is how a client MUST access attributes
the root DSE nor saying that server has to implement any
search semantics which differ in anyway from those described
in 4.5.1.

>As regards extending this filter, I note that the root DSE has no object class and so a literal interpretation of the filter would not have
>the desired effect.

Then wouldn't you think the TS would have made explicit mention
that the filter is not to be evaluated?  or required an empty
filter and requiring the field to be ignored?  or a filter
that would always match such as (supportedLDAPVersion=*)?

As far as the root DSE not having an object class, that's
somewhat debatable... I refer you to this message in the
archives which basically covers it:
  <15586.942781060@threadgill.austin.innosoft.com>
(but I was saving this issue for another thread :-)

>I think that the 4.5.1 statement regarding the return of operational
>attributes was itself overridden in the case of the root DSE.

What leads you to the conclusion that the statements
in 4.5.1 and 3.2.1 do not apply to the root DSE search?
Is there something in the "core" RFCs, X.501, or X.511 I've missed?

Kurt