📄 rfc2167.txt
字号:
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.5Status 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 19972. Architecture2.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.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -