Network Working Group S. WilliamsonRequest for Comments: 2167

Network Working Group S. WilliamsonRequest for Comments: 2167 M. KostersObsoletes: RFC 1714 D. BlackaCategory: Informational J. Singh K. Zeilstra Network Solutions, Inc. June 1997 Referral Whois (RWhois) Protocol V1.5

Status of this Memo

This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Abstract

This memo describes Version 1.5 of the client/server interaction of RWhois. RWhois provides a distributed system for the discovery, retrieval, and maintenance of directory information. This system is primarily hierarchical by design. It allows for the deterministic routing of a query based on hierarchical tags, referring the user closer to the maintainer of the information. While RWhois can be considered a generic directory services protocol, it distinguishes itself from other protocols by providing an integrated, hierarchical architecture and query routing mechanism.

1. Introduction

Early in the development of the ARPANET, the SRI-NIC established a centralized Whois database that provided host and network information about the systems connected to the network and the electronic mail (email) addresses of the users on those systems [RFC 954]. The

ARPANET experiment evolved into a global network, the Internet, with countless people and hundreds of thousands of end systems. The sheer size and effort needed to maintain a centralized database

necessitates an alternate, decentralized approach to storing and retrieving this information.

Williamson, et. al. Informational [Page 1]

RFC 2167 RWhois Protocol June 1997 The original Whois function was to be a central directory of

resources and people on ARPANET. However, it could not adequately meet the needs of the expanded Internet. RWhois extends and enhances the Whois concept in a hierarchical and scaleable fashion. In

accordance with this, RWhois focuses primarily on the distribution of "network objects", or the data representing Internet resources or people, and uses the inherently hierarchical nature of these network objects (domain names, Internet Protocol (IP) networks, email

addresses) to more accurately discover the requested information. RWhois synthesizes concepts from other, established Internet

protocols. The RWhois protocol and architecture derive a great deal of structure from the Domain Name System (DNS) [RFC 1034] and borrow directory service concepts from other directory service efforts, primarily [X.500]. The protocol is also influenced by earlier

established Internet protocols, such as the Simple Mail Transport Protocol (SMTP) [RFC 821].

This RWhois specification defines both a directory access protocol and a directory architecture. The directory access protocol

specifically describes the syntax of the client/server interaction. It describes how an RWhois client can search for data on an RWhois server, or how the client can modify data on the server. It also describes how the server is to interpret input from the client, and how the client should interpret the results returned by the server. The architecture portion of this document describes the conceptual framework behind the RWhois protocol. It details the concepts upon which the protocol is based and describes its structural elements. The protocol implements the architecture.

This document uses language like SHOULD and SHALL that have special meaning as specified in "Key words for use in RFCs to Indicate Requirement Levels". [RFC2119]

Williamson, et. al. Informational [Page 2]

RFC 2167 RWhois Protocol June 1997

2. Architecture

2.1 Overview

As a directory service, RWhois is a distributed database, where data is split across multiple servers to keep database sizes manageable. The architecture portion of this document details the concepts upon which the protocol is based and describes its structural elements. Specifically, the architecture is concerned with how the data is split across the different servers. The basis of this splitting is the lexically hierarchical label (or tag), which is a text string

whose position in a hierarchy can be determined from the structure of the string itself.

All data can follow some sort of hierarchy, even if the hierarchy seems somewhat arbitrary. For example, person names can be arranged into hierarchical groups via geography. If all the people in

particular towns are grouped into town groups, then all of the town groups can be grouped into state (or province) groups, and then all of the state groups can be grouped into a country group. Then, a particular name would belong in a town group, a state group, and a country group. However, just given a name, it would be impossible to determine where in the hierarchy it belongs. Therefore, a person name is not lexically hierarchical.

However, there are certain types of data whose position in the hierarchy can be determined by deciphering the data itself, for example, phone numbers. A phone number is grouped according to country code, area code, local exchange, and local extension. By looking at a phone number, it is possible to determine to which of all these groups the number belongs: 1-303-555-2367 is in country code 1, area code 303, local exchange 555, and has a local extension of 2367. Therefore, a phone number is lexically hierarchical.

