[Date Prev][Date Next]
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
> 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.