doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc2258.txt b/doc/rfc/rfc2258.txt
new file mode 100644
index 0000000..6510aed
--- /dev/null
+++ b/doc/rfc/rfc2258.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                         J. Ordille
+Request for Comments: 2258                Bell Labs, Lucent Technologies
+Category: Informational                                     January 1998
+
+
+
+
+
+                      Internet Nomenclator Project
+
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+Abstract
+
+   The goal of the Internet Nomenclator Project is to integrate the
+   hundreds of publicly available CCSO servers from around the world.
+   Each CCSO server has a database schema that is tailored to the needs
+   of the organization that owns it.  The project is integrating the
+   different database schema into one query service.  The Internet
+   Nomenclator Project will provide fast cross-server searches for
+   locating people on the Internet.  It augments existing CCSO services
+   by supplying schema integration, more extensive indexing, and two
+   kinds of caching -- all this in a system that scales as the number of
+   CCSO servers grows.  One of the best things about the system is that
+   administrators can incorporate their CCSO servers into Nomenclator
+   without changing the servers. All Nomenclator needs is basic
+   information about the server.
+
+   This document provides an overview of the Nomenclator system,
+   describes how to register a CCSO server in the Internet Nomenclator
+   Project, and how to use the Nomenclator search engine to find people
+   on the Internet.
+
+
+
+
+
+
+
+
+
+
+Ordille                      Informational                      [Page 1]
+
+RFC 2258              Internet Nomenclator Project          January 1998
+
+
+1.  Introduction
+
+   Hundreds of organizations provide directory information through the
+   CCSO name service protocol [3]. Although the organizations provide a
+   wealth of information about people, finding any one person can be
+   difficult because each organization's server is independent.  The
+   different servers have different database schemas (attribute names
+   and data formats).  The 300+ CCSO servers have more than 900
+   different attributes to describe information about people. Very few
+   common attributes exist.  Only name and email occur in more than 90%
+   of the servers [4].  No special support exists for cross-server
+   searches, so searching can be slow and expensive.
+
+   The goal of the Internet Nomenclator Project is to provide fast,
+   integrated access to the information in the CCSO servers.  The
+   project is the first large-scale use of the  Nomenclator system.
+   Nomenclator is a more general system than a white pages directory
+   service.  It is a scalable, extensible information system for the
+   Internet.
+
+   Nomenclator answers descriptive (i.e. relational) queries.  Users can
+   locate information about people, organizations, hosts, services,
+   publications, and other objects by describing their attributes.
+   Nomenclator achieves fast descriptive query processing through an
+   active catalog, and extensive meta-data and data caching.  The active
+   catalog constrains the search space for a query by returning a list
+   of data repositories where the answer to the query is likely to be
+   found.  Meta-data and data caching keep frequently used query
+   processing resources close to the user, thus reducing communication
+   and processing costs.
+
+   Through the Internet Nomenclator Project, users can query any CCSO
+   server, regardless of its attribute names or data formats, by
+   specifying the query to Nomenclator (see Figure 1).  Nomenclator
+   provides a world view of the data in the different servers.  Users
+   express their queries in this world view.  Nomenclator returns the
+   answer immediately if it has been cached by a previous query. If not,
+   Nomenclator uses its active catalog to constrain the query to the
+   subset of relevant CCSO servers.  The speed of the query is
+   increased, because only relevant servers are contacted. Nomenclator
+   translates the global query into local queries for each relevant CCSO
+   server.  It then translates the responses into the format of the
+   world view.
+
+
+
+
+
+
+
+
+Ordille                      Informational                      [Page 2]
+
+RFC 2258              Internet Nomenclator Project          January 1998
+
+
+   --------------------------------------------------------------------
+
+
+                     +-------------+             +-------------+
+                     |             |             |             |
+         World View  |             | Local View  |             |
+         Query       |             | Query       |  Relevant   |
+         ----------->|             |------------>|             |
+                     | Nomenclator |             |  CCSO       |
+                     |             |             |             |
+         <-----------|             |<------------|  Server     |
+          World View |             |  Local View |             |
+          Response   |             |  Response   |             |
+                     +-------------+             +-------------+
+
+
+
+                      Figure 1:  A Nomenclator Query
+
+                  Nomenclator translates queries to and from
+                  the language of the relevant CCSO servers.
+
+   --------------------------------------------------------------------
+
+   The Internet Nomenclator Project makes it easier for users to find a
+   particular CCSO server, but it does not send all queries to that
+   server.  When Nomenclator constrains the search for a query answer,
+   it screens out irrelevant queries from ever reaching the server.
+   When Nomenclator finds an answer in its cache, it screens out
+   redundant queries from reaching the server.  The server becomes
+   easier to find and use without experiencing the high loads caused by
+   exhaustive and redundant searches.
+
+   The Internet Nomenclator Project creates the foundation for a much
+   broader heterogeneous directory service for the Internet.  The
+   current version of Nomenclator provides integrated access to CCSO and
+   relational database services. The Nomenclator System Architecture
+   supports fast, integrated searches of any collection of heterogeneous
+   directories.  The Internet Nomenclator Project can be enhanced to
+   support additional name services, or provide intergated query
+   services for other application domains. The project is starting with
+   CCSO services, because the CCSO services are widely available and
+   successful.
+
+   Section 2 describes the Nomenclator system in more detail.  Section 3
+   explains how to register a CCSO server as part of the project.
+   Section 4 briefly describes how to use Nomenclator.  Section 5
+   provides a summary.
+
+
+
+Ordille                      Informational                      [Page 3]
+
+RFC 2258              Internet Nomenclator Project          January 1998
+
+
+2.  Nomenclator System
+
+   Nomenclator is a scalable, extensible information system for the
+   Internet. It supports descriptive (i.e. relational) queries.  Users
+   locate information about people, organizations, hosts, services,
+   publications, and other objects by describing their attributes.
+   Nomenclator achieves fast descriptive query processing through an
+   active catalog, and extensive meta-data and data caching.
+
+   The active catalog constrains the search space for a query by
+   returning a list of data repositories where the answer to the query
+   is likely to be found.  Components of the catalog are distributed
+   indices that isolate queries to parts of the network, and smart
+   algorithms for limiting the search space by using semantic,
+   syntactic, or structural constraints.  Meta-data caching improves
+   performance by keeping frequently used characterizations of the
+   search space close to the user, thus reducing active catalog
+   communication and processing costs.  When searching for query
+   responses, these techniques improve query performance by contacting
+   only the data repositories likely to have actual responses, resulting
+   in acceptable search times.
+
+   Administrators make their data available in Nomenclator by supplying
+   information about the location, format, contents, and protocols of
+   their data repositories.  Experience with Nomenclator shows that
+   gathering a small amount of information from data owners can have a
+   substantial positive impact on the ability of users to retrieve
+   information.  For example, each CCSO administrator provides a mapping
+   from the local view of data (i.e. the local schema) at the CCSO
+   server to Nomenclator's world view.  The administrator also supplies
+   possible values for any attributes with small domains at the data
+   repository (such as the "city" or "state_or_province" attributes).
+   With this information, Nomenclator can isolate queries to a small
+   percentage of the CCSO data repositories, and provide an integrated
+   view of their data.  Nomenclator provides tools that minimize the
+   effort that administrators expend in characterizing their data
+   repositories.  Nomenclator does not require administrators to change
+   the format of their data or the access protocol for their database.
+
+2.1 Components of a Nomenclator System
+
+   A Nomenclator system is comprised of a distributed catalog service
+   and a query resolver (see Figure 2).  The distributed catalog service
+   gathers meta-data about data repositories and makes it available to
+   the query resolver. Meta-data includes constraints on attribute
+
+
+
+
+
+
+Ordille                      Informational                      [Page 4]
+
+RFC 2258              Internet Nomenclator Project          January 1998
+
+
+   values at a data repository, known patterns of data distribution
+   across several data repositories, search and navigation techniques,
+   schema and protocol translation techniques, and the differing schema
+   at data repositories.
+
+   --------------------------------------------------------------------
+
+
+                     +-------------+             +-------------+
+                     |             |             |             |
+         World View  |             |  Meta Data  |             |
+         Query       |             |  Request    | Distributed |
+         ----------->|   Query     | ----------->|             |
+                     |   Resolver  |             |  Catalog    |
+                     |             |             |             |
+         <-----------|   (caches)  | <-----------|  Service    |
+          World View |             |  Meta Data  |             |
+          Response   |             |  Response   |             |
+                     +-------------+             +-------------+
+
+
+
+                   Figure 2: Components of a Nomenclator System
+
+   --------------------------------------------------------------------
+
+   Query resolvers at the user sites retrieve, use, cache, and re-use
+   this meta-data in answering user queries.  The catalog is "active" in
+   two ways. First, some meta-data moves from the distributed catalog
+   service to each query resolver during query processing.  Second, the
+   query resolver uses the initial meta-data, in particular the search
+   and navigation techniques, to generate additional meta-data that
+   guides query processing.  Typically, one resolver process serves a
+   few hundred users in an organization, so users can benefit from
+   larger resolver caches.
+
+   Query resolvers cache techniques for constraining the search space
+   and the results of previously constrained searches (meta-data), and
+   past query answers (data) to speed future query processing.  Meta-
+   data and data caching tailor the query resolver to the specific needs
+   of the users at the query site.  They also increase the scale of a
+   Nomenclator system by reducing the load from repeated searches or
+   queries on the distributed catalog service, data repositories, and
+   communications network.
+
+
+
+
+
+
+
+Ordille                      Informational                      [Page 5]
+
+RFC 2258              Internet Nomenclator Project          January 1998
+
+
+   The distributed catalog service is logically one network service, but
+   it can be divided into pieces that are distributed and/or replicated.
+   Query resolvers access this distributed, replicated service using the
+   same techniques that work for multiple data repositories.
+
+   A Nomenclator system naturally includes many query resolvers.
+   Resolvers are independent, but renewable, query agents that can be as
+   powerful as the resources available at the user site.  Caching
+   decreases the dependence of the resolver on the distributed catalog
+   service for frequently used meta-data, and on data repositories for
+   frequently used data.  Caching thus improves the number of users that
+   can be supported and the local availability of the query service.
+
+2.2 Meta-Data Techniques
+
+   The active catalog structures the information space into a collection
+   of relations about people, hosts, organizations, services and other
+   objects. It collects meta-data for each relation and structures it
+   into "access functions" for locating and retrieving data.  Access
+   functions respond to the question: "Where is data to answer this
+   query?"  There are two types of responses corresponding to the two
+   types of access functions.  The first type of response is: "Look over
+   there." "Catalog functions" return this response; they constrain the
+   query search by limiting the data repositories contacted to those
+   having data relevant to the query. Catalog functions return a
+   referral to data access functions that will answer the query or to
+   additional catalog functions to contact for more detailed
+   information.  The second response to "Where?" is: "Here it is!" "Data
+   access functions" return this response; they understand how to obtain
+   query answers from specific data repositories.  They return tuples
+   that answer the query.  Nomenclator supplies access functions for
+   common name services, such as the CCSO service, and organizations can
+   write and supply access functions for data in their repositories.
+
+   Access functions are implemented as remote or local services.  Remote
+   access functions are services that are available through a standard
+   remote procedure call interface.  Local access functions are
+   functions that are supplied with the query resolver.  Local access
+   functions can be applied to a variety of indexing and data retrieval
+   tasks by loading them with meta-data stored in distributed catalog
+   service.  Remote access functions are preferred over local ones when
+   the resources of the query resolver are inadequate to support the
+   access function.  The owners of data may also choose to supply remote
+   access functions for privacy reasons if their access functions use
+   proprietary information or algorithms.  Local functions are preferred
+   whenever possible, because they are highly replicated in resolver
+   caches.  They can reduce system and network load by bringing the
+   resources of the active catalog directly to the users.
+
+
+
+Ordille                      Informational                      [Page 6]
+
+RFC 2258              Internet Nomenclator Project          January 1998
+
+
+   Remote access functions are simple to add to Nomenclator and local
+   access functions are simple to apply to new data repositories,
+   because the active catalog provides "referrals" that describe the
+   conditions for using access functions.  For simplicity, this document
+   describes referral techniques for exact matching of query strings.
+   Extensions to these techniques in Nomenclator support matching query
+   strings that contain wildcards or word-based matching of query
+   strings in the style of the CCSO services.
+
+   Each referral contains a template and a list of references to access
+   functions.  The template is a conjunctive selection predicate that
+   describes the scope of the access functions.  Conjunctive queries
+   that are within the scope of the template can be answered with the
+   referral.  When a template contains a wildcard value ("*") for an
+   attribute, the attribute must be present in any queries that are
+   processed by the referral.  The system follows the following rule:
+
+     Query Coverage Rule:
+
+     If the set of tuples satisfying the selection predicate in a query
+     is covered by (is a subset of) the set of tuples satisfying the
+     template, then the query can be answered by the access functions in
+     the reference list of the referral.
+
+   For example, the query below:
+
+     select * from People where country = "US" and surname = "Ordille";
+
+
+   is covered by the following templates in Lines (1) through (3), but
+   not by the templates in Lines (4) and (5):
+
+
+      (1) country = "US" and surname = "*"
+
+      (2) country = "US" and surname = "Ordille"
+
+      (3) country = "US"
+
+      (4) organization = "*"
+
+      (5) country = "US" and surname = "Elliott"
+
+   Referrals form a generalization/specialization graph for a relation
+   called a "referral graph."  Referral graphs are a conceptual tool
+   that guides the integration of different catalog functions into our
+   system and that supplies a basis for catalog function construction
+   and query processing.  A "referral graph" is a partial ordering of
+
+
+
+Ordille                      Informational                      [Page 7]
+
+RFC 2258              Internet Nomenclator Project          January 1998
+
+
+   the referrals for a relation.  It is constructed using the
+   subset/superset relationship: "S is a subset of G."  A referral S is
+   a subset of referral G if the set of queries covered by the template
+   of S is a subset of the set of queries covered by the template of G.
+   S is considered a more specific referral than G; G is considered a
+   more general referral than S.  For example, the subset relationship
+   exists between the pairs of referrals with the templates listed
+   below:
+
+
+      (1) country = "US" and surname = "Ordille"
+          is a subset of
+          country = "US"
+
+      (2) country = "US" and surname = "Ordille"
+          is a subset of
+          country = "US" and surname = "*"
+
+      (3) country = "US" and surname = "*"
+          is a subset of
+          country ="US"
+
+      (4) country = "US"
+          is a subset
+          "empty template"
+
+   but it does not exist between the pairs of referrals with the
+   following templates:
+
+      (5) country = "US"
+          is not a subset of
+          department = "CS"
+
+      (6) country = "US" and name = "Ordille"
+          is not a subset of
+          country = "US" and name = "Elliott"
+
+   In Lines (1) and (2), the more general referral covers more queries,
+   because it covers queries that list different values for surname.  In
+   Line (3), the more general referral covers more queries, because it
+   covers queries that do not constrain surname to a value.  In Line
+   (4), the specific referral covers only those queries that constrain
+   the country to "US" while the empty template covers all queries.
+
+   During query processing, wildcards in a template are replaced with
+   the value of the corresponding attribute in the query.  For any query
+   covered by two referrals S and G such that S is a subset of G, the
+   set of tuples satisfying the template in S is covered by the set of
+
+
+
+Ordille                      Informational                      [Page 8]
+
+RFC 2258              Internet Nomenclator Project          January 1998
+
+
+   tuples satisfying the template in G.  S is used to process the query,
+   because it provides the more constrained (and faster) search space.
+   The referral S has a more constrained logical search space than G,
+   because the set of tuples in the scope of S is no larger, and often
+   smaller, than the set in the scope of G. Moreover, S has a more
+   constrained physical search space than G, because the data
+   repositories that must contacted for answers to S must also be
+   contacted for answers to G, but additional data repositories may need
+   to be contacted to answer G.
+
+   In constraining a query, a catalog function always produces a
+   referral that is more specific than the referral containing the
+   catalog function.  Wildcards ("*") in a template indicate which
+   attribute values are used by the associated catalog function to
+   generate a more specific referral.  In other words, catalog functions
+   always follow the rule:
+
+      Catalog Function Constrained Search Rule:
+
+      Given a referral R with a template t and a catalog function cf,
+      and a query q covered by t, the result of using cf to process q,
+      cf(q), is a referral R' with template t' such that q  is covered
+      by t' and R' is more specific than R.
+
+   Catalog functions make it possible to import a portion of the indices
+   for the information space into the query resolver.  Since they
+   generate referrals, the resolver can cache the most useful referrals
+   for a relation and call the catalog function as needed to generate
+   new referrals.
+
+   The resolver query processing algorithm obtains an initial set of
+   referrals from the distributed catalog service.  It then navigates
+   the referral graph, calling catalog functions as necessary to obtain
+   additional referrals that narrow the search space. Sometimes, two
+   referrals that cover the query have the relationship of general to
+   specific to each other.  The resolver eliminates unnecessary access
+   function processing by using only the most specific referral along
+   each path of the referral graph.
+
+   The search space for the query is initially set to all the data
+   repositories in the relation.  As the resolver obtains referrals to
+   sets of relevant data repositories (and their associated data access
+   functions) it forms the intersection of the referrals to constrain
+   the search space further.  The intersection of the referrals includes
+   only those data repositories listed in all the referrals.
+   Intersection combines independent paths through the referral graph to
+   derive benefit from indices on different attributes.
+
+
+
+
+Ordille                      Informational                      [Page 9]
+
+RFC 2258              Internet Nomenclator Project          January 1998
+
+
+2.3 Meta-Data and Data Caching
+
+   A Nomenclator query resolver caches the meta-data that result from
+   calling catalog functions.  It also caches the responses for queries.
+   If the predicate of a new query is covered by the predicate of a
+   previous query, Nomenclator calculates the response for the new query
+   from the cached response of the old query.  Nomenclator timestamps
+   its cache entries to provide measures of the currentness of query
+   responses and selective cache refresh.  The timestamps are used to
+   calculate a t-bound on query responses [5][1].  A t-bound is the time
+   after which changes may have occurred to the data that are not
+   reflected in the query response. It is the time of the oldest cache
+   entry used to calculate the response.  Nomenclator returns a t-bound
+   with each query response.  Users can request more current data by
+   asking for responses that are more recent than this t-bound. Making
+   such a request flushes older items from the cache if more recent
+   items are available.  Query resolvers calculate a minimum t-bound
+   that is some refresh interval earlier than the current time.
+   Resolvers keep themselves current by replacing items in the cache
+   that are earlier than the minimum t-bound.
+
+2.4 Scale and Performance
+
+   Three performance studies of active catalog and meta-data caching
+   techniques are available [5].  The first study shows that the active
+   catalog and meta-data caching can constrain the search effectively in
+   a real environment, the X.500 name space.  The second study examined
+   the performance of an active catalog and meta-data caching for single
+   users on a local area network.  The experiments showed that the
+   techniques to eliminate data repositories from the search space can
+   dramatically improve response time.  Response times improve, because
+   latency is reduced.  The reduction of latency in communications and
+   processing is critical to large-scale descriptive query optimization.
+   The experiments also showed that an active catalog is the most
+   significant contributor to better response time in a system with low
+   load, and that meta-data caching functions to reduce the load on the
+   system.  The third study used an analytical model to evaluate the
+   performance and scaling of these techniques for a large Internet
+   environment.  It showed that meta-data caching plays an essential
+   role in scaling the distributed catalog service to millions of users.
+   It also showed that constraining the search space with an active
+   catalog contributes significantly to scaling data repositories to
+   millions of users.  Replication and data caching also contribute to
+   the scale of the system in a large Internet environment.
+
+
+
+
+
+
+
+Ordille                      Informational                     [Page 10]
+
+RFC 2258              Internet Nomenclator Project          January 1998
+
+
+3.  Registering a CCSO Server
+
+   The Internet Nomenclator Project supports the following home page:
+
+      http://cm.bell-labs.com/cs/what/nomenclator
+
+   The home page provides a variety of information and services.
+
+   Administrators can register their CCSO servers through services on
+   this home page.  The registration service collects CCSO server
+   location information, contact information for the administrator of
+   the CCSO server, implicit and explicit constraints on entries in the
+   server's database, and a mapping from the local schema of the CCSO
+   server to the schema of the world view.
+
+   The implicit and explicit constraints on the server's database are
+   the fuel for Nomenclator's catalog functions.  The registration
+   center currently collects constraints on organization name,
+   department, city, state or province name, country, phone number,
+   postal code, and email address.  These constraints are automatically
+   incorporated into Nomenclator's distributed catalog service.  They
+   are used by catalog functions in query resolvers to constrain
+   searches to relevant CCSO servers.  For example, a database only
+   contains information about the computer science and electrical
+   engineering departments at a French university.  The department,
+   organization and country attributes are constrained.  Nomenclator
+   uses these constraints to prevent queries about other departments,
+   organizations or countries from being sent to this CCSO server.
+
+   The mapping from the local schema of the CCSO server to the schema of
+   the world view allows Nomenclator to translate queries and responses
+   for the CCSO server.  The registration center currently collects this
+   mapping by requesting an example of how to translate a typical entry
+   in the CCSO server into the world view schema and, optionally, an
+   example of how to translate a canonical entry in the world view
+   schema into the local schema of the CCSO server [4].  These examples
+   are then used to generate a mapping program that is stored in the
+   distributed catalog service.  The CCSO data access function in the
+   query resolver interprets these programs to translate queries and
+   responses communicated with that CCSO server.  We plan to release the
+   mapping language to CCSO server administrators, so administrators can
+   write and maintain the mapping for their servers.  We have
+   experimented with more than 20 mapping programs.  They are seldom
+   more than 50 lines, and are often shorter.  It typically takes one or
+   two lines to map an attribute.
+
+
+
+
+
+
+Ordille                      Informational                     [Page 11]
+
+RFC 2258              Internet Nomenclator Project          January 1998
+
+
+4.  Using Nomenclator
+
+   The Internet Nomenclator Project currently provides a centralized
+   query service on the Internet.  The project runs a Nomenclator query
+   resolver that is accessible through its Web page (see the URL in
+   Section 3) and the Simple Nomenclator Query Protocol (SNQP) [2].
+
+   The service answers queries that are a conjunction of string values
+   for attributes.  A variety of matching techniques are supported
+   including exact string matching, matching with wildcards, and word-
+   based matching in the style of the CCSO service.  Our web interface
+   uses the Simple Nomenclator Query Protocol (SNQP) [2].  Programmers
+   can create their own interfaces by using this protocol to communicate
+   with the Nomenclator query resolver.  They will require the host name
+   and port number for the query resolver which they can obtain from the
+   Nomenclator home page.  SNQP, and hence the web interface, are
+   defined for US-ASCII.  Support for other character sets will require
+   further work.
+
+   Subsequent phases of the project will provide enhanced services such
+   as providing advice about the cost of queries and ways to constrain
+   queries further to produce faster response times, and allowing users
+   to request more current data.  We also plan to distribute query
+   resolvers, so users can benefit from running query resolvers locally.
+   Local query resolvers reduce latency for the user, and distribute
+   query processing load throughout the network.
+
+5.  Summary
+
+   The Internet Nomenclator Project augments existing CCSO services by
+   supplying schema integration and fast cross-server searches. The key
+   to speed in descriptive query processing is an active catalog, and
+   extensive meta-data and data caching.  The Nomenclator system is the
+   result of research in distributed systems [5][6][7][4].  It can be
+   extended to incorporate other name servers, besides the CCSO servers,
+   and to address distributed search and retrieval challenges in other
+   application domains. In addition to providing a white pages service,
+   the Internet Nomenclator Project will evaluate how an active catalog,
+   meta-data caching and data caching perform in very large global
+   information system.  The ultimate goal of the project is to refine
+   these techniques to provide the best possible global information
+   systems.
+
+
+
+
+
+
+
+
+
+Ordille                      Informational                     [Page 12]
+
+RFC 2258              Internet Nomenclator Project          January 1998
+
+
+6.  Security Considerations
+
+   In the Internet Nomenclator Project, the participants' data are
+   openly available and read-only. Since the risk of tampering with
+   queries and responses is considered low, this version of Nomenclator
+   does not define procedures for protecting the information in its
+   queries and responses.
+
+7.  References
+
+
+   [1]   H. Garcia-Molina, G. Wiederhold. "Read-Only Transactions in
+         a Distributed Database,"  ACM Transactions on Database Systems
+         7(2), pp. 209-234.  June 1982.
+
+   [2]   Elliott, J., and J. Ordille, "The Simple Nomenclator Query
+         Protocol (SNQP)," RFC 2259, January 1998.
+
+   [3]   S. Dorner, P. Pomes. "The CCSO Nameserver: A Description,"
+         Computer and Communications Services Office Technical Report,
+         University of Illinois, Urbana, USA. 1992. Avaialble in the
+         current "qi" distribution from
+         <URL:ftp://uiarchive.cso.uiuc.edu/local/packages/ph>
+
+   [4]   A. Levy, J. Ordille. "An Experiment in Integrating Internet
+         Information Sources," AAAI Fall Symposium on AI Applications in
+         Knowledge Navigation and Retrieval, November 1995.
+         <URL:http://cm.bell-labs.com/cm/cs/doc/95/11-01.ps.gz>
+
+   [5]   J. Ordille. "Descriptive Name Services for Large Internets,"
+         Ph. D. Dissertation. University of Wisconsin. 1993.
+         <URL:http://cm.bell-labs.com/cm/cs/doc/93/12-01.ps.gz>
+
+   [6]   J. Ordille, B. Miller. "Distributed Active Catalogs and
+         Meta-Data Caching in Descriptive Name Services," Thirteenth
+         International IEEE Conference on Distributed Computing Systems,
+         pp. 120-129.  May 1993.
+         <URL:http://cm.bell-labs.com/cm/cs/doc/93/5-01.ps.gz>
+
+   [7]   J. Ordille, B. Miller. "Nomenclator Descriptive Query
+         Optimization in Large X.500 Environments," ACM SIGCOMM
+         Symposium on Communications Architectures and Protocols, pp.
+         185-196, September 1991.
+         <URL:http://cm.bell-labs.com/cm/cs/doc/91/9-01.ps.gz>
+
+
+
+
+
+
+
+Ordille                      Informational                     [Page 13]
+
+RFC 2258              Internet Nomenclator Project          January 1998
+
+
+8.  Author's Address
+
+   Joann J. Ordille
+   Bell Labs, Lucent Technologies
+   Computing Sciences Research Center
+   700 Mountain Avenue, Rm 2C-301
+   Murray Hill, NJ 07974  USA
+
+   EMail: joann@bell-labs.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ordille                      Informational                     [Page 14]
+
+RFC 2258              Internet Nomenclator Project          January 1998
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ordille                      Informational                     [Page 15]
+