Re: root dse search

[Steve Miller <Steve.Miller@openwave.com>]

"Kurt D. Zeilenga" wrote:
> 
> 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.

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

> 
> 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