-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
- --On Thursday, October 16, 2008 4:29 PM +0200 Pierangelo Masarati <[EMAIL PROTECTED]> wrote: > > ----- "Michael Ströder" <[EMAIL PROTECTED]> wrote: > >> Pierangelo Masarati wrote: >> > ----- "Emmanuel Lecharny" <[EMAIL PROTECTED]> wrote: >> > >> >> >> http://www.watersprings.org/pub/id/draft-just-ldapv3-rescodes-02.txt >> > >> > Iinternet Drafts are not authoritative sources of information. >> They >> > should never cited except as work-in-progress. No one seems to be >> > questioning that noSuchObject is a legitimate response code for >> LDAP >> > searches. The point is whether noSuchObject is appropriate for a >> > search whose searchBase exists. >> >> I wonder why that's such a big issue at all. When implementing LDAP >> client software one has to handle noSuchObject and an empty result >> set >> anyway. In most cases the handling is mainly the same. > > Let me disagree: from an implementation point of view, it depends on what a > client is supposed to do. If the client's task is over after the search > response is returned, I might agree. But in any case, from a(n informed) > user's perspective, the two responses are not the same. In case of > "success", no entry matched the search criteria, while in case of > "noSuchObject" one search criterium, the searchBase, was inappropriate. I agree. Client software should behave differently under an error condition than it would with an empty search result. That's why this discussion is not trivial or nonsense. > I concur that this whole discussion is a little nonsense, as I believe the > expected behavior is so well explained in RFC 4511, which is the sole > authoritative source of information for this topic, that there is no point in > discussing it any further. Also, I believe many implementations 'round do > not conform yet to RFC 451*, as they might still conform to RFC 225* (like > OpenLDAP 2.3 itself). However, I don't see much difference with respect to > this issue. > > p. > Ah, but the expected behavior is *not* well explained in this case. Appendix A only has this for the description of noSuchObject: "Indicates that the object does not exist in the DIT." Well, *which* object? It's not too much of a stretch to interpret that as "the object for which you were searching does not exist". In which case the server developer might feel justified in returning noSuchObject for an empty search. I believe that the interpretation should be that an object for a supplied DN (i.e., the bind DN or the search base) doesn't exist. You don't know the DN of the object you are searching for, so you haven't supplied it. Therefore the noSuchObject shouldn't be returned. But just because I & others interpret it that way doesn't mean it's clear to everyone. There should either be wording to specify that an empty search should or must not return noSuchObject, or the definition of that result code should be worded more explicitly to remove the ambiguity. -paul - -- Paul D. Engle | Rice University Sr. Systems Adminstrator, RHCE | Information Technology - MS119 713-348-4702 | PO Box 1892 [EMAIL PROTECTED] | Houston, TX 77251-1892 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFI91e6CpkISWtyHNsRAlTzAJ4l48g+/hPqHKRle511h9ON3wkkTgCgtXwu QLQUYn5flFQyPim22ZvCnMs= =guBu -----END PGP SIGNATURE-----
