Re: LDAP shall speak unto LDAP + first cut at best-first searching

Tim Howes <tim@terminator.rs.itd.umich.edu> Mon, 29 November 1993 18:23 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01849; 29 Nov 93 13:23 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01845; 29 Nov 93 13:23 EST
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa16265; 29 Nov 93 13:23 EST
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.05097-0@haig.cs.ucl.ac.uk>; Mon, 29 Nov 1993 16:00:54 +0000
Received: from terminator.rs.itd.umich.edu by bells.cs.ucl.ac.uk with Internet SMTP id <g.08951-0@bells.cs.ucl.ac.uk>; Mon, 29 Nov 1993 16:00:34 +0000
Received: from vertigo.rs.itd.umich.edu by terminator.rs.itd.umich.edu (8.6.4/2.2) with SMTP id KAA25286; Mon, 29 Nov 1993 10:59:07 -0500
Message-Id: <199311291559.KAA25286@terminator.rs.itd.umich.edu>
To: Simon E Spero <ses@tipper.oit.unc.edu>
cc: ldap@umich.edu, osi-ds@cs.ucl.ac.uk
Subject: Re: LDAP shall speak unto LDAP + first cut at best-first searching
In-reply-to: Your message of "Sat, 27 Nov 93 17:58:59 EST." <9311272258.AA01189@tipper.oit.unc.edu>
Date: Mon, 29 Nov 93 10:59:06 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Tim Howes <tim@terminator.rs.itd.umich.edu>

> From:    Simon E Spero <ses@tipper.oit.unc.edu>
> To:      ldap@umich.edu, osi-ds@cs.ucl.ac.uk

> Now that I have the protocol layer I've been working on a general
> search harness I can plug various strategies into. As I've been
> filling in the blanks, I've come upon what seems to be a nice search
> strategy based on best first search for solving the soft pages problem
> (name->url mapping). Given a few assumptions it should return
> near-optimal results. I'm still a bit fuzzy as to how long the search
> will take, especially when the object being searched for does not exist.
> There may a slight problem in the handling of servers which poll themselves
> which I can't quite spot at the moment. I need more sleep.

Hi Simon.  I'm still a little fuzzy on what it is you're doing and
how it relates to your proposed LDAP extensions.  If you could take
a step or two back and give me the big picture it would be good.
In the meantime...

You have proposed two kinds of changes to LDAP.  One is to handle
CLDAP requests better.  The other is to support the centroid stuff.
The former change is the grouping of requests in a single message,
which allows one to send a bind-search-unbind request, i.e. it enables
authentication with CLDAP.  Is an explicit group-of-messages construct
really needed, or can messages just be grouped together in a single
udp packet and have the same effect achieved?

The latter changes are a little more confusing.  In a previous message,
you said the new "topology" scope and the namedHierarchy and hierarchyName
components were related to centroids.  Is the idea that if you look
at normal LDAP (X.500) it (usually) has a single "topology", that being
a geographical/organizational relationship amongst the servers.  By adding
these new components, you are allowing a server to live in other
topological arrangements, and allowing the client to specify which topology
it wants to search?  So, for example, you are saying there might be a
geographical topology, an organizational topology, a computer professional
topology, a general special interest topology, etc.

About the algorithm in your last message.  It makes sense to me, except
I'm not sure what the cost information is for exactly.  Is it strictly
to be used by the server, or can the client make use of it?  If it's
the client too, how does knowing what the cost of accessing an item is
to the server help the client?                             -- Tim