Subject: RE: root dse search

From: "Ramsay, Ron" <[email-masked]>
Date: Thu, 15 Mar 2001 15:56:42 +1100

Kurt,

The filter (objectClass=*) was meant to be special and to indicate that
retrieving the root DSE was intended. 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.

I think that the 4.5.1 statement regarding the return of operational
attributes was itself overridden in the case of the root DSE. For example,
namingContexts is an operational attribute but (is this Netscape's doing)
clients expect it to be returned. I changed my implementation for
interoperability. I think Mark Wahl has written on the LDAPext list that
operational attributes in the root DSE are treated as user attributes.

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Thursday, 15 March 2001 10:20
To: [email-masked]
Subject: root dse search

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: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 14 Mar 2001 23:53:57 -0800

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 other restrictions
portion of your reply.

Do you think the any of these "other" restrictions apply to
the root DSE?
  - administrative limits,
  - applicability to client's context (certain SASL mechanisms,
    controls, and extensions may only be visible when available), and
  - restrictions imposed by search controls.

I would think "there may be extremely large number of values
for certain operational attributes" (4.5.1) as the stated rational
for restricting the return of operational attributes clearly
applies to the root DSE.

At 03:56 PM 3/15/01 +1100, Ramsay, Ron wrote:
>attributes was itself overridden in the case of the root DSE.

What in the TS leads you to this conclusion?
Is there something specific in the "core" RFC, X.501, or X.511
I've missed?

I believe one must take into account all relevant purposes of
the TS when interpreting a particular aspect of the TS.  I believe
section 4.5.1 is clearly relevant to search of the root DSE.
Without a specific statement in TS overriding these semantics
as it applies to section 3.4, I believe no requirement of 4.5.1
is overridden.

Kurt

---

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

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:
>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:
  <[email-masked]>
(but I was saving this issue for another thread :-)

>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

---

From: [email-masked] (Mark C Smith)
Date: Thu, 15 Mar 2001 09:45:01 -0500

> operational attributes in the root DSE are treated as user attributes.

I think some implementations have done one thing (treat the rootDSE
attributes as special) and some have do another (treat them like regular
operational attributes).  The correct answer is in the eye of the
beholder.  It seems more convenient to me to return the rootDSE
attributes even when the client does not request them, but I see
no text in 2251 or 2252 that explicitly supports that point of view.

For better or worse, the Netscape server (now iPlanet) has always
returned the root DSE attributes without the client requesting them by
name.  I am sure that means there are a lot of clients out there that DO
NOT request them by name.  My practical side says, let's not break those
clients.  But I can't speak to the intent of the authors of 2251 or
2252.

-Mark Smith
 Netscape

---

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

At 09:45 AM 3/15/01 -0500, Mark C Smith wrote:
>name.

Some servers also return all operational attributes without
requesting them by name for other entries, in particular
subschema entries (despite even clearer indication in the
TS that 4.5.1 restrictions apply here as well).

>I am sure that means there are a lot of clients out there that DO
>clients.

Are you actually proposing we actually add language
to the TS explicitly requiring all server implementations
to return all root DSE operational attributes without their
request by name?

If so, I note that additional language should explicitly
state that due to the possibility of large number of
attributes and values that clients SHOULD request desired
attributes by name to avoid getting pounded.  Also, as
you noted with my "+" proposal, you should put in a
statement that the server is not obligated to return
all operational attributes when requested to do so as
some operational attributes are very expensive to
produce or are made available under large number of
attribute descriptions.

 From a practical side, I note that most folks are fixing
these clients to solicit the attributes they desire.  They
are doing this for a number of reasons including:
   because they run into a server which requires this,
   because they run into a server which returns a large
     number of undesirable attributes and values, and
   because they run into a server which returns a small
     number of expensive to produce attributes and values.

Kurt

---

From: [email-masked] (Mark C Smith)
Date: Thu, 15 Mar 2001 14:11:17 -0500

> to return all root DSE operational attributes without their

No.  But I am not sure we should prohibit servers from returning the
values either(I really have not decided one way or another).

> produce or are made available under large number of

I agree.

>      number of expensive to produce attributes and values.

That is good news.

-Mark