Re: re : X.500 -Reply
Chris Weider <clw@bunyip.com> Tue, 26 September 1995 15:58 UTC
Received: from ietf.nri.reston.va.us 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 haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa13377; 26 Sep 95 11:58 EDT
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.07520-0@haig.cs.ucl.ac.uk>; Mon, 25 Sep 1995 22:39:26 +0100
Received: from sun2.nsfnet-relay.ac.uk by bells.cs.ucl.ac.uk with UK SMTP id <g.29819-0@bells.cs.ucl.ac.uk>; Mon, 25 Sep 1995 22:39:15 +0100
Received: from mocha.Bunyip.Com by sun2.nsfnet-relay.ac.uk with Internet SMTP id <sg.29444-0@sun2.nsfnet-relay.ac.uk>; Mon, 25 Sep 1995 22:35:52 +0100
Received: from kosh.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA06480 (mail destined for DaveHU@novell.com); Mon, 25 Sep 95 14:32:39 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Chris Weider <clw@bunyip.com>
Received: (clw@localhost) by kosh.bunyip.com (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: <199509251836.OAA01980@kosh.bunyip.com>
To: Ed_Reed@novell.com, maciag@server1.deltanet.com, pays@gctech.edelweb.fr
Subject: Re: re : X.500 -Reply
Cc: DaveHU@novell.com, Jeff_Hawkins@novell.com, Lenley_Hensarling@novell.com, THasan@novell.com, Therron_Powell@novell.com, osi-ds@cs.ucl.ac.uk
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 posted. Chris
- re : X.500 -Reply Ed Reed
- Re: re : X.500 -Reply Sylvain Langlois
- Re: re : X.500 -Reply Chris Weider
- Re: re : X.500 -Reply Chris Weider