[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: What Does De-Reference Mean?
At 05:33 AM 5/20/2003, you wrote:
>Kurt,
>Going by the same argument, the rest of the search criteria e.g. the
>base dn and scope of the search should also be applied after the alias
>has been derferenced to the actual entry
The base DN is "finding" criteria while the scope and filter
are "searching" criteria, so my argument does not apply to
the base DN but does apply to scope.
I couldn't parse your example, so I won't try to comment as
to how my clarification applies to it.
Kurt
>So in the example below,
>
> ou=deptB
> ou=deptA
> |
> |
> alias_teamA - - - - - - - - - - - - - - - - - - - - - - -
>- - - - - >ou= teamA
>
> |
>
> ou= DT
>
>
> |
>
> Computer object (objectClass=computer)
>
>
>
> Search Operation:
> set search base = deptB
> set search scope = subtree search
> set deref aliases = always
> search for objects of objectClass=computer
>
>Computer object should not be returned as it does not qualify the scope
>criteria for ou=deptb as the base.
>Correct ?
>
>Prasad
>
>>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 3/28/2003 5:12:53 AM >>>
>It should be clear that each and every entry returned in
>response to a search request did match the search filter. That
>is, if the filter is (CN=foo) than each entry returned has "foo"
>as a (not necessarily returned) value of an attribute whose
>type is CN or a subtype of CN.
>
>When dereferencing during searching (by derefInSearching or
>derefAlways), the filter should be matched against the entry which
>the alias refers to, not the alias itself.
>
>If the client asks for all alias objects, e.g, (objectClass=alias)
>with dereferencing during finding enabled, then no entries should
>be returned. Likewise, when requesting (objectClass=*) with
>dereferencing during finding enabled, none of entries returned
>should belong to the alias objectClass.
>
>So, to answer your specific question, it is not relevant to
>the matching what values of CN the 'alias' has. The values
>of the aliased entry are, however, quite relevant.
>
>Kurt
>
>
>At 11:22 AM 3/26/2003, Chris Harding wrote:
>>Hi -
>>
>>The interpretation of the LDAP RFCs as regards dereferencing has
>become an issue for the new certification program that The Open Group
>plans to launch for LDAP servers. We have discussed it in the Directory
>Interoperability Forum, and agreed that we should ask the experts in the
>ldapbis group. Accordingly, I would like to ask your help in clarifying
>this issue.
>>
>>Here's the issue. The requirement in the specification is:
>>
>> When a server receives a search request with the derefAliases
>field
>> set to derefInSearching then it will dereference aliases in
>subordinates
>> of the base object in searching.
>>
>>We have a test suite for use in the certification program. The suite
>includes a test of this requirement (which is in fact derived from a
>test in BLITS). The test data includes two entries: Jonathan Adams and
>Jonny Adams. The Jonny Adams entry is an alias for Jonathan Adams.
>>
>>The test should check that Jonny Adams is de-referenced and Jonathan
>Adams is returned. The question is, should the test search for Jonny or
>for Jonathan.
>>
>>RFC 2251 does not explain dereferencing but defers to X.501.
>Unfortunately, X.501 does not seem to explain it very well. My personal
>interpretation after reading it is that, whenever a server encounters an
>alias entry in the course of a search and dereferencing has been
>requested, the server should dereference the alias and carry on
>searching from the entry that the alias points to. Under this
>interpretation, a search for Jonny should return the same result as a
>search for Jonathan - the Jonathan Adams entry.
>>
>>I don't claim to be an expert on the interpretation of the
>specifications - but I hope that experts in the IETF community can shed
>light on this!
>>
>>Please send your comments to the ldapbis list. I will report the
>consensus (assuming that one is reached) to the DIF.
>>
>>Regards,
>>
>>Chris
>>+++++
>>
>>========================================================================
>> Dr. Christopher J. Harding
>> T H E Executive Director for the Directory Interoperability
>Forum
>> O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK
>>G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 902 3018
>> WWW: http://www.opengroup.org Mobile: +44 774 063 1520
>>========================================================================
>>
>> The Open Group's Consortia Services - Association
>Management For I.T.:
>> http://www.opengroup.org/consortia_services
>>
>>========================================================================