Subject: Re: What Does De-Reference Mean?

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 27 Mar 2003 15:42:53 -0800

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: Chris Harding <[email-masked]>
Date: Fri, 28 Mar 2003 16:18:01 +0000

Hi, Kurt -

Thanks for this response. It clearly implies that if there is an entry 
"Jonathan Adams" and an alias entry "Jonny Adams" that points to it then:

    - a search for "Jonathan Adams" with alias dereferencing requested
      should return the Jonathan Adams entry

    - a search for "Jonny Adams" with alias dereferencing requested
      should not return either entry.

Does anyone disagree with this interpretation?

At 15:42 27/03/2003 -0800, Kurt D. Zeilenga wrote:
> >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.
> >
> >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
> >+++++
> >

Regards,

Chris
+++++

             The Open Group's Consortia Services - Association Management 
For I.T.:
             http://www.opengroup.org/consortia_services

---

From: David Chadwick <[email-masked]>
Date: Sun, 30 Mar 2003 13:06:35 -0800

Chris

I dont disagree with your interpretation, but it shows something that we
found out years ago in the Paradise project, that it is better to simply
search for surname rather than full name, as you are more likely to find
the person. This is because you dont know if the directory stores common
names as D.W.Chadwick, David Chadwick, Chadwick, D.W. etc. and all 3
were present in Paradise.

regards

david

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************

---

From: Chris Harding <[email-masked]>
Date: Mon, 31 Mar 2003 11:29:10 +0100

Hi, David -

Thanks for your response!

What you point out is very relevant to directory usage guidelines. There is 
in fact a Directory Best Practice Guide activity that The Open Group 
supports and for which we host the web page and mail list, see 
http://www.opengroup.org/dif/bpg/. Certifying directory servers is however 
a different kind of activity. For this purpose we need to look at what the 
RFCs really say, rather than at what is the best way to use them.

Regards,

Chris
+++++