Reply to Whois++ and X.500 Wed, 27 September 1995 21:23 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa18006; 27 Sep 95 17:23 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18002; 27 Sep 95 17:23 EDT
Received: from by CNRI.Reston.VA.US id aa21290; 27 Sep 95 17:23 EDT
Received: from by with local SMTP id <>; Wed, 27 Sep 1995 21:41:57 +0100
Received: from by with Internet SMTP id <>; Wed, 27 Sep 1995 21:41:46 +0100
Received: from by; Wed, 27 Sep 95 15:42:58 -0500
Default-Recipient-Options: report nonreceipt, no reply, return content
Subject: Reply to Whois++ and X.500
In-reply-to: Your message of "26 Sep 95 10:27:00" <>
Sensitivity: personal
Importance: normal
Priority: non-urgent
Delivery-Options: allow alternate recipients, return content, allow conversion, mask P1 recipients
Date: Wed, 27 Sep 95 15:46:48 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
Message-Id: <>

>Having just returned from a very interesting presentation about Whois++ at the
>recent Nameflow-Paradise meeting, it seems that the designers have one very
>good feature for searching for information, that X.500 does not have, and that
>is the ability to index on any attribute value or type, rather than simply
>on the distinguished RDN value, and to pass these indices up to the centroids
>(this was mentioned by Chris in his last message)

I am certainly at a loss as to the meaning of this paragraph.  Do you refer
to the linkage by DN from the X.500 subtree held by one DSA to the subtree
held by another, subordinate DSA?  The X.500 Standards do not limit search
to some set of attributes, so to what feature does this indexing refer.

Does the paragraph mean that the owner of the Whois++ centroid must have access
to every value I hold in my Whois++ directory in order for me to offer search
against those values?  I know I can offer search X.500 values to a particular
set of users without having to expose the values to other sites.  Even the X.500
RDN values need not be exposed if NSSRs are used to link DSAs.

Thanks, Jim Reed
	Control Data Systems.