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

[hyc@symas.com]

h.b.furuseth@usit.uio.no wrote:
> Howard Chu writes:
>>> 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.

RFC4510 Section 2 "Relationship to X.500"

    This technical specification defines LDAP in terms of [X.500] as an
    X.500 access mechanism.  An LDAP server MUST act in accordance with
    the X.500 (1993) series of International Telecommunication Union -
    Telecommunication Standardization (ITU-T) Recommendations when
    providing the service.

> 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?

As I've said many times before, LDAP referrals are a poorly designed piece of 
junk. The fact that the spec leaves it open to return other types of URLs but 
nobody in the world knows what that should actually mean to an LDAP client is 
just further proof of the abysmal lack of thought that went into the design.

> Also LDAP started out a lot sloppier than X.500.

That's self-evident. ;)

> Getting some response
> which hopefully resembled what you wanted was better than none:-)

Getting a wrong answer is worse than getting no answer, because the client 
will just assume that everything is OK and keep going, rather than reporting 
an error to the user.

>> 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

No, in this case the client is not being told to retry the *same* operation in 
another server, it's being told to try a *very different* operation in another 
server. Once again, the client made a specific request to create an entry with 
a specific DN. If the server can't honor the request as specified then it 
should fail and the operation should halt.

Anyway, the very existence of LDAP referrals is a violation of the service 
model. X.501(1993) section 18.2:
	It is a requirement of the Directory that, for particular modes of
	user interaction, the distribution of the directory be rendered
	transparent, thereby giving the effect that the whole of the DIB
	appears to be within each and every DSA.

LDAPv1 had no referrals. When they were introduced in LDAPv2 it's clear that 
nobody knew what they were doing, or nobody wanted to tackle the glaring 
absence of an analogue to X.500 DSP. They should never have been introduced. 
We're stuck with them for now, but we can at least try to make them make sense.
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/