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
- LDAP Comments Eric Rosenquist
- Re: LDAP Comments Tim Howes
- Re: LDAP Comments pays
- Re: LDAP Comments Tim Howes
- Re: LDAP Comments pays
- Re: LDAP Comments Alan Shepherd
- Re: LDAP Comments Tim Howes
- Re: LDAP Comments pays
- Re: LDAP Comments Tim Howes
- Re: LDAP Comments pays
- Re: LDAP Comments Alan Shepherd
- Re: LDAP Comments Valdis Kletnieks
- Re: LDAP Comments Tim Howes
- Re: LDAP Comments pays
- Re: LDAP Comments Christian Huitema
- Re: LDAP Comments Tim Howes
- Re: LDAP Comments Steve Kille
- Re: LDAP Comments Christian Huitema