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

[Kurt@OpenLDAP.org]

At 12:36 AM 9/29/00 +0000, baccala@freesoft.org wrote:
>Full_Name: Brent Baccala
>Version: 2.0.4
>OS: Linux Redhat 6.2
>URL: http://www.freesoft.org/bbaccala/servers.slapd.result.patch
>Submission from: (NULL) (63.216.69.197)
>
>
>Current openldap-2.0.4 implementation returns canonical names in search
>results,
>even if the client requested an alias.

Yes.  This is the easiest way to ensures we send back the most
appropriate name.

>For example, core.schema defines "surname" as an alias for "sn" (since "sn" is listed first in the schema definition).
>Thus, a client search request for "surname" will return "sn".

Well, a client which asks for 'surname' is skating on thin ice.
The formal (RFC 2256) specification of surname is:
    ( 2.5.4.4 NAME 'sn' SUP name )

Note that 'surname' is NOT listed an alternative name.  Implementations
are allowed to support additional names, we support 'surname'... but
the code is specifically designed only to return the primary alternative
name ('sn' in this case).

>This is probably a protocol violation

It's not.  A server is free to return any one of the alternative names it
has available.  

>Also,
>it doesn't make much sense this way - the client should be given what it asked
>for.

Returning the attribute exactly as the client requested it can violate the
technical specification.  If the client asked for attribute type by OID,
the server MUST return the attribute type by NAME if it has a NAME for
the attribute type.  I agree that this doesn't make sense, but that's
what the specification (currently) requires.

I also note that a server is obligated to produce attribute types options
in ascending order.  If a client requests "userCertificate;lang-en;binary",
the server is obligated to return this as "userCertificate;binary;lang-en".

>Also, the openldap-2.0.4 implementation returns attributes in the internal
>order they were pulled out of the database.  At least one client (Microsoft
>NetMeeting) can't handle this

This client is hosed... from what I've gathered (from Microsoft's website),
this client only works with MS's ILS (Site Server).

>- it expects the attributes in the result to
>be in the same order they were requested in the search.

That's a terrible assumption...  most clients handle attributed
returned in any order.

>Although the standard is unclear on this point,
>it makes sense to be conservative in dealing with
>clients, and hand them back exactly what they asked for, in the order they
>asked for it.

I rather not encourage other clients to make such bogus assumptions.

>The referenced patch addresses both of these issues, returning attributes to
>the clients in the order requested, using the names requested.

Please note that patches should be against HEAD branch, in unified diff format,
...  see http://www.openldap.org/devel/contributing.html for details.