Re: Whois++ and X.500

Mark Wahl <mark@wahl.austin.tx.us> Wed, 27 September 1995 19:58 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16364; 27 Sep 95 15:58 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa16360; 27 Sep 95 15:58 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa18984; 27 Sep 95 15:57 EDT
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.07063-0@haig.cs.ucl.ac.uk>; Wed, 27 Sep 1995 17:36:18 +0100
Received: from felix.austin.isode.com by bells.cs.ucl.ac.uk with Internet SMTP id <g.28113-0@bells.cs.ucl.ac.uk>; Wed, 27 Sep 1995 17:36:00 +0100
Received: from next.wahl.austin.tx.us by felix.austin.isode.com with Internet SMTP (PP); Wed, 27 Sep 1995 11:33:57 +0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Mark Wahl <mark@wahl.austin.tx.us>
To: D.W.Chadwick@iti.salford.ac.uk
Cc: osi-ds@cs.ucl.ac.uk
Reply-To: M.Wahl@isode.com, mark@wahl.austin.tx.us
Subject: Re: Whois++ and X.500
Date: Wed, 27 Sep 1995 11:32:32 -0800
X-Orig-Sender: me@next.wahl.austin.tx.us
Message-ID: <9509271558.aa18984@CNRI.Reston.VA.US>

> So, how about turning the problem on its head. Instead of writing off X.500
> because of its limitations, and looking to Whois++ as the panacea (which
> incidentally has taken a lot of ideas from X.500 in its design, these
> similarities with X.500 became very clear at the presentation), we take the
> good ideas from Whois++ and build them into X.500.

I too have been doing some thinking of how Whois++-style indexing could be used
to ease the problem of searches based at country and root levels, where a large
number of organizational DSAs would potentially need to be contacted.

An approach I have been considering would be to use the DISP framework, with an
update mechanism that would transfer from an organizational to a country-level
DSA only values of attributes which are commonly searchable, such as 
commonName and surname.  Non-searchable attributes would not be included, nor 
would any naming or structural information. 

(The index information might be structured something like
 SET OF SEQUENCE { AttributeType, SET OF AttributeValue }.  It would be 
 wrapped in an ASN.1 EXTERNAL and placed in the refresh info otherStrategy.)  

When a subtree search arrives at the country-level DSA, it would typically need
to multi-chain to all the subordinate DSAs.  However if it is consuming index
information from one or more subordinates, and the search filter did not match 
values in their indicies then it would not need to contact those subordinates.
If it did match an index value it would still need to contact the subordinate 
DSA which would perform the search operation.  This additional function would 
be transparent to DUAs, and to DSAs which do not participate in indexing.

Using DISP as the transfer mechanism simplifies its implementation in X.500(93)
DSAs which would be using it for ordinary shadowing, for they would already 
have implemented some forms of update scheduling, refresh generation and 
such for the total or incremental updates.  There would probably be a few
significant differences, for instance DISP only covers a single naming context
while the index information would be most useful if it was taken from a merge
of a naming context and all its subordinate contexts. 

Other issues include how to reduce the amount of information which would need 
to be transferred, such as using soundex or other hash codes for string-valued 
attributes.  

		--------------------------------------------
	Mark Wahl; <mark@wahl.austin.tx.us>;Home account of <M.Wahl@isode.com>