summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2258.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2258.txt')
-rw-r--r--doc/rfc/rfc2258.txt843
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]
+