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
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、電子メール、およびHTTPを利用し、CIP要求、応答、および索引オブジェクトを輸送するための3つのプロトコルを指定します。オブジェクト自体は[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上に使用されるメッセージフォーマット及びCIPの搬送機構の正式な定義であり、HTTP及び郵便物。
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 building. It should also stand as an example of a simple way to leverage existing Internet technologies to easily implement new application-level services.
CIPプロトコルの設計の哲学は、ビルディング・ブロックデザインの一つです。代わりにかさばるプロトコル定義ツール、またはアドホックテキストエンコーディングに頼るので、CIPはMIME、RFC-822、Whoisの++、FTP、およびSMTPなどの既存の、よく理解インターネット技術に描画します。うまくいけば、これは実装と合意形成を緩和するのに役立つであろう。また、簡単に新しいアプリケーションレベルのサービスを実装するために、既存のインターネット技術を活用するための簡単な方法の一例として立つべき。
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].
キーワード「MUST」と「MAY」このドキュメントの「要件レベルを示すためにRFCsにおける使用のためのキーワード」[キーワード]で説明したように解釈されるべきです。
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メッセージの交換に依存しています。これらのメッセージは、双方向、信頼性の高い輸送システムを介して渡されます。この文書では、HTTPを経由して、信頼性の高いネットワークストリーム（TCP経由）を介してトランスポートを定義し、インターネットメールインフラストラクチャを介しました。
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接続を介して送信されます。メッシュ構成で指定されたトランザクションは、任意の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によって確認されています。これらのコードのフォーマット、CIPサーバが生成する応答のリスト、およびそれぞれの予想送信者-CIPのアクションのためのセクション2.1.1を参照してください。
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.
Whois ++サーバを既存との後方互換性を維持するために、CIPv3送信者-CIPを最初新しいプロトコルがサポートされていることを確かめなければなりません。彼らは、以下の違法のWhois ++システム・コマンドを送信することで、次の操作を行います "＃CIP-バージョン：3 <CR> <LF>"。 CIPのバージョン1および2を実装する既存のWhois ++サーバーでは、これは500-シリーズの応答コードになり、そしてサーバーは接続を終了します。サーバはCIPv3を実装する場合、それは代わりに、CIPの300の将来のバージョンが正しく異なる文字列（すなわち、「：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.
注意：文字列とすぐCIPv3要求でそれに従ってください：送信者-CIPは、安全にサーバがCIPv3を実装し、それは「3＃CIP-バージョン」を送信するように選択していると仮定することができます。この最適化は、知られている唯一の均質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>".
「<CR>：送信者-CIPが正常にサーバがCIPv3要求をサポートしていることを確認したら、それが終わるネットワークの標準ラインを使用して、マイム・バージョンとのContent-Typeヘッダ（のみ）でのMIMEメッセージとしてフォーマット要求を送信することができます<LF>」。
Cip-Req = Req-Hdrs CRLF Req-Body
CIP-REQ = REQ-HDRS CRLF REQ-ボディ
Req-Hdrs = *( Version-Hdr | Req-Cntnt-Hdr ) Req-Body = Body ; format of request body as in [CIP-MIME]
REQ-HDRS = *（バージョン-HDR | REQ-Cntnt-HDR）REQ-ボディ=ボディ。 [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]
バージョン-HDR = "マイム・バージョン：" "1.0" CRLF REQ-Cntnt-HDR = "Content-Typeの" REQ-コンテンツCRLF REQ-コンテンツ=;フォーマットは、[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-コードCRLF [RSP-HDRS CRLF RSP-ボディ] [INDX-Cntnt-HDR CRLF索引ボディ] RSP-コード=桁の数字桁コメントコメント=。 CRとを除く任意の文字LF RSP-HDRS = *（バージョン-HDR | RSP-Cntnt-HDR）RSP-Cntnt-HDR = "Content-Typeの" RSP-コンテンツCRLF RSP-コンテンツ=;フォーマットは、[CIP-MIME] RSP-ボディ=体内で指定されています。 [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型CRLF INDX-OBJ-タイプ=;登録されているすべてのインデックスオブジェクトのMIMEタイプ。フォーマットは、[RFC2045]索引ボディ=体内で指定されています。各インデックスで定義されたフォーマット。仕様
CRLF = CR LF ; Internet standard newline CR = %x0D ; carriage return LF = %x0A ; linefeed DIGIT = %x30-39
CRLF = CR LF。インターネット標準改行CR =％x0D。キャリッジリターンLF =％X0A。改行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>
>>> <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> >>>バージョン：Xタグインデックス-1 <CR> <LF> >>> UPDATETYPE：インクリメンタル<CR> <LF> >>>最終更新日：855940000 <CR> <LF > >>> thisUpdateの：855938804 <CR> <LF> >>> IO-スキーマをBEGIN <CR> <LF> >>> CN：TOKEN <CR> <LF> >>> SN：FULL <CR> <LF> >>>タイトル：FULL <CR> <LF> >>> END IO-スキーマ<CR> <LF> >>> BEGIN更新ブロック<CR> <LF> >>> BEGIN旧<CR> <LF> >> >タイトル：3 / testpilot <CR> <LF> END旧>>> <CR> <LF> >>> BEGIN新しい<CR> <LF> >>>タイトル：3 / chiefpilot <CR> <LF> >> > END新しい<CR> <LF> >>> END更新ブロック<CR> <LF> >>>。<CR> <LF> <<<％200良いMIMEメッセージは、{送信者CIPは書き込み用ソケットをシャットダウン}受信送信者CIPの停止に応答して<<<％222接続閉鎖{レシーバ-CIPは、その側を閉じリセットし、新しい送信者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 }
{送信側CIPは、CIPを受信機に接続} <<<％220件のWhois ++サーバ準備<CR> <LF> >>>＃CIP-バージョン：3 <CR> <LF> <<<％500構文エラー<CR> < LF> {サーバが接続を閉じます}
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不明またはアプリケーション/ 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は、リモート管理者と協力し、TP、問題の診断と解決すべき署名の警告ローカル管理者を、チェックすることはできません。 （おそらく公開鍵を欠落しています。）
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取引は、既存のインターネットメールインフラストラクチャ上で行うことができます。 CIPのこの機能のために2つの動機があります。まず、それは葉のサーバー用の参入障壁を低下させます。完全な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仕様の定義によって、あります。いくつかの簡単なルールで、我々はこのトランスポートを実装することを選択した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:
CIP-バージョンが使用されている上に何の情報がMIMEメッセージ内に存在しないので、この情報はmailheaderで運ばなければなりません。従ってCIP-バージョンheaderlineを含まなければならないメールトランスポートを使用して送信されたCIP要求は、[MHREG]に従って登録します。この行の形式は次のとおりです。
DIGIT = %x30-39 number = 1*DIGIT cipversion = "CIP-Version:" <sp> number["." number]
DIGIT =％のx30-39数= 1 * DIGITのcipversion = "CIP-バージョン：" "" <SP>番号[数]
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.
彼らはただMIMEオブジェクトであるため、HTTPはまた、CIPオブジェクトを転送するために使用されるかもしれません。トランザクションは、アプリケーション/ index.cmdを送信するPOSTメソッドを使用して、アプリケーション/ index.responseまたはHTTP応答でアプリケーション/ index.objを返すことによって行われます。ポストの対象である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 }
{クライアントが接続を開き、POST送信} >>> POST / HTTP / 1.1 <CR> <LF> >>>ホスト：cip.some.corp <CR> <LF> >>>コンテンツタイプ：アプリケーション/ index.cmd.noop <CR> <LF> >>>日：木、1997年6月6日午後06時16分03秒GMT <CR> <LF> >>>のContent-Length：2 <CR> <LF> >>>接続：閉じる<CR> <LF> >>> <CR> <LF> {サーバーが要求を処理} <<< HTTP / 1.1 204いいえコンテンツ<CR> <LF> {サーバが接続を閉じます}
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 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.
HTTPに付属しているセキュリティ機能を活用することに加えて、CIP文脈で有用である可能性がある他のHTTPの機能があります。 CIPクライアントが受け入れ-文字セットを使用して、特定の文字セットや自然言語のインデックスを取得したいという願望を表現するためにHTTPヘッダのAccept-Languageかもしれません。これは、（例えば）へのAccept-Encodingヘッダーを使用することがCIPサーバが転送エンコーディングヘッダと一緒に送るかもしれ圧縮応答を扱うことができることを示してもよいです。これは、ヘッダの最後のポーリング以降に変更されていない索引の無駄な送信を防止するために修飾-ので、もしを使用するかもしれません。 CIPサーバは、サーバがビジーであるとき、そのクライアントの再試行後に要求するために、再試行-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.
インデックス情報を保護することのできる2つのレベルがあります。最初は、第二輸送を確保するための利用可能な技術を使用して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交換のための特別な保護はTLS [SMTPTLS]以上のSecure 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]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年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.、Frystyk、H.、Masinter、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]フランク、J.、ハラム・ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.およびL.スチュワート、 "HTTP認証：基本とダイジェストアクセス認証" 、RFC 2617、1999年6月。
[CIP-ARCH] Allen, J. and M. Mealling, "The Architecture of the Common Indexing Protocol (CIP)", RFC 2651, August 1999.
[CIP-ARCH]アレン、J.とM. Mealling、RFC 2651、1999年8月 "共通インデックスプロトコル（CIP）のアーキテクチャ"。
[CIP-MIME] Allen, J. and M. Mealling, "MIME Object Definitions for the Common Indexing Protocol (CIP)", RFC 2652, August 1999.
[CIP-MIME]アレン、J.とM. Mealling、 "共通インデックスプロトコルのMIMEオブジェクト定義（CIP）"、RFC 2652、1999年8月。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF]クロッカー、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]ヘドバーグ、R.、グリーンブラット、B.、堀、R.及びM.ワール、 "共通インデックスプロトコルにおける使用のためのタグ付きインデックスオブジェクト"、RFC 2654、1999年8月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ガルビン、J.、マーフィー、S.、クロッカー、S.およびN.フリード、 "MIMEマルチパートのセキュリティ：マルチパート/署名およびマルチパート/暗号化"、RFC 1847、1995年10月には。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[SMTPTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over TLS", RFC 2487, January 1999.
[SMTPTLS]ホフマン、P.、 "TLSの上にセキュアなSMTPのためのSMTPサービス拡張子"、RFC 2487、1999年1月。
[MHREG] Jacob, P., "Mail and Netnews Header Registration Procedure", Work in Progress.
[MHREG]ヤコブ、P.、「メールやネットニュースのヘッダ登録手順」が進行中で働いています。
Jeff R. Allen 246 Hawthorne St. Palo Alto, CA 94301
ジェフ・R.アレン246ホーソーンセントパロアルト、CA 94301
EMail: jeff.allen@acm.org
メールアドレス：jeff.allen@acm.org
Paul J. Leach Microsoft 1 Microsoft Way Redmond, WA 98052
ポール・J.リーチマイクロソフト1マイクロソフト道レドモンド、WA 98052
EMail: paulle@microsoft.com
メールアドレス：paulle@microsoft.com
Roland Hedberg Catalogix Dalsveien 53 0775 Oslo Norway
ローランドヘドバーグCatalogix Dalsveien 53 0775オスロノルウェー
EMail: roland@catalogix.ac.se
メールアドレス：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 Editor機能のための基金は現在、インターネット協会によって提供されます。