RFC2653 日本語訳
2653 CIP Transport Protocols. J. Allen, P. Leach, R. Hedberg. August 1999. (Format: TXT=22999 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Allen
Request for Comments: 2653 WebTV Networks, Inc.
Category: Standards Track P. Leach
Microsoft
R. Hedberg
Catalogix
August 1999
コメントを求めるワーキンググループJ.アレンの要求をネットワークでつないでください: 2653年のWebTV Networks Inc.カテゴリ: 標準化過程P.リーチマイクロソフトR.ヘドバーグCatalogix1999年8月
CIP Transport Protocols
CIPトランスポート・プロトコル
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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]で定義されます。
1. Protocol
1. プロトコル
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のメッセージ・フォーマットとトランスファ・メカニズムの正式の定義です。
1.1 Philosophy
1.1 哲学
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プロトコルデザインの哲学は1です。ブロックデザインについて。 厖大なプロトコル定義ツール、または臨時のテキストencodingsを当てにすることの代わりに、CIPはMIMEのような既存の、そして、よく理解されているインターネット技術を利用します、RFC-822、Whois++、FTP、およびSMTP。 うまくいけば、これは、実装とコンセンサスを緩和するのに役立つでしょう。
Allen, et al. Standards Track [Page 1] RFC 2653 CIP Transport Protocols August 1999
アレン、他 標準化過程[1ページ]RFC2653CIPは1999年8月にプロトコルを輸送します。
building. It should also stand as an example of a simple way to leverage existing Internet technologies to easily implement new application-level services.
建てること。 また、それは既存のインターネットが容易に新しいアプリケーションレベルサービスを実装する技術であると利用する簡単な方法に関する例の候補に立つべきです。
1.2 Conventions
1.2 コンベンション
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"と「5月」は「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メッセージの置き換えに依存します。 これらのメッセージは双方向の、そして、高信頼の輸送システムの上に通過されます。 このドキュメントは信頼できるネットワークストリーム(TCPを通した)の上と、そして、HTTPを通して、インターネット・メールインフラストラクチャで輸送を定義します。
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と呼ばれます。
2.1 The Stream Transport
2.1 ストリーム輸送
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
最初に後方に+ + サーバ、CIPv3送付者-CIPsがそうしなければならない既存のWhoisとの互換性を維持するには、より新しいプロトコルがサポートされることを確かめてください。 彼らは+ + システム・コマンドを以下の不法なWhoisに送ることによって、これをします: 「#CIP-バージョン:」 「3<cr><lf>。」 既存のWhoisでは、これは500シリーズ応答コードをもたらして、+ + サーバがCIPのバージョン1と2を実装する、サーバは接続を終えます。 if
Allen, et al. Standards Track [Page 2] RFC 2653 CIP Transport Protocols August 1999
アレン、他 標準化過程[2ページ]RFC2653CIPは1999年8月にプロトコルを輸送します。
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の将来のバージョンを交渉できる、(「CIP-バージョン: 4インチ)、」 この短い置き換えに関する例は以下に出されます。
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-バージョン: 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に要求をサポートすることをいったん首尾よく確かめると、ネットワークの標準の系列結末を使用することでMime-バージョンと(単に)のコンテントタイプヘッダーと共にMIMEメッセージとしてフォーマットされた要求は送ることができます: 「<cr><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インチのCRLF Req-Cntnt-Hdrが等しい、「コンテントタイプ:」、」 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=と等しい、「コンテントタイプ:」 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が等しい、「コンテントタイプ:」 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
Allen, et al. Standards Track [Page 3] RFC 2653 CIP Transport Protocols August 1999
アレン、他 標準化過程[3ページ]RFC2653CIPは1999年8月にプロトコルを輸送します。
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 MUSTは、別の要求メッセージを読むのを準備します、送付者-CIPがちょうどCIPバージョンについて確かめたところなとき、肝心の状態をリセットして。 送付者-CIPが要求をし終わっているなら、それは接続を終えるかもしれません。 応答では、受信機-CIP MUSTはメッセージを読むのを中止して、新しい送付者-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]へのインデックスオブジェクト定義は使用されるでしょう。 線結末はanglebracketsに明らかに示されます。 本稿のニューラインは読み易さのためだけに加えられます。 コメントはブレースに起こります。
{ 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>
送付者-CIPが受信機-CIPに接続する、持ち合わせの<<<%220の>>>>#Example CIPサーバ<cr><lf CIP-バージョン: 3 <cr><lf><<<%300CIPv3OK!<cr><lf>>>>パントマイムバージョン: 1.0<cr><lf>>>>文書内容: アプリケーション/index.cmd.datachanged。 xがインデックス1にタグ付けをしていた状態で、=>>>をタイプしてください。 .5の.10<crな><lfなdsi=1.2.752.17のlf>>>>>>>><cr><updatetype: 増加のtagbased<のlf>>>>cr><thisupdate: 855938804 <cr><lf>>>>lastupdate: 855940000 <cr><lf>>>><cr><lf><<<%200Good MIMEメッセージは>>>MIMEバージョンを受けました: 1.0 <cr><lf>>>>コンテントタイプ: アプリケーション/index.obj.tagged。 >>>dsi=1.2.752.17.5.10。 >>>ベース-uriが等しい、「ldap://ldap.umu.se/dc=umu、dc=se「<cr><lf>」
Allen, et al. Standards Track [Page 4] RFC 2653 CIP Transport Protocols August 1999
アレン、他 標準化過程[4ページ]RFC2653CIPは1999年8月にプロトコルを輸送します。
>>> <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: 増加の<のlf>>>>cr><lastupdate: 855940000 <cr><lf>>>>thisupdate: 855938804<cr><lf>>>>BEGIN IO-図式<cr><lf>>>>cn: TOKEN<cr><lf>>>>sn: FULL<cr><lf>>>>タイトル: FULL<cr><lf>>>>END IO-図式<cr><lf>>>>BEGIN Update Block<cr><は>>>>BEGIN Old<cr><lf>>>>タイトルをlfします: 3/testpilot<cr><lf>>>>END Old<cr><lf>>>>BEGIN New<cr><lf>>>>タイトル: 3/chiefpilot<cr><lf>>>>END New<cr><lf>>>>END Update Block<cr><lf>>>><cr><は送付者-CIP閉鎖に対応して<<<%222Connection終わりであることで受け取って、送付者-CIPが書くことのためにソケットを止めるという><<<%200Good MIMEメッセージをlfします。受信機-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に接続する、持ち合わせのcr<<<%220の<lf>>>Whois++サーバ<>>#CIP-バージョン: 3 <cr><lf><<<%500Syntax誤り<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は、後の試みを避けるためにこの失敗の交渉の結果をキャッシュするかもしれません。
2.1.1 Transport specific response codes
2.1.1 特定の応答コードを輸送してください。
The following response codes are used with the stream transport:
以下の応答コードはストリーム輸送と共に使用されます:
Code Suggested description Sender-CIP action
text
コードSuggested記述Sender-CIP動作テキスト
200 MIME request received Expect no output, continue session
and processed (or close)
200MIME要求は、出力されなかったExpectを受けて、セッションを続けて、処理されました。(近い)
Allen, et al. Standards Track [Page 5] RFC 2653 CIP Transport Protocols August 1999
アレン、他 標準化過程[5ページ]RFC2653CIPは1999年8月にプロトコルを輸送します。
201 MIME request received Read a response, delimited by SMTP-
and processed, output style message delimiter.
follows
SMTPによって区切られて、処理された容認されたRead a応答がスタイルメッセージデリミタ尾行を出力したという201MIME要求
220 Initial server banner Continue with Whois++ interaction,
message or attempt CIP version negotiation.
220はWhois++相互作用、メッセージまたは試みCIPバージョン交渉でサーババナーContinueに頭文字をつけます。
222 Connection closing (in Done with transaction.
response to sender-CIP
close)
222接続閉鎖(トランザクション送付者-CIPへの応答が近くにあるDoneの)
300 Requested CIP version Continue with CIP transaction, in
accepted the specified version.
300はCIPトランザクションでCIPバージョンContinueを要求して、指定されたバージョンは中で受け入れました。
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.
一時Retryへの400であることができない、後で。 サーバにはインデックスを受け入れるために利用可能なリソースが現在ないのを示すという中古のプロセス要求であるかもしれません。
500 Bad MIME message format Retry with correctly formatted MIME
500 正しくフォーマットされたMIMEがある悪いMIMEメッセージ・フォーマットRetry
501 Unknown or missing Retry with correct CIP command
request in
application/index.cmd
501 正しいCIPコマンド要求がアプリケーション/index.cmdにある未知の、または、なくなったRetry
502 Request is missing Retry with correct CIP attributes.
required CIP attributes
502要求は正しいCIP属性必要なCIP属性があるなくなったRetryです。
520 Aborting connection for Alert local administrator.
some unexpected reason
520 Alert地元の管理者何らかの予期しなかった理由のための接続を中止すること。
530 Request requires valid Sign the request, if possible, and
signature retry. Otherwise, report problem to
the administrator.
530要求は要求であって、可能な有効なSign、および署名再試行を必要とします。 さもなければ、問題を管理者に報告してください。
531 Request has invalid Report problem to the administrator.
signature
531要求が無効のReport問題を管理者に持っている、署名
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は署名のAlert地元の管理者をチェックできません。(その管理者は、tpが診断するリモート管理者と協力して、問題を解決するべきです)。 (たぶん、公開鍵を逃します。)
Allen, et al. Standards Track [Page 6] RFC 2653 CIP Transport Protocols August 1999
アレン、他 標準化過程[6ページ]RFC2653CIPは1999年8月にプロトコルを輸送します。
2.2 Internet mail infrastructure as transport
2.2 輸送としてのインターネット・メールインフラストラクチャ
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.
2番目に、それは、存在を利用する哲学でインターネットが技術であることを保ちます。 要求と応答がそうので定義上インターネット・メールインフラストラクチャを通して輸送に適したMIME仕様について使用されるMIMEメッセージ。 いくつかの簡単な規則で、私たちはこの輸送を実装するのを選ぶCIPサーバと対話する完全に異なった方法を開けます。 以下で様々な輸送をサポートすることに関してimplementersにはどんなオプションサーバがあるかに関する詳細に関してプロトコルConformanceを見てください。
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オブジェクトのメール輸送のために考えられる必要があるいくつかの特別なケースをはっきりさせます。 一般に、CIPメール輸送と共にすべてのメールプロトコルとメール書式仕様(特にMIME Security Multiparts)を使用できます。
2.2.1 CIP-Version negotiation
2.2.1 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要求は、[MHREG]に従って登録されるためにCIP-バージョンheaderlineを含まなければなりません。 この系列の形式は以下の通りです。
DIGIT = %x30-39 number = 1*DIGIT cipversion = "CIP-Version:" <sp> number["." number]
DIGIT=%x30-39番号=1*DIGIT cipversionが等しい、「CIP-バージョン:」 <sp>番号[「. 」 数、]
2.2.2 Return path
2.2.2 リターンパス
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のものによって使用されたいくつかの発見的教授法が実際にはありますが。
Allen, et al. Standards Track [Page 7] RFC 2653 CIP Transport Protocols August 1999
アレン、他 標準化過程[7ページ]RFC2653CIPは1999年8月にプロトコルを輸送します。
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要求がメール輸送が含まなければならない使用を送った、Reply、-、ヘッダー、RFC-822によって指定されるように。 どんなメールも処理のためにaなしでメールが輸送であると実装するCIPサーバによって受信された、Reply、-、ヘッダーを無視しなければならなくて、メッセージは地元の管理者のために登録されるべきです。 受信機は、誤りで入って来るメールから得られたどんなアドレスに関しても返答するのを試みてはいけません。
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要求に送られることになっているかを入れるべきである、Reply、-、ヘッダー、それのアドレス「<>」で。 受信機は、そのアドレスに回答を送るのを決して試みてはいけません、それが無効に(ここ、およびRFC-822のBNF文法による)なるように定義されるとき。 一般に、このように報告する誤りをオフにするのが、悪い考えであることに注意されるべきです。 しかしながら、インデックス押すプログラムの最も簡単な場合では、これは望ましい簡素化であるかもしれません。
2.3 HTTP transport
2.3 HTTP輸送
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は、それらがただMIMEオブジェクトであるので、CIPオブジェクトを輸送するのに使用されるかもしれません。 トランザクションは、アプリケーション/index.cmdを送るポストメソッドを使用して、HTTP回答でアプリケーション/index.responseかアプリケーション/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 }
クライアントは、接続を開いて、ポストを送ります。>>>ポスト/ HTTP/1.1<cr><は>>>>Hostをlfします: cip.some.corp<cr><lf>>>>文書内容: アプリケーション/index.cmd.noop<cr><lf>>>>日付: グリニッジ標準時1997年6月6日木曜日18時16分3秒の<cr><lf>>>>コンテンツの長さ: 2 <cr><lf>>>>接続: <cr><lf>>>><cr><lf>を閉じてください、サーバが要求を処理する、<のcrの>の<のlfの<<<HTTP/1.1 204ノーContent>。サーバは接続を終えます。
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と共に来る能力であると利用することに加えて、他のCIP文脈で役に立つかもしれないHTTP機能があります。 CIPクライアントは、特定の文字集合か自然言語でインデックスを検索する願望を述べるのにAccept-CharsetとAccept-言語HTTPヘッダを使用するかもしれません。 それは、CIPサーバがTransferコード化に関連してヘッダーに送るかもしれない圧縮された応答を扱うことができるのを示すこと(例えば)にAcceptをコード化しているヘッダーを使用するかもしれません。 それは防ぐ以来変更されたIfヘッダーを使用するかもしれません。
Allen, et al. Standards Track [Page 8] RFC 2653 CIP Transport Protocols August 1999
アレン、他 標準化過程[8ページ]RFC2653CIPは1999年8月にプロトコルを輸送します。
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ヘッダーを使用できます。
3. Security Considerations
3. セキュリティ問題
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つのレベルがあります。 1番目が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において、Securityは、HTTP Basic Authentication[RFC2616]、HTTP Message Digest Authentication[RFC2617]またはSSL/TLSを使用することによって、扱われます。 SMTP交換のための特別な防護措置はTLSの上のSecure SMTPの使用で[SMTPTLS]を達成することであるかもしれません。
4. References
4. 参照
[RFC 2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
解放された[RFC2045]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、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.
[RFC2616] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、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.
[RFC2617] フランクス、J.、ハラム-ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、「HTTP認証:」 「基本的、そして、ダイジェストアクセス認証」、RFC2617、1999年6月。
[CIP-ARCH] Allen, J. and M. Mealling, "The Architecture of the Common
Indexing Protocol (CIP)", RFC 2651, August 1999.
[CIP-アーチ] アレンとJ.とM.食事、「一般的なインデックスプロトコル(CIP)のアーキテクチャ」、RFC2651、1999年8月。
[CIP-MIME] Allen, J. and M. Mealling, "MIME Object Definitions for
the Common Indexing Protocol (CIP)", RFC 2652, August
1999.
[CIP-MIME] アレンとJ.とM.食事、「一般的なインデックスプロトコル(CIP)のためのMIMEオブジェクト定義」、RFC2652、1999年8月。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[ABNF] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[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.ウォール、「Common Indexingプロトコルにおける使用のためのTagged Index Object」、RFC2654、1999年8月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Allen, et al. Standards Track [Page 9] RFC 2653 CIP Transport Protocols August 1999
アレン、他 標準化過程[9ページ]RFC2653CIPは1999年8月にプロトコルを輸送します。
[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秒] ガルビン、J.、マーフィー、S.、クロッカー、S.、および解放されたN.、「MIMEのためのセキュリティMultiparts:」 「署名していて複合の/が暗号化した複合/」、RFC1847、1995年10月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[TLS] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[SMTPTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over
TLS", RFC 2487, January 1999.
[SMTPTLS]ホフマン、P.、「TLSの上の安全なSMTPのためのSMTPサービス拡張子」、RFC2487、1999年1月。
[MHREG] Jacob, P., "Mail and Netnews Header Registration
Procedure", Work in Progress.
[MHREG] ヤコブと、P.と、「メールとネットニュースヘッダー登録手順」は進行中で働いています。
5. Authors' Addresses
5. 作者のアドレス
Jeff R. Allen 246 Hawthorne St. Palo Alto, CA 94301
聖パロアルト、ジェフ・R.アレン246・Hawthorneカリフォルニア 94301
EMail: jeff.allen@acm.org
メール: jeff.allen@acm.org
Paul J. Leach Microsoft 1 Microsoft Way Redmond, WA 98052
ポールJ.リーチマイクロソフト1マイクロソフト道、レッドモンド、ワシントン 98052
EMail: paulle@microsoft.com
メール: paulle@microsoft.com
Roland Hedberg Catalogix Dalsveien 53 0775 Oslo Norway
ローランドヘドバーグCatalogix Dalsveien53 0775オスロノルウェー
EMail: roland@catalogix.ac.se
メール: roland@catalogix.ac.se
Allen, et al. Standards Track [Page 10] RFC 2653 CIP Transport Protocols August 1999
アレン、他 標準化過程[10ページ]RFC2653CIPは1999年8月にプロトコルを輸送します。
6. Full Copyright Statement
6. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Allen, et al. Standards Track [Page 11]
アレン、他 標準化過程[11ページ]
一覧
スポンサーリンク
