changed notes changed state Open to Suspended
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. 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". This is probably a protocol violation, since RFC 2251 states that search results will contain attributes "as specified in the attributes field of the Search Request". Also, it doesn't make much sense this way - the client should be given what it asked for. 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 - it expects the attributes in the result to be in the same order they were requested in the search. 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. The referenced patch addresses both of these issues, returning attributes to the clients in the order requested, using the names requested.
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.
"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. -- -bwb Brent Baccala bacccala@FreeSoft.org
At 05:59 AM 9/29/00 +0000, baccala@freesoft.org wrote: >"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. RFC 2251, 4.1.4. Note also the requirement to generate attribute description options in ascending order. RFC2251, 4.1.5. >> This client is hosed... from what I've gathered (from Microsoft's website), >> this client only works with MS's ILS (Site Server). >But I _have_ gotten it working with openldap, using a perl script and >the shell backend to fixup its brokenness. Why not fix these other issues in your backend?
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
moved from Incoming to Development
changed notes
moved from Development to Contrib
changed notes changed state Suspended to Closed