Re: Bug Fix: attribute names/ordering in search returns (ITS#787)

[Kurt@OpenLDAP.org]

Just for clarity...

My point is that the behavior of OpenLDAP 2.0 in respect to
the two issues raised is allowed by the technical specification.
It may not be what some clients expect, but clients often
expect more than the specification guarantees them.  Such
clients are going to break... especially when faced with
subtypes of requested attributes descriptions or distributed
environments where not all entries within scope share the
same subschema.

I concur that the OpenLDAP 2.0 could do more in regarding to
the NAME select as allowed by the technical specification.
In particular, it could use the provided attribute description
list to select which of the alternative attribute type names to
return (NOTE: all NAMEs are alternative to the OID).  But the
implementation of such must be consistent with the technical
specification.  In particular, the implementation should be
consistent with the OID v. NAME and ascending option ordering
requirements of the current technical specification.

I believe it best not to use any other information for NAME
selection (in particular contents of the base DN, filter,
or controls [excepting controls specifically designed for
such purposes]).

As far as the second issue, ordering of results.  I do not
believe OpenLDAP should be modified to order results based
upon the order of the requested attribute description list.
This would likely interfere with the future implementation
of controls designed to sort results.

Kurt