Re: A philosophical question about large directory structures

Tim,

See below.

At 14:00 99/06/24 -0700, Tim Howes wrote:
>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?

You seem to forget that the Internet is already divided into countries.
Each country already has a domain registration service.  So why would this
be any different?  The big problem is the very large .com domain that will
be bearly impossible to organize.

>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

Now, Tim, when was the last time you believed TV?  Was it mr Rogers?  :-)

Global economy is fine, but you are still going to deal with local laws
somehow.  A DN that reflects the country just makes that easier.  In fact,
the US has some of the strongest laws barring you from trading with little
bad countries, so having the country in the DN may even help you.

>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?

That is a real problem.  Everybody wants to be in the .com domain and as we
have all agreed (unless I am wrong), it may be hard to find unique names in
that domain.

I think we can agree that no name space is ideal.  We are just talking
about the degree of pain.  My personal opinion is that starting with a very
large flat space at the top of the DIT is a very bad idea.

>
>> >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,

Search engines do not return very accurate results.  I think of the
Directory as somewhat more derterministic.  I don't think we can compare
the two at all.

>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.

I agree that is a hard one.
>
>> >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

Well, from my perspective, PKI is driving directories a good deal.  And
most of the services I have planned have gone through the proper
registration procedures - just so they could be sure to "own" the namespaces.

>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.

True, we still need to be able to find the subtrees.  But it *does* narrow
the search if I can focus on one country rather than the whole world.


>
>> >> 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.

Not if you want to use the Directory to *find* email addresses and web
pages the first place.  And you are not addressing the problem.  It may
work for Netscape, but not for Canadian Airlines.  Had I not been a
frequent flyer, I may never have found the URL of the latter.



>
>> 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

Here I agree with you 100%.  However, that is not a technical issue.  And
this is unique to the US, I may add.  We are close to having the problem
solved in Canada :-)  

Cheers,                    ....Erik.

---------------------------------------
Erik Skovgaard
GeoTrain Corp.
LDAP & X.500 Training and Consulting
http://www.geotrain.com

>
>