On the Internet, two such types of data are widely used: domain names and IP networks. Domain names are organized via a label-dot system, reading from a more specific label to a more general label left to right; for example, war.west.netsol.com is a part of west.netsol.com, which is a part of netsol.com, which is a part of com. IP networks are also lexically hierarchical labels using the Classless Inter- Domain Routing (CIDR) notation, but their hierarchy is not easily determined with simple text manipulation; for example, 198.41.0.0/22 is a part of 198.41.0.0/16, which is a part of 198.40.0.0/15.

Instead, an IP network’s hierarchy is determined by converting the network to binary notation and applying successively shorter bit masks.

Williamson, et. al. Informational [Page 3]

RFC 2167 RWhois Protocol June 1997 It is important to note that, while very little real data is

lexically hierarchical in nature, people often create label systems (or namespaces) to help manage the data and provide an element of

uniqueness, for example, Social Security Numbers, ISBNs, or the Dewey Decimal System. RWhois leverages lexically hierarchical labels, domain names and IP networks, for its data splitting using the concepts of authority areas and referrals. An authority area is

associated with an RWhois server and a lexically hierarchical label, which is considered to be its name. An authority area is a piece of the distributed database that speaks with authority about its

assigned part of the hierarchy. All data associated with a particular lexically hierarchical tag should be located within that authority area’s database. Authority areas are further explained in Section

2.4.

RWhois directs clients toward the appropriate authority area by generating referrals. Referrals are pointers to other servers that are presumed to be closer to the desired data. The client uses this referral to contact the next server and ask the same question. The next server may respond with data, an error, or another referral (or referrals). By following this chain of referrals, the client will eventually reach the server with the appropriate authority area. In the RWhois architecture, referrals are generated by identifying a lexically hierarchical label and deciphering the label to determine the next server. Referrals are further explained in Section 2.5. When a number of RWhois servers containing authority areas are

brought on line and informed about each other, they form an RWhois tree. The tree has a root authority area, which is the group that contains all other groups. The root authority area must keep

pointers to the servers and authority areas that form the first level of the hierarchy. The authority areas in the first level of the

hierarchy are then responsible for keeping pointers to the authority areas below them and for keeping a pointer to the root.

2.2 Design Philosophy

The design goals for the RWhois protocol are as follows.

* It should be a directory access protocol. The server should be able to access and update the data residing on it.

* It should facilitate query routing. An unresolved query should be redirected to a server that is presumed to be closer to the desired data.

* It should enable data replication. The server should be able to duplicate its data on another server.

* The server should be lightweight and delegate more functions to the client.

Williamson, et. al. Informational [Page 4]

RFC 2167 RWhois Protocol June 1997 The concepts used to achieve these design goals are explained in the remaining document.

2.3 Schema Model

As a directory service, RWhois uses various database schema to store and represent data. Schema, in this document, has two definitions. First, it refers to the entire structure of a database, all the

tables and fields forming a complete database. When schema is used in this context, it is called the "database schema". Database schema consists of attributes, classes, and objects. Schema may also refer to a single piece of the database, a single table with fields. When schema is used in this context, it is just called "schema" or it is preceded by the name of the particular piece: contact schema or domain schema, for example. In this usage, schema is equivalent to "class", defined below.

There is no standard database schema in the RWhois architecture. Each authority area is presumed to be able to define its own local schema. However, an authority area that is part of a larger RWhois tree is expected to have some part of its schema pertain to the lexically hierarchical label upon which the RWhois tree is based. An authority area schema may not change throughout much of an RWhois tree.

2.3.1 Attributes

An attribute is a named field and is the smallest typed unit in the database schema. It is equivalent to a relational database’s field. An attribute is not considered to be data by itself; it is simply used to give data a type. When a piece of data has been typed by an attribute, it is typically referred to as a value and is represented as an attribute-value pair. The RWhois syntax for the attribute-value pair is to separate them with a colon, for example:

First-Name:Bill

Attributes have a number of properties, some mandated by the RWhois protocol and some that are implementation dependent. These properties are usually a reflection of the database system used by the server. The following is a list of the protocol-mandated properties and their descriptions.

