[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#5339) wrong referral from back-bdb



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.

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/