Re: (ITS#5339) wrong referral from back-bdb

[h.b.furuseth@usit.uio.no]

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

-- 
Hallvard