Subject: Re: What Does De-Reference Mean?

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 05 Jun 2003 20:15:10 -0600

So, I'm trying to clarify this, and it occurs to me once again that I
don't like the semantics of derefInSearching.

I can't dereference all aliases in the search scope, yet not
dereference aliases while resolving the base. This is limiting. I may
want a subtree search to fail if there are aliases somewhere in the
middle of the DN, so I choose not to derefFindingBaseObject. Yet, once
the base object is found (even if it itself is an alias), I want all
aliases in my scope to be dereferenced.

AFAIK, LDAPv3 is consistent with X.511, so I guess there's not much we
can do about it here.

Anyway, I do need to clarify the wording. Right now it says
"Dereference aliases in subordinates of the base object in searching,
but not in locating the base object of the search". This is invalid if
the scope is base. It also doesn't tell me to continue a subtree search
in the subtree of a dereferenced object. I'll make those two
clarifications if no one sees a problem with them.

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 5/21/03 1:56:53 PM >>>
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" <[email-masked]> 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:[email-masked] 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 
>>
>>========================================================================

---

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 05 Jun 2003 20:24:23 -0600

My proposed text is:
derefInSearching: While searching, dereference any alias object
subordinate to the base object which is also in the search scope. The
filter is applied to the dereferenced object(s). If the search scope is
wholeSubtree, the search continues in the subtree of any dereferenced
object. Aliases in that subtree are also dereferenced. Servers SHOULD
detect looping in this process to prevent denial of service attacks.

Jim

>>> "Jim Sermersheim" <[email-masked]> 6/5/03 8:15:10 PM >>>

the scope is base. It also doesn't tell me to continue a subtree
search

Jim

alias

Kurt

-

scope
Directory
the
clarifying
and
or
personal
an
shed

---

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 6 Jun 2003 14:48:40 +1000

I'm sorry, but aren't you actually trying to confuse the issue?

A search has only ONE base object. To find that base object is called navigation. You may control dereferencing of aliases in navigation. This is in the commonArguments of X.500 but rolled into a search parameter in LDAP.

Having navigated to an actual entry (which may be an alias), you now start returning results. For each result DN, you may dereference aliases or not, depending on a parameter in the search request. Dereferenced aliases are not new base-objects of THE search. Of course, a subtree search in which aliases are dereferenced has two side-effects -
a) these entries may not appear to be in the orignal scope (can't be helped!)
b) these entries out of scope cause 'new' subtree searches to be included (scary).
It seems to be b) which is giving (understandable) grief. But let's not confuse the types of dereferencing going on with this effect. (The problem seems to be that the dereferenced alias may have subordinates - are these logically part of the orinal scope? Yes - because, if the entry were not an alias, the real entry with its subordinates would have to appear in place of the alias; No - because the subordinates are not in scope!)

Please don't 'over-explain" aliase dereferencing.

Ron

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]]
Sent: Friday, 6 June 2003 12:15
To: [email-masked]
Subject: Re: What Does De-Reference Mean?

Jim

alias

Kurt

-

 

 
scope
Directory
the
clarifying
and
or
personal
an
shed

---

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 6 Jun 2003 15:10:41 +1000

... and to prevent the return of duplicate entries.

OK

Ron

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]]
Sent: Friday, 6 June 2003 12:24
To: [email-masked]
Subject: Re: What Does De-Reference Mean?

My proposed text is:

Jim

Jim

alias

Kurt

-

scope
Directory
the
clarifying
and
or
personal
an
shed

---

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 06 Jun 2003 02:40:17 -0600

Without trying, I guess I did confuse. You went down different path than
the one I intended. My issue (which I will leave alone) is the scenario
where while "navigating", we are not dereferencing aliases and the
search base happens to be an alias. Now, if this is a subtree search, we
*Do not* dereference (one of) the object(s) that we are evaluating
(namely the search base).

In other words, when we deref when searching, and not when navigating,
there is the possibility that the search filter is applied to one alias
(the search base). There is the possibility that an alias object will be
returned from the search. If a server returns an alias object when
derefInSearching is set, it will likely confuse some people (with or
without my help).

Jim

>>> "Ramsay, Ron" <[email-masked]> 6/5/03 10:48:40 PM >>>

