Re: OpenLDAP enhancements

[Julio Sánchez Fernández <j_sanchez@stl.es>]

David J N Begley wrote:

> Yeah, but RFC 2251 refers to RFC 2119 for interpreting compliance or
> requirements words and neither "are not" nor "will not" are either capitalised
> or treated in RFC 2119 (as the other phrases are throughout RFC 2251).

Yes, the RFCs could be more precise in a lot of areas.  But the only
sensible interpretation on the whole is that operational attributes are not
returned unless explicitly asked for.  A client that expects them to be
returned is broken.

Some history on 'objectClass' is useful here.  In the past, there were
no operational attributes in X.500.  When they introduced the four
attribute classes ('user' and the other three 'operational' classes),
they found a problem: objectClass was already there and clients were
used to expect it to be returned.  So, though objectClass is clearly
an operational attribute, it had to be left as a user attribute, much
against the standard writers' wishes.  There is text in the standards
saying as much (sorry, I don't have the reference handy).

So not returning them may be pedantic, but it was clear in the standard
writers' mind that clients have no right to expect them if they did not
make a specific request for them.

On the other hand, not returning them simplifies the processing, since
now attribute handling is uniformly done according to the schema, while
formerly a few attribute types were special-cased.  Putting back the
operational attribute types in the root DSE would need special casing
again and a strong case should be made for it.  Especially now that a
a method (asking for "+") has been implemented to request all operational
attributes after a proposal made on the IETF LDAP extensions WG (X.500
has such a method, but no provision for it had been made for LDAP).

Julio