LDAPv3: All Operational Attributes proposal

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

I would like to draw your attention to the I-D:
  draft-zeilenga-ldapv3bis-opattrs-02.txt

This I-D updates LDAP to provide a simple mechanism to
allow a client to request the return of all operational
attributes.

In short, the proposal updates to RFC 2251 to state
that a "+" in the list of requested attributes should
return all operational attributes (much like "*" returns
all user attributes).   This approach was suggested
by Bruce Greenblatt in a November 1998 post to the
LDAPext mailing list.

It should be noted that other alternatives were considered:
  1) use of an LDAPv3 control
     This mechanism cannot be retrofitted into servers
     which also support LDAPv2.  This approach would require
     change to existing clients and servers to support.
      
  2) use of an additional tag within the searchRequest
     SEQUENCE.  Though RFC 2251, Sect 4 requires unrecognized
     tags of element SEQUENCE to be ignored, operational
     experience has been that implementations often do
     not ignore them.  In addition, this alternative would
     require change to existing SDKs, clients and servers to
     support.

  3) use of some special, non-instantiatable, non-assertable,
     non-subtypable attribute type in which no options could
     be added to.  Ruled out as being too hard to specify
     and may be problematic to implement (as it directly
     overloads attribute typing).

The proposed approach is to use a string in a manner comparable
to '*' to indicate the special behavior.  The string just
should not conflict with attribute types description.  The
choice of "+" is otherwise purely historical.

One of the key benefits of special string approach is that it
is compatible with pre-existing general purpose browsers and
SDKs.  That is, a user can type the URI:
  ldap://ldap.openldap.org/dc=openldap,dc=org?%2B,*

into their favorite LDAP-aware browser to request the return
of all attributes or a developer can write a client using any of
the preexisting SDKs.  In addition, this mechanism can be
retrofitted into LDAPv2 server implementations (just like
"*" was).

Operational experience has demonstrated the approach to
be sound and generally useful.  It is believed that no
current client SDK which disallows the encoding of such
a request nor that no server behaves in a manner inconsistent
with that described in the proposal (that is, all servers which
do not yet support the mechanism ignored the "+").  [If there
is operational experience to the contrary, please speak up].

As this proposal describes a "new feature", I personally do
not believe it appropriate for inclusion in LDAPbis work.  However,
as is does update a "core" document, I do believe it appropriate
to be reviewed on this mailing list.  I defer chair responsibilities
in regards to measuring consensus of the list in regards to this
I-D to Bob.

I solicit your comment in regard to this proposal.