A search has only ONE base object. To find that base object is called
navigation. You may control dereferencing of aliases in navigation. This
is in the commonArguments of X.500 but rolled into a search parameter in
LDAP.

Having navigated to an actual entry (which may be an alias), you now
start returning results. For each result DN, you may dereference aliases
or not, depending on a parameter in the search request. Dereferenced
aliases are not new base-objects of THE search. Of course, a subtree
search in which aliases are dereferenced has two side-effects -
a) these entries may not appear to be in the orignal scope (can't be
helped!)
b) these entries out of scope cause 'new' subtree searches to be
included (scary).
It seems to be b) which is giving (understandable) grief. But let's not
confuse the types of dereferencing going on with this effect. (The
problem seems to be that the dereferenced alias may have subordinates -
are these logically part of the orinal scope? Yes - because, if the
entry were not an alias, the real entry with its subordinates would have
to appear in place of the alias; No - because the subordinates are not
in scope!)

Ron

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]] 
Sent: Friday, 6 June 2003 12:15
To: [email-masked] 
Subject: Re: What Does De-Reference Mean?

Jim

alias

Kurt

-

scope
Directory
the
clarifying
and
or
personal
an
shed

---

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 6 Jun 2003 19:30:35 +1000

OK, so you do not deref when navigating, so the base object is an alias. Now you must return the object but deref aliases while doing it. As it is a subtree search, you must explore the new subtree. Is this it?

Hmmmm

Ron

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]]
Sent: Friday, 6 June 2003 18:40
To: Ramsay, Ron; [email-masked]
Subject: RE: What Does De-Reference Mean?

Jim

Ron

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]] 
Sent: Friday, 6 June 2003 12:15
To: [email-masked] 
Subject: Re: What Does De-Reference Mean?

Jim

alias

Kurt

-

scope
Directory
the
clarifying
and
or
personal
an
shed

---

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 06 Jun 2003 07:23:13 -0600

yes, but the language in x.511 and ldapv3 prevents this, and only
_objects subordinate to the base_ may be dereferenced.

>>> "Ramsay, Ron" <[email-masked]> 6/6/03 3:30:35 AM >>>
OK, so you do not deref when navigating, so the base object is an
alias. Now you must return the object but deref aliases while doing it.
As it is a subtree search, you must explore the new subtree. Is this
it?

Hmmmm

Ron

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]] 
Sent: Friday, 6 June 2003 18:40
To: Ramsay, Ron; [email-masked] 
Subject: RE: What Does De-Reference Mean?

Without trying, I guess I did confuse. You went down different path
than
the one I intended. My issue (which I will leave alone) is the
scenario
where while "navigating", we are not dereferencing aliases and the
search base happens to be an alias. Now, if this is a subtree search,
we
*Do not* dereference (one of) the object(s) that we are evaluating
(namely the search base).

In other words, when we deref when searching, and not when navigating,
there is the possibility that the search filter is applied to one
alias
(the search base). There is the possibility that an alias object will
be
returned from the search. If a server returns an alias object when
derefInSearching is set, it will likely confuse some people (with or
without my help).

Jim

A search has only ONE base object. To find that base object is called
navigation. You may control dereferencing of aliases in navigation.
This
is in the commonArguments of X.500 but rolled into a search parameter
in
LDAP.

Having navigated to an actual entry (which may be an alias), you now
start returning results. For each result DN, you may dereference
aliases
or not, depending on a parameter in the search request. Dereferenced
aliases are not new base-objects of THE search. Of course, a subtree
search in which aliases are dereferenced has two side-effects -
a) these entries may not appear to be in the orignal scope (can't be
helped!)
b) these entries out of scope cause 'new' subtree searches to be
included (scary).
It seems to be b) which is giving (understandable) grief. But let's
not
confuse the types of dereferencing going on with this effect. (The
problem seems to be that the dereferenced alias may have subordinates
-
are these logically part of the orinal scope? Yes - because, if the
entry were not an alias, the real entry with its subordinates would
have
to appear in place of the alias; No - because the subordinates are not
in scope!)

Ron

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]] 
Sent: Friday, 6 June 2003 12:15
To: [email-masked] 
Subject: Re: What Does De-Reference Mean?

Jim

alias

Kurt

-

scope
Directory
the
clarifying
and
or
personal
an
shed