Network Working Group J. Allen
Request for Comments: 2652 WebTV Networks, Inc.
Category: Standards Track M. Mealling
Network Solutions, Inc.
August 1999
Network Working Group J. Allen
Request for Comments: 2652 WebTV Networks, Inc.
Category: Standards Track M. Mealling
Network Solutions, Inc.
August 1999
MIME Object Definitions for the Common Indexing Protocol (CIP)
通用索引协议（CIP）的MIME对象定义
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. The protocol is comprised of several MIME objects being passed from server to server. This document describes the definitions of those objects as well as the methods and requirements needed to define a new index type.
公共索引协议（CIP）用于将索引信息从服务器传递到服务器，以便于查询路由。该协议由几个从服务器传递到服务器的MIME对象组成。本文档描述了这些对象的定义以及定义新索引类型所需的方法和要求。
The Common Indexing Protocol (CIP) is used to pass indexes between servers that combine multiple indexes and/or route queries based on those indexes. The overall framework for the protocol is specified in the CIP Framework document [FRAMEWORK]. This document should be read within the context of that document as there are fundamental concepts contained in the framework that are not fully explained here.
公共索引协议（CIP）用于在组合多个索引的服务器之间传递索引和/或基于这些索引路由查询。CIP框架文件[框架]中规定了协议的总体框架。本文件应在该文件的背景下阅读，因为该框架中包含的一些基本概念在此未作充分解释。
Since there are several different ways to index a given database there will be multiple types of indexes to pass. These indexes may have different transport requirements, different ways of specifying parameters, and different referral rules. These different requirements are handled by encapsulating the indexes within MIME wrappers in order to have a standardized way to specify those different parameters.
由于有几种不同的方法为给定数据库编制索引，因此需要传递多种类型的索引。这些索引可能有不同的传输要求、不同的参数指定方式和不同的引用规则。这些不同的需求是通过在MIME包装器中封装索引来处理的，以便有一种标准化的方法来指定这些不同的参数。
Appendix A contains the actual MIME [RFC2046] registration templates sent to the IANA for registration [RFC2048].
附录A包含发送给IANA进行注册[RFC2048]的实际MIME[RFC2046]注册模板。
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].
本文件使用的语言如“应”和“应”，具有“RFC中用于表示需求水平的关键词”[RFC2119]中规定的特殊含义。
Messages passed by CIP implementations over reliable transport mechanisms fall into three categories: requests, responses and results. All requests result in either a response or a result. A result sent in response to a request must be interpreted as a successful operation.
CIP实现通过可靠传输机制传递的消息分为三类：请求、响应和结果。所有请求都会产生响应或结果。响应请求发送的结果必须解释为成功的操作。
Requests, responses and results are formatted as MIME [RFC2046] messages. The specific MIME types involved are defined below.
请求、响应和结果的格式为MIME[RFC2046]消息。所涉及的特定MIME类型定义如下。
As with all MIME objects, CIP messages may be wrapped in a security multipart package to provide authentication and privacy. The security policy with respect to all messages is implementation defined, when not explicitly discussed below. CIP implementors are strongly urged to allow server administrators maximum configurability to secure their servers against maliciously sent anonymous CIP messages. In general, operations which can permanently change the server's state in a harmful way should only take place upon receipt of a properly signed message from a trusted CIP peer or administrator. Implementors should provide appropriate auditing capabilities so that both successful and failed requests can be tracked by the server administrator.
与所有MIME对象一样，CIP消息可以包装在安全多部分包中，以提供身份验证和隐私。当下面没有明确讨论时，所有消息的安全策略都是由实现定义的。强烈敦促CIP实施者允许服务器管理员最大限度地配置，以保护其服务器免受恶意发送的匿名CIP消息的攻击。通常，只能在收到来自可信CIP对等方或管理员的正确签名消息后，才能以有害方式永久更改服务器状态的操作。实现者应该提供适当的审核功能，以便服务器管理员可以跟踪成功和失败的请求。
Since these MIME objects can and will be sent over several different protocols, body termination is specified by the transfer protocol. New protocols are encouraged to use SMTP [RFC821] style body termination.
由于这些MIME对象可以并将通过几个不同的协议发送，因此主体终止由传输协议指定。鼓励新协议使用SMTP[RFC821]样式的正文终止。
Finally, since MIME objects can specify their own encoding, the line-breaks contained within each body are defined by the encoding. Thus, instead of specifying them as carriage-return and/or linefeed, the identifier <linebreak> is used. Linebreaks in the headers and separating the body from the headers follow existing standards.
最后，由于MIME对象可以指定自己的编码，因此每个主体中包含的换行符都由编码定义。因此，使用标识符<linebreak>而不是将其指定为回车符和/或换行符。页眉中的换行符以及将正文与页眉分离遵循现有标准。
There are certain syntactic elements common to all of the CIP transactions. These include type, DSI and the Base-URI.
所有CIP事务都有一些共同的语法元素。这些包括类型、DSI和基本URI。
Due to requirements in RFC2048 concerning objects that have the same type but different syntaxes, CIP objects will use the application/index tree but include "facets" [RFC2048] which extend it as other types have done with respect to global elements and vendor specific enhancements. Thus the tree is divided up into the following branches:
由于RFC2048中关于具有相同类型但不同语法的对象的要求，CIP对象将使用应用程序/索引树，但包括“facet”[RFC2048]，它与其他类型在全局元素和特定于供应商的增强功能方面所做的扩展一样。因此，该树被分成以下分支：
application/index.cmd._command_ application/index.response application/index.obj._type_ application/index.vnd._xxx_
应用程序/index.cmd.\u命令\uu应用程序/index.response应用程序/index.obj.\u类型\uu应用程序/index.vnd.\uxxx_
_command_ is a command as specified here. It contains commands and their arguments.
_command_uu是此处指定的命令。它包含命令及其参数。
_type_ identifies what type of CIP index object is contained within the body. It is unique among all other reserved types. Reserved types are those previously documented by other CIP index object specifications, according to standard IETF processes.
_类型\标识主体中包含的CIP索引对象的类型。它在所有其他保留类型中是唯一的。根据标准IETF流程，保留类型是以前由其他CIP索引对象规范记录的类型。
_xxx_ is an identifier specified by a vendor for use by that vendor in operations specifically to do with indexes.
_xxx_uu是供应商指定的标识符，供该供应商在与索引相关的操作中使用。
All of the above identifiers follow the rules in RFC2048 for valid MIME types. In addition commands, responses and types are limited by this document to consist of from 1 to 20 characters from the set [a-zA-Z0-9-]; that is, all upper and lower case letters, all digits, and the ASCII minus character (decimal 45). Though type names may be specified case sensitively, they must be compared and otherwise processed case insensitively.
以上所有标识符都遵循RFC2048中有效MIME类型的规则。此外，本文件限制命令、响应和类型由集合[a-zA-Z0-9-]中的1至20个字符组成；也就是说，所有大小写字母、所有数字和ASCII减号（十进制45）。尽管类型名可以区分大小写指定，但它们必须进行比较，否则将不区分大小写处理。
Appendix A contains the registration template for the application/index tree.
附录A包含应用程序/索引树的注册模板。
A dataset identifier is an identifier chosen from any part of the ISO/CCITT OID space. The DSI uniquely identifies a given dataset among all datasets indexed by CIP.
数据集标识符是从ISO/CCITT OID空间的任何部分选择的标识符。DSI在CIP索引的所有数据集中唯一标识给定数据集。
As currently defined, OID's are an unbounded sequence of unbounded integers. While this creates an infinite numbering space, it presents problems for implementors dealing with machines with finite resources. To ease implementation, this document specifies an ASCII encoding of the OID, and specifies limits which make implementation easier.
按照目前的定义，OID是无界整数的无界序列。虽然这会创建一个无限的编号空间，但对于处理资源有限的机器的实现者来说，这会带来问题。为了简化实现，本文档指定了OID的ASCII编码，并指定了使实现更容易的限制。
For the purposes of interchange in CIP messages, an OID must conform to the following rules:
为了在CIP报文中进行交换，OID必须符合以下规则：
dsi = integer *( "." integer)
integer = all-digits / (one-to-nine *all-digits)
one-to-nine = "1" / "2" / "3" / "4" / "5" / "6" / "7" /
"8" / "9"
all-digits = "0" / one-to-nine
dsi = integer *( "." integer)
integer = all-digits / (one-to-nine *all-digits)
one-to-nine = "1" / "2" / "3" / "4" / "5" / "6" / "7" /
"8" / "9"
all-digits = "0" / one-to-nine
Under no circumstances shall the total length of the resulting string exceed 255 characters. OID's which cannot, due to their length, conform to these rules must not be used as CIP dataset identifiers.
在任何情况下，结果字符串的总长度都不得超过255个字符。由于长度原因不能符合这些规则的OID不得用作CIP数据集标识符。
An implementation must not attempt to parse the individual integers unless it is prepared to handle arbitrary-length integers. Treating the DSI as anything other than an opaque string of US-ASCII characters is not recommended.
除非准备处理任意长度的整数，否则实现不得尝试解析单个整数。不建议将DSI视为US-ASCII字符不透明字符串以外的任何内容。
Two CIP DSI's are considered to match if both conform to the above rules and every number matches.
如果两个CIP DSI都符合上述规则且每个数字都匹配，则认为两个CIP DSI匹配。
CIP index objects carry base-URI's to facilitate referral generation based on the index object. The base-URI parameter carries a whitespace-delimited list of URL's. URL's are defined in RFC-1738. The exact rules are as follows:
CIP索引对象带有基本URI，以便于基于索引对象生成引用。基本URI参数包含一个以空格分隔的URL列表。URL在RFC-1738中定义。具体规则如下：
base-uri = genericurl *( 1*whitespace genericurl )
whitespace = "<space>" (decimal 32) /
"<tab>" (decimal 9) /
"<cr>" (decimal 13) /
"<lf>" (decimal 10)
genericurl = { as specified in RFC-1738, section 5 }
base-uri = genericurl *( 1*whitespace genericurl )
whitespace = "<space>" (decimal 32) /
"<tab>" (decimal 9) /
"<cr>" (decimal 13) /
"<lf>" (decimal 10)
genericurl = { as specified in RFC-1738, section 5 }
All requests must be followed by a response code, except in the cases where a return path is unavailable.
除返回路径不可用的情况外，所有请求后面都必须有响应代码。
The definition for this MIME type is:
此MIME类型的定义为：
MIME type name: application MIME subtype name: index.response Required parameters: code Optional parameters: charset Security considerations: (See Section 4)
MIME类型名称：应用程序MIME子类型名称：index.response必需参数：代码可选参数：字符集安全注意事项：（参见第4节）
The code parameter contains a 3 digit return code that denotes the status of the last command.
code参数包含一个3位数的返回码，表示最后一个命令的状态。
The format of the body is such that the first line is interpreted as the comment corresponding to the code. As with most response codes this comment is intended for human consumption and may not exist and must not be depended on by the protocol. Subsequent lines in the body are reserved for each response to define. In the case where the comment is not given the first must be an empty line.
正文的格式是，第一行被解释为与代码对应的注释。与大多数响应代码一样，该注释仅供人类使用，可能不存在，且不得依赖于协议。正文中的后续行是为每个要定义的响应保留的。如果未给出注释，则第一行必须为空行。
body = comment linebreak payload
comment = { any text }
linebreak = (decimal 13) (decimal 10)
payload = { any text }
body = comment linebreak payload
comment = { any text }
linebreak = (decimal 13) (decimal 10)
payload = { any text }
The charset parameter has its normal MIME meaning. Below are several examples:
charset参数有其正常的MIME含义。以下是几个例子：
[begin MIME]
Content-type: application/index.response; code=220
[begin MIME]
Content-type: application/index.response; code=220
CIP Server v1.0 ready!<linebreak> [end MIME]
CIP服务器1.0版准备就绪<换行符>[结束MIME]
[begin MIME]
Content-type: application/index.response; code=500
[begin MIME]
Content-type: application/index.response; code=500
MIME formatting problem<linebreak> [end MIME]
MIME格式问题<linebreak>[结束MIME]
[begin MIME]
Content-type: application/index.response; code=520
[begin MIME]
Content-type: application/index.response; code=520
<linebreak> [end MIME]
<linebreak>[结束MIME]
While the responses described in this document do not utilize the rest of the lines in the body of a response implementors should take care to not disallow it in the future. A good example would be a message specifying that a poll request did not contain required attributes. This message might look like this:
虽然本文档中描述的响应没有使用响应主体中的其余行，但实现者应注意不要在将来拒绝它。一个很好的例子是一条消息，指定轮询请求不包含必需的属性。此消息可能如下所示：
[begin MIME]
Content-type: application/index.response; code=502
[begin MIME]
Content-type: application/index.response; code=502
Request is missing required CIP attributes Missing-Attribute: attribute1 Missing-Attribute: attribute2 Missing-Attribute: attribute3 [end MIME]
请求缺少必需的CIP属性缺少属性：attribute1缺少属性：attribute2缺少属性：attribute3[结束MIME]
The meaning of the various digits in the response codes is discussed in RFC-821, Appendix E.
RFC-821附录E中讨论了响应代码中各种数字的含义。
See Appendix B for a list of the valid response codes.
有关有效响应代码的列表，请参见附录B。
A CIP command either initiates an index transfer, interrogates the state of the receiver-CIP (or the server's participation in the mesh), or changes the state of the server (or the server's place in the mesh).
CIP命令可以启动索引传输、询问接收方CIP的状态（或服务器在网格中的参与），或更改服务器的状态（或服务器在网格中的位置）。
CIP commands are sent as a MIME message of type "application/index.cmd._command_". The definition for this MIME type tree follows:
CIP命令作为类型为“application/index.cmd.\u command”的MIME消息发送。此MIME类型树的定义如下：
MIME type name: application MIME subtype name: index.cmd._command_ Optional parameters: type, dsi Security considerations: (See Section 4)
MIME类型名称：应用程序MIME子类型名称：index.cmd.\u命令\可选参数：类型，dsi安全注意事项：（参见第4节）
The format of the body is defined by each command. A general attribute/value pair orientation is preserved throughout the following specified commands. Those developing future command should attempt to maintain that orientation but are not required to do so.
正文的格式由每个命令定义。在以下指定命令中，将保留常规属性/值对方向。发展未来司令部的人应该尝试保持这种方向，但不需要这样做。
In the following sections, the server's response for each possible value for "command" is defined. Note that the parameters listed as optional above are only optional with respect to the generic MIME form. The optional parameters are only optional with respect to MIME parsing. If one or more of the parameters needed to fulfill a command is missing, a response code of 502 is returned.
在以下部分中，定义了服务器对“command”的每个可能值的响应。请注意，上面列出的可选参数仅对通用MIME表单是可选的。可选参数仅在MIME解析方面是可选的。如果缺少执行命令所需的一个或多个参数，则返回响应代码502。
Extra optional parameters which are unrecognized must be silently ignored.
必须以静默方式忽略无法识别的额外可选参数。
Command Name: application/index.cmd.noop Required parameters: (none)
命令名：application/index.cmd.noop所需参数：（无）
A CIP command with the "command" parameter set to "noop" must be acknowledged with response type code 200 (command OK, no response forthcoming).
“command”参数设置为“noop”的CIP命令必须用响应类型代码200进行确认（命令正常，无响应）。
This command must not require a signed MIME object. Implementations should accept commands which have been validly signed.
此命令不得要求有签名的MIME对象。实现应接受已有效签名的命令。
Example:
例子：
[begin MIME] Content-type: application/index.cmd.noop
[开始MIME]内容类型：application/index.cmd.noop
[end MIME]
[完]
Note the lack of a body but how the <linebreak> pair is still preserved after the Content-type header.
请注意缺少正文，但内容类型标题之后仍然保留<linebreak>对。
Request Name: application/index.cmd.poll Required parameters: type, dsi
请求名称：application/index.cmd.poll所需参数：类型，dsi
The "poll" command is used by a poller to request the transfer of an index object. It requires the following parameters:
轮询器使用“poll”命令请求传输索引对象。它需要以下参数：
type: The index object type requested dsi: The dataset which the index should cover
类型：请求的索引对象类型dsi：索引应覆盖的数据集
If there are no index objects available for a given DSI, or the receiver-CIP does not support a given index object type, the receiver-CIP must respond with response code 200, (successful, no response forthcoming). Otherwise, the response code must be 201 (successful, response is forthcoming).
如果给定DSI没有可用的索引对象，或者接收器CIP不支持给定的索引对象类型，则接收器CIP必须使用响应代码200进行响应（成功，无响应）。否则，响应代码必须为201（成功，响应即将到来）。
The security policy for polling commands is wholly implementation defined. Implementations may be configured to accept or reject anonymous poll commands.
轮询命令的安全策略完全由实现定义。实现可以配置为接受或拒绝匿名轮询命令。
Example:
例子：
[begin MIME]
Content-type: application/index.cmd.poll; type="simple";
dsi= "1.3.5.7.9"
[begin MIME]
Content-type: application/index.cmd.poll; type="simple";
dsi= "1.3.5.7.9"
Template: contact name address phone<linebreak>
Start-time: Fri May 30 14:25:30 EDT 1997<linebreak>
End-time: Sat May 31 14:25:30 EDT 1997<linebreak>
[end MIME]
Template: contact name address phone<linebreak>
Start-time: Fri May 30 14:25:30 EDT 1997<linebreak>
End-time: Sat May 31 14:25:30 EDT 1997<linebreak>
[end MIME]
Request Name: application/index.cmd.datachanged Required parameters: type, dsi
请求名称：application/index.cmd.datachanged所需参数：type，dsi
The "datachanged" command is used by a pollee to notify a poller that the data within an index has changed. It requires the following parameters:
被轮询者使用“datachange”命令通知轮询器索引中的数据已更改。它需要以下参数：
type: The index object type requested dsi: The dataset which the index should cover
类型：请求的索引对象类型dsi：索引应覆盖的数据集
If there are no index objects available for a given DSI, or the receiver-CIP does not support a given index object type, the receiver-CIP must respond with response code 200, (successful, no response forthcoming). Otherwise, the response code must be 201 (successful, response is forthcoming).
如果给定DSI没有可用的索引对象，或者接收器CIP不支持给定的索引对象类型，则接收器CIP必须使用响应代码200进行响应（成功，无响应）。否则，响应代码必须为201（成功，响应即将到来）。
The body of a DataChanged command is formatted as a simple set of attribute value pairs following the rules of RFC822. The actual attributes and values allowed are defined by the index type specification.
DataChanged命令的主体按照RFC822的规则格式化为一组简单的属性值对。允许的实际属性和值由索引类型规范定义。
The security policy for DataChanged commands is wholly implementation defined. Implementations may be configured to accept or reject anonymous DataChanged commands.
DataChanged命令的安全策略完全由实现定义。可以将实现配置为接受或拒绝匿名DataChanged命令。
Example:
例子：
[begin MIME]
Content-type: application/index.cmd.datachanged;
type="simple"; dsi= "1.3.5.7.9"<linebreak>
[begin MIME]
Content-type: application/index.cmd.datachanged;
type="simple"; dsi= "1.3.5.7.9"<linebreak>
Time-of-latest-change: Fri May 30 14:25:30 EDT 1997<linebreak>
Time-of-message-generation: Fri May 30 14:25:30 EDT 1997<linebreak>
Host-Name: cip.rwhois.net<linebreak>
Host-Port: 4322<linebreak>
Protocol: RWhois2.0<linebreak>
[end MIME]
Time-of-latest-change: Fri May 30 14:25:30 EDT 1997<linebreak>
Time-of-message-generation: Fri May 30 14:25:30 EDT 1997<linebreak>
Host-Name: cip.rwhois.net<linebreak>
Host-Port: 4322<linebreak>
Protocol: RWhois2.0<linebreak>
[end MIME]
The requests specified above are those required to implement a simple mesh. It is expected that other requests will be developed to handle issues of mesh-management and statistics gathering requests. At this point this is an area of additional work. Specifically more work is needed in the area of mesh management as meshes will tend to be organized around the characteristics of their index type.
上面指定的请求是实现简单网格所需的请求。预计将开发其他请求来处理网格管理和统计数据收集请求的问题。在这一点上，这是一个额外的工作领域。特别是在网格管理领域需要做更多的工作，因为网格将倾向于围绕其索引类型的特征进行组织。
In reply to the "poll" command, a server may choose to send one or more index objects. Regardless of the number of index objects returned, the response must take the form of a MIME multipart/mixed message. Each part must itself be a MIME object of type "application/index.obj._type_". The definition for this type follows:
作为对“poll”命令的响应，服务器可以选择发送一个或多个索引对象。不管返回的索引对象数量如何，响应必须采用MIME多部分/混合消息的形式。每个部分本身必须是类型为“application/index.obj.\u type\uj”的MIME对象。此类型的定义如下：
MIME type name: application MIME subtype name: index.obj._type_ Required parameters: dsi, base-uri Optional parameters: none Security considerations: (See Section 4)
MIME类型名称：应用程序MIME子类型名称：index.obj.\u类型\u必需参数：dsi，基本uri可选参数：无安全注意事项：（请参阅第4节）
As previously described, each index object is of a particular type. This type is specified in the MIME subtype name since some types may have a different syntax.
如前所述，每个索引对象都是特定类型的。此类型在MIME子类型名称中指定，因为某些类型可能具有不同的语法。
The required parameters are to be used as follows:
所需参数的使用如下：
DSI: The DSI is a string which globally uniquely identifies the dataset from which the index was created.
DSI：DSI是一个字符串，全局唯一地标识从中创建索引的数据集。
base-URI: One or more URI's will form the base of any referrals created based upon this index object.
基本URI：一个或多个URI将构成基于此索引对象创建的任何引用的基础。
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 structure of the mesh of servers which pass a particular type of index is dependent on the application domain. While companion documents will describe index objects, there is a set of base requirements and questions those documents must address. This is to ensure that the base assumptions that the CIP protocol makes about its indexes are actually expressible within the index.
由于需要特定于应用领域的索引，CIP索引对象是抽象的；它们必须由单独的规范定义。移动索引对象的基本协议广泛适用，但索引的具体设计以及通过特定类型索引的服务器网格的结构取决于应用领域。虽然伴随文档将描述索引对象，但这些文档必须解决一组基本需求和问题。这是为了确保CIP协议对其索引所做的基本假设在索引中实际是可表达的。
Since each type is a MIME type all its own, registration of new types follows the standard registration policies specified in RFC2048.
由于每个类型都是MIME类型，因此新类型的注册遵循RFC2048中指定的标准注册策略。
Any index type definition must address the type specific bodies of the Poll and DataChanged requests. All parameters included in the body must be specified.
任何索引类型定义都必须处理轮询和DataChanged请求的特定于类型的主体。必须指定正文中包含的所有参数。
See the above definitions for allowed values for type.
有关类型的允许值，请参见上述定义。
A new name must be assigned when any changes to the document describing the index object type are not completely backwards compatible.
当描述索引对象类型的文档的任何更改不完全向后兼容时，必须指定新名称。
Another attribute is the "DSI", or Dataset Identifier, which uniquely identifies the dataset from which the index was created. The index specification should define the policies for how the DSI is generated. This includes the concept of what a data-set means for the given index.
另一个属性是“DSI”或数据集标识符，它唯一地标识从中创建索引的数据集。索引规范应定义如何生成DSI的策略。这包括数据集对于给定索引意味着什么的概念。
An attribute of the index object which is crucial for generating referrals is the "Base-URI". The URI (or URI's) contained in this attribute 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 possible types of aggregation. This use of the Base-URI is used to deal with meshes that support multiple protocols.
索引对象的一个属性是“基本URI”，它对生成引用至关重要。此属性中包含的URI构成基于此索引块生成的任何引用的基础。URI还用作索引聚合过程中的输入，以约束可能的聚合类型。基本URI的这种用法用于处理支持多种协议的网格。
Thus, an index specification should define how the Base-URI applies to the underlying index and how it is changed during the aggregation process.
因此，索引规范应该定义基本URI如何应用于基础索引，以及在聚合过程中如何更改。
All index object specifications must address the issue of aggregation. This is the method by which an index server takes two or more indexes and combines them into one index to be passed on. It is not required that a given index-type aggregate. If it does not it must explicitly address the reasons why and what affect that has on scalability.
所有索引对象规范都必须解决聚合问题。这是索引服务器获取两个或多个索引并将它们组合成一个要传递的索引的方法。给定的索引类型不需要聚合。如果没有，则必须明确说明原因以及对可伸缩性的影响。
If a given index does aggregate, the algorithm for that aggregation must be given. It must also address how that algorithm affects mesh organization and scalability.
如果给定的索引确实聚合，则必须给出该聚合的算法。它还必须解决该算法如何影响网格组织和可伸缩性。
Index object document authors should remember that any 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.
索引对象文档作者应该记住，任何类型的聚合都应该在不损害正确路由查询的能力的情况下执行，同时避免过多的遗漏结果。必须在每个应用程序域的基础上确定可接受的误报可能性，并由索引的粒度和特定规范为其定义的聚合规则控制。
Nothing in these documents specifically disallows aggregation rules that deal with different index object types. This type of heterogeneous mesh is difficult to formulate at best and thus is not covered by these documents. If document authors wish to attempt such a mesh they should be aware that it is considered an ill understood concept that contains many pitfalls for the mesh builder.
这些文档中没有明确禁止处理不同索引对象类型的聚合规则。这种类型的非均匀网格最多很难表达，因此这些文档中没有涉及。如果文档作者希望尝试这样的网格，他们应该知道，这被认为是一个理解不透彻的概念，其中包含网格生成器的许多陷阱。
Since the method by which a client navigates the mesh is by referrals, the document must address how a given access protocol generates a referral from the index. Authors should pay particular attention to the case where an index is accessed by different protocols and the interaction between them. For example, an index that supports referrals being generated for both RWhois and LDAP must understand that one uses a Distinguished Name while the other doesn't. The impacts of these differences on the referral should be clear.
由于客户端导航网格的方法是通过引用，因此文档必须说明给定访问协议如何从索引生成引用。作者应该特别注意索引被不同协议访问的情况以及它们之间的交互。例如，支持为RWhois和LDAP生成的引用的索引必须理解其中一个使用可分辨名称，而另一个不使用。这些差异对转诊的影响应该是明确的。
In order to generate a referral the decision of whether or not to do so must be handled by the access protocol. The semantics surrounding this decision have a large impact on the efficiency of searches as well as the requirements on aggregation. Thus, index specification authors must be very clear about how a match is determined.
为了生成转介，是否这样做的决定必须由访问协议处理。围绕此决策的语义对搜索的效率以及聚合的要求有很大的影响。因此，索引规范的作者必须非常清楚如何确定匹配。
As is customary with Internet protocol documentation, a brief review of security implications of the proposed object must be included. This section may need to do little more than echo the considerations expressed in this document's Security Considerations section.
按照互联网协议文件的惯例，必须包括对提议对象的安全影响的简要审查。本节可能只需要重复本文档的“安全注意事项”一节中表达的注意事项。
Because indexing algorithms, stop-lists, and data reduction technologies are considered by some index object designers to be proprietary, it is not necessary to discuss the process used to derive indexing information from a body of source material. When proprietary indexing technologies are used in a public mesh, all CIP servers in the mesh should be able to parse the index object (and perform aggregation operations, if necessary), though not all of them need to be able to create these proprietary indices from source data.
由于索引算法、停止列表和数据缩减技术被某些索引对象设计人员视为专有技术，因此无需讨论从源材料体中导出索引信息的过程。在公共网格中使用专有索引技术时，网格中的所有CIP服务器都应该能够解析索引对象（并在必要时执行聚合操作），尽管并非所有服务器都需要能够从源数据创建这些专有索引。
Thus, index object designers may choose to remain silent on the algorithms used for the generation of indices, as long as they adequately document how to participate in a mesh of servers passing these proprietary indices.
因此，索引对象设计者可以选择对用于生成索引的算法保持沉默，只要他们充分记录了如何参与通过这些专有索引的服务器网格。
Designers should also seriously consider including useful examples of source data, the generated index, and the expected results from example matches. When the aggregation algorithm is complex, it is recommended that a table showing two indices and the resultant aggregate index be included.
设计人员还应该认真考虑包括源数据、生成的索引以及示例匹配的预期结果的有用示例。当聚合算法复杂时，建议包括一个显示两个索引和结果聚合索引的表。
Security considerations come into play in at least the following two scenarios. 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. Both topics are covered below.
安全考虑至少在以下两种情况下发挥作用。除非小心控制，否则索引信息可能会泄漏大量不必要的专有信息。在更基本的层面上，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.
CIP旨在为各种数据编制索引。其中一些数据可能被数据维护者认为是有价值的、专有的，甚至是高度敏感的。以人力资源数据库为例。某些数据在适度的情况下对公司的公开非常有帮助。然而，整个数据库是一项非常宝贵的资产，公司必须加以保护。多年来，目录服务社区已经积累了很多经验，了解如何在完全显示数据库和提供有用的数据库片段之间走这条细线。
Another example where security becomes a problem is for a data publisher who would 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的一个基本前提是，数据提供商愿意向对等索引服务器提供其数据的索引。除非仔细构造这些索引，否则这些索引可能对数据库的安全构成威胁。所以，在开发新的索引对象类型时，数据的安全性必须是首要考虑因素。仅基于从数据库导出的索引对数据库进行反向工程的风险必须保持在与数据值和细粒度索引需求一致的级别。
Since CIP is encoded as MIME objects, MIME security solutions should be used whenever possible. Specifically when dealing with security between index servers.
由于CIP被编码为MIME对象，因此应尽可能使用MIME安全解决方案。特别是在处理索引服务器之间的安全性时。
CIP protocol exchanges, taking the form of MIME messages, can be secured using any technology available for securing MIME objects. In particular, use of RFC-1847's Security Multiparts are recommended. A solid application of RFC-1847 using widely available encryption software is PGP/MIME, RFC-2016. Implementors are encouraged to support PGP/MIME, as it is the first viable application of the MIME Security Multiparts architecture. As other technologies become available, they may be incorporated into the CIP mesh.
采用MIME消息形式的CIP协议交换可以使用任何可用于保护MIME对象的技术进行保护。特别推荐使用RFC-1847的安全多部件。使用广泛可用的加密软件的RFC-1847的可靠应用是PGP/MIME，RFC-2016。鼓励实现者支持PGP/MIME，因为它是MIME安全多部分体系结构的第一个可行应用程序。当其他技术可用时，可将其并入CIP网格中。
If an incoming request does not have a valid signature, it must be considered anonymous for the purposes of access control. Servers may choose to allow certain requests from anonymous peers, especially when the request cannot cause permanent damage to the local server. In particular, answering anonymous poll requests encourages index builders to poll a server, making the server's resources better known.
如果传入的请求没有有效的签名，则出于访问控制的目的，必须将其视为匿名的。服务器可能会选择允许来自匿名对等方的某些请求，尤其是当该请求不会对本地服务器造成永久性损坏时。特别是，回答匿名轮询请求会鼓励索引构建器轮询服务器，从而更好地了解服务器的资源。
The explicit security policy with respect to incoming requests is outside the scope of this specification. Implementors are free to accept or reject any request based on the security attributes of the incoming message. When a request is rejected due to authentication reasons, a response code from the 530 series must be issued.
有关传入请求的明确安全策略不在本规范的范围内。实现者可以根据传入消息的安全属性自由接受或拒绝任何请求。由于身份验证原因拒绝请求时，必须发出530系列的响应代码。
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.
特别感谢Bunyip信息系统公司的Jeff Allen。他对这些文件的原始版本极大地帮助了辩论和共识的具体化。本文档中的大部分实际文本最初由Jeff编写。
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: +1-703-742-0400
EMail: michael.mealling@RWhois.net
Phone: +1-703-742-0400
EMail: michael.mealling@RWhois.net
References
工具书类
[FRAMEWORK] Allen, J. and M. Mealling, "The Architecture of the Common Indexing Protocol (CIP)", RFC 2651, August 1999.
[框架]Allen，J.和M.Melling，“公共索引协议（CIP）的架构”，RFC 26511999年8月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, January 1996.
[RFC2046]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年1月。
[RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: MIME Registration Procedures", RFC 2048, January 1996.
[RFC2048]Freed，N.，Klensin，J.和J.Postel，“多用途互联网邮件扩展（MIME）第四部分：MIME注册程序”，RFC 20481996年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1992.
[RFC821]Postel，J.，“简单邮件传输协议”，STD 10，RFC 8211992年8月。
Appendix A: Media Type Registration Templates
附录A：媒体类型注册模板
The following templates have been registered with the IANA:
以下模板已在IANA注册：
Index tree
索引树
To: ietf-types@iana.org
Subject: Registration of MIME media type tree application/index
To: ietf-types@iana.org
Subject: Registration of MIME media type tree application/index
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: index
MIME子类型名称：索引
Required parameters: none
所需参数：无
Optional parameters: none
可选参数：无
Encoding considerations: none
编码注意事项：无
Security considerations:
安全考虑：
Security considerations come into play in at least the following two scenarios. 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. Both topics are covered below.
安全考虑至少在以下两种情况下发挥作用。除非小心控制，否则索引信息可能会泄漏大量不必要的专有信息。在更基本的层面上，CIP协议本身要求外部安全服务以安全的方式运行。下面将介绍这两个主题。
Interoperability considerations:
互操作性注意事项：
Published specification:
已发布的规范：
RFC 2652
RFC 2652
Applications which use this media type:
使用此媒体类型的应用程序：
This media type is used to contain information about indices and how they inter-operate to form meshes of index servers.
此媒体类型用于包含有关索引的信息，以及它们如何相互操作以形成索引服务器的网格。
Additional information:
其他信息：
This media type is not a standalone type. It is the top level of a tree similar to the vnd or prs trees specified in Section 2.1 of RFC2048. There are four specified branches to this tree: application/index.cmd application/index.response application/index.obj application/index.vnd
此媒体类型不是独立类型。它是树的顶层，类似于RFC2048第2.1节中规定的vnd或prs树。此树有四个指定的分支：application/index.cmd application/index.response application/index.obj application/index.vnd
Each of these branches is a tree in its own right with types registered below them. See those registrations for more information on the types allowed below those branches.
这些分支中的每一个都是一棵树，其下注册了类型。有关这些分支下面允许的类型的更多信息，请参阅这些注册。
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Intended usage: LIMITED USE
预期用途：有限用途
Author/Change controller:
作者/变更控制员：
Command tree
命令树
To: ietf-types@iana.org
Subject: Registration of MIME media type application/index.cmd
To: ietf-types@iana.org
Subject: Registration of MIME media type application/index.cmd
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: index.cmd
MIME子类型名称：index.cmd
Required parameters: none
所需参数：无
Optional parameters: none
可选参数：无
Encoding considerations: none
编码注意事项：无
Security considerations:
安全考虑：
Security considerations come into play in at least the following two scenarios. 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. Both topics are covered below.
安全考虑至少在以下两种情况下发挥作用。除非小心控制，否则索引信息可能会泄漏大量不必要的专有信息。在更基本的层面上，CIP协议本身要求外部安全服务以安全的方式运行。下面将介绍这两个主题。
Interoperability considerations:
互操作性注意事项：
Implementors should handle unknown commands gracefully.
实现者应该优雅地处理未知命令。
Published specification:
已发布的规范：
RFC 2652
RFC 2652
Applications which use this media type:
使用此媒体类型的应用程序：
This media type is the top of a tree of media types that express commands between hosts that exchange indices for the purpose of routing referrals.
此媒体类型是媒体类型树的顶部，表示主机之间交换索引以路由引用的命令。
Additional information:
其他信息：
This media type is not a standalone type. It is the top of a tree similar to the vnd and prs trees specified in Section 2.1 of RFC2048. Types registered within this tree are limited to being commands as specified in the document(s) referenced in the "Published specifications" section.
此媒体类型不是独立类型。它是树的顶部，类似于RFC2048第2.1节中规定的vnd和prs树。在此树中注册的类型仅限于“已发布规范”部分中引用的文档中指定的命令。
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Intended usage: LIMITED USE
预期用途：有限用途
Author/Change controller:
作者/变更控制员：
Response tree
响应树
To: ietf-types@iana.org
Subject: Registration of MIME media type application/index.response
To: ietf-types@iana.org
Subject: Registration of MIME media type application/index.response
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: index.response
MIME子类型名称：index.response
Required parameters: code
所需参数：代码
Optional parameters: none
可选参数：无
Encoding considerations: none
编码注意事项：无
Security considerations:
安全考虑：
Security considerations come into play in at least the following two scenarios. 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. Both topics are covered below.
安全考虑至少在以下两种情况下发挥作用。除非小心控制，否则索引信息可能会泄漏大量不必要的专有信息。在更基本的层面上，CIP协议本身要求外部安全服务以安全的方式运行。下面将介绍这两个主题。
Interoperability considerations:
互操作性注意事项：
Implementors should handle unknown responses gracefully.
实现者应该优雅地处理未知响应。
Published specification:
已发布的规范：
RFC 2652
RFC 2652
Applications which use this media type:
使用此媒体类型的应用程序：
This media type is used to encode responses to CIP commands passed between hosts that exchange indices for the purpose of routing referrals.
此媒体类型用于对主机之间传递的CIP命令的响应进行编码，主机之间交换索引以进行路由引用。
Additional information:
其他信息：
This media type _is_ a standalone type. The code parameter contains the specific response code as specified by Appendix B of the specification document.
此媒体类型为独立类型。代码参数包含规范文件附录B中规定的特定响应代码。
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Intended usage: LIMITED USE
预期用途：有限用途
Author/Change controller:
作者/变更控制员：
Index Object tree
索引对象树
To: ietf-types@iana.org
Subject: Registration of MIME media type application/index.obj
To: ietf-types@iana.org
Subject: Registration of MIME media type application/index.obj
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: index.obj
MIME子类型名称：index.obj
Required parameters: type, dsi, base-uri
所需参数：类型、dsi、基本uri
Optional parameters: none
可选参数：无
Encoding considerations: none
编码注意事项：无
Security considerations:
安全考虑：
Security considerations come into play in at least the following two scenarios. 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. Both topics are covered below.
安全考虑至少在以下两种情况下发挥作用。除非小心控制，否则索引信息可能会泄漏大量不必要的专有信息。在更基本的层面上，CIP协议本身要求外部安全服务以安全的方式运行。下面将介绍这两个主题。
Interoperability considerations:
互操作性注意事项：
Implementors should handle unknown index objects according to rules specified in the published specification.
实现者应该根据发布的规范中指定的规则处理未知的索引对象。
Published specification:
已发布的规范：
RFC 2652
RFC 2652
Applications which use this media type:
使用此媒体类型的应用程序：
This media type is the top of a tree of media types that express indexes that are exchanged between hosts that operate within a referral mesh.
此媒体类型是媒体类型树的顶部，表示在引用网格中运行的主机之间交换的索引。
Additional information:
其他信息：
This media type is not a standalone type. It is the top of a tree similar to the vnd and prs trees specified in Section 2.1 of RFC2048. Types registered within this tree are limited to being representations of indexes that contain some summary of the data found in some database and is used to generate referrals as specified in the above specified publication.
此媒体类型不是独立类型。它是树的顶部，类似于RFC2048第2.1节中规定的vnd和prs树。在此树中注册的类型仅限于索引的表示形式，这些索引包含在某些数据库中找到的数据的某些摘要，并用于生成上述指定发布中指定的引用。
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Intended usage: LIMITED USE
预期用途：有限用途
Author/Change controller:
作者/变更控制员：
Vendor tree
供应商树
To: ietf-types@iana.org
Subject: Registration of MIME media type application/index.vnd
To: ietf-types@iana.org
Subject: Registration of MIME media type application/index.vnd
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: index.vnd
MIME子类型名称：index.vnd
Required parameters: none
所需参数：无
Optional parameters: none
可选参数：无
Encoding considerations: none
编码注意事项：无
Security considerations:
安全考虑：
Security considerations come into play in at least the following two scenarios. 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. Both topics are covered below.
安全考虑至少在以下两种情况下发挥作用。除非小心控制，否则索引信息可能会泄漏大量不必要的专有信息。在更基本的层面上，CIP协议本身要求外部安全服务以安全的方式运行。下面将介绍这两个主题。
Interoperability considerations:
互操作性注意事项：
Implementors should handle unknown objects gracefully.
实现者应该优雅地处理未知对象。
Published specification:
已发布的规范：
RFC 2652
RFC 2652
Applications which use this media type:
使用此媒体类型的应用程序：
This media type is the top of a tree of media types that express vendor specific extensions to the framework specified in the published specifications.
此媒体类型是媒体类型树的顶部，表示对已发布规范中指定的框架的特定于供应商的扩展。
Additional information:
其他信息：
This media type is not a standalone type. It is the top of a tree similar to the vnd and prs trees specified in Section 2.1 of RFC2048. Types registered within this tree are limited to being vendor specific extensions to the CIP framework as specified in the publications. Any registrations within this tree are still limited to dealing with indexes, meshes and referrals.
此媒体类型不是独立类型。它是树的顶部，类似于RFC2048第2.1节中规定的vnd和prs树。在此树中注册的类型仅限于出版物中指定的CIP框架的供应商特定扩展。此树中的任何注册仍然限于处理索引、网格和引用。
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Intended usage: LIMITED USE
预期用途：有限用途
Appendix B: Response Codes
附录B：响应代码
The meaning of the various digits in the response codes is discussed in RFC-821, Appendix E.
RFC-821附录E中讨论了响应代码中各种数字的含义。
The following response codes are defined for use by CIPv3 servers. Implementors must use these exact codes; undefined codes should be interpreted by CIP servers as fatal protocol errors. Instead of defining new codes for unforeseen situations, implementors must adapt one of the given codes. The implementation should attach a useful alternative comment to the reused response code.
以下响应代码定义供CIPv3服务器使用。实施者必须使用这些精确的代码；CIP服务器应将未定义的代码解释为致命的协议错误。实现者必须调整给定的代码之一，而不是为不可预见的情况定义新的代码。实现应该向重用的响应代码附加有用的替代注释。
Code Suggested description text
Sender-CIP action
--------------------------------------------------------
220 Initial server banner message
Code Suggested description text
Sender-CIP action
--------------------------------------------------------
220 Initial server banner message
300 Requested CIP version accepted Continue with CIP transaction, in the specified version.
300接受请求的CIP版本，继续指定版本的CIP事务。
222 Connection closing (in response to sender-CIP close) Done with transaction.
222连接关闭（响应发送方CIP关闭）已完成事务。
200 MIME request received and processed Expect no output, continue session (or close)
收到并处理了200个MIME请求，无输出，继续会话（或关闭）
201 MIME request received and processed, output follows Read a response, delimited by SMTP-style message delimiter.
201接收并处理MIME请求，输出跟随读取响应，由SMTP样式的消息分隔符分隔。
400 Temporarily unable to process request Retry at a later time. May be used to indicate that the server does not currently have the resources available to accept an index.
400暂时无法处理请求，请稍后重试。可用于指示服务器当前没有可用于接受索引的资源。
500 Bad MIME message format Retry with correctly formatted MIME request.
500错误的MIME消息格式使用格式正确的MIME请求重试。
501 Unknown or missing request in application/index.cmd Retry with correct CIP command.
501应用程序/index.cmd中的请求未知或缺失，请使用正确的CIP命令重试。
502 Request is missing required CIP attributes Retry with correct CIP attributes.
502请求缺少必需的CIP属性请使用正确的CIP属性重试。
520 Aborting connection for some unexpected reason Retry and/or alert local administrator.
520由于某些意外原因中止连接，请重试和/或通知本地管理员。
530 Request requires valid signature Sign the request, if possible, and retry. Otherwise, report problem to the administrator.
530请求需要有效的签名。如果可能，请在请求上签名，然后重试。否则，请向管理员报告问题。
531 Request has invalid signature Report problem to the administrator.
531请求向管理员报告无效签名问题。
532 Cannot check signature Alert local administrator, who should cooperate with remote administrator to diagnose and resolve the problem. (Probably missing a public key.)
532无法检查签名警报本地管理员，本地管理员应与远程管理员合作诊断并解决问题。（可能缺少公钥。）
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编辑功能的资金目前由互联网协会提供。