Network Working Group J. Allen
Request for Comments: 2651 WebTV Networks
Category: Standards Track M. Mealling
Network Solutions, Inc.
August 1999
Network Working Group J. Allen
Request for Comments: 2651 WebTV Networks
Category: Standards Track M. Mealling
Network Solutions, Inc.
August 1999
The Architecture of the Common Indexing Protocol (CIP)
通用索引协议（CIP）的体系结构
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
The Common Indexing Protocol (CIP) is used to pass indexing information from server to server in order to facilitate query routing. Query routing is the process of redirecting and replicating queries through a distributed database system towards servers holding the desired results. This document describes the CIP framework, including its architecture and the protocol specifics of exchanging indices.
公共索引协议（CIP）用于将索引信息从服务器传递到服务器，以便于查询路由。查询路由是通过分布式数据库系统将查询重定向和复制到保存所需结果的服务器的过程。本文档描述了CIP框架，包括其体系结构和交换索引的协议细节。
The Common Indexing Protocol (CIP) is an evolution and refinement of distributed indexing concepts first introduced in the Whois++ Directory Service [RFC1913, RFC1914]. While indexing proved useful in that system to promote query routing, the centroid index object which is passed among Whois++ servers is specifically designed for template-based databases searchable by token-based matching. With alternative index objects, the index-passing technology will prove useful to many more application domains, not simply Directory Services and those applications which can be cast into the form of template collections.
公共索引协议（CIP）是首次在Whois++目录服务[RFC1913，RFC1914]中引入的分布式索引概念的演变和完善。虽然索引在该系统中被证明有助于促进查询路由，但在Whois++服务器之间传递的质心索引对象是专门为基于模板的数据库设计的，可通过基于令牌的匹配进行搜索。对于替代索引对象，索引传递技术将被证明对更多的应用程序域有用，而不仅仅是目录服务和那些可以转换为模板集合形式的应用程序。
The indexing part of Whois++ is integrated with the data access protocol. The goal in designing CIP is to extract the indexing portion of Whois++, while abstracting the index objects to apply more broadly to information retrieval. In addition, another kind of technology reuse has been undertaken by converting the ad-hoc data representations used by Whois++ into structures based on the MIME specification for structured Internet mail.
Whois++的索引部分与数据访问协议集成。设计CIP的目的是提取Whois++的索引部分，同时提取索引对象以更广泛地应用于信息检索。此外，通过将Whois++使用的特殊数据表示转换为基于结构化Internet邮件MIME规范的结构，实现了另一种技术重用。
Whois++ used a version number field in centroid objects to facilitate future growth. The initial version was "1". Version 1 of CIP (then embedded in Whois++, and not referred to separately as CIP) had support for only ISO-8895-1 characters, and for only the centroid index object type.
Whois++在形心对象中使用了一个版本号字段，以促进未来的增长。最初的版本是“1”。CIP版本1（随后嵌入Whois++，不单独称为CIP）仅支持ISO-8895-1字符，且仅支持形心索引对象类型。
Version 2 of the Whois++ centroid was used in the Digger software by Bunyip Information Systems to notify recipients that the centroid carried extra character set information. Digger's centroids can carry UTF-8 encoded 16-bit Unicode characters, or ISO-8859-1 characters, determined by a field in the headers.
Bunyip信息系统在Digger软件中使用了Whois++质心的第2版，以通知接收者质心携带了额外的字符集信息。Digger的质心可以携带UTF-8编码的16位Unicode字符，或ISO-8859-1字符，由标题中的字段确定。
This specification is for CIP version 3. Version 3 is a major overhaul to the protocol. However, by using of a short negotiation sequence, CIP version 3 servers can interoperate with earlier servers in an index-passing mesh.
本规范适用于CIP版本3。第3版是对该协议的重大修改。但是，通过使用短协商序列，CIP版本3服务器可以与索引传递网格中的早期服务器进行互操作。
For unclear terms the reader is referred to the glossary in Appendix A.
对于不清楚的术语，读者可参考附录A中的术语表。
CIP facilitates query routing. CIP is a protocol used between servers in a network to pass hints which make data access by clients at a later date more efficient. Query routing is the act of redirecting and replicating queries through a distributed database system towards the servers holding the actual results via reference to indexing information.
CIP有助于查询路由。CIP是一种在网络中的服务器之间使用的协议，用于传递提示，使客户端在以后更高效地访问数据。查询路由是通过引用索引信息，通过分布式数据库系统将查询重定向和复制到保存实际结果的服务器的行为。
CIP is a "backend" protocol -- it is implemented in and "spoken" only among network servers. These same servers must also speak some kind of data access protocol to communicate with clients. During query resolution in the native protocol implementation, the server will refer to the indexing information collected by the CIP implementation for guidance on how to route the query.
CIP是一种“后端”协议——它是在网络服务器中实现的，并且只在网络服务器之间进行“对话”。这些服务器还必须使用某种数据访问协议与客户端通信。在本机协议实现中的查询解析期间，服务器将参考CIP实现收集的索引信息，以获得有关如何路由查询的指导。
Data access protocols used with CIP must have some provision for control information in the form of a referral. The syntax and semantics of these referrals are outside the scope of this specification.
与CIP一起使用的数据访问协议必须以引用的形式提供一些控制信息。这些引用的语法和语义不在本规范的范围内。
This document is one of three documents. This document describes the fundamental concepts and framework of CIP.
本文件是三份文件之一。本文件描述了CIP的基本概念和框架。
The document "MIME Object Definitions for the Common Indexing Protocol" [CIP-MIME] describes the MIME objects that make up the items that are passed by the transport system.
文档“通用索引协议的MIME对象定义”[CIP-MIME]描述了组成传输系统传递的项的MIME对象。
Requirements and examples of several transport systems are specified in the "CIP Transport Protocols" [CIP-TRANSPORT] document.
“CIP传输协议”[CIP-transport]文件中规定了几种传输系统的要求和示例。
A second set of document describe the various specifications for specific index types.
第二组文档描述了特定索引类型的各种规范。
In order to better understand how CIP fits into the information retrieval world, we need to first understand the unifying abstract features of existing information retrieval technology. Next, we discuss why adding indexing technology to this model results in a system capable of query routing, and why query routing is useful.
为了更好地理解CIP如何融入信息检索领域，我们首先需要了解现有信息检索技术的统一抽象特征。接下来，我们将讨论为什么向该模型中添加索引技术会产生一个能够查询路由的系统，以及为什么查询路由是有用的。
An abstract view of the client/server data retrieval process includes data sets and data access protocols. An individual server is responsible for handling queries over a fixed domain of data. For the purposes of CIP, we call this domain of data the dataset. Clients make searches in the dataset and retrieve parts of it via a data access protocol. There are many data access protocols, each optimized for the data in question. For instance, LDAP and Whois++ are access protocols that reflect the needs of the directory services application domain. Other data access protocols include HTTP and Z39.50.
客户机/服务器数据检索过程的抽象视图包括数据集和数据访问协议。单个服务器负责处理固定数据域上的查询。出于CIP的目的，我们将此数据域称为数据集。客户端在数据集中进行搜索，并通过数据访问协议检索部分数据。有许多数据访问协议，每个协议都针对所讨论的数据进行了优化。例如，LDAP和Whois++是反映目录服务应用程序域需求的访问协议。其他数据访问协议包括HTTP和Z39.50。
The above description reflects a world without indexing, where no server knows about any other server. In some cases (as with X.500 referrals, and HTTP redirects) a server will, as part of its reply, implicate another server in the process of resolving the query. However, those servers generate replies based solely on their local knowledge. When indexing information is introduced into a server's local database, the server now knows not only answers based on the
上面的描述反映了一个没有索引的世界，没有服务器知道任何其他服务器。在某些情况下（与X.500引用和HTTP重定向一样），服务器将在其答复中暗示另一台服务器参与解析查询的过程。但是，这些服务器仅根据其本地知识生成回复。将索引信息引入服务器的本地数据库时，服务器现在不仅知道基于
local dataset, but also answers based on external indices. These indices come from peer servers, via an indexing protocol. CIP is one such indexing protocol.
本地数据集，但也基于外部索引进行回答。这些索引通过索引协议来自对等服务器。CIP就是这样一种索引协议。
Replies based on index information may not be the complete answer. After all, an index is not a replicated version of the remote dataset, but a possibly reduced version of it. Thus, in addition to giving complete replies from the local dataset, the server may give referrals to other datasets. These referrals are the core feature necessary for effective query routing. When servers use CIP to pass indices from server to server, they make a kind of investment. At the cost of some resources to create, transmit and store the indices, query routing becomes possible.
基于索引信息的答复可能不是完整的答复。毕竟，索引不是远程数据集的复制版本，而是它的简化版本。因此，除了从本地数据集提供完整的回复外，服务器还可以向其他数据集提供引用。这些引用是有效查询路由所必需的核心功能。当服务器使用CIP将索引从一台服务器传递到另一台服务器时，它们会进行某种投资。以创建、传输和存储索引所需的资源为代价，查询路由成为可能。
Query Routing is the process of replicating and moving a query closer to datasets which can satisfy the query. In some distributed systems, widely distributed searches must be accomplished by replicating the query to all sub-datasets. This approach can be wasteful of resources both in the network, and on the servers, and is thus sometimes explicitly disabled. Using indexing in such a system opens the door to more efficient distributed searching.
查询路由是将查询复制并移动到更接近能够满足查询的数据集的过程。在某些分布式系统中，广泛分布的搜索必须通过将查询复制到所有子数据集来完成。这种方法可能会浪费网络和服务器上的资源，因此有时会显式禁用。在这样的系统中使用索引为更高效的分布式搜索打开了大门。
While CIP-equipped servers provide the referrals necessary to make query routing work, it is always the client's responsibility to collate, filter, and chase the referrals it receives. This gives the end-user (or agent, in the case that there's no human user involved in the search) greatest control over the query resolution process. The cost of the added client complexity is weighed against the benefits of total control over query resolution. In some cases, it may also be possible to decouple the referral chasing from the client by introducing a proxy, allowing existing simple clients to make use of query routing. Such a proxy would transparently resolve referrals into concrete results before returning them to the simple-minded client.
虽然配备CIP的服务器提供查询路由工作所需的转介，但客户始终负责整理、过滤和追踪收到的转介。这使最终用户（或代理，在没有人工用户参与搜索的情况下）能够最大程度地控制查询解析过程。增加客户端复杂性的成本与完全控制查询解析的好处相权衡。在某些情况下，还可以通过引入代理将引用追踪与客户端分离，从而允许现有简单客户端使用查询路由。这种代理将透明地将转介解析为具体结果，然后再将其返回给头脑简单的客户机。
As useful as indices seem, the fact remains that not all queries can benefit from the same type of index. For example, say the index consists of a simple list of keywords. With such an index, it is impossible to answer queries about whether two keywords were near one another, or if a keyword was present in a certain context (for instance, in the title).
尽管索引看起来很有用，但事实是并非所有查询都能从相同类型的索引中获益。例如，假设索引由一个简单的关键字列表组成。有了这样一个索引，就不可能回答关于两个关键字是否彼此相邻，或者某个关键字是否存在于某个上下文中（例如，标题中）的查询。
Because of the need for application domain specific indices, CIP index objects are abstract; they must be defined by a separate specification. The basic protocols for moving index objects are widely applicable, but the specific design of the index, and the
由于需要特定于应用领域的索引，CIP索引对象是抽象的；它们必须由单独的规范定义。移动索引对象的基本协议广泛适用，但索引的具体设计以及
structure of the mesh of servers which pass a particular type of index is dependent on the application domain. This document describes only the protocols for moving indices among servers. Companion documents describe initial index objects.
通过特定类型索引的服务器网格结构取决于应用程序域。本文档仅描述在服务器之间移动索引的协议。配套文档描述了初始索引对象。
The requirements that index type specifications must address are specified in the [CIP-MIME] document.
[CIP-MIME]文档中规定了索引类型规范必须满足的要求。
CIP implements index passing, providing the forward knowledge necessary to generate the referrals used for query routing. The core of the protocol is the index object. In the following sections, the structure of the index objects themselves is presented. Next, how and why indices are passed from server to server is discussed. Finally, the circumstances under which a server may synthesize an index object based on incoming ones are discussed.
CIP实现索引传递，提供生成用于查询路由的引用所需的转发知识。协议的核心是索引对象。在以下部分中，将介绍索引对象本身的结构。接下来，将讨论索引如何以及为什么从服务器传递到服务器。最后，讨论了服务器可以根据传入的索引对象合成索引对象的情况。
A CIP index object is composed of two parts, the header and the payload. The header contains metadata necessary to process and make use of the index object being transmitted. The actual index resides in the payload.
CIP索引对象由两部分组成，头和有效负载。标头包含处理和使用正在传输的索引对象所需的元数据。实际索引驻留在有效负载中。
Three particular headers warrant specific mention at this point. The "type" of the index object selects one of many distinct CIP index object specifications which define exactly how the index blocks are to be created, parsed and used to facilitate query routing. Another header of note is the "DSI", or Dataset Identifier, which uniquely identifies the dataset from which the index was created. Another header that is crucial for generating referrals is the "Base-URI". The URI (or URI's) contained in this header form the basis of any referrals generated based on this index block. The URI is also used as input during the index aggregation process to constrain the kinds of aggregation possible, due to multiprotocol constraints. How that URI is used is defined by the aggregation algorithm. The exact syntax of these headers is specified in the CIP MIME specification document [CIP-MIME].
在这一点上，有三个特别的标题值得特别提及。索引对象的“类型”选择了许多不同的CIP索引对象规范中的一种，这些规范准确地定义了如何创建、解析和使用索引块来促进查询路由。另一个值得注意的标题是“DSI”或数据集标识符，它唯一地标识从中创建索引的数据集。另一个对生成引用至关重要的头是“基本URI”。此标头中包含的URI构成基于此索引块生成的任何引用的基础。由于多协议约束，在索引聚合过程中，URI还用作输入，以约束可能的聚合类型。该URI的使用方式由聚合算法定义。这些头的确切语法在CIP MIME规范文档[CIP-MIME]中指定。
The payload is opaque to CIP itself. It is defined exclusively by the index object specification associated with the object's MIME type. Specifications on how to parse and use the payload are published separately as "CIP index object specifications". This abstract definition of the index object forms the basis of CIP's applicability to indexing needs across multiple application domains.
有效载荷对CIP本身是不透明的。它由与对象的MIME类型关联的索引对象规范专门定义。关于如何解析和使用有效负载的规范作为“CIP索引对象规范”单独发布。索引对象的这种抽象定义构成了CIP适用于跨多个应用程序域的索引需求的基础。
A precise definition of the content and form of a CIP index block can be found in the Protocol document [CIP-MIME]
CIP索引块的内容和形式的精确定义可在协议文档[CIP-MIME]中找到
Indices are transmitted among servers participating in a CIP mesh. By distributing this information in anticipation of a query, efficient, accurate query routing is possible at the time a query arrives.
索引在参与CIP网格的服务器之间传输。通过在预期查询的情况下分发此信息，可以在查询到达时实现高效、准确的查询路由。
A CIP mesh is a set of CIP servers which pass indices of the same type among themselves. Typically, a mesh is arranged in a hierarchical tree fashion, with servers nearer the root of the tree having larger and more comprehensive indices. See Figure 1. However, a CIP mesh is explicitly allowed to have lateral links in it, and there may be more than one part of the mesh that has the properties of a "root". Mesh administrators are encouraged to avoid loops in the system, but they are not obliged to maintain a strict tree structure. Clients wishing to completely resolve all referrals they receive should protect against referral loops while attempting to traverse the mesh to avoid wasting time and network resources. See the section on "Navigating the Mesh" for a discussion of this.
CIP网格是一组在它们之间传递相同类型索引的CIP服务器。通常，网格以分层树的方式排列，靠近树根的服务器具有更大和更全面的索引。参见图1。但是，明确允许CIP网格具有横向链接，并且可能有多个网格部分具有“根”属性。鼓励Mesh管理员避免系统中的循环，但他们没有义务维护严格的树结构。希望完全解析其收到的所有转介的客户端应在尝试遍历网格时防止转介循环，以避免浪费时间和网络资源。有关这方面的讨论，请参见“导航网格”部分。
base level index index
directory servers servers
servers for for
base level lower-level
servers index servers
_______
| |
| A |__
|_______| \ _______
\---CIP----| |
_______ | D |__
| | /---CIP----|_______| \ ------
| B |__/ \--CIP------| |
|_______| | F |
/--CIP------|______|
/
_______ _______ /
| | | |-
| C |-------CIP----| E |
|_______| |_______|-
| \
r \
_______ e \ ______
| | f \--CIP-----| |
| G |-------CIP---------e------------------| H |
|_______| r |______|
\--referral---| r --referral-/
base level index index
directory servers servers
servers for for
base level lower-level
servers index servers
_______
| |
| A |__
|_______| \ _______
\---CIP----| |
_______ | D |__
| | /---CIP----|_______| \ ------
| B |__/ \--CIP------| |
|_______| | F |
/--CIP------|______|
/
_______ _______ /
| | | |-
| C |-------CIP----| E |
|_______| |_______|-
| \
r \
_______ e \ ______
| | f \--CIP-----| |
| G |-------CIP---------e------------------| H |
|_______| r |______|
\--referral---| r --referral-/
| a |
|a|
| l |
|l|
\ 3 | 2 | 1
\ 3 | 2 | 1
\--------/
\--------/
| |
| |
| client |
|客户|
| |
| |
--------
--------
Figure 1: Sample layout of the Index Service mesh
图1：索引服务网格的示例布局
All indices passed in a given mesh are assumed, as of this writing, to be of the same type (i.e. governed by the same CIP index object specification). It may be possible to create gateways between meshes carrying different index objects, but at this time that process is undefined and declared to be outside the scope of this specification.
在撰写本文时，假设给定网格中传递的所有索引都是相同类型的（即受相同CIP索引对象规范的控制）。可以在承载不同索引对象的网格之间创建网关，但此时该过程未定义，并声明不在本规范的范围内。
In the case where a CIP server receives an index of a type that it does not understand it _can_ pass that index forward untouched. In the case where a server implementation decides not to accept unknown indices it should return an appropriate error message to the server sending the index. This behavior is to allow mesh implementations to attempt heterogeneous meshes. As stated above heterogeneous meshes are considered to be ill defined and as such should be considered dangerous.
如果CIP服务器接收到一个它不理解的索引类型，那么它可以将该索引原封不动地向前传递。在服务器实现决定不接受未知索引的情况下，它应该向发送索引的服务器返回适当的错误消息。此行为允许网格实现尝试异构网格。如上所述，不均匀网格被视为定义不清，因此应被视为危险网格。
Experience suggests that this index passing activity should take place among CIP servers as a parallel (and possibly lower-priority) job to their primary job of answering queries. Index objects travel among CIP servers by protocol exchanges explicitly defined in this document, not via the server's native protocol. This distinction is important, and bears repeating:
经验表明，这种索引传递活动应该在CIP服务器之间进行，作为一种与其应答查询的主要工作并行（可能优先级较低）的工作。索引对象通过本文档中明确定义的协议交换在CIP服务器之间传输，而不是通过服务器的本机协议。这一区别很重要，值得重复：
Queries are answered (and referrals are sent) via the native data access protocol.
通过本机数据访问协议回答查询（并发送转介）。
Index objects are transferred via alternative means, as defined by this document.
索引对象通过本文档定义的其他方式传输。
When two servers cooperate to move indexing information, the pair are said to be in a "polling relationship". The server that holds the data of interest, and generates the index is called the "polled server". The other server, which is the one that collects the generated index, is the "polling server".
当两台服务器合作移动索引信息时，这对服务器就被称为处于“轮询关系”。保存感兴趣的数据并生成索引的服务器称为“轮询服务器”。另一个收集生成的索引的服务器是“轮询服务器”。
In a polling relationship, the polled server is responsible for notifying the polling server when it has a new index that the polling server might be interested in. In response, the polling server may immediately pick up the index object, or it may schedule a job to pick up a copy of the new index at a more convenient time. But, a polling server is not required to wait on the polled server to notify it of changes. The polling server can request a new index at any time.
在轮询关系中，轮询服务器负责在轮询服务器可能感兴趣的新索引出现时通知轮询服务器。作为响应，轮询服务器可以立即拾取索引对象，或者它可以安排作业，以便在更方便的时间拾取新索引的副本。但是，轮询服务器不需要等待轮询服务器通知其更改。轮询服务器可以随时请求新索引。
Independent of the symmetric polling relationship, there's another way that servers can pass indices using CIP. In an "index pushing" relationship, a CIP server simply sends the index to a peer whenever necessary, and allows the receiver to handle the index object as it
独立于对称轮询关系，还有另一种方式，服务器可以使用CIP传递索引。在“索引推送”关系中，CIP服务器只需在必要时将索引发送给对等方，并允许接收方在需要时处理索引对象
chooses. The receiving server may refuse it, may accept it, then silently discard it, may accept only portions of it (by accepting it as is, then filtering it), or may accept it without question.
选择。接收服务器可以拒绝它，可以接受它，然后默默地丢弃它，可以只接受它的一部分（通过原样接受它，然后过滤它），或者可以毫无疑问地接受它。
The index pushing relationship is intended for use by dumb leaf nodes which simply want to make their index available to the global mesh of servers, but have no interest in implementing the complete CIP transaction protocol. It lowers the barriers to entry for CIP leaf nodes. For more information on participating in a CIP mesh in this restricted manner, see the section below on "Protocol Conformance". CIP index passing operations take place across a reliable transport mechanisms, including both TCP connections, and Internet mail messages. The precise mechanisms are described in the Transport document [CIP-Transport].
索引推送关系旨在供哑巴叶节点使用，哑巴叶节点只想使其索引可用于服务器的全局网格，但对实现完整的CIP事务协议没有兴趣。它降低了CIP叶节点的进入壁垒。有关以这种受限方式参与CIP网格的更多信息，请参阅下面关于“协议一致性”的部分。CIP索引传递操作通过可靠的传输机制进行，包括TCP连接和Internet邮件消息。运输文件[CIP运输]中描述了精确的机制。
From the preceding discussion, it should be clear that indexing servers read and write index objects as they pass them around the mesh. However, a CIP server need not simply pass the in-bound indices through as the out-bound ones. While it is always permissible to pass an index object through to other servers, a server may choose to aggregate two or more of them, thereby reducing redundancy in the index, at the cost of longer referral chains.
从前面的讨论中可以清楚地看到，索引服务器在网格中传递索引对象时读取和写入索引对象。然而，CIP服务器不需要简单地将入界索引作为出界索引传递。虽然始终允许将索引对象传递给其他服务器，但服务器可以选择聚合其中的两个或多个，从而减少索引中的冗余，但代价是引用链更长。
A basic premise of index passing is that even while collapsing a body of data into an index by lossy compression methods, hints useful to routing queries will survive in the resulting index. Since the index is not a complete copy of the original dataset, it contains less information. Index objects can be passed along unchanged, but as more and more information collects in the resulting index object, redundancy will creep in again, and it may prove useful to apply the compression again, by aggregating two or more index objects into one.
索引传递的一个基本前提是，即使通过有损压缩方法将数据体压缩为索引，对路由查询有用的提示也会保留在结果索引中。由于索引不是原始数据集的完整副本，因此包含的信息较少。索引对象可以原封不动地传递，但随着越来越多的信息收集到结果索引对象中，冗余将再次出现，通过将两个或多个索引对象聚合到一个索引对象中，再次应用压缩可能会很有用。
This kind of aggregation should be performed without compromising the ability to correctly route queries while avoiding excessive numbers of missed results. The acceptable likelihood of false negatives must be established on a per-application-domain basis, and is controlled by the granularity of the index and the aggregation rules defined for it by the particular specification.
这种聚合应该在不损害正确路由查询的能力的情况下执行，同时避免过多的遗漏结果。必须在每个应用程序域的基础上确定可接受的误报可能性，并由索引的粒度和特定规范为其定义的聚合规则控制。
However, when CIP is used in a multi-protocol application domain, such as a Directory Service (with contenders including Whois++, LDAP, and Ph), things get significantly trickier. The fundamental problem is to avoid forcing a referral chain to pass through part of the mesh which does not support the protocol by which that client made the query. If this ever happens, the client loses access to any hits
然而，当CIP用于多协议应用领域时，比如目录服务（包括Whois++、LDAP和Ph），事情会变得非常棘手。基本问题是避免强制引用链通过不支持客户端进行查询的协议的网格部分。如果发生这种情况，客户端将无法访问任何点击
beyond that point in the referral chain, since it cannot resolve the referral in its native data access protocol. This is a failure of query routing, which should be avoided.
超出引用链中的该点，因为它无法在其本机数据访问协议中解析引用。这是查询路由的失败，应该避免。
In addition to multi-protocol considerations, server managers may choose not to allow index object aggregation for performance reasons. As referral chains lengthen, a client needs to perform more transactions to resolve a query. As the number of transactions increases, so do the user-perceived delays, the system loads, and the global bandwidth demands. In general, there's a tradeoff between aggressive aggregation (which leads to reductions in the indexing overhead) and aggressive referral chain optimization. This tradeoff, which is also sensitive to the particular application domain, needs to be explored more in actual operational situations.
除了多协议注意事项外，出于性能原因，服务器管理器可能会选择不允许索引对象聚合。随着引用链的延长，客户机需要执行更多的事务来解决查询。随着事务数量的增加，用户感知的延迟、系统负载和全局带宽需求也会增加。一般来说，积极聚合（这会减少索引开销）和积极推荐链优化之间存在权衡。这种权衡对特定的应用领域也很敏感，需要在实际操作情况下进行更多的探索。
Conceptually, a CIP index server has several index objects on hand at any given time. If it holds data in addition to indexing information, the server has an index object formed from its own data, called the "local index". It may have one or more indices from remote servers which it has collected via the index passing mechanisms. These are called "in-bound indices".
从概念上讲，CIP索引服务器在任何给定时间都有多个索引对象。如果服务器除了保存索引信息外还保存数据，那么它就有一个由自己的数据形成的索引对象，称为“本地索引”。它可能有一个或多个通过索引传递机制从远程服务器收集的索引。这些被称为“内界指数”。
Implementor's Note: It may not be necessary to keep all of these structures intact and distinct in the local database. It is also not required to keep the out-bound index (or indices) built and ready to distribute at all times. The previous paragraph merely introduces a useful model for expressing the aggregation rules. Implementors are free to model index objects internally however they see fit.
实现者注意：可能没有必要在本地数据库中保持所有这些结构的完整性和独特性。也不需要始终构建并准备分发外边界索引。上一段仅介绍了一个用于表示聚合规则的有用模型。实现者可以自由地对索引对象进行内部建模，但他们认为合适。
The following two rules control how a CIP server formulates its outgoing indices:
以下两条规则控制CIP服务器如何制定其传出索引：
1. An index server may pass any of the index objects in its local index and its in-bound indices through unchanged to polling servers.
1. 索引服务器可以将其本地索引和绑定索引中的任何索引对象通过unchanged传递给轮询服务器。
2. If and only if the following three conditions are true, an index server can aggregate two or more index objects into a single new index object, to be added to the set of out-bound indices.
2. 如果且仅当以下三个条件为真时，索引服务器可以将两个或多个索引对象聚合为一个新的索引对象，以添加到外边界索引集中。
a. Each index object to be aggregated covers exactly the same set of protocols, as defined by the scheme component of the Base-URI's in each index object.
a. 要聚合的每个索引对象覆盖完全相同的协议集，这是由每个索引对象中基本URI的scheme组件定义的。
b. The index server supports every one of the data access protocols represented by the Base-URI's in the index objects to be aggregated.
b. 索引服务器支持由要聚合的索引对象中的基本URI表示的每一个数据访问协议。
c. The specification for the index object type specified by the type header of the index objects explicitly defines the aggregation operation.
c. 由索引对象的类型标头指定的索引对象类型规范明确定义了聚合操作。
The resulting index object must have Base-URI's characteristic of the local server for each protocol it supports. The outgoing objects should have the DSI of the local server.
对于所支持的每个协议，结果索引对象必须具有本地服务器的基本URI特征。传出对象应具有本地服务器的DSI。
With the CIP infrastructure in place to manage index objects, the only problem remaining is how to successfully use the indexing information to do efficient searches. CIP facilitates query routing, which is essentially a client activity. A client connects to one server, which redirects the query to servers "closer to" the answer. This redirection message is called a referral.
使用CIP基础设施管理索引对象后，剩下的唯一问题是如何成功地使用索引信息进行高效搜索。CIP促进了查询路由，这本质上是一种客户端活动。客户机连接到一台服务器，这会将查询重定向到“更接近”答案的服务器。此重定向消息称为引用。
The concept of a referral and the mechanism for deciding when they should be issued is described by CIP. However, the referral itself must be transferred to the client in the native protocol, so its syntax is not directly a CIP issue. The mechanism for deciding that a referral needs to be made and generating that referral resides in the CIP implementation in the server. The mechanism for sending the referral to the client resides in the server's native protocol implementation.
CIP描述了转介的概念和决定何时发布的机制。但是，引用本身必须在本机协议中传输到客户端，因此其语法不是直接的CIP问题。决定需要进行引用并生成该引用的机制驻留在服务器的CIP实现中。将引用发送到客户端的机制驻留在服务器的本机协议实现中。
A referral is made when a search against the index objects held by the server shows that there may be hits available in one of the datasets represented by those index objects. If more that one index object indicates that a referral must be generated to a given dataset, the server should generate only one referral to the given dataset, as the client may not be able to detect duplicates.
当对服务器持有的索引对象的搜索显示这些索引对象所代表的数据集中可能有可用的点击时，就会进行引用。如果多个索引对象指示必须生成对给定数据集的引用，则服务器应仅生成对给定数据集的一个引用，因为客户端可能无法检测到重复。
Though the format of the referral is dependent on the native protocol(s) of the CIP server, the baseline contents of the referral are constant across all protocols. At the least, a DSI and a URI must be returned. The DSI is the DSI associated with the dataset which caused the hit. This must be presented to the client so that it can avoid referral loops. The Base-URI parameter which travels along with index objects is used to provide the other required part of a referral.
尽管引用的格式取决于CIP服务器的本机协议，但在所有协议中，引用的基线内容都是恒定的。至少，必须返回DSI和URI。DSI是与导致命中的数据集关联的DSI。这必须呈现给客户机，以便它可以避免引用循环。与索引对象一起移动的基本URI参数用于提供引用的其他必需部分。
The additional information in the Base-URI may be necessary for the server receiving the referred query to correctly handle it. A good example of this is an LDAP server, which needs a base X.500 distinguished name from which to search. When an LDAP server sends a
基本URI中的附加信息可能是接收引用查询的服务器正确处理查询所必需的。LDAP服务器就是一个很好的例子，它需要一个基本的X.500可分辨名称来进行搜索。当LDAP服务器发送
centroid-format index object up to a CIP indexing server, it sends a Base-URI along with the name of the X.500 subtree for which the index was made. When a referral is made, the Base-URI is passed back to the client so that it can pass it to the original LDAP server.
质心格式索引对象，它向CIP索引服务器发送一个基本URI以及为其创建索引的X.500子树的名称。在进行引用时，基本URI会传递回客户端，以便客户端可以将其传递给原始LDAP服务器。
As usual, in addition to sending the DSI, a DSI-Description header can be optionally sent. Because a client may attempt to check with the user before chasing the referral, and because this string is the friendliest representation of the DSI that CIP has to offer, it should be included in referrals when available (i.e. when it was sent along with the index object).
通常，除了发送DSI之外，还可以选择发送DSI描述头。由于客户机可能会在追踪转介之前尝试与用户进行检查，并且由于此字符串是CIP必须提供的DSI的最友好表示形式，因此应在可用时（即，当它与索引对象一起发送时）将其包括在转介中。
Each data access protocol which uses CIP will need a clearly defined set of rules to map queries in the native protocol to searches against an index object. These rules will vary according to the data domain. In principle, this could create a bit of a scaling difficulty; for N protocols and M data domains, there would be N x M mappings required. In practice, this should not be the case, since some access protocols will be wholly unsuited to some data domains. Consider for example, a LDAP server trying to make a search in an index object composed from unorganized text based pages. What would the results be? How would the client make sense of the results?
使用CIP的每个数据访问协议都需要一组明确定义的规则，以将本机协议中的查询映射到针对索引对象的搜索。这些规则因数据域而异。原则上，这可能会造成一些缩放困难；对于N个协议和M个数据域，需要N x M个映射。实际上，情况不应该是这样，因为某些访问协议将完全不适合某些数据域。例如，考虑LDAP服务器试图在由无组织的基于文本的页面组成的索引对象中进行搜索。结果会怎样？客户如何理解结果？
However, as pre-existing protocols are connected to CIP, and as new ones are developed to work with CIP, this issue must be examined. In the case of Whois++ and the CENTROID index type, there is an extremely close mapping, since the two were designed together. When hooking LDAP to the CENTROID index type, it will be necessary to map the attribute names used in the LDAP system to attribute names which are already being used in the CENTROID mesh. It will also be necessary to tokenize the LDAP queries under the same rules as the CENTROID indexing policy, so that searches will take place correctly. These application- and protocol-specific actions must be specified in the index object specification, as discussed in the [CIP-MIME] document.
然而，由于已有的协议连接到CIP，并且开发了新的协议与CIP一起使用，因此必须检查这个问题。在Whois++和形心索引类型的情况下，有一个非常接近的映射，因为这两个是一起设计的。将LDAP挂接到质心索引类型时，需要将LDAP系统中使用的属性名称映射到质心网格中已经使用的属性名称。还需要根据与形心索引策略相同的规则标记LDAP查询，以便正确进行搜索。这些特定于应用程序和协议的操作必须在索引对象规范中指定，如[CIP-MIME]文档中所述。
From a client's point of view, CIP simply pushes all the "hard work" onto its shoulders. After all, it is the client which needs to track down the real data. While this is true, it is very misleading. Because the client has control over the query routing process, the client has significant control over the size of the result set, the speed with which the query progresses, and the depth of the search.
从客户的角度来看，CIP只是将所有的“艰苦工作”推到自己的肩上。毕竟，需要跟踪真实数据的是客户机。虽然这是真的，但这是非常误导的。因为客户机可以控制查询路由过程，所以客户机可以显著控制结果集的大小、查询进程的速度以及搜索的深度。
The simplest client implementation provides referrals to the user in a raw, ready-to-reuse form, without attempting to follow them. For instance, one Whois++ client, which interacts with the user via a Web-based form, simply makes referrals into HTML hypertext links. Encoded in the link via the HTML forms interface GET encoding rules is the data of the referral: the hostname, port, and query. If a user chooses to follow the referral link, he executes a new search on the new host. A more savvy client might present the referrals to the user and ask which should be followed. And, assuming appropriate limits were placed on search time and bandwidth usage, it might be reasonable to program a client to follow all referrals automatically.
最简单的客户机实现以原始的、可重用的形式向用户提供引用，而无需尝试遵循这些引用。例如，一个Whois++客户机通过基于Web的表单与用户交互，只需将引用转换为HTML超文本链接。通过HTML表单接口GET编码规则在链接中编码的是引用的数据：主机名、端口和查询。如果用户选择跟随推荐链接，他将在新主机上执行新搜索。一个更精明的客户可能会向用户介绍推荐，并询问应该遵循哪一条。而且，假设对搜索时间和带宽使用设置了适当的限制，那么对客户端进行编程以自动跟踪所有推荐可能是合理的。
When following all referrals, a client must show a bit of intelligence. Remember that the mesh is defined as an interconnected graph of CIP servers. This graph may have cycles, which could cause an infinite loop of referrals, wasting the servers' time and the client's too. When faced with the job of tacking down all referrals, a client must use some form of a mesh traversal algorithm. Such an algorithm has been documented for use with Whois++ in RFC-1914. The same algorithm can be easily used with this version of CIP. In Whois++ the equivalent of a DSI is called a handle. With this substitution, the Whois++ mesh traversal algorithm works unchanged with CIP.
当遵循所有推荐时，客户必须表现出一定的智慧。请记住，网格定义为CIP服务器的互连图。这个图可能有循环，这可能导致无限循环的引用，浪费服务器和客户端的时间。当面对处理所有转介的工作时，客户机必须使用某种形式的网格遍历算法。这种算法已在RFC-1914中记录，可与Whois++一起使用。此版本的CIP可以轻松使用相同的算法。在Whois++中，DSI的等价物称为句柄。通过这种替换，Whois++网格遍历算法的工作原理与CIP相同。
Finally, the mesh entry point (i.e. the first server queried) can have an impact on the success of the query. To avoid scaling issues, it is not acceptable to use a single "root" node, and force all clients to connect to it. Instead, clients should connect to a reasonably well connected (with respect to the CIP mesh, not the Internet infrastructure) local server. If no match can be made from this entry point, the client can expand the search by asking the original server who polls it. In general, those servers will have a better "vantage point" on the mesh, and will turn up answers that the initial search didn't. The mechanism for dynamically determining the mesh structure like this exists, but is not documented here for brevity. See RFC-1913 for more information on the POLLED-BY and POLLED-FOR commands.
最后，mesh入口点（即第一个查询的服务器）可能会影响查询的成功。为了避免伸缩问题，不允许使用单个“根”节点并强制所有客户端连接到该节点。相反，客户端应该连接到一个连接合理的本地服务器（相对于CIP网格，而不是互联网基础设施）。如果无法从此入口点进行匹配，则客户端可以通过询问轮询它的原始服务器来扩展搜索。一般来说，这些服务器在网格上会有更好的“有利位置”，并且会找到最初搜索没有找到的答案。这种动态确定网格结构的机制是存在的，但为了简洁起见，这里没有记录。有关POLLED-BY和POLLED-for命令的更多信息，请参阅RFC-1913。
It still should be noted that, while these mesh operations are important to optimizing the searches that a client should make, the client still speaks its native protocol. This information must be communicated to the client without causing the client to have to understand CIP.
仍然需要注意的是，虽然这些网格操作对于优化客户端应该进行的搜索非常重要，但客户端仍然使用其本机协议。该信息必须传达给客户，而不会导致客户理解CIP。
In this section, we discuss the security considerations necessary when making use of this specification. There are at least three levels at which security considerations come into play. Indexing information can leak undesirable amounts of proprietary information, unless carefully controlled. At a more fundamental level, the CIP protocol itself requires external security services to operate in a safe manner. Lastly, CIP itself can be used to propogate false information.
在本节中，我们将讨论使用本规范时所需的安全注意事项。至少有三个级别的安全考虑因素发挥作用。除非小心控制，否则索引信息可能会泄漏大量不必要的专有信息。在更基本的层面上，CIP协议本身要求外部安全服务以安全的方式运行。最后，CIP本身可以用来传播虚假信息。
CIP is designed to index all kinds of data. Some of this data might be considered valuable, proprietary, or even highly sensitive by the data maintainer. Take, for example, a human resources database. Certain bits of data, in moderation, can be very helpful for a company to make public. However, the database in its entirety is a very valuable asset, which the company must protect. Much experience has been gained in the directory service community over the years as to how best to walk this fine line between completely revealing the database and making useful pieces of it available. There are also legal considerations regarding what data can be collected and shared.
CIP旨在为各种数据编制索引。其中一些数据可能被数据维护者认为是有价值的、专有的，甚至是高度敏感的。以人力资源数据库为例。某些数据在适度的情况下对公司的公开非常有帮助。然而，整个数据库是一项非常宝贵的资产，公司必须加以保护。多年来，目录服务社区已经积累了很多经验，了解如何在完全显示数据库和提供有用的数据库片段之间走这条细线。关于可以收集和共享哪些数据，还有一些法律方面的考虑。
Another example where security becomes a problem is for a data publisher who'd like to participate in a CIP mesh. The data that publisher creates and manages is the prime asset of the company. There is a financial incentive to participate in a CIP mesh, since exporting indices of the data will make it more likely that people will search your database. (Making profit off of the search activity is left as an exercise to the entrepreneur.) Once again, the index must be designed carefully to protect the database while providing a useful synopsis of the data.
安全性成为问题的另一个例子是，数据发布者希望参与CIP网格。publisher创建和管理的数据是公司的主要资产。加入CIP网格是一种经济激励，因为导出数据索引将使人们更有可能搜索您的数据库。（从搜索活动中获利是留给企业家的一项练习。）再次，索引必须仔细设计，以保护数据库，同时提供有用的数据概要。
One of the basic premises of CIP is that data providers will be willing to provide indices of their data to peer indexing servers. Unless they are carefully constructed, these indices could constitute a threat to the security of the database. Thus, security of the data must be a prime consideration when developing a new index object type. The risk of reverse engineering a database based only on the index exported from it must be kept to a level consistent with the value of the data and the need for fine-grained indexing.
CIP的一个基本前提是，数据提供商愿意向对等索引服务器提供其数据的索引。除非仔细构造这些索引，否则这些索引可能对数据库的安全构成威胁。所以，在开发新的索引对象类型时，数据的安全性必须是首要考虑因素。仅基于从数据库导出的索引对数据库进行反向工程的风险必须保持在与数据值和细粒度索引需求一致的级别。
Lastly, mesh organizers should be aware that the insertion of false data into a mesh can be used as part of an attack. Depending on the type of mesh and aggregation algorithms, an index can selectivly prune parts of a mesh. Also, since CIP is used to discover
最后，网格组织者应该意识到，将虚假数据插入网格可能被用作攻击的一部分。根据网格类型和聚合算法，索引可以选择性地修剪网格的各个部分。此外，由于CIP用于发现
information, it will be the target for the advertisement of false information. CIP does not provide a method for trusting the data that it contains.
信息，它将成为虚假信息广告的目标。CIP不提供信任其包含的数据的方法。
Acknowledgments
致谢
Thanks to the many helpful members of the FIND working group for discussions leading to this specification.
感谢FIND工作组中许多有帮助的成员对本规范的讨论。
Specific acknowledgment is given to Jeff Allen formerly of Bunyip Information Systems. His original version of these documents helped enormously in crystallizing the debate and consensus. Most of the actual text in this document was originally authored by Jeff. Jeff is no longer involved with the FIND Working Group or with editing this document. His authorship is preserved by a specific decision of the current editor.
特别感谢Bunyip信息系统公司的Jeff Allen。他对这些文件的原始版本极大地帮助了辩论和共识的具体化。本文档中的大部分实际文本最初由Jeff编写。Jeff不再参与FIND工作组或编辑此文档。现任编辑的具体决定保留了他的作者身份。
Authors' Addresses
作者地址
Jeff R. Allen 246 Hawthorne St. Palo Alto, CA 94301
杰夫·R·艾伦246霍桑圣帕洛阿尔托，加利福尼亚州94301
EMail: jeff.allen@acm.org
EMail: jeff.allen@acm.org
Michael Mealling Network Solutions, Inc. 505 Huntmar Park Drive Herndon, VA 22070
迈克尔·米林网络解决方案有限公司，地址：弗吉尼亚州亨特马公园大道505号，邮编：22070
Phone: (703) 742-0400 EMail: michael.mealling@RWhois.net
电话：（703）742-0400电子邮件：迈克尔。mealling@RWhois.net
References
工具书类
[RFC1913] Weider, C., Fullton, J. and S. Spero, "Architecture of the Whois++Index Service", RFC 1913, February 1996.
[RFC1913]Weider，C.，Fullton，J.和S.Spero，“Whois++索引服务的体系结构”，RFC19131996年2月。
[RFC1914] Faltstrom, P., Schoultz, R. and C. Weider, "How to Interact with a Whois++ Mesh", RFC 1914, February 1996.
[RFC1914]Faltstrom，P.，Schoultz，R.和C.Weider，“如何与Whois++网格交互”，RFC19141996年2月。
[CIP-MIME] Allen, J. and M. Mealling, "MIME Object Definitions for the Common Indexing Protocol (CIP)", RFC 2652, August 1999.
[CIP-MIME]Allen，J.和M.Mealling，“通用索引协议（CIP）的MIME对象定义”，RFC 2652，1999年8月。
[CIP-TRANSPORT] Allen, J. and P. Leach, "CIP Transport Protocols", RFC 2653, August 1999.
[CIP-TRANSPORT]Allen，J.和P.Leach，“CIP传输协议”，RFC 2653，1999年8月。
Appendix A: Glossary
附录A：词汇表
application domain: A problem domain to which CIP is applied which has indexing requirements which are not subsumed by any existing problem domain. Separate application domains require separate index object specifications, and potentially separate CIP meshes. See index object specification.
应用领域：应用CIP的问题领域，其索引要求不属于任何现有问题领域。单独的应用程序域需要单独的索引对象规范，并且可能需要单独的CIP网格。请参阅索引对象规范。
centroid: An index object type used with Whois++. In CIP versions before version 3, the index was not extensible, and could only take the form of a centroid. A centroid is a list of (template name, attribute name, token) tuples with duplicate removed.
形心：与Whois++一起使用的索引对象类型。在版本3之前的CIP版本中，索引不可扩展，只能采用形心的形式。质心是（模板名称、属性名称、标记）元组的列表，其中删除了重复的元组。
dataset: A collection of data (real or virtual) over which an index is created. When a CIP server aggregates two or more indices, the resultant index represents the index from a "virtual dataset", spanning the previous two datasets.
数据集：在其上创建索引的数据集合（真实或虚拟）。当CIP服务器聚合两个或多个索引时，结果索引表示跨越前两个数据集的“虚拟数据集”中的索引。
Dataset Identifier: An identifier chosen from any part of the ISO/CCITT OID space which uniquely identifies a given dataset among all datasets indexed by CIP.
数据集标识符：从ISO/CCITT OID空间的任何部分中选择的标识符，它在CIP索引的所有数据集中唯一地标识给定的数据集。
DSI: See Dataset Identifier.
DSI：请参阅数据集标识符。
DSI-description: A human readable string optionally carried along with DSI's to make them more user-friendly. See dataset Identifier.
DSI描述：一个人类可读的字符串，可以选择与DSI一起携带，以使其更加用户友好。请参阅数据集标识符。
index: A summary or compressed form of a body of data. Examples include a unique list of words, a codified full text analysis, a set of keywords, etc.
索引：数据体的摘要或压缩形式。示例包括一个独特的单词列表、一个编码的全文分析、一组关键字等。
index object: The embodiment of the indices passed by CIP. An index object consists of some control attributes and an opaque payload.
索引对象：CIP传递的索引的体现。索引对象由一些控件属性和不透明的负载组成。
index object specification: A document describing an index object type for use with the CIP system described in this document. See index object and payload.
索引对象规范：描述用于本文档所述CIP系统的索引对象类型的文档。请参阅索引对象和有效负载。
index pushing: The act of presenting, unsolicited, an index to a peer CIP server.
索引推送：主动向对等CIP服务器提交索引的行为。
MIME: see Multipurpose Internet Mail Extensions
MIME：请参阅多用途Internet邮件扩展
Multipurpose Internet Mail Extensions: A set of rules for encoding Internet Mail messages that gives them richer structure. CIP uses MIME rules to simplify object encoding issues. MIME is specified in RFC-1521 and RFC-1522.
多用途Internet邮件扩展：一组用于编码Internet邮件消息的规则，使其具有更丰富的结构。CIP使用MIME规则简化对象编码问题。RFC-1521和RFC-1522中规定了MIME。
payload: The application domain specific indexing information stored inside an index object. The format of the payload is specified externally to this document, and depends on the type of the containing index object.
有效负载：存储在索引对象中的特定于应用程序域的索引信息。有效负载的格式在此文档外部指定，并取决于包含索引对象的类型。
polled server: A CIP server which receives a request to generate and pass an index to a peer server.
轮询服务器：一种CIP服务器，接收生成索引并将其传递给对等服务器的请求。
polling server: A CIP server which generates a request to a peer server for its index.
轮询服务器：向对等服务器生成索引请求的CIP服务器。
referral chain: The set of referrals generated by the process of routing a query. See query routing.
转介链：路由查询过程生成的转介集。请参阅查询路由。
query routing: Based on reference to indexing information, redirecting and replicating queries through a distributed database system towards the servers holding the actual results.
查询路由：基于对索引信息的引用，通过分布式数据库系统将查询重定向和复制到保存实际结果的服务器。
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。