[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#5339) wrong referral from back-bdb
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.
--
Hallvard