Re: Whois++ and X.500

Chris Weider <> Wed, 27 September 1995 21:24 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa18045; 27 Sep 95 17:24 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18041; 27 Sep 95 17:24 EDT
Received: from by CNRI.Reston.VA.US id aa21320; 27 Sep 95 17:24 EDT
Received: from by with local SMTP id <>; Wed, 27 Sep 1995 21:48:06 +0100
Received: from mocha.Bunyip.Com by with Internet SMTP id <>; Wed, 27 Sep 1995 21:47:53 +0100
Received: from kosh.Bunyip.Com by with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22540 (mail destined for; Wed, 27 Sep 95 16:47:44 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Chris Weider <>
Received: (clw@localhost) by (8.6.9/8.6.10) id QAA02745; Wed, 27 Sep 1995 16:51:52 -0400
Date: Wed, 27 Sep 1995 16:51:52 -0400
Message-Id: <>
Subject: Re: Whois++ and X.500

Hi Mark:
  The question I have about your approach is that while I think that
it would work for White Pages (i.e. people information) I'm not sure that
it would work for Yellow Pages or Resource Location. If you want to limit
the application of X.500 (mod WHOIS++) to White Pages, I think that would
be o.k., but the sense I've gotten over the past 5 years is that any Directory
Service is immediately going to be pushed into all these other applications.

In a Yellow Pages or Resource Location framework, it is very difficult to
determine a priori which attributes should be searchable and which should not.
And again, unless you put all of these indices at the root of the DIT, someone
has to know enough about the DIT to navigate to the proper index server.

As a bit of history, I started out in late 1990 trying to put file information
and network information (as a part of the FOX.500 project at Merit) into
X.500. The proper location of the information immediately became problematic
because the namespace was too tightly tied to navigation. 
Do I put this information under Merit? Do I create a new part of the DIT?
Does it go under the root? Does this scale? The primary problems (and ones
which have *still* not been addressed) are:

Object class hierarchies designed for management, not the addition of
  new information

DN being the only determinant of location

Inability to split a given level of the tree across multiple servers
 (required to avoid having to either coalesce multiple submanagement
  domains onto a single server, which has replication problems, or to
  explicitly detail the split and encode it in the namespace)

Local object class determination through the protocol

Attempting to solve these problems in the current standard is going to 
require major effort. And I think at this point that attempting to 
undo a lot of the current X.500 assumptions is going to make things
even more heavyweight than they are now. 

I'm sorry to be so negative here. But I do think that a fresh approach that
starts out light and adds complexity as needed is best.