[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

"Kurt D. Zeilenga" wrote:

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

No, it doesn't make sense.  What is the source of the requirement?  I
have the RFCs, but not the X.500 documents.

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

You bet this client is hosed.  It adds entries without making sure their
parents exist, doesn't specify "objectclass" attributes, uses "%"
instead of "*" for wildcarding, and a couple other screwy things I don't
feel like going into.

But I _have_ gotten it working with openldap, using a perl script and
the shell backend to fixup its brokenness.
> >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.

I don't think this is about encouraging other clients.  It's about a
server being liberal about what it accepts, and conservative about what
it sends, which tends to be a fairly good design principle.  I'm not an
LDAP or X.500 expert; I worked on this code because I needed it for a
particular application, but it just doesn't make sense to me that a
client could ask for one thing, be handed back something else, and this
not only be legal but required.

I guess I could get the thing working by using a custom copy of
core.schema, that defined surname as a seperate attribute.  If this is
the approach adopted, then I'd suggest taking "surname" out of the
distributed core.schema entirely, since (as you noted) it's not an
official alias for "sn".  I don't know if there's some way to define
aliases for already specified attributes in an auxillary file, what do
you think?

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

Sorry, I'm used to context diffs and used the wrong switch.  I can
resubmit it if you decide to take it.


                                        Brent Baccala