Architecture of the Whois++ Index Service
RFC 1913

Document Type RFC - Historic (February 1996; No errata)
Authors Chris Weider  , Simon Spero  , Jim Fullton 
Last updated 2013-03-02
Stream Internet Engineering Task Force (IETF)
Formats plain text html pdf htmlized (tools) htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 1913 (Historic)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          C. Weider
Request for Comments: 1913                                        Bunyip
Category: Standards Track                                     J. Fullton
                                                                S. Spero
                                                           February 1996

               Architecture of the Whois++ Index Service

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.


   The authors describe an architecture for indexing in distributed
   databases, and apply this to the WHOIS++ protocol.

1. Purpose:

   The WHOIS++ directory service [Deutsch, et al, 1995] is intended to
   provide a simple, extensible directory service predicated on a
   template-based information model and a flexible query language. This
   document describes a general architecture designed for indexing
   distributed databases, and then applys that architecture to link
   together many of these WHOIS++ servers into a distributed, searchable
   wide area directory service.

2. Scope:

   This document details a distributed, easily maintained architecture
   for providing a unified index to a large number of distributed
   WHOIS++ servers. This architecture can be used with systems other
   than WHOIS++ to provide a distributed directory service which is also

3. Motivation and Introduction:

   It seems clear that with the vast amount of directory information
   potentially available on the Internet, it is simply not feasible to
   build a centralized directory to serve all this information. If we
   are to distribute the directory service, the easiest (although not

Weider, et al               Standards Track                     [Page 1]
RFC 1913       Architecture of the Whois++ Index Service   February 1996

   necessarily the best) way of building the directory service is to
   build a hierarchy of directory information collection agents. In this
   architecture, a directory query is delivered to a certain agent in
   the tree, and then handed up or down, as appropriate, so that the
   query is delivered to the agent which holds the information which
   fills the query.  This approach has been tried before, most notably
   in some implementations of the X.500 standard. However, there are
   number of major flaws with the approach as it has been taken. This
   new Index Service is designed to fix these flaws.

3.1. The search problem

   One of the primary assumptions made by recent implementations of
   distributed directory services is that every entry resides in some
   location in a hierarchical name space. While this arrangement is
   ideal for reading the entry once one knows its location, it is not as
   good when one is searching for the location in the namespace of those
   entries which meet some set of criteria. If the only criteria we know
   about a desired entry are items which do not appear in the namespace,
   we are forced to do a global query. Whenever we issue a global query
   (at the root of the namespace), or a query at the top of a given
   subtree in the namespace, that query is replicated to "all" subtrees
   of the starting point. The replication of the query to all subtrees
   is not necessarily a problem; queries are cheap. However, every
   server to which the query has been replicated must process that
   query, even if it has no entries which match the specified criteria.
   This part of the global query processing is quite expensive. A poorly
   designed namespace or a thin namespace can cause the vast majority of
   queries to be replicated globally, but a very broad namespace can
   cause its own navigation problems. Because of these problems, search
   has been turned off at high levels of the X.500 namespace.

3.2. The location problem

   With global search turned off, one must know in advance how the name
   space is laid out so that one can guide a query to a proper location.
   Also, the layout of the namespace then becomes critical to a user's
   ability to find the desired information. Thus there are endless
   battles about how to lay out the name space to best serve a given set
   of users, and enormous headaches whenever it becomes apparent that
   the current namespace is unsuited to the current usages and must be
   changed (as recently happened in X.500). Also, assuming one does
   impose multiple hierarchies on the entries through use of the
   namespace, the mechanisms to maintain these multiple hierarchies in
Show full document text