Attribute This is the name of the attribute.

Description This is a natural language description of the

attribute.

Williamson, et. al. Informational [Page 5]

RFC 2167 RWhois Protocol June 1997 Type This is a parameter that broadly indicates the use of the attribute to the protocol. There are three

standard types: TEXT, ID, and SEE-ALSO. The default is TEXT, which indicates that the value is a text string. ID indicates that the attribute contains the ID of another RWhois object. This type of attribute is used for database normalization. SEE-ALSO indicates that the attribute contains a pointer (a Uniform Resource Identifier (URI)) to some other kind of external data; for example, a World Wide Web page or FTP site. Format This is an interpretable string that describes the acceptance format of the value. The server (and

optionally the client) should match the value to the format string to determine if the value is acceptable. The format of this property is a keyword indicating the syntax of the format string, followed by a colon, followed by the format string itself. Currently, the only keyword recognized is "re" for POSIX.2 extended regular expressions.

Indexed This is a true or false flag indicating that this

attribute should be indexed (and therefore able to be searched).

Required This is a true or false flag indicating that this attribute must have a value in an instance of the class.

Multi-Line This is a true or false flag indicating that this

attribute may have multiple instances in a class, but all of the instances are to be considered as multiple lines of the same attribute instance. This allows normal line terminators to terminate values.

Repeatable This is a true or false flag indicating that there may be multiple instances of this attribute in a class and each instance is to be interpreted as a separate instance (in contrast to Multi-Line). This flag is mutually exclusive with Multi-Line: if Multi-Line is true, then Repeatable must be false and vice versa.

Williamson, et. al. Informational [Page 6]

RFC 2167 RWhois Protocol June 1997 Primary This is a true or false flag that indicates that this attribute is a primary key. If more than one attribute in a class is marked as primary, then these attributes together form a single primary key. The primary key is intended to be used to force uniqueness among class

instances. Therefore, there can be only one instance of a primary key in a database. The Primary flag implies that the attribute is also required.

Hierarchical This is a true or false flag that indicates that this attribute is lexically hierarchical.

Private This is a true or false flag that indicates whether or not this attribute is private (that is, publicly not viewable). It defaults to false. If it is true, then only the clients that satisfy the

authentication/encryption requirements of a guardian (described below) are able to view the attribute-value pair.

2.3.2 Class

A class is a collection of attributes; it is a structure, not data. The concept is equivalent to that of a relational database table. It is also equivalent to the second definition of schema, above.

A class also has some properties that are sometimes referred to as its "meta" information. These properties are listed below.

Version This is a time/date stamp that is used to quickly detect when a class definition has been changed.

Description This is a natural language description of the class.

2.3.3 Object

An object is an instance of a class. It is data with a type of .

2.3.4 Base Class

While RWhois does not have or advocate using a specific, standardized schema, it does impose a few requirements. It requires that all

defined classes inherit attributes from a particular base class (or base schema). The RWhois specification does not require the actual implementation of inheritance. Instead, all classes must include the attributes defined in the base class.

Williamson, et. al. Informational [Page 7]

RFC 2167 RWhois Protocol June 1997 The base class has the following attributes.

Class-Name This attribute contains the name of the class to which the object belongs. It is the type of the object itself. It is of type TEXT and is required.

Auth-Area This attribute contains the name of the authority area to which the object belongs. It, along with Class- Name, definitively defines the type of the object. It is of type TEXT and is required.

ID This attribute is a universal identifier for the object. It is formed by choosing a string that is unique within an authority area and appending the

authority area to it, separating the local string from the authority area name with a period. The only

restrictions on the local string are that it must be unique within the authority area and not contain the period character. This attribute is hierarchical in nature. It is always generated by the server (for example, during a register operation). It is of type TEXT and is required.

Updated This attribute is a time/date stamp that indicates the time of last modification of the object. It is both informational and a form of record locking. It

prevents two clients from modifying the same object at the same time. It is of type TEXT and is required. Guardian This attribute is a link to a guardian object

(described below). Its value is the ID of a guardian object. It is of type ID and is optional. It is repeatable, since an object may have multiple

guardians.

