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.