Howard Chu writes: >Hallvard B Furuseth wrote: >>[EMAIL PROTECTED] 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 -- Hallvard
