[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