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.
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.
RFC 3296 (Named Subordinate References in LDAP) disagrees:
4. Named Subordinate References Typically the DN of the referral object and the DN of the object in ^^^^^^^^^ the referenced server are the same.
5.1. Example Configuration dn: OU=People,O=MNN,C=WW ^^^^ ou: People ref: ldap://hostb/OU=People,O=MNN,C=US ref: ldap://hostc/OU=People,O=MNN,C=US ^^^^ objectClass: referral objectClass: extensibleObject
In general, I think it is inappropriate for referral URIs to contain DNs.
Both RFCs disagree. 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.