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.

...

A referral is not an alias. If I try to add an entry "cn=me,o=we" then that is the DN that the entry must be created with. If something redirects me to create "cn=me,o=they" this should be an error - that is not the entry I requested the server to create.

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.

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.

RFC 4511 4.1.10. Referral: - It is RECOMMENDED that the<dn> part be present to avoid ambiguity. RFC 3296 section 2.2 (about 'ref'): The LDAP URL SHOULD contain a non-empty DN. The handling of LDAP URLs with absent or empty DN parts or with explicit scope specifier is not defined by this specification. RFC 3296 Section 5.2: The DN part MUST be modified such that it refers to the appropriate target in the referenced server (as detailed below). Even where the DN to be returned is the same as the target DN, the DN part SHOULD NOT be trimmed.

The X.500 model does not allow for arbitrary DNs to be inserted here. The RFC text implies that arbitrary DNs are allowed, but that's incorrect.