[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: What Does De-Reference Mean?
Prasad, All,
The text in X.511 reads:
"If the searchAliases parameter is TRUE, aliases shall be dereferenced,
if the parameter is FALSE, aliases shall not be dereferenced. If the
searchAliases parameter is TRUE, the search shall continue in the
subtree of the aliased entry."
While overly vague (and maybe Skip or David can point to some better
documentation), to me, this means that if searchAliases is TRUE, then
1) Every alias in the scope of the search is dereferenced. In my mind,
dereferenced implies that the entry is not considered in the search.
2) The search continues in the subtree of the aliased entry. To me, I
don't think this excludes subtrees that were not in the original
subtree.
2.1) If the original base was sub, then the dereferenced entry becomes
the new base for the continued search in the dereferenced subtree.
(effectively, set dereferenced entry as base and go to #1.)
If we are to exclude subtrees that are not held within the original
subtree, then what would the point of searchAliases be, other than to
exclude the alias object (which can be done in the filter anyway)?
I do agree, there is not enough documentation here.
Jim
>>> "Vithalprasad Gaitonde" <gvithalprasad@novell.com> 5/20/03 6:33:45
AM >>>
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
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
>
>========================================================================