Re: Directory Services Work coordination proposal

Simon E Spero <ses@tipper.oit.unc.edu> Sat, 13 November 1993 01:18 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15858; 12 Nov 93 20:18 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15854; 12 Nov 93 20:18 EST
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa28306; 12 Nov 93 20:18 EST
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.09542-0@haig.cs.ucl.ac.uk>; Fri, 12 Nov 1993 23:53:46 +0000
Received: from tipper.oit.unc.edu by bells.cs.ucl.ac.uk with Internet SMTP id <g.11529-0@bells.cs.ucl.ac.uk>; Fri, 12 Nov 1993 23:53:25 +0000
Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA11047; Fri, 12 Nov 93 18:52:58 EST
Message-Id: <9311122352.AA11047@tipper.oit.unc.edu>
To: "Barry M. Leiner" <leiner@nsipo.nasa.gov>
Cc: "Erik Huizer (SURFnet BV)" <Erik.Huizer@surfnet.nl>, RARE & IETF OSI-DS wg <osi-ds@cs.ucl.ac.uk>, ietf-wnils@ucdavis.edu, apples@surfnet.nl
Subject: Re: Directory Services Work coordination proposal
In-Reply-To: Your message of "Fri, 12 Nov 93 13:08:54 PST." <9311122108.AA22432@dscs.arc.nasa.gov>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 12 Nov 1993 18:52:57 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Simon E Spero <ses@tipper.oit.unc.edu>

I think there have been two major philosphical breakthroughs that make
me much more hopeful for the future of a globally useful white pages 
service. 

The first breakthrough is the death of the universal namespace; like 
Russel's universal set, there is no one directory name space that can be
used for general purpose searching. An arbritrary namespace can be created
to optimise simple directory lookups, but assigning deeper meaning to the
name is an exercise in futility. 

Several new techniques can now be used to get rid of namespace hangups. One 
of the more powerful of these techniques is the passing round of forwarding
information (termed centroids in my document). These allow the searchspace
to be pruned dramatically. Making global searches more practical. 

  Another technique is allowing each directory server to be a member of 
multiple hierachies. The examples used in the whois++ index architecture
document were "topological", "geographical", and "administrative". The 
administrative hierchacy corresponds to the DNS or X.500 namespaces. The
hierachy is ordered purely on administrative grounds; the terms at each
level can be made unique simply by administrative fiat; this hierachy is
very suitable for simple DNS style lookups.

  The other two hierachies, geographical and topological, are more useful
for yellow-pages style searching. The topological hiearchy corresponds to
a sites network connections. If I wanted to find a copy of gnu emacs, 
the best result is the one closest to me by network. By starting at my 
local server, and then spreading outwards by following topology links, I'll
soon find the closest copy. This feature will be particularly important when
the directory is linked to a caching file-store. This hiearchy offers a 
solution to the "soft-pages" problem.

  The geographical hiearchy corresponds to the actual, physical, geographical 
location of a server. Although this hiearchy would seem to be related to 
topology, for nearly every major corporation this is not the case. If 
an engineer at Sun's Research Triangle Park facility wanted to find a 
plumber, a list of firms based in Mountain view is going to be of no
use whatsoever. Geographical searching can be handled in a similar way 
to topological searching; however in this case the ability to start the 
search at a particular node becomes extremely useful. If I wanted to 
buy  Erik a pizza, I could start my search at a SURFnet server, and then
fan out until I found a suitable company. I could even check his directory
entry to see if he had a listing for favouriteToppings. This hiearchy 
offers a solution to the "restaurant schema" problem.

  None of these techniques are specific to whois++; i'm currently working 
on an implementation of an extended version of CLDAP to handle these changes
(mail me if you'ld like a copy)
The main change is adding support for referrals back into the LDAPs
 In general, any directory service that can support referrals can be made to 
work with this scheme.

The second breakthrough is the general understanding that, Even if you build it
, people won't come if there's no parking and the hot-dogs cost $95. The 
entry cost has to be kept extremely low, setting up servers should be 
matter of typing make, and the instructions for maintaining and updating
an entry should be able to fit on a sheet of A4. Maintaining directory 
entries is a chore that generally only benefits other people- unless
adding an entry is as simple as writing your name, people will treat it as 
yet another stupid form. 

New, lightweight protcols like {C}LDAP, SOLO, and whois++ go a long way to 
addressing these problems. Allowing updates by email, using an encoding like
STIF, or SHAVE with shortrefs is also a big win. Don't tell people about
useful, but non-obvious fields until they're ready to move on from the basics.

In a meeting today with the UNC Internation Studies centre, who are 
compiling a directory of faculty with international activities, an
attempt to get a spec for the schema they wanted let to a flurry of 
different attributes, whose semantic differences would probably not have 
been significant for the entire remaining lifetime of the Nation-state. 

  One simple question managed to get things focused again. 
"If this were a form and I dropped it on your desk, would you bother to
fill it out?"

Simon // Suppose they threw a directory and nobody came.