[要約] RFC 2653は、CIP（Common Industrial Protocol）トランスポートプロトコルに関する技術仕様です。このRFCの目的は、CIPを使用して工業制御システム間でデータを転送するためのトランスポートプロトコルを定義することです。
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.
Copyright（c）The Internet Society（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、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 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プロトコル設計の哲学は、ビルディングブロックデザインの1つです。かさばるプロトコル定義ツール、またはアドホックテキストエンコーディングに依存する代わりに、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].
このドキュメントのキーワード「必須」と「5月」は、「要件レベルを示すために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 "<<< ".
例では、Sender-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と呼ばれます。Sender-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によって応答コードを使用して確認されます。これらのコードの形式については、セクション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 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 Sender-Cipsはまず新しいプロトコルがサポートされていることを確認する必要があります。彼らは、次の違法なWHOISシステムコマンドを送信することでこれを行います。CIPのバージョン1と2を実装する既存のWHOISサーバーでは、500シリーズの応答コードが発生し、サーバーが接続を終了します。サーバーがCIPV3を実装する場合、代わりに応答コード300で応答する必要があります。CIPの将来のバージョンは、この手法を異なる文字列（つまり、 "CIP-version：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-Version：3」文字列を送信することを選択できます。この最適化は、既知の均一な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>".
Sender-CIPがサーバーがCIPV3リクエストをサポートすることを正常に確認したら、ネットワーク標準ラインのエンディングを使用して、MIMEバージョンとコンテンツタイプのヘッダーを使用してMIMEメッセージとしてフォーマットされるリクエストを送信できます。<lf> "。
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]
Body = Data CRLF "." CRLF Data = ; data with CRLF "." CRLF replaced by ; CRLF ".." CRLF
body = data crlf "。"crlf data =;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]
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
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.
When the data is finished, the octet pattern "<cr><lf>.<cr><lf>" is transmitted to the receiver-CIP.
データが終了すると、オクテットパターン「<cr> <lf>。<cr> <lf>」が受信機に送信されます。
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.
Receiver-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シリーズのいずれかから応答コードを送信します。その後、受信機がリクエストを処理し、必要に応じて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は別の要求メッセージを読み取る準備をしなければなりません。SenderCIPがCIPバージョンを確認したばかりのポイントまで状態をリセットする必要があります。Sender-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]のインデックスオブジェクト定義が使用されます。ラインエンディングは、アングルブラケットで明示的に表示されます。このテキストのnewlinesは、読みやすさのためにのみ追加されます。コメントはカーリーブラケットで発生します。
{ 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 }
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 }
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.
Sender-CIPは、バージョン1または2プロトコルを使用して再試行しようとする場合があります。Sender-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と処理された出力スタイルメッセージDelimiterによって区切られた応答を読み取りました。続きます
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接続クロージング（トランザクションで完了。Sender-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マイムメッセージフォーマットは、正しくフォーマットされたマイムで再試行します
501 Unknown or missing Retry with correct CIP command request in application/index.cmd
501 application/index.cmdで正しいCIPコマンド要求を使用した501リトリーの欠如
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トランザクションは既存のインターネットメールインフラストラクチャを介して行われます。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-versionが使用している情報はMIMEメッセージに存在していないため、この情報はMailheaderで実施する必要があります。したがって、メールトランスポートを使用して送信されたCIPリクエストには、[MHREG]に従って登録するために、CIP-Version Headerlineを含める必要があります。この行の形式は次のとおりです。
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はFiatによってこの問題を解決します。メールトランスポートを使用して送信された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は、MIMEオブジェクトであるため、CIPオブジェクトを輸送するためにも使用できます。POSTメソッドを使用してApplication/index.cmdを送信し、HTTP返信でApplication/index.ResponseまたはApplication/Index.OBJを返すことにより、トランザクションが実行されます。投稿のターゲットであるURLは、CIP-Receiver関係に対する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 }
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クライアントは、特定のキャラクターセットまたは自然言語でインデックスを取得したいという欲求を表明するために、Accept-CharsetおよびAccept-Language HTTPヘッダーを使用できます。Accept-Encodingヘッダーを使用して（例えば）圧縮応答を処理できることを示します。これは、CIPサーバーが転送エンコードヘッダーと併せて送信する場合があります。if修正型ヘッダーを使用して、最後の世論調査以来変更されていないインデックスの無駄な伝送を防ぐことができます。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.
インデックス情報を保護できる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の場合、HTTP基本認証[RFC 2616]、HTTPメッセージダイジェスト認証[RFC2617]またはSSL/TLSを使用してセキュリティが処理されます。SMTP交換のための特別な保護は、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、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners-lee、「HyperText Transfer Protocol-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.、Luotonen、A。and L. Stewart、「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] Allen、J。およびM. Mealling、「共通インデックスプロトコル（CIP）のアーキテクチャ」、RFC 2651、1999年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のセキュリティマルチパート：MultiPart/Signed and MultiPart/Encrypted」、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サービス拡張」、RFC 2487、1999年1月。
[MHREG] Jacob, P., "Mail and Netnews Header Registration Procedure", Work in Progress.
[MHREG] Jacob、P。、「メールおよびNetNewsヘッダー登録手順」、進行中の作業。
Jeff R. Allen 246 Hawthorne St. Palo Alto, CA 94301
ジェフ・R・アレン246ホーソーンセントパロアルト、カリフォルニア94301
EMail: jeff.allen@acm.org
Paul J. Leach Microsoft 1 Microsoft Way Redmond, WA 98052
Paul J. Leach Microsoft 1 Microsoft Way Redmond、WA 98052
EMail: paulle@microsoft.com
Roland Hedberg Catalogix Dalsveien 53 0775 Oslo Norway
Roland Hedberg Catalogix Dalsveien 53 0775 Oslo Norway
EMail: roland@catalogix.ac.se
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。