Re: LDAP Comments

Tim Howes <tim@terminator.rs.itd.umich.edu> Fri, 07 May 1993 21:59 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19078; 7 May 93 17:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19074; 7 May 93 17:59 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa26729; 7 May 93 17:59 EDT
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.03486-0@haig.cs.ucl.ac.uk>; Fri, 7 May 1993 14:57:46 +0100
Received: from terminator.rs.itd.umich.edu by bells.cs.ucl.ac.uk with Internet SMTP id <g.27803-0@bells.cs.ucl.ac.uk>; Fri, 7 May 1993 14:57:11 +0100
Received: from vertigo.rs.itd.umich.edu by terminator.rs.itd.umich.edu (5.67/2.2) with SMTP id AA00383; Fri, 7 May 93 09:55:56 -0400
Message-Id: <9305071355.AA00383@terminator.rs.itd.umich.edu>
To: Christian Huitema <Christian.Huitema@sophia.inria.fr>
Cc: Valdis Kletnieks <valdis@black-ice.cc.vt.edu>, pays@faugeres.inria.fr, osi-ds@cs.ucl.ac.uk
Subject: Re: LDAP Comments
In-Reply-To: Your message of "Fri, 07 May 93 10:51:58 +0200." <199305070851.AA02600@mitsou.inria.fr>
Date: Fri, 07 May 1993 09:55:54 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Tim Howes <tim@terminator.rs.itd.umich.edu>

> From:    Christian Huitema <Christian.Huitema@sophia.inria.fr>
> To:      Valdis Kletnieks <valdis@black-ice.cc.vt.edu>

>  (2) It is FALSE to believe that LIST can be equated by "search one level
>      with Filter: object-class present, return only names". The LIST results
>      can be returned with minimal duplications -- only need to know the RDNs
>      of the subordinate entries. The SEARCH result need to access the content
>      of the entry, hence require to either duplicate all subordinate entries
>      on the DSA holding the base name or to chain the SEARCH request to all
>      DSAs holding subordinate information. Or to recognize the particular
>      kind of "match all" filters, and convert search to list in the DSA -- but
>      that is hardly a standard feature!

I agree with much of this, but I don't think it's correct to say that
all you need to know are the RDNs of subordinate entries for list.
Perhaps I am missing something here, but here's why I think that
list is not as simple as you do.  From X.518, section 18.7.2.1.1
on "List procedure":

"This procedure applies where the List request has nameResolutionPhase
component of OperationProgress set to notStarted or proceeding and where
the DSA, after performing Name Resolution finds that it holds the base
object.

	The base object will be denoted by "e".

	1) Get each locally held immediate subordinate of e to form a
	   local set of results.  Set aliasEntry and fromEntry in listResult
	   as appropriate.

	2) Get the set of non-specific subordinate references and
	   subordinate references to DSAs which hold immediate subordinates
	   of "e".

	3) Pass the subrequest with base object = e, and OperationProgress
	   set to completed to the Operation Dispatcher which subsequently
	   forwards it to each DSA which holds immediate subordinates of e.

	Note - If the DSA holds subordinate references with an indication
of whether or not the subordinate entry are aliases, and the dontUseCopy
is FALSE, then this step can be omitted for those entries.  The information
about the subordinates is available directly."

It seems to me that for both list and search to work well (i.e. without
chaining to all subordinates), two things need to be true:

	1) The dontUseCopy service control has to be FALSE.  If it is
	TRUE, the DSA has to chain for both search and list, unless it
	is master for everything.

	2) The DSA getting the request must replicate certain information.
	For list, the information that needs replicating is small and is
	only an indication of whether each subordinate is an alias or not.
	For search, the information that needs replicating is whatever
	information is needed by the search.  For a search for objectClass
	present, return only names, this is only the objectClass attribute,
	which is not sensitive and would, incidentally, also tell whether
	an entry was an alias or not.

So in summary, it seems to me that the list and search operations cause
chaining to occur in very similar circumstances.

Have I misunderstood the standard here, or is my summary correct?  How
do other implementations handle list when dontUseCopy is TRUE?  It seems
pretty clear to me, but like I said I could be confused.

> By the way. LDAP is been advanced to "proposed internet standard" status by
> the IESG, but the discussion seem to indicate that there is no formal
> agreement in the working group. Do you expect that there will be serious
> modifications and that the protocol should be resubmitted?

I do not expect there to be serious modifications to LDAP, at least not
until somebody can convince me I am wrong ;-).  There was, at one time,
consensus in the working group that LDAP should be advanced.  I believe
that consensus still exists.  There have been some late-breaking
comments in the past few days, but I believe these comments have been
satisfactorially addressed.  If others disagree, they should speak up
now and say whether they really think that LDAP should be kicked back
to the working group.                                        -- Tim