Re: A philosophical question about large directory structures

This is a multi-part message in MIME format.
--------------D61E70D2DA50B07228CC8CBA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

James and Erik,

Why do we have to argue the superiority of one model over the other? Take for
example the telephone directory. We have been living with two of them (White
Pages and Yellow Pages) since a long time and we don't want to give up any of
them.

Concerning the Universal Directory, I believe that we need both the "dc" and the
"Country/Org." models. Once they become a reality we should keep them in sync.
and rules may be defined for that. One model ("dc") reflects the technology,
while the other one (Country/Organization) reflects the business. As this gets
implemented, we will probably see lots of o=<my_company> registrations at the
top of the tree just like we see so many <my_company>.com today in DNS. This is
something we can not avoid.

Mircea.

James Benedict wrote:

> > -----Original Message-----
> > From: Erik Skovgaard [mailto:[email protected]]
> > Sent: Thursday, July 22, 1999 3:40 PM
> > To: Benedict, James [CAR:5N41:EXCH]; [email protected]
> > Cc: Michel, Ian [FITZ2:8M52:EXCH]
> > Subject: RE: A philosophical question about large directory structures
> >
> >
> > James,
> >
> > I think there is a difference between us on this list and the general
> > public.  You and I are educated about the Internet and used
> > to host names,
> > but the general unwashed public may not be so educated.  For
> > them it is
> > better to think of organizations located in countries or
> > provinces rather
> > than the somewhat cryptic host names.
> >
>
> Once I believed that as well... but I no longer think so.
> The Web has changed that, people now think of www.whatever.com the
> same way they think of a telephone number.  I would actually
> argue that the easiest way to reach the unwashed public is by
> following the anything.whatever.com model.  If I call my completely
> computer illiterate grandmother in the middle of rural canada... she's
> never used a computer (the monitors are hard on her eyes), but she can
> tell me the email address of every one of her grandchildren.
>
> I'm not arguing that the DNS name model isn't cryptic (you can
> consider me unwashed... I had to use a web-search to find
> Canadian Airlines) but I think it is a reasonable model today,
> and will become more and more intuitive as the average person
> becomes internet enabled.
>
> > The example I always give is Canadian Airlines.  Who would
> > ever guess that
> > the host name is 'cdnair.com'?  There a many other examples
> > and it gets
> > worse when an organization has multiple identities (e.g.
> > Citicorp, Citibank
> > and Citigroup) where only one is actually registered in the DNS.
> >
> > Keep in mind that the Directory will be used for many other
> > things than
> > just finding orgaizational people.  What about residential
> > people?  How do
> > they fit into the dc= scheme?  Is there an inherent
> > assumption that every
> > living person will have an Internet host?
> >
>
> The DNS model doesn't preclude the use of geographich identifiers.
> dc=ca and dc=us are both valid domains.  Maybe the real answer
> here is that we need two models... one for residential people and
> one for coprorate people.
>
> > I recognize that the DNS host name is simple to use, but does
> > it solve the
> > problem?  I would rather like to use the Directory to *find*
> > a hostname of
> > an organization rather than using the host name as the basis
> > for the DN.
> > The thinking here is backwards IMHO.
>
> In the end, I think I would rather use the directory to *find* the
> information I need... not guess at a DN.  I've seen many threads (here
> and on other directory lists) that advocate the use of DNs as "pointers
> to entries".  I don't believe that anyone can come up with a naming context
> that will be 100% guessable (I believe that is an oxymoron).  I look at
> DN design from 2 perspectives:
>
> 1) does it logically subdivide my directory tree into usefull sub-trees?
> 2) if I were to browse my directory structure top-down, would each level
>    progressively narrow my search in an intuitive way.
>
> These are user-oriented considerations, if I take a more operational
> approach, I
> am most concerned with how often a DN/subtree will need to be moved, because
> I
> need to consider all of the costs:  modRDN times, PKI cert recalcs,
> Alias/reference
> updates, etc.
>
> At this point I want something as invariant as possible.  At that point
> locality
> seems to make sense... but even then, I don't think location is any less
> variant than
> company.
>
> >
> > Cheers,                 ....Erik.
> >
> > ------------------------------------
> > Erik Skovgaard
> > GeoTrain Corp.
> > Enterprise Directory Engineering
> > http://www.geotrain.com
> >
> > At 13:47 99/07/22 -0400, 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"
> > >> >
> > >>
> > >
> > >
> >

--------------D61E70D2DA50B07228CC8CBA
Content-Type: text/x-vcard; charset=us-ascii;
 name="mpana.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Mircea Pana
Content-Disposition: attachment;
 filename="mpana.vcf"

begin:vcard 
n:Pana;Mircea
tel;pager:+1-613-364-1385
tel;fax:+1-613-591-3680
tel;work:+1-613-599-3600 x6907
x-mozilla-html:TRUE
url:http://www.newbridge.com
org:Newbridge Networks;Messaging and Directory Systems
version:2.1
email;internet:[email protected]
title:Systems Architect
adr;quoted-printable:;;PO Box. 13600.=0D=0A600 March Road;Kanata;Ontario;K2E 2E6;Canada
fn:Mircea Pana
end:vcard

--------------D61E70D2DA50B07228CC8CBA--