Re: re : X.500 -Reply

Chris Weider <> Tue, 26 September 1995 15:58 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa11391; 26 Sep 95 11:58 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11387; 26 Sep 95 11:58 EDT
Received: from by CNRI.Reston.VA.US id aa13377; 26 Sep 95 11:58 EDT
Received: from by with local SMTP id <>; Mon, 25 Sep 1995 22:39:26 +0100
Received: from by with UK SMTP id <>; Mon, 25 Sep 1995 22:39:15 +0100
Received: from mocha.Bunyip.Com by with Internet SMTP id <>; Mon, 25 Sep 1995 22:35:52 +0100
Received: from kosh.Bunyip.Com by with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA06480 (mail destined for; Mon, 25 Sep 95 14:32:39 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Chris Weider <>
Received: (clw@localhost) by (8.6.9/8.6.10) id OAA01980; Mon, 25 Sep 1995 14:36:46 -0400
Date: Mon, 25 Sep 1995 14:36:46 -0400
Message-Id: <>
Subject: Re: re : X.500 -Reply

Hi Ed, Paul-Andre, and others:
  I agree (quelle suprise :^) ) with most of what Paul-Andre has said.
I just wanted to make several additional points about WHOIS++ and the
Harvest Gatherer.

First, it is entirely possible that in some *very limited* aspects, WHOIS++
will look more and more like X.500 (88). There are a large number of
valuable lessons that were learned in the attempted deployment of X.500
that are immediately applicable to ANY global information system which is
intending to provide global or semi-global view of the data space to the
users. We intend to look very closely at this work as the distributed
management issues become more important. 

As to finding specifically named objects in WHOIS++, that is possible.
Each server has a unique server handle and each record within the server has
a unique ID. The critical point of difference is that the namespace
in WHOIS++ is disconnected from the global navigation techniques. 
If we wished to recreate the DIT in WHOIS++ to resolve record handles, that
would be perfectly possible. But in X.500, all navigation is tied so closely
to the namespace that one is REQUIRED to manipulate the record namespace to
find the records. In our view, this is like indexing and organizing
all the records on a single attribute which is frequently not even the one
searched for.

I think that the general philosophy we have taken in the development of 
WHOIS++ is to start as simple as possible and then add on gradually the
other functionality the users demand. This allows us to make sure that each
part works before adding on the next.

If the users demand such things as fully configurable access control lists,
we'll look at adding them to the protocol. But a 3 or 4 level access technique
(us, them, and everyone else) certainly seems to cover the majority of cases.
The rest is functionality looking for a market, it seems to me.

We've been looking at potential interactions between the Harvest Gatherer
and WHOIS++ for some time now. There may be a good fit; I'll keep people