Howard Chu writes:
Hallvard B Furuseth wrote:
hyc@symas.com writes:
Frankly this whole example doesn't make sense, and RFC4511 doesn't say anything specific about it.
Yes it does. Section 4.1.10. Referral: - If the<dn> part is present, the client uses this name in its next request to progress the operation, and if it is not present the client uses the same name as in the original request.
Yes, I saw that. But the text doesn't give any explanation of the ramifications of what it's describing. Which is what I'm complaining about here.
Take it up with ldapext:-) And I guess we could make a slapd.conf option which turns on your preferred way.
The ramifications are that things can break, I think. In particular DN-valued attributes in the search result or in an Add request. The server can't help with that either, the client would have to handle it.
Also, now that I think of it, back-hdb/ldif subtree rename is broken if there are referral objects with DNs in the subtree. So I guess the slapd.conf option should allow to strip DNs that match the entry DN. And maybe allow to be more paranoid about rewriting writes (and Binds?) than searches.
However...
Both RFCs disagree.
They are wrong. Or at least, under-specified. In X.501 section 17.3 "Directory Distribution Model" it's quite clear that all of the components of a distributed directory must belong to a single DIT.
Which is not true in the LDAP world, and I don't know about today's X.500 world. Nameflow died and Dante was unable to resurrect it. Maybe the X.500 world has also switched to 'dc' structure, I don't know.
Anyway, LDAP is not X.500. Remember, LDAP referrals need not even be LDAP URLs. My guess is that's one reason for the difference from X.500: When you can even return a HTTP URL, why should you _not_ be allowed to return a far smaller change from the original URL?
Also LDAP started out a lot sloppier than X.500. Getting some response which hopefully resembled what you wanted was better than none:-)
And again, the service model requires the directory to store the client's data without any alteration. If the client wants to create the entry "cn=me,o=we" either that exact entry must be created, or the operation must fail.
Well, the operation does fail in the original server. Then the client may try another operation at another server... I don't know if that's a valid interpretation of the service model or not. In any case, it's a detail compared to the mess