Private This attribute is a true or false flag that indicates whether or not an object is private (that is, publicly not viewable). It defaults to false. If it is true, then only the clients that satisfy the

authentication/encryption requirements of one of the object’s guardians are able to view the object. If the object is publicly viewable, then the Private

attribute property of each of its attributes still applies.

Williamson, et. al. Informational [Page 8]

RFC 2167 RWhois Protocol June 1997 TTL This attribute is the "time-to-live" of a given object. It is included only if an object has a

different time-to-live than the default given in the Start of Authority information. Its value is specified in seconds. It is of type TEXT and is optional.

The RWhois specification defines two standard classes that should be included in all implementations: the referral and guardian classes.

2.3.5 Referral Class

The referral class is defined to hold referral information (typically for link referrals). It consists of attributes defined as part of the base class, the protocol-specific attributes described below, and any installation-specific attributes.

Referred-Auth-Area This attribute contains the name of the authority area to which the referral points. It is used as a search key during the query routing. It is of type TEXT and is required. It is repeatable,

since referrals can point to servers hosting more than one authority area.

Referral This attribute contains the referral itself. It is an RWhois URL. It is of type TEXT and is

required. It is repeatable, since more than one server can host a Referred-Auth-Area.

2.3.6 Guardian Class

The guardian class is defined to hold security information. The

fundamental concept behind the guardian class is that an object (or another structure) is "guarded" by containing a pointer to a guardian object [Guardian]. To modify, delete, or possibly view the guarded object, the authentication (or encryption, or both) scheme must be satisfied. Guardians are intended to not have rank: if an object is guarded by more than one guardian object, satisfying any one of those guardians is sufficient. A guardian object that does not have any Guardian attribute linking it to other guardians guards itself. That is, the authentication scheme in the guardian object itself must be satisfied to modify, delete, or possibly view it.

Guardian objects are typically linked to actual database objects with the Guardian attribute found in the base class. However, a guardian may also be linked to an entire authority area, in which case the guardian becomes implicitly linked to all of the objects contained within the authority area.

Williamson, et. al. Informational [Page 9]

RFC 2167 RWhois Protocol June 1997 The guardian class consists of the base class, the protocol-specific attributes described below, and any installation-specific attributes. Guard-Scheme This attribute contains a keyword indicating the authentication methodology. Its value must be

understood by both the client and server, and its value dictates the contents of the Guard-Info attribute. It is of type TEXT and is required.

Guard-Info This attribute contains that data that is used by the Guard-Scheme to verify the authentication. Its actual format is dictated by the Guard-Scheme, for example, it could contain a password or Pretty Good Privacy (PGP) public key id [RFC 1991]. For security reasons, it should not be displayed, and its Private attribute

property should be set to true. It is of type TEXT and is required.

2.4 Authority Areas

The concept of authority areas is pivotal to the RWhois architecture. When an RWhois tree is created for a particular lexically

hierarchical namespace, the different pieces of the hierarchy are mapped to authority areas. The most important concept behind an authority area is the ability for a portion of the RWhois tree to definitively control that portion of the hierarchy. This means that an authority area is able to state whether or not a hierarchical tag is in the whole RWhois tree. It does this either by returning the object containing this tag, returning a referral to a sub-authority area, or returning a response indicating that no objects were found. This structure enables efficient routing of queries based on the

hierarchical label to the piece of the hierarchy responsible for it. For example, in the domain name namespace as served by RWhois, the root of the tree would be an authority area named ".", which would delegate a "us" sub-authority area, which would delegate "va", "co", "md", and "ca" authority areas, and so forth. When the server with the "va.us" authority area is asked about "loudoun.va.us", it will be able to authoritatively state that either no "loudoun.va.us" exists or it will provide an object for or a referral to "loudoun.va.us". Further, if the server is asked about "howard.md.us", it cannot answer authoritatively, so it must provide a referral to its

hierarchical parent ("us" or the root).

This use of authority area strongly indicates where data should be stored within an RWhois tree. Because RWhois uses a specific query routing model, data needs to be placed under the proper authority area. It is certainly possible to place a piece of data under the

Williamson, et. al. Informational [Page 10]