Network Working Group J. Allen
Request for Comments: 2653 WebTV Networks, Inc.
Category: Standards Track P. Leach
Microsoft
R. Hedberg
Catalogix
August 1999
Network Working Group J. Allen
Request for Comments: 2653 WebTV Networks, Inc.
Category: Standards Track P. Leach
Microsoft
R. Hedberg
Catalogix
August 1999
CIP Transport Protocols
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
摘要
This document specifies three protocols for transporting CIP requests, responses and index objects, utilizing TCP, mail, and HTTP. The objects themselves are defined in [CIP-MIME] and the overall CIP architecture is defined in [CIP-ARCH].
本文档指定了使用TCP、mail和HTTP传输CIP请求、响应和索引对象的三种协议。对象本身在[CIP-MIME]中定义，整个CIP体系结构在[CIP-ARCH]中定义。
In this section, the actual protocol for transmitting CIP index objects and maintaining the mesh is presented. While companion documents ([CIP-ARCH] and [CIP-MIME]) describe the concepts involved and the formats of the CIP MIME objects, this document is the authoritative definition of the message formats and transfer mechanisms of CIP used over TCP, HTTP and mail.
本节介绍了传输CIP索引对象和维护网格的实际协议。虽然伴随文档（[CIP-ARCH]和[CIP-MIME]）描述了涉及的概念和CIP MIME对象的格式，但本文档是对通过TCP、HTTP和邮件使用的CIP消息格式和传输机制的权威定义。
The philosophy of the CIP protocol design is one of building-block design. Instead of relying on bulky protocol definition tools, or ad-hoc text encodings, CIP draws on existing, well understood Internet technologies like MIME, RFC-822, Whois++, FTP, and SMTP. Hopefully this will serve to ease implementation and consensus
CIP协议的设计理念是构建块设计。CIP不依赖庞大的协议定义工具或特殊的文本编码，而是利用现有的、众所周知的互联网技术，如MIME、RFC-822、Whois++、FTP和SMTP。希望这将有助于简化实施和达成共识
building. It should also stand as an example of a simple way to leverage existing Internet technologies to easily implement new application-level services.
建筑物它还应该成为利用现有互联网技术轻松实现新的应用程序级服务的简单方法的示例。
The key words "MUST" and "MAY" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
本文件中的关键词“必须”和“可能”应按照“RFC中用于指示需求水平的关键词”[关键词]中的描述进行解释。
Formal syntax is defined using ABNF [ABNF].
形式语法是使用ABNF[ABNF]定义的。
In examples octets sent by the sender-CIP are preceded by ">>> " and those sent by the receiver-CIP by "<<< ".
在示例中，发送方CIP发送的八位字节前面加“>>>”，接收方CIP发送的八位字节前面加“<<”。
2 MIME message exchange mechanisms
2 MIME消息交换机制
CIP relies on interchange of standard MIME messages for all requests and replies. These messages are passed over a bidirectional, reliable transport system. This document defines transport over reliable network streams (via TCP), via HTTP, and via the Internet mail infrastructure.
CIP依赖于所有请求和回复的标准MIME消息交换。这些消息通过双向、可靠的传输系统传递。本文档定义了通过可靠网络流（通过TCP）、HTTP和Internet邮件基础设施的传输。
The CIP server which initiates the connection (conventionally referred to as a client) will be referred to below as the sender-CIP. The CIP server which accepts a sender-CIP's incoming connection and responds to the sender-CIP's requests is called a receiver-CIP.
发起连接的CIP服务器（通常称为客户端）将在下文中称为发送方CIP。接受发送方CIP的传入连接并响应发送方CIP请求的CIP服务器称为接收方CIP。
CIP messages are transmitted over bi-directional TCP connections via a simple text protocol. The transaction can take place over any TCP port, as specified by the mesh configuration. There is no "well known port" for CIP transactions. All configuration information in the system must include both a hostname and a port.
CIP消息通过简单的文本协议通过双向TCP连接传输。根据mesh配置的指定，事务可以通过任何TCP端口进行。CIP交易没有“众所周知的端口”。系统中的所有配置信息必须包括主机名和端口。
All sender-CIP actions (including requests, connection initiation, and connection finalization) are acknowledged by the receiver-CIP with a response code. See section 2.1.1 for the format of these codes, a list of the responses a CIP server may generate, and the expected sender-CIP action for each.
所有发送方CIP操作（包括请求、连接启动和连接终止）都由接收方CIP用响应代码确认。参见第2.1.1节了解这些代码的格式、CIP服务器可能生成的响应列表以及每个响应的预期发送方CIP操作。
In order to maintain backwards compatibility with existing Whois++
servers, CIPv3 sender-CIPs MUST first verify that the newer protocol
is supported. They do this by sending the following illegal Whois++
system command: "# CIP-Version: 3<cr><lf>". On existing Whois++
servers implementing version 1 and 2 of CIP, this results in a 500-
series response code, and the server terminates the connection. If
In order to maintain backwards compatibility with existing Whois++
servers, CIPv3 sender-CIPs MUST first verify that the newer protocol
is supported. They do this by sending the following illegal Whois++
system command: "# CIP-Version: 3<cr><lf>". On existing Whois++
servers implementing version 1 and 2 of CIP, this results in a 500-
series response code, and the server terminates the connection. If
the server implements CIPv3, it MUST instead respond with response code 300. Future versions of CIP can be correctly negotiated using this technique with a different string (i.e. "CIP-Version: 4"). An example of this short interchange is given below.
服务器实现了CIPv3，它必须使用响应代码300进行响应。使用此技术，可以使用不同的字符串（即“CIP版本：4”）正确协商CIP的未来版本。下面给出了这种短交换的一个示例。
Note: If a sender-CIP can safely assume that the server implements CIPv3, it may choose to send the "# CIP-Version: 3" string and immediately follow it with the CIPv3 request. This optimization, useful only in known homogeneous CIPv3 meshes, avoids waiting for the roundtrip inherent in the negotiation.
注意：如果发送方CIP可以安全地假设服务器实现了CIPv3，那么它可以选择发送“#CIP Version:3”字符串，并立即在其后面发送CIPv3请求。这种优化只在已知的均质CIPv3网格中有用，避免了等待协商中固有的往返。
Once a sender-CIP has successfully verified that the server supports CIPv3 requests, it can send the request, formatted as a MIME message with Mime-Version and Content-Type headers (only), using the network standard line ending: "<cr><lf>".
一旦发送方CIP成功验证服务器支持CIPv3请求，它就可以使用网络标准行结尾“<cr><lf>”发送请求，该请求的格式为MIME消息，带有MIME版本和内容类型头（仅限）。
Cip-Req = Req-Hdrs CRLF Req-Body
Cip-Req = Req-Hdrs CRLF Req-Body
Req-Hdrs = *( Version-Hdr | Req-Cntnt-Hdr )
Req-Body = Body ; format of request body as in [CIP-MIME]
Req-Hdrs = *( Version-Hdr | Req-Cntnt-Hdr )
Req-Body = Body ; format of request body as in [CIP-MIME]
Body = Data CRLF "." CRLF Data = ; data with CRLF "." CRLF replaced by ; CRLF ".." CRLF
正文=数据CRLF“。CRLF数据=；带有CRLF的数据。“CRLF”替换为；CRLF.“CRLF”
Version-Hdr = "Mime-Version:" "1.0" CRLF
Req-Cntnt-Hdr = "Content-Type:" Req-Content CRLF
Req-Content = ; format is specified in [CIP-MIME]
Version-Hdr = "Mime-Version:" "1.0" CRLF
Req-Cntnt-Hdr = "Content-Type:" Req-Content CRLF
Req-Content = ; format is specified in [CIP-MIME]
Cip-Rsp = Rsp-Code CRLF [ Rsp-Hdrs CRLF Rsp-Body ]
[ Indx-Cntnt-Hdr CRLF Index-Body ]
Rsp-Code = DIGIT DIGIT DIGIT Comment
Comment = ; any chars except CR and LF
Rsp-Hdrs = *( Version-Hdr | Rsp-Cntnt-Hdr )
Rsp-Cntnt-Hdr = "Content-Type:" Rsp-Content CRLF
Rsp-Content = ; format is specified in [CIP-MIME]
Rsp-Body = Body ; format of response body as in [CIP-MIME]
Cip-Rsp = Rsp-Code CRLF [ Rsp-Hdrs CRLF Rsp-Body ]
[ Indx-Cntnt-Hdr CRLF Index-Body ]
Rsp-Code = DIGIT DIGIT DIGIT Comment
Comment = ; any chars except CR and LF
Rsp-Hdrs = *( Version-Hdr | Rsp-Cntnt-Hdr )
Rsp-Cntnt-Hdr = "Content-Type:" Rsp-Content CRLF
Rsp-Content = ; format is specified in [CIP-MIME]
Rsp-Body = Body ; format of response body as in [CIP-MIME]
Indx-Cntnt-Hdr = "Content-Type:" Indx-Obj-Type CRLF
Indx-Obj-Type = ; any registered index object's MIME-type
; the format is specified in [RFC2045]
Index-Body = Body ; format defined in each index
; specifications
Indx-Cntnt-Hdr = "Content-Type:" Indx-Obj-Type CRLF
Indx-Obj-Type = ; any registered index object's MIME-type
; the format is specified in [RFC2045]
Index-Body = Body ; format defined in each index
; specifications
CRLF = CR LF ; Internet standard newline
CR = %x0D ; carriage return
LF = %x0A ; linefeed
DIGIT = %x30-39
CRLF = CR LF ; Internet standard newline
CR = %x0D ; carriage return
LF = %x0A ; linefeed
DIGIT = %x30-39
The message is terminated using SMTP-style message termination. The data is sent octet-for-octet, except when the pattern <cr><lf>1*["."]<cr><lf> is seen, in which case one more period is added.
使用SMTP样式的邮件终止来终止邮件。数据以八位字节为单位发送，除非看到模式<cr><lf>1*[“]<cr><lf>，在这种情况下，会再添加一个周期。
When the data is finished, the octet pattern "<cr><lf>.<cr><lf>" is transmitted to the receiver-CIP.
当数据完成时，八位组模式“<cr><lf><cr><lf>”被发送到接收机CIP。
On the receiver-CIP's side, the reverse transformation is applied, and the message read consists of all bytes up to, but not including, the terminating pattern.
在接收方CIP端，应用反向转换，并且消息读取由终止模式之前（但不包括终止模式）的所有字节组成。
In response to the request, the receiver-CIP sends a response code, from either the 200, 400, or 500 series. The receiver-CIP then processes the request and replies, if necessary, with a MIME message. This reply is also delimited by an SMTP-style message terminator.
作为对请求的响应，接收器CIP从200、400或500系列发送响应代码。然后，接收方CIP处理请求，并在必要时使用MIME消息进行回复。此回复也由SMTP样式的邮件终止符分隔。
After responding with a response code, the receiver-CIP MUST prepare to read another request message, resetting state to the point when the sender-CIP has just verified the CIP version. If the sender-CIP is finished making requests, it may close the connection. In response the receiver-CIP MUST abort reading the message and prepare for a new sender-CIP connection (resetting its state completely).
在使用响应代码进行响应后，接收方CIP必须准备读取另一条请求消息，并将状态重置为发送方CIP刚刚验证CIP版本时的状态。如果发送方CIP完成请求，它可能会关闭连接。作为响应，接收方CIP必须中止读取消息并准备新的发送方CIP连接（完全重置其状态）。
An example is given below. It is again worth reiterating that the command format is defined in [CIP-MIME] whereas the message body is defined in each index object definition. In this example the index object definition in [CIP-TIO] will be used. Line endings are explicitly shown in anglebrackets; newlines in this text are added only for readability. Comments occur in curly-brackets.
下面给出了一个例子。值得再次重申的是，命令格式是在[CIP-MIME]中定义的，而消息体是在每个索引对象定义中定义的。在本例中，将使用[CIP-TIO]中的索引对象定义。线端明确显示在尖括号中；本文中添加的换行符仅用于可读性。注释出现在花括号中。
{ sender-CIP connects to receiver-CIP }
<<< % 220 Example CIP server ready<cr><lf>
>>> # CIP-Version: 3<cr><lf>
<<< % 300 CIPv3 OK!<cr><lf>
>>> Mime-Version: 1.0<cr><lf>
>>> Content-type: application/index.cmd.datachanged; type=
>>> x-tagged-index-1; dsi=1.2.752.17.5.10<cr><lf>
>>> <cr><lf>
>>> updatetype: incremental tagbased<cr><lf>
>>> thisupdate: 855938804<cr><lf>
>>> lastupdate: 855940000<cr><lf>
>>> .<cr><lf>
<<< % 200 Good MIME message received
>>> MIME-Version: 1.0<cr><lf>
>>> Content-Type: application/index.obj.tagged;
>>> dsi=1.2.752.17.5.10;
>>> base-uri="ldap://ldap.umu.se/dc=umu,dc=se"<cr><lf>
{ sender-CIP connects to receiver-CIP }
<<< % 220 Example CIP server ready<cr><lf>
>>> # CIP-Version: 3<cr><lf>
<<< % 300 CIPv3 OK!<cr><lf>
>>> Mime-Version: 1.0<cr><lf>
>>> Content-type: application/index.cmd.datachanged; type=
>>> x-tagged-index-1; dsi=1.2.752.17.5.10<cr><lf>
>>> <cr><lf>
>>> updatetype: incremental tagbased<cr><lf>
>>> thisupdate: 855938804<cr><lf>
>>> lastupdate: 855940000<cr><lf>
>>> .<cr><lf>
<<< % 200 Good MIME message received
>>> MIME-Version: 1.0<cr><lf>
>>> Content-Type: application/index.obj.tagged;
>>> dsi=1.2.752.17.5.10;
>>> base-uri="ldap://ldap.umu.se/dc=umu,dc=se"<cr><lf>
>>> <cr><lf>
>>> version: x-tagged-index-1<cr><lf>
>>> updatetype: incremental<cr><lf>
>>> lastupdate: 855940000<cr><lf>
>>> thisupdate: 855938804<cr><lf>
>>> BEGIN IO-schema<cr><lf>
>>> cn: TOKEN<cr><lf>
>>> sn: FULL<cr><lf>
>>> title: FULL<cr><lf>
>>> END IO-Schema<cr><lf>
>>> BEGIN Update Block<cr><lf>
>>> BEGIN Old<cr><lf>
>>> title: 3/testpilot<cr><lf>
>>> END Old<cr><lf>
>>> BEGIN New<cr><lf>
>>> title: 3/chiefpilot<cr><lf>
>>> END New<cr><lf>
>>> END Update Block<cr><lf>
>>> .<cr><lf>
<<< % 200 Good MIME message received
{ Sender-CIP shuts down socket for writing }
<<< % 222 Connection closing in response to sender-CIP shutdown
{ receiver-CIP closes its side, resets, and awaits a
new sender-CIP }
>>> <cr><lf>
>>> version: x-tagged-index-1<cr><lf>
>>> updatetype: incremental<cr><lf>
>>> lastupdate: 855940000<cr><lf>
>>> thisupdate: 855938804<cr><lf>
>>> BEGIN IO-schema<cr><lf>
>>> cn: TOKEN<cr><lf>
>>> sn: FULL<cr><lf>
>>> title: FULL<cr><lf>
>>> END IO-Schema<cr><lf>
>>> BEGIN Update Block<cr><lf>
>>> BEGIN Old<cr><lf>
>>> title: 3/testpilot<cr><lf>
>>> END Old<cr><lf>
>>> BEGIN New<cr><lf>
>>> title: 3/chiefpilot<cr><lf>
>>> END New<cr><lf>
>>> END Update Block<cr><lf>
>>> .<cr><lf>
<<< % 200 Good MIME message received
{ Sender-CIP shuts down socket for writing }
<<< % 222 Connection closing in response to sender-CIP shutdown
{ receiver-CIP closes its side, resets, and awaits a
new sender-CIP }
An example of an unsuccessful version negotiation looks like this:
不成功的版本协商示例如下所示：
{ sender-CIP connects to receiver-CIP }
<<< % 220 Whois++ server ready<cr><lf>
>>> # CIP-Version: 3<cr><lf>
<<< % 500 Syntax error<cr><lf>
{ server closes connection }
{ sender-CIP connects to receiver-CIP }
<<< % 220 Whois++ server ready<cr><lf>
>>> # CIP-Version: 3<cr><lf>
<<< % 500 Syntax error<cr><lf>
{ server closes connection }
The sender-CIP may attempt to retry using version 1 or 2 protocol. Sender-CIP may cache results of this unsuccessful negotiation to avoid later attempts.
发送方CIP可能尝试使用版本1或版本2协议重试。发送方CIP可能会缓存此不成功协商的结果，以避免以后的尝试。
The following response codes are used with the stream transport:
以下响应代码用于流传输：
Code Suggested description Sender-CIP action text
代码建议说明发送方CIP操作文本
200 MIME request received Expect no output, continue session and processed (or close)
收到200个MIME请求，但不期望输出，继续会话并处理（或关闭）
201 MIME request received Read a response, delimited by SMTP-and processed, output style message delimiter. follows
201 MIME请求收到读取响应，由SMTP分隔并处理，输出样式消息分隔符。跟随
220 Initial server banner Continue with Whois++ interaction, message or attempt CIP version negotiation.
220初始服务器横幅继续进行Whois++交互、消息或尝试CIP版本协商。
222 Connection closing (in Done with transaction. response to sender-CIP close)
222连接关闭（已完成事务处理。响应发件人CIP关闭）
300 Requested CIP version Continue with CIP transaction, in accepted the specified version.
300请求的CIP版本在指定版本中继续进行CIP事务。
400 Temporarily unable to Retry at a later time. May be used process request 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
500错误的MIME消息格式使用格式正确的MIME重试
501 Unknown or missing Retry with correct CIP command request in application/index.cmd
501在application/index.cmd中使用正确的CIP命令请求进行未知或缺少重试
502 Request is missing Retry with correct CIP attributes. required CIP attributes
502请求缺少具有正确CIP属性的重试。要求的CIP属性
520 Aborting connection for Alert local administrator. some unexpected reason
520正在中止警报本地管理员的连接。一些意想不到的原因
530 Request requires valid Sign the request, if possible, and signature retry. Otherwise, report problem to the administrator.
530请求需要对请求进行有效签名（如果可能），然后重试签名。否则，请向管理员报告问题。
531 Request has invalid Report problem to the administrator. signature
531请求向管理员报告的问题无效。签名
532 Cannot check signature Alert local administrator, who should cooperate with remote administrator tp diagnose and resolve the problem. (Probably missing a public key.)
532无法检查签名警报本地管理员，本地管理员应与远程管理员合作诊断并解决问题。（可能缺少公钥。）
As an alternative to TCP streams, CIP transactions can take place over the existing Internet mail infrastructure. There are two motivations for this feature of CIP. First, it lowers the barriers to entry for leaf servers. When the need for a full TCP implementation is relaxed, leaf nodes (which, by definition, only send index objects) can consist of as little as a database and an indexing program (possibly written in a very high level language) to participate in the mesh.
作为TCP流的替代方案，CIP事务可以在现有的Internet邮件基础设施上进行。CIP的这一特性有两个动机。首先，它降低了叶服务器的进入壁垒。当对完整TCP实现的需求放松时，叶节点（根据定义，叶节点仅发送索引对象）可以由一个数据库和一个索引程序（可能用非常高级的语言编写）组成，以参与网格。
Second, it keeps with the philosophy of making use of existing Internet technology. The MIME messages used for requests and responses are, by definition of the MIME specification, suitable for transport via the Internet mail infrastructure. With a few simple rules, we open up an entirely different way to interact with CIP servers which choose to implement this transport. See Protocol Conformance, below, for details on what options server implementers have about supporting the various transports.
其次，它符合利用现有互联网技术的理念。根据MIME规范的定义，用于请求和响应的MIME消息适合通过Internet邮件基础设施进行传输。通过一些简单的规则，我们开辟了一种与选择实现这种传输的CIP服务器交互的完全不同的方式。请参阅下面的协议一致性，以了解服务器实现者关于支持各种传输的选项的详细信息。
The basic rhythm of request/response is maintained when using the mail transport. The following sections clarify some special cases which need to be considered for mail transport of CIP objects. In general, all mail protocols and mail format specifications (especially MIME Security Multiparts) can be used with the CIP mail transport.
使用邮件传输时，请求/响应的基本节奏得以保持。以下各节阐明了CIP对象邮件传输需要考虑的一些特殊情况。通常，所有邮件协议和邮件格式规范（特别是MIME安全多部分）都可以与CIP邮件传输一起使用。
Since no information on which CIP-version is in use is present in the MIME message, this information has to be carried in the mailheader. Therefore CIP requests sent using the mail transport MUST include a CIP-version headerline, to be registered according to [MHREG]. The format of this line is:
由于MIME消息中不存在使用哪种CIP版本的信息，因此必须在邮件头中携带此信息。因此，使用邮件传输发送的CIP请求必须包括CIP版本的标题行，并根据[MHREG]进行注册。该行的格式为：
DIGIT = %x30-39
number = 1*DIGIT
cipversion = "CIP-Version:" <sp> number["." number]
DIGIT = %x30-39
number = 1*DIGIT
cipversion = "CIP-Version:" <sp> number["." number]
When CIP transactions take place over a bidirectional stream, the return path for errors and results is implicit. Using mail as a transport introduces difficulties to the recipient, because it's not always clear from the headers exactly where the reply should go, though in practice there are some heuristics used by MUA's.
当CIP事务在双向流上发生时，错误和结果的返回路径是隐式的。使用邮件作为传输工具给收件人带来了困难，因为从邮件头中并不总是清楚回复应该放在哪里，尽管在实践中MUA使用了一些启发式方法。
CIP solves this problem by fiat. CIP requests sent using the mail transport MUST include a Reply-To header as specified by RFC-822. Any mail received for processing by a CIP server implementing the mail transport without a Reply-To header MUST be ignored, and a message should be logged for the local administrator. The receiver MUST not attempt to reply with an error to any address derived from the incoming mail.
CIP通过菲亚特解决了这个问题。使用邮件传输发送的CIP请求必须包括RFC-822指定的回复标头。必须忽略实现邮件传输的CIP服务器接收到的、用于处理的、没有回复邮件头的任何邮件，并且应该为本地管理员记录一条消息。接收人不得试图回复从传入邮件中派生的任何地址，并带有错误。
If there are no circumstances under which a response is to be sent to a CIP request, the sender should include a Reply-To header with the address "<>" in it. Receivers MUST never attempt to send replies to that address, as it is defined to be invalid (both here, and by the BNF grammar in RFC-822). It should be noted that, in general, it is a bad idea to turn off error reporting in this way. However, in the simplest case of an index pushing program, this MAY be a desirable simplification.
如果在任何情况下都不会向CIP请求发送响应，则发送方应在其中包含一个地址为“<>”的回复头。接收方不得尝试向该地址发送回复，因为该地址被定义为无效（此处以及RFC-822中的BNF语法）。应该注意的是，一般来说，以这种方式关闭错误报告是个坏主意。然而，在索引推送程序的最简单情况下，这可能是一种理想的简化。
HTTP MAY also be used to transport CIP objects, since they are just MIME objects. A transaction is performed by using the POST method to send an application/index.cmd and returning an application/index.response or an application/index.obj in the HTTP reply. The URL that is the target of the post is a configuration parameter of the CIP-sender to CIP-receiver relationship.
HTTP也可用于传输CIP对象，因为它们只是MIME对象。通过使用POST方法发送application/index.cmd并在HTTP应答中返回application/index.response或application/index.obj来执行事务。作为post目标的URL是CIP发送方到CIP接收方关系的配置参数。
Example:
例子：
{ the client opens the connection and sends a POST }
>>> POST / HTTP/1.1<cr><lf>
>>> Host: cip.some.corp<cr><lf>
>>> Content-type: application/index.cmd.noop<cr><lf>
>>> Date: Thu, 6 Jun 1997 18:16:03 GMT<cr><lf>
>>> Content-Length: 2<cr><lf>
>>> Connection: close<cr><lf>
>>> <cr><lf>
{ the server processes the request }
<<< HTTP/1.1 204 No Content<cr><lf>
{ the server closes the connection }
{ the client opens the connection and sends a POST }
>>> POST / HTTP/1.1<cr><lf>
>>> Host: cip.some.corp<cr><lf>
>>> Content-type: application/index.cmd.noop<cr><lf>
>>> Date: Thu, 6 Jun 1997 18:16:03 GMT<cr><lf>
>>> Content-Length: 2<cr><lf>
>>> Connection: close<cr><lf>
>>> <cr><lf>
{ the server processes the request }
<<< HTTP/1.1 204 No Content<cr><lf>
{ the server closes the connection }
In addition to leveraging the security capabilities that come with HTTP, there are other HTTP features that MAY be useful in a CIP context. A CIP client MAY use the Accept-Charset and Accept-Language HTTP headers to express a desire to retrieve an index in a particular character set or natural language. It MAY use the Accept-Encoding header to (e.g.) indicate that it can handle compressed responses, which the CIP server MAY send in conjunction with the Transfer-Encoding header. It MAY use the If-Modified-Since header to prevent
除了利用HTTP附带的安全功能外，还有其他HTTP功能在CIP环境中可能很有用。CIP客户端可以使用Accept字符集和Accept Language HTTP头来表示检索特定字符集或自然语言索引的愿望。它可以使用Accept Encoding报头（例如）表示它可以处理压缩响应，CIP服务器可以将压缩响应与传输编码报头一起发送。它可以使用If-Modified-Since标头来防止
wasted transmission of an index that has not changed since the last poll. A CIP server can use the Retry-After header to request that the client retry later when the server is less busy.
浪费传输自上次轮询以来未更改的索引。CIP服务器可以使用Retry After标头请求客户端稍后在服务器不忙时重试。
There are two levels at which the index information can be protected; the first is by use of the technology available for securing MIME [MIME-SEC] objects, and secondly by using the technology available for securing the transport.
有两个级别可以保护索引信息；第一种是使用可用于保护MIME[MIME-SEC]对象的技术，第二种是使用可用于保护传输的技术。
When it comes to transport the stream transport can be protected by the use of TLS [TLS] . For HTTP the Security is handled by using HTTP Basic Authentication [RFC 2616], HTTP Message Digest Authentication [RFC2617] or SSL/TLS. Extra protection for the SMTP exchange can be achieve by the use of Secure SMTP over TLS [SMTPTLS].
在传输方面，可以使用TLS[TLS]来保护流传输。对于HTTP，通过使用HTTP基本身份验证[RFC 2616]、HTTP消息摘要身份验证[RFC2617]或SSL/TLS来处理安全性。通过使用安全的SMTP over TLS[SMTPTLS]，可以实现对SMTP交换的额外保护。
[RFC 2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC 2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC 2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC 2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC 2617]Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[CIP-ARCH] Allen, J. and M. Mealling, "The Architecture of the Common Indexing Protocol (CIP)", RFC 2651, August 1999.
[CIP-ARCH]Allen，J.和M.Melling，“公共索引协议（CIP）的体系结构”，RFC 26511999年8月。
[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月。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[CIP-TIO] Hedberg, R., Greenblatt, B., Moats, R. and M. Wahl, "A Tagged Index Object for use in the Common Indexing Protocol", RFC 2654, August 1999.
[CIP-TIO]Hedberg，R.，Greenblatt，B.，Moats，R.和M.Wahl，“通用索引协议中使用的标记索引对象”，RFC 2654，1999年8月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[MIME-SEC] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[MIME-SEC]Galvin，J.，Murphy，S.，Crocker，S.和N.Freed，“MIME的安全多部分：多部分/签名和多部分/加密”，RFC 1847，1995年10月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC 2246，1999年1月。
[SMTPTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over TLS", RFC 2487, January 1999.
[SMTPTLS]Hoffman，P.，“TLS上安全SMTP的SMTP服务扩展”，RFC2487，1999年1月。
[MHREG] Jacob, P., "Mail and Netnews Header Registration Procedure", Work in Progress.
[MHREG]Jacob，P.，“邮件和网络新闻标题注册程序”，正在进行中。
Jeff R. Allen 246 Hawthorne St. Palo Alto, CA 94301
杰夫·R·艾伦246霍桑圣帕洛阿尔托，加利福尼亚州94301
EMail: jeff.allen@acm.org
EMail: jeff.allen@acm.org
Paul J. Leach Microsoft 1 Microsoft Way Redmond, WA 98052
Paul J.Leach微软1微软路雷德蒙德，华盛顿州，98052
EMail: paulle@microsoft.com
EMail: paulle@microsoft.com
Roland Hedberg Catalogix Dalsveien 53 0775 Oslo Norway
挪威奥斯陆罗兰·赫德伯格目录Dalsveien 53 0775
EMail: roland@catalogix.ac.se
EMail: roland@catalogix.ac.se
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编辑功能的资金目前由互联网协会提供。