Re: A philosophical question about large directory structures

Erik Skovgaard wrote:
> 
> >> If you do not somehow guess the upper levels of a DIT, you would always
> >> have initiate large searches before finding the subtree you are looking
> for.
> >>
> >> Right now you can pretty much assume that most commercial entities will be
> >> under the .com domain, but what happens when we have many other TLDs?  Is
> >> every single client going to maintain a list of all the second level
> >> domains?  Even if they did (which would require a client with lots of
> >> memory), I would still find host names that may not look like a company
> >> name at all.
> >
> >I don't think there is any hope of a guessing approach or a "search
> >everything across many servers" approach to work.  A "directory or
> 
> But we are talking about limiting the search here.  If the DIT is divided
> into countries, we at least have a good start.

What does an Internet user know about countries?
I thought the whole point of the Net was to create
a global economy. At least, that's what I heard on
TV. :) If step one to finding something is to know
the country it's in, we've lost. One could argue
that things should be listed in the countries or
other portions of the tree where they want to be
found, but that doesn't work. You end up with
everybody listing everywhere. Who doesn't want
to be found everywhere people are looking?

> >directories" will be needed, which is what I thought CIP was all about.
> >To find someone you need to do both of these steps:
> >
> >1) Locate the directory service or services that might have information
> >about the person.
> >
> >2) Search the services (by contacting organization-specific servers or
> >similar) and retrieve information about the person you are seeking.
> 
> As you point out below, who is going to set up the key DSA?  Using my
> proposal you simply pass the buck to each country and it is up to them to
> establish an infrastructure that works.  Of course, that may be a problem
> in the US :-)

Passing the buck is not going to solve the problem.
How do people find things today on the web? They
go to a search engine. There are many of these,
providing a good amount of choice for people. From
a technical perspective, providing a similar service
that lets you find directories rather than web pages
is not hard. The problem is creating the incentive
for somebody to do it.

> >LDAP is sufficient for 2) but not for 1) by itself.  Actually, the
> >problem is not with LDAP but, as many others here have pointed out, it
> >is with registering directory services and building a global service.
> >There is no incentive for anyone to do it... and not enough incentive
> >for everyone to play nice together to build it.
> 
> Exactly!  That has always been our problem.  However, with PKI as the
> incentive many countries are actually setting up a name registration
> authority.

I doubt that PKI is going to be the thing that
provides sufficient incentive to solve this
problem. And anyway, the problem is not one of
namespace registration. Suppose we had a global
namespace everybody agreed on. So what? How does
that put me any closer to being able to find what
I want? I don't think it does.

> >> Some companies are lucky enough to have "good" domain names (such as
> >> Netscape), but many will not.  I would rather see the Directory as an aid
> >> to finding the hostname than using an artificial and at times misleading
> name.
> >>
> >> We are talking about a Directory infrastructure that should be able to
> >> scale significantly.  I shudder just thinking of the large number searches
> >> that would be required if the .com domain were divided up among thousands
> >> of DSAs.  Who would maintain the knowledge references?
> >>
> >> I would argue that the .com name space is simply too flat.
> >
> >I doubt it... how many .com domains are there today?  Also, the
> 
> I do not have the number, but certainly a few orders of magnitude more than
> there are countries.

I would bet there are fewer .com domains than web
pages, and despite all the complaints I'm sure we
all have about the inadequecies of search engines,
they basically work.

> >"directory of directories" approach nicely separates the naming problem
> >(I say use dc naming but use whatever you like) from the directory
> >service location problem.  Tying these two problems together too tightly
> >is a hopeless approach.  It hasn't worked so far.
> 
> It seems to me that you are trying to tie the naming schema and the server
> location together.  I want them separated so I can ensure user-friendly
> Directory names.

"User-friendly directory name" sounds like an oxymoron
to me. Directory names should be hidden from users as
much as possible. To the extent that they are exposed,
wouldn't it be nice if they had some relationship to
something users already use and understand, like email
addresses or domain names.

> A "directory of directories" would be nice, but the practical problem of
> agreeing on who should run it and in which country it should live is a
> recipe for disaster.

The problem is thinking of this directory of directories
as some kind of public service that is tied to some
governmental responsibility. The government (in the US,
anyway) no longer funds NSFNet, DNS, or other key infrastructure
components. All those things have been privatized. If
we want something like a directory of directories to
exist, we need to figure out the business model behind it.
If there is no incentive, then ultimately maybe it does
not really need to exist.                 -- Tim