Re: A philosophical question about large directory structures

I think you are omitting scenarios for larger companies like:

    [email protected]

Large corporations need to subdivide their name space so as to effect
routing of messages within their own networks, which are
geography-based.

If they happen to have Joe as a unique entry in an internally
addressable directory they may allow [email protected] and resolve the routing
by an internal lookup.

This example is real.


James Benedict wrote:
> 
> Erik,
> 
> You are right about the size of dc=com, but I think its size is caused
> as much by the fact that we tried to divide DNS up by country as well.
> 
> When you talk in internet terms, I don't think that countries make much
> sense.  This has always been a problem for large enterprises like Nortel
> Networks.
> But, today, even smaller companies (less than 60 employees) have a global
> presence.
> In a location-oriented scheme, where do we put companies like this?
> 
> The internet itself transcends geographical boundries, I think its naming
> contexts need to as well.
> 
> I'de like to re-visit the dc-naming model from an end-user perspective.
> 
> DNS, LDAP & email Alignment
> 
>   The idea here is that my DNS entry maps to the RHS of my email address,
> and that they
>   both map to the dc components of my DIT.
> 
>   (eg)
>   rfc822 = [email protected]
>   DNS = nortelnetworks.com
>   dc=nortelnetworks, dc=com
> 
>   What can I do with this:
> 
>   If I know a user's email address, I can guess that his PKI cert will be
> somewhere in the
>   subtree of dc=nortelnetworks, dc=com.  I could go out on a limb and either
> try
>   [email protected], dc=nortelnetworks, dc=com
>   or
>   DN=userid=grunt, dc=nortelnetworks, dc=com
> 
>   Failing that, I could try to do some sort of search filter with email or
> userid.
> 
>   I could always take a chance that ldap.nortelnetworks.com is a valid
> LDAPv3 server
>   and ask for its schema attribute.
> 
>   Chances are, if I know anything about an organization (besides its name)
> it will be either
>   an email address (with a DNS name) or a web-page (which also has a DNS
> name).  Anything else,
>   I will have to do a search which will likely result in one of the
> previously mentioned pieces
>   of information.
> 
>   Overall, I think that modeling DNS does quickly reduce the search set in
> most cases.  I can
>   also see cases where browsing a country-oriented tree might confuse more
> than help: Which country
>   do you think Nortel is in?  What if I want to lookup someone at my local
> IBM office?
> 
>   Personally, I like the "Keep It Simple" principle.  DNS could have
> benifited from a little better
>   organization (didn't they try country as well), but "If you can't beat
> 'em... join 'em"
> 
> James A Benedict
> Advisor, IP Directory Systems Architecture
> Carrier Packet Solutions
> NORTEL NETWORKS
> Ph:  (613) 763-3909
> 
> > -----Original Message-----
> > From: Erik Skovgaard [mailto:[email protected]]
> > Sent: Thursday, July 22, 1999 12:31 PM
> > To: alexis.bor; 'Tim Howes'
> > Cc: 'Thomas Lenggenhager'; ietf-lsd
> > Subject: RE: A philosophical question about large directory structures
> >
> >
> > Alexis,
> >
> > I still feel very strongly that the dc= naming is a bad
> > thing.  Look at the
> > number of entries immediately under dc=com!
> >
> > The correct thing to do is to reduce the search set quickly
> > (CS 101 as I
> > recall) and the best way we currently have is to use the division by
> > country.  In practice, that is what is done many places
> > around the world.
> >
> > Certainly, we can agree that not all directories will be
> > interconnected,
> > but to make the assumption that none of them will, is plainly a bad
> > assumption.  I think PKI will drive a lot of the interconnection or at
> > least coordination.
> >
> > Cheers,                 ....Erik.
> >
> > ------------------------------------
> > Erik Skovgaard
> > GeoTrain Corp.
> > Enterprise Directory Planning Services
> > http://www.geotrain.com
> >
> > At 16:37 99/06/28 -0400, Alexis Bor wrote:
> > >Tim,
> > >I agree with you that domain names are what people are good
> > at guessing
> > >these days.  I think that we learned that lesson at least
> > twice, once with
> > >email and once with the web.
> > >
> > >I have been preaching the idea of the DN as just a pointer
> > to an entry since
> > >the early 90s and have always hid them from all of my
> > applications.  I'm
> > >glad that others are seeing the value in that, but it has
> > been a long road.
> > >
> > >Naming has always been an ugly thing and it has caused lots
> > of grief to all
> > >of us in the directory space, as well as others.  Everyone
> > seems to take
> > >names very seriously - and understandably so.  The real
> > question is how to
> > >do we get past that.  I think that dc naming gets us part of
> > the way there.
> > >What we need is a mechanism where if we don't know the dc,
> > to go out and
> > >find it - and hopefully we can do that with protocol most of
> > the time.
> > >
> > >You made an interesting comment early on in this thread that
> > 4 years ago you
> > >realized that directories wouldn't be all connected and that
> > it was probably
> > >a bad thing if they were.  I tend to disagree with that.  I
> > think that you
> > >were right 4 years ago that the current method of doing it
> > was not workable
> > >for both social and technical reasons.  However, that
> > doesn't remove the
> > >need for doing it some day.  If you think of DNS as a form
> > of directory,
> > >then it is possible and is useful.  I think that there are
> > many applications
> > >that are currently disabled because they can't get to
> > information that could
> > >be stored in directories.
> > >
> > >We are on the verge of having directories deployed in almost
> > every company
> > >with an IT department on the planet, many of them will have multiple
> > >directories from multiple vendors.  At that point, it will
> > be clear that we
> > >need to quickly figure out how to do it, and the rewards
> > will be great.
> > >Just think back of what it was like to maintain HOSTS tables
> > for every
> > >system running IP, and that wasn't very long ago.  I think
> > that twenty years
> > >from now, we'll be talking about the good 'ol days when
> > business to business
> > >communication that uses directories was just a dream that
> > many of us were
> > >saying would never happen.  And noone will believe that they
> > made routers
> > >and hubs that didn't use DEN...
> > >
> > >-- Alexis
> > >
> > >
> > >Alexis Bor
> > >Directory Works, Inc.
> > >P.O. Box 470276
> > >Celebration, FL  34747-0276
> > >407-566-9250
> > >407-566-9251 (FAX)
> > >[email protected]
> > >http://www.directoryworks.com
> > >
> > >
> > >> -----Original Message-----
> > >> From: [email protected]
> > >> [mailto:[email protected]]On Behalf Of
> > >> Tim Howes
> > >> Sent: Wednesday, June 23, 1999 6:58 PM
> > >> To: Erik Skovgaard
> > >> Cc: Thomas Lenggenhager; [email protected]
> > >> Subject: Re: A philosophical question about large
> > directory structures
> > >>
> > >>
> > >> Just an opinion, but I don't think anybody wants to
> > >> guess at distinguished names. I actually think it's
> > >> likely to be significantly less effective than trying
> > >> to guess domain names, which people seem to be guessing
> > >> or otherwise figuring out today without too much
> > >> trouble. And I don't think any respectable user agents
> > >> will support guessing except possibly as some last
> > >> resort mode of operation. We've seen directory clients
> > >> moving more and more toward hiding DNs from users, and
> > >> I think that's a very good thing and one we're likely
> > >> to see increasingly.                 -- Tim
> > >>
> > >> Erik Skovgaard wrote:
> > >> >
> > >> > Thomas,
> > >> >
> > >> > I agree that namespaces have to be unique, but I *also*
> > >> believe they should
> > >> > make sense to users.  Granted, *some* host names are
> > >> user-friendly, but
> > >> > many are not.
> > >> >
> > >> > In the specific example you mention, I would suggest that {o=Sun
> > >> > Microsystems, c=ch} is a reasonable and guessable
> > >> namespace.  I would not
> > >> > venture to guess what your hostname is.
> > >> >
> > >> > Cheers,                  ....Erik.
> > >> >
> > >> > -----------------------------------
> > >> > Erik Skovgaard
> > >> > GeoTrain Corp.
> > >> > Enterprise Directory Engineering
> > >> > http://www.geotrain.com
> > >> >
> > >> > At 23:41 99/06/23 +0200, Thomas Lenggenhager wrote:
> > >> > >On Wednesday, 23 Jun 1999, Erik Skovgaard writes:
> > >> > >> The DC namespace is poorly suited for the Directory
> > >> since the Internet host
> > >> > >> names are not all guessable.  For instance, if I were to
> > >> look up Canadian
> > >> > >> Airlines, I would have to *know* that the hostname is
> > >> 'cdnair.com'.
> > >> > >
> > >> > >We are going a bit off track with these messages about
> > namespace.
> > >> > >
> > >> > >The namespace should mainly be unique. That would be
> > >> provided by DC.
> > >> > >Finding something should not be tried to achieve by
> > >> guessing the right
> > >> > >name, but by searching for it (index/directory).
> > >> > >
> > >> > >> Since the Directory name registration is closely tied to
> > >> the legal names of
> > >> > >> companies in most countries, I think that makes for a
> > >> much better choice.
> > >> > >> I would rather find Canadian Airlines as {o=Canadian
> > >> Airlines, c=ca} than
> > >> > >> the somewhat cryptic {dc=cdnair, dc=com}.
> > >> > >
> > >> > >And how about the official name of Canadian Airlines in
> > >> French and the
> > >> > >DN you proposed?
> > >> > >
> > >> > >What is the official name of a company?
> > >> > >       Acme    or Acme Inc.    or Acme, Inc.
> > >> > >
> > >> > >Just as an example of quite ugly and non-guessable names,
> > >> the official
> > >> > >name of Sun in Switzerland:
> > >> > >       Sun Microsystems (Schweiz) AG
> > >> > >
> > >> > >Thomas
> > >> > >
> > >> > >
> > >>
> > >> --
> > >> Tim Howes
> > >> Vice President, Technology
> > >> Office of the CTO
> > >> America Online, Inc.
> > >>
> > >
> > >
> > >
> > >Attachment Converted: "d:\Program Files\Eudora\Attach\Alexis Bor
> > (E-mail)3.vcf"
> > >
> >