Network Working Group J. Allen
Request for Comments: 2652 WebTV Networks, Inc.
Category: Standards Track M. Mealling
Network Solutions, Inc.
August 1999
MIME Object Definitions for the Common Indexing Protocol (CIP)
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
The Common Indexing Protocol (CIP) is used to pass indexing information from server to server in order to facilitate query routing. The protocol is comprised of several MIME objects being passed from server to server. This document describes the definitions of those objects as well as the methods and requirements needed to define a new index type.
一般的なインデックスプロトコル（CIP）は、クエリのルーティングを容易にするためにサーバにサーバからインデックス情報を渡すために使用されます。プロトコルは、サーバからサーバに渡されるいくつかのMIMEオブジェクトで構成されています。この文書では、これらのオブジェクトの定義だけでなく、新しいインデックス・タイプを定義するために必要なメソッドと要件について説明します。
The Common Indexing Protocol (CIP) is used to pass indexes between servers that combine multiple indexes and/or route queries based on those indexes. The overall framework for the protocol is specified in the CIP Framework document [FRAMEWORK]. This document should be read within the context of that document as there are fundamental concepts contained in the framework that are not fully explained here.
一般的なインデックスプロトコル（CIP）は、これらの指標に基づいて複数のインデックスおよび/またはルートクエリを組み合わせたサーバー間でインデックスを渡すために使用されます。プロトコルの全体的な枠組みは、CIPフレームワークドキュメント[FRAMEWORK]で指定されています。完全にはここで説明されていないフレームワークに含まれる基本的な概念があるとして、この文書は、その文書の文脈の中で読まれるべきです。
Since there are several different ways to index a given database there will be multiple types of indexes to pass. These indexes may have different transport requirements, different ways of specifying parameters, and different referral rules. These different requirements are handled by encapsulating the indexes within MIME wrappers in order to have a standardized way to specify those different parameters.
インデックスには、いくつかの異なる方法があるので、与えられたデータベースが通過するインデックスの複数のタイプが存在することになります。これらのインデックスは、異なるトランスポート要件、パラメータを指定するさまざまな方法、およびさまざまな紹介のルールを有することができます。これらの異なる要件は、これらの異なるパラメータを指定するための標準化された方法を持っているために、MIMEラッパー内のインデックスをカプセル化することによって処理されます。
Appendix A contains the actual MIME [RFC2046] registration templates sent to the IANA for registration [RFC2048].
付録Aは、登録[RFC2048]のためにIANAに送られた実際のMIME [RFC2046]登録テンプレートが含まれています。
This document uses language like SHOULD and SHALL that have special meaning as specified in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
この文書では、SHOULDのような言語を使用し、「要件レベルを示すためにRFCsにおける使用のためのキーワード」[RFC2119]で指定された特別な意味を持つものとします。
Messages passed by CIP implementations over reliable transport mechanisms fall into three categories: requests, responses and results. All requests result in either a response or a result. A result sent in response to a request must be interpreted as a successful operation.
要求、応答および結果：信頼性の高いトランスポート・メカニズムを介してCIPの実装によって渡されたメッセージは、次の3つのカテゴリに分類されます。すべての要求は応答または結果のいずれかにつながります。要求に応答して送信された結果は、成功した操作として解釈されなければなりません。
Requests, responses and results are formatted as MIME [RFC2046] messages. The specific MIME types involved are defined below.
要求、応答及び結果はMIME [RFC2046]のメッセージとしてフォーマットされています。関与する特定のMIMEタイプは、以下に定義されています。
As with all MIME objects, CIP messages may be wrapped in a security multipart package to provide authentication and privacy. The security policy with respect to all messages is implementation defined, when not explicitly discussed below. CIP implementors are strongly urged to allow server administrators maximum configurability to secure their servers against maliciously sent anonymous CIP messages. In general, operations which can permanently change the server's state in a harmful way should only take place upon receipt of a properly signed message from a trusted CIP peer or administrator. Implementors should provide appropriate auditing capabilities so that both successful and failed requests can be tracked by the server administrator.
すべてのMIMEオブジェクトと同様に、CIPメッセージは、認証とプライバシーを提供するために、セキュリティマルチパートパッケージに包まれていてもよいです。明示的に、以下に説明しない場合は、すべてのメッセージに関して、セキュリティポリシーは、定義された実装です。 CIP実装は強く悪意を持って送信された匿名のCIPメッセージに対して自分のサーバーを確保するために、サーバーの管理者に最大限の構成可能性を許可するように促しています。一般的には、恒久的に有害な方法でサーバの状態を変更できる操作は、信頼できるCIPピアまたは管理者から適切に署名されたメッセージの受信時に行われるべきです。成功と失敗の両方の要求は、サーバー管理者が追跡できるように実装者は、適切な監査機能を提供する必要があります。
Since these MIME objects can and will be sent over several different protocols, body termination is specified by the transfer protocol. New protocols are encouraged to use SMTP [RFC821] style body termination.
これらのMIMEオブジェクトは、いくつかの異なるプロトコルを介して送信することができるので、本体終端は転送プロトコルにより指定されます。新しいプロトコルはSMTP [RFC821]スタイルのボディ終端を使用することをお勧めします。
Finally, since MIME objects can specify their own encoding, the line-breaks contained within each body are defined by the encoding. Thus, instead of specifying them as carriage-return and/or linefeed, the identifier <linebreak> is used. Linebreaks in the headers and separating the body from the headers follow existing standards.
MIMEオブジェクトは、独自のエンコーディングを指定することができるので、最終的に、各本体内に含まれる改行を符号化することによって定義されます。したがって、代わりにキャリッジ・リターンおよび/または改行、識別子<改行>としてそれらを指定するために使用されます。ヘッダー内の改行とヘッダから体を分離するには、既存の規格に従ってください。
There are certain syntactic elements common to all of the CIP transactions. These include type, DSI and the Base-URI.
CIP取引の全てに共通する特定の構文要素があります。これらは、タイプ、DSIとベースURIを含みます。
Due to requirements in RFC2048 concerning objects that have the same type but different syntaxes, CIP objects will use the application/index tree but include "facets" [RFC2048] which extend it as other types have done with respect to global elements and vendor specific enhancements. Thus the tree is divided up into the following branches:
同じタイプであるが異なる構文を持つオブジェクトに関するRFC2048の要求に、CIPオブジェクトは、アプリケーション/インデックスツリーを使用するが、他のタイプとして、それを延ばす「ファセット」[RFC2048]を含むであろうグローバル要素およびベンダ固有の拡張に対して行っています。したがって、ツリーは、次の枝に分割されています。
application/index.cmd._command_ application/index.response application/index.obj._type_ application/index.vnd._xxx_
アプリケーション/ index.cmd._command_アプリケーション/ index.responseアプリケーション/ index.obj._type_アプリケーション/ index.vnd._xxx_
_command_ is a command as specified here. It contains commands and their arguments.
ここで指定されているよう_command_はコマンドです。これは、コマンドとその引数が含まれています。
_type_ identifies what type of CIP index object is contained within the body. It is unique among all other reserved types. Reserved types are those previously documented by other CIP index object specifications, according to standard IETF processes.
_type_は本体内に収容されているCIPインデックスオブジェクトの種類を識別する。これは、他のすべての予約済みのタイプの中でユニークです。予約タイプは、標準的なIETFプロセスによれば、以前に他のCIPインデックスオブジェクト仕様で文書化されるものです。
_xxx_ is an identifier specified by a vendor for use by that vendor in operations specifically to do with indexes.
_xxx_は、具体的には、インデックスと関係する操作でそのベンダーが使用するためのベンダによって指定された識別子です。
All of the above identifiers follow the rules in RFC2048 for valid MIME types. In addition commands, responses and types are limited by this document to consist of from 1 to 20 characters from the set [a-zA-Z0-9-]; that is, all upper and lower case letters, all digits, and the ASCII minus character (decimal 45). Though type names may be specified case sensitively, they must be compared and otherwise processed case insensitively.
上記の識別子のすべてが有効なMIMEタイプのためのRFC2048の規則に従ってください。またコマンドで、応答およびタイプは、セットから1〜20文字で構成する場合は、この文書によって制限される[-ZA-Z0-9-]。それは、すべて大文字と小文字、すべての数字、およびASCIIのマイナス文字（45進）です。タイプ名は敏感ケースを指定することができますが、彼らは比較し、それ以外の場合は小文字を区別せずにケースを処理する必要があります。
Appendix A contains the registration template for the application/index tree.
付録Aには、アプリケーション/インデックスツリーの登録テンプレートが含まれています。
A dataset identifier is an identifier chosen from any part of the ISO/CCITT OID space. The DSI uniquely identifies a given dataset among all datasets indexed by CIP.
データセット識別子は、ISO / CCITT OID空間の任意の部分から選択された識別子です。 DSIは、一意CIPによってインデックス付けすべてのデータセットのうち、指定されたデータセットを識別する。
As currently defined, OID's are an unbounded sequence of unbounded integers. While this creates an infinite numbering space, it presents problems for implementors dealing with machines with finite resources. To ease implementation, this document specifies an ASCII encoding of the OID, and specifies limits which make implementation easier.
現在定義されているように、OIDのは、無限の整数の無限のシーケンスです。これは無限のナンバリングスペースを作成しますが、それは有限な資源を持つマシンを扱う実装のために問題を提起します。実装を容易にするために、このドキュメントは、OIDのASCIIエンコーディングを指定し、実装を容易に制限を指定します。
For the purposes of interchange in CIP messages, an OID must conform to the following rules:
CIPメッセージで交流の目的のために、OIDは、次の規則に従わなければなりません。
dsi = integer *( "." integer) integer = all-digits / (one-to-nine *all-digits) one-to-nine = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" all-digits = "0" / one-to-nine
DSI =整数*（ "" の整数）の整数=全桁/（1対9 *全桁）1対9 = "1" / "2" / "3" / "4" / " 5" / "6" / "7" / "8" / "9" 全桁= "0" / 1対9
Under no circumstances shall the total length of the resulting string exceed 255 characters. OID's which cannot, due to their length, conform to these rules must not be used as CIP dataset identifiers.
いかなる状況下では、結果の文字列の長さの合計が255文字を超えてはなりません。 OIDの、それらの長さに、これらの規則に準拠することができないがCIPデータセット識別子として使用することはできません。
An implementation must not attempt to parse the individual integers unless it is prepared to handle arbitrary-length integers. Treating the DSI as anything other than an opaque string of US-ASCII characters is not recommended.
実装は、任意の長さの整数を処理する用意がある場合を除き、個々の整数を解析しようとしない必要があります。 US-ASCII文字の不透明な文字列以外のものとして、DSIを処理することは推奨されません。
Two CIP DSI's are considered to match if both conform to the above rules and every number matches.
二CIP DSIのは、両方のは、上記の規則に準拠し、すべての番号が一致した場合に一致すると考えられています。
CIP index objects carry base-URI's to facilitate referral generation based on the index object. The base-URI parameter carries a whitespace-delimited list of URL's. URL's are defined in RFC-1738. The exact rules are as follows:
CIPインデックスオブジェクトは、インデックスオブジェクトに基づいて紹介生成を容易にするために、ベースURIのを運びます。ベースURIパラメータは、URLのの空白区切りのリストを運びます。 URLのは、RFC-1738で定義されています。次のように厳密なルールは以下のとおりです。
base-uri = genericurl *( 1*whitespace genericurl ) whitespace = "<space>" (decimal 32) / "<tab>" (decimal 9) / "<cr>" (decimal 13) / "<lf>" (decimal 10) genericurl = { as specified in RFC-1738, section 5 }
ベースURI = genericurl *（1 *空白genericurl）空白= "<スペース>"（10進32）/ "<タブ>"（10進9）/ "<CR>"（10進13）/ "<LF>"（小数10）genericurl = {RFC-1738で指定されるように、セクション5}
All requests must be followed by a response code, except in the cases where a return path is unavailable.
すべての要求はリターンパスが利用できない場合を除いて、応答コードが続かなければなりません。
The definition for this MIME type is:
このMIMEタイプの定義は次のとおりです。
MIME type name: application MIME subtype name: index.response Required parameters: code Optional parameters: charset Security considerations: (See Section 4)
MIMEタイプ名：アプリケーションMIMEサブタイプ名：index.response必須パラメーター：コードオプションのパラメータ：文字セットセキュリティに関する注意事項：（第4章を参照してください）
The code parameter contains a 3 digit return code that denotes the status of the last command.
コードのパラメータは、最後のコマンドのステータスを表す3桁のリターン・コードが含まれています。
The format of the body is such that the first line is interpreted as the comment corresponding to the code. As with most response codes this comment is intended for human consumption and may not exist and must not be depended on by the protocol. Subsequent lines in the body are reserved for each response to define. In the case where the comment is not given the first must be an empty line.
本体のフォーマットは、最初の行は、コードに対応するコメントとして解釈されるようなものです。ほとんどの応答コードと同じように、このコメントは、人間の消費のために意図されており、存在しない可能性があり、プロトコルが依存してはいけません。本体内の後続の行を定義するために、各応答のために予約されています。コメントは、最初に与えられていない場合には空白行でなければなりません。
body = comment linebreak payload comment = { any text } linebreak = (decimal 13) (decimal 10) payload = { any text }
本体=コメント改行ペイロードコメント= {テキスト}改行=（小数13）（小数点以下10）ペイロード= {テキスト}
The charset parameter has its normal MIME meaning. Below are several examples:
charsetパラメータは、通常のMIMEの意味を持ちます。以下にいくつかの例は以下のとおりです。
[begin MIME] Content-type: application/index.response; code=220
コンテンツタイプ[MIME開始]：アプリケーション/ index.responseを。コード= 220
CIP Server v1.0 ready!<linebreak> [end MIME]
CIPサーバーv1.0の準備を！<改行> [エンドMIME]
[begin MIME] Content-type: application/index.response; code=500
コンテンツタイプ[MIME開始]：アプリケーション/ index.responseを。コード= 500
MIME formatting problem<linebreak> [end MIME]
MIME形式の問題<改行> [エンドMIME]
[begin MIME] Content-type: application/index.response; code=520
コンテンツタイプ[MIME開始]：アプリケーション/ index.responseを。コード= 520
<linebreak> [end MIME]
<改行> [エンドMIME]
While the responses described in this document do not utilize the rest of the lines in the body of a response implementors should take care to not disallow it in the future. A good example would be a message specifying that a poll request did not contain required attributes. This message might look like this:
この文書で説明応答は、応答の実装者の身体の行の残りの部分を利用していないものの、将来的にそれを禁止しないように注意する必要があります。良い例は、ポーリング要求は、必要な属性が含まれていないことを指定して、メッセージになります。このメッセージは、次のようになります。
[begin MIME] Content-type: application/index.response; code=502
コンテンツタイプ[MIME開始]：アプリケーション/ index.responseを。コード= 502
Request is missing required CIP attributes Missing-Attribute: attribute1 Missing-Attribute: attribute2 Missing-Attribute: attribute3 [end MIME]
リクエストが必要に不足しているCIP属性欠落-属性：欠落-属性ATTRIBUTE1：attribute2の欠落-属性：attribute3 [エンドMIME]
The meaning of the various digits in the response codes is discussed in RFC-821, Appendix E.
応答コード内の様々な数字の意味は、RFC-821、付録Eに記載されています
See Appendix B for a list of the valid response codes.
有効な応答コードのリストについては、付録Bを参照してください。
A CIP command either initiates an index transfer, interrogates the state of the receiver-CIP (or the server's participation in the mesh), or changes the state of the server (or the server's place in the mesh).
CIPコマンドは、インデックス転送を開始レシーバ-CIP（またはメッシュ内のサーバーの参加）の状態を問い合わせ、またはサーバ（またはメッシュ内のサーバの場所）の状態を変化させるのいずれか。
CIP commands are sent as a MIME message of type "application/index.cmd._command_". The definition for this MIME type tree follows:
CIPコマンドは、タイプ「アプリケーション/ index.cmd._command_」のMIMEメッセージとして送信されます。このMIMEタイプ・ツリーの定義は次のとおりです。
MIME type name: application MIME subtype name: index.cmd._command_ Optional parameters: type, dsi Security considerations: (See Section 4)
MIMEタイプ名：application MIMEサブタイプ名：タイプ、DSIセキュリティに関する注意事項：オプションのパラメータindex.cmd._command_（第4章を参照してください）
The format of the body is defined by each command. A general attribute/value pair orientation is preserved throughout the following specified commands. Those developing future command should attempt to maintain that orientation but are not required to do so.
本体のフォーマットは、各コマンドによって定義されます。一般的な属性/値のペアの向きは、以下の指定されたコマンド全体で保存されています。これらの開発の将来のコマンドは、その方向性を維持しようとすべきであるが、その必要はありません。
In the following sections, the server's response for each possible value for "command" is defined. Note that the parameters listed as optional above are only optional with respect to the generic MIME form. The optional parameters are only optional with respect to MIME parsing. If one or more of the parameters needed to fulfill a command is missing, a response code of 502 is returned.
次のセクションでは、「コマンド」の各値に対するサーバーの応答が定義されています。オプションとしてリストされたパラメータは、上記の一般的なMIME形式に対してのみオプションであることに留意されたいです。オプションのパラメータは、MIME解析に対してのみオプションです。コマンドを満たすために必要なパラメータの1つ以上が欠落している場合、502のレスポンスコードが返されます。
Extra optional parameters which are unrecognized must be silently ignored.
認識されていない余分なオプションのパラメータは黙って無視されなければなりません。
Command Name: application/index.cmd.noop
Required parameters: (none)
A CIP command with the "command" parameter set to "noop" must be acknowledged with response type code 200 (command OK, no response forthcoming).
「NOOP」に設定「コマンド」パラメータとCIPコマンドは、応答タイプコード200（コマンドOK、今後の無応答）で確認する必要があります。
This command must not require a signed MIME object. Implementations should accept commands which have been validly signed.
このコマンドは、署名されたMIMEオブジェクトを要求することはできません。実装は、有効に署名されたコマンドを受け入れる必要があります。
Example:
例：
[begin MIME] Content-type: application/index.cmd.noop
コンテンツタイプ[MIME開始]：アプリケーション/ index.cmd.noopを
[end MIME]
【端MIME]
Note the lack of a body but how the <linebreak> pair is still preserved after the Content-type header.
体の欠如を注意したが、<改行>ペアはまだContent-Typeヘッダの後に保存されていますか。
Request Name: application/index.cmd.poll
Required parameters: type, dsi
The "poll" command is used by a poller to request the transfer of an index object. It requires the following parameters:
「ポーリング」コマンドは、インデックスオブジェクトの転送を要求するためにポーラーによって使用されます。それは、次のパラメータが必要です。
type: The index object type requested dsi: The dataset which the index should cover
タイプ：DSIを要求されたインデックスオブジェクトの型：インデックスがカバーすべきデータセット
If there are no index objects available for a given DSI, or the receiver-CIP does not support a given index object type, the receiver-CIP must respond with response code 200, (successful, no response forthcoming). Otherwise, the response code must be 201 (successful, response is forthcoming).
与えられたDSIのために利用可能なインデックスオブジェクト、または受信機 - CIPが存在しない場合は指定されたインデックスのオブジェクト・タイプをサポートしていない、受信機-CIPは、応答コード200、（今後の成功、無応答）で応答する必要があります。そうでなければ、応答コードが201である必要があります（成功し、応答が迫っています）。
The security policy for polling commands is wholly implementation defined. Implementations may be configured to accept or reject anonymous poll commands.
ポーリングコマンドのセキュリティポリシーは、完全に定義された実装です。実装は匿名のポーリングコマンドを受け入れるか拒否するように構成することができます。
Example:
例：
[begin MIME] Content-type: application/index.cmd.poll; type="simple"; dsi= "1.3.5.7.9"
コンテンツタイプ[MIME開始]：アプリケーション/ index.cmd.pollを。タイプ=「シンプル」。 DSI = "1.3.5.7.9"
Template: contact name address phone<linebreak> Start-time: Fri May 30 14:25:30 EDT 1997<linebreak> End-time: Sat May 31 14:25:30 EDT 1997<linebreak> [end MIME]
テンプレート：連絡先の名前アドレス電話<改行>開始時：金5月30日14時25分30秒EDT 1997 <改行>終了時間：土5月31日14時25分30秒EDT 1997 <改行> [エンドMIME]
Request Name: application/index.cmd.datachanged
Required parameters: type, dsi
The "datachanged" command is used by a pollee to notify a poller that the data within an index has changed. It requires the following parameters:
「datachanged」コマンドは、インデックス内のデータが変更されたポーラーに通知するpolleeによって使用されます。それは、次のパラメータが必要です。
type: The index object type requested dsi: The dataset which the index should cover
タイプ：DSIを要求されたインデックスオブジェクトの型：インデックスがカバーすべきデータセット
If there are no index objects available for a given DSI, or the receiver-CIP does not support a given index object type, the receiver-CIP must respond with response code 200, (successful, no response forthcoming). Otherwise, the response code must be 201 (successful, response is forthcoming).
与えられたDSIのために利用可能なインデックスオブジェクト、または受信機 - CIPが存在しない場合は指定されたインデックスのオブジェクト・タイプをサポートしていない、受信機-CIPは、応答コード200、（今後の成功、無応答）で応答する必要があります。そうでなければ、応答コードが201である必要があります（成功し、応答が迫っています）。
The body of a DataChanged command is formatted as a simple set of attribute value pairs following the rules of RFC822. The actual attributes and values allowed are defined by the index type specification.
DataChangedコマンドの本体は、RFC822のルールを次の属性と値のペアの簡単なセットとしてフォーマットされます。許可され、実際の属性と値は、インデックスタイプ仕様で定義されています。
The security policy for DataChanged commands is wholly implementation defined. Implementations may be configured to accept or reject anonymous DataChanged commands.
DataChangedコマンドのセキュリティポリシーは、完全に実装定義されています。実装は匿名DataChangedコマンドを受け入れるか拒否するように構成することができます。
Example:
例：
[begin MIME] Content-type: application/index.cmd.datachanged; type="simple"; dsi= "1.3.5.7.9"<linebreak>
コンテンツタイプ[MIMEを開始]：アプリケーション/ index.cmd.datachanged。タイプ=「シンプル」。 DSI = "1.3.5.7.9" <改行>
Time-of-latest-change: Fri May 30 14:25:30 EDT 1997<linebreak> Time-of-message-generation: Fri May 30 14:25:30 EDT 1997<linebreak> Host-Name: cip.rwhois.net<linebreak> Host-Port: 4322<linebreak> Protocol: RWhois2.0<linebreak> [end MIME]
時間の-最新の変更：金5月30日14時25分30秒EDT 1997 <改行>時間型メッセージ世代：金5月30日14時25分30秒EDT 1997 <改行>ホスト名：cip.rwhois。ネット<改行>ホスト・ポート：4322 <改行>プロトコル：RWhois2.0 <改行> [エンドMIME]
The requests specified above are those required to implement a simple mesh. It is expected that other requests will be developed to handle issues of mesh-management and statistics gathering requests. At this point this is an area of additional work. Specifically more work is needed in the area of mesh management as meshes will tend to be organized around the characteristics of their index type.
上記の指定された要求は、単純なメッシュを実装するために必要なものがあります。他の要求がメッシュ管理と統計情報の収集要求の問題を処理するために開発されると予想されます。この時点で、これは追加の作業の領域です。メッシュは、インデックス型の特性を中心に組織される傾向があるとして、具体的に、より多くの作業は、メッシュ管理の分野で必要とされます。
In reply to the "poll" command, a server may choose to send one or more index objects. Regardless of the number of index objects returned, the response must take the form of a MIME multipart/mixed message. Each part must itself be a MIME object of type "application/index.obj._type_". The definition for this type follows:
「世論調査」コマンドへの応答では、サーバは、1つまたは複数のインデックスオブジェクトを送信することもできます。インデックスオブジェクトの数が返さ関わらず、応答は、MIMEマルチパート/混合、メッセージの形式を取らなければなりません。各部分は、それ自体は、タイプ「アプリケーション/ index.obj._type_」のMIMEオブジェクトでなければなりません。このタイプの定義は次のとおりです。
MIME type name: application MIME subtype name: index.obj._type_ Required parameters: dsi, base-uri Optional parameters: none Security considerations: (See Section 4)
MIMEタイプ名：アプリケーションMIMEサブタイプ名：index.obj._type_必須パラメータ：DSI、ベースURIオプションのパラメータ：なしセキュリティに関する注意事項：（第4章を参照してください）
As previously described, each index object is of a particular type. This type is specified in the MIME subtype name since some types may have a different syntax.
前述のように、各インデックスオブジェクトは、特定のタイプのものです。いくつかの種類が異なる構文を持っているかもしれないので、このタイプは、MIMEサブタイプ名で指定されています。
The required parameters are to be used as follows:
必要なパラメータは以下のように使用されるべきです。
DSI: The DSI is a string which globally uniquely identifies the dataset from which the index was created.
DSI：DSIは、グローバルに一意のインデックスが作成されたデータセットを識別する文字列です。
base-URI: One or more URI's will form the base of any referrals created based upon this index object.
ベースURI：1つ以上のURIのは、このインデックスオブジェクトに基づいて作成された任意の紹介の基盤を形成します。
Because of the need for application domain specific indices, CIP index objects are abstract; they must be defined by a separate specification. The basic protocols for moving index objects are widely applicable, but the specific design of the index, and the structure of the mesh of servers which pass a particular type of index is dependent on the application domain. While companion documents will describe index objects, there is a set of base requirements and questions those documents must address. This is to ensure that the base assumptions that the CIP protocol makes about its indexes are actually expressible within the index.
そのため、アプリケーションドメイン固有の指標を必要とするため、CIPインデックスオブジェクトは抽象的です。彼らは別の仕様で定義されなければなりません。インデックスオブジェクトを移動するための基本的なプロトコルが広く適用されているが、インデックス、およびインデックスの特定の型を渡すサーバのメッシュ構造の特定の設計は、アプリケーションドメインに依存しています。コンパニオンの文書がインデックスオブジェクトを記述しますが、基本要件およびそれらの文書が対処しなければならない一連の質問があります。これは、CIPプロトコルはそのインデックスについて作る基本仮定は、実際に、インデックス内で表現可能であることを保証することです。
Since each type is a MIME type all its own, registration of new types follows the standard registration policies specified in RFC2048.
各タイプは、すべて独自のMIMEタイプですので、新しいタイプの登録は、RFC2048で規定された標準の登録ポリシーに従います。
Any index type definition must address the type specific bodies of the Poll and DataChanged requests. All parameters included in the body must be specified.
任意のインデックスタイプの定義は、ポーリングとDataChanged要求の種類の特定の体に取り組まなければなりません。体内に含まれるすべてのパラメータを指定する必要があります。
See the above definitions for allowed values for type.
タイプに使用できる値については、上記の定義を参照してください。
A new name must be assigned when any changes to the document describing the index object type are not completely backwards compatible.
インデックスオブジェクトのタイプを記述するドキュメントへの変更が完全に後方互換性がない場合、新しい名前が割り当てられなければなりません。
Another attribute is the "DSI", or Dataset Identifier, which uniquely identifies the dataset from which the index was created. The index specification should define the policies for how the DSI is generated. This includes the concept of what a data-set means for the given index.
別の属性は、一意のインデックスが作成されたデータセットを識別する「DSI」、またはデータセット識別子です。インデックスの仕様では、DSIを生成する方法のポリシーを定義する必要があります。これは、データ・セットが指定されたインデックスのために何を意味するのかの概念を含んでいます。
An attribute of the index object which is crucial for generating referrals is the "Base-URI". The URI (or URI's) contained in this attribute form the basis of any referrals generated based on this index block. The URI is also used as input during the index aggregation process to constrain the possible types of aggregation. This use of the Base-URI is used to deal with meshes that support multiple protocols.
リフェラルを発生させるために重要であるインデックスオブジェクトの属性は、「ベース-URI」です。この属性に含まれるURI（またはURIの）は、このインデックス・ブロックに基づいて生成された照会の基礎を形成します。 URIはまた、凝集の可能なタイプを制約するインデックス凝集プロセス中に入力として使用されます。ベース-URIの使用は、複数のプロトコルをサポートするメッシュに対処するために使用されます。
Thus, an index specification should define how the Base-URI applies to the underlying index and how it is changed during the aggregation process.
したがって、インデックス指定は、ベースURIは、基礎となるインデックスに適用され、どのようにそれが凝集工程中に変更される方法を定義しなければなりません。
All index object specifications must address the issue of aggregation. This is the method by which an index server takes two or more indexes and combines them into one index to be passed on. It is not required that a given index-type aggregate. If it does not it must explicitly address the reasons why and what affect that has on scalability.
すべてのインデックスオブジェクトの仕様は、凝集の問題に対処しなければなりません。これは、インデックスサーバーに2つの以上のインデックスを取り、渡される1つのインデックスにそれらを組み合わせた方法です。これは、指定されたインデックス型集約することを必要とされていません。そうでない場合には、明示的に、どのようなことがスケーラビリティに持っている影響を与える理由に対処しなければなりません。
If a given index does aggregate, the algorithm for that aggregation must be given. It must also address how that algorithm affects mesh organization and scalability.
指定されたインデックスが集約している場合、その集約のためのアルゴリズムが与えられなければなりません。また、そのアルゴリズムは、メッシュ組織と拡張性をどのように影響するか対処しなければなりません。
Index object document authors should remember that any kind of aggregation should be performed without compromising the ability to correctly route queries while avoiding excessive numbers of missed results. The acceptable likelihood of false negatives must be established on a per-application-domain basis, and is controlled by the granularity of the index and the aggregation rules defined for it by the particular specification.
インデックス対象文書の作成者は、集計のいずれかの種類が逃した結果の過剰な数を回避しながら能力に正しくルーティングクエリを損なうことなく行われるべきであることを覚えておいてください。偽陰性の許容される可能性は、アプリケーションごとのドメインに基づいて確立されなければならない、特定の仕様で、定義された指標と集約ルールの粒度によって制御されます。
Nothing in these documents specifically disallows aggregation rules that deal with different index object types. This type of heterogeneous mesh is difficult to formulate at best and thus is not covered by these documents. If document authors wish to attempt such a mesh they should be aware that it is considered an ill understood concept that contains many pitfalls for the mesh builder.
これらの文書には何も特に異なるインデックスオブジェクトタイプを扱う集計ルールを禁止していません。異種メッシュのこのタイプは、最高の状態で、したがって、これらの文書でカバーされていません策定することは困難です。文書の作成者は、このようなメッシュを試みたい場合、彼らはそれがメッシュビルダーのための多くの落とし穴が含まれている病気の理解概念と考えられていることに注意する必要があります。
Since the method by which a client navigates the mesh is by referrals, the document must address how a given access protocol generates a referral from the index. Authors should pay particular attention to the case where an index is accessed by different protocols and the interaction between them. For example, an index that supports referrals being generated for both RWhois and LDAP must understand that one uses a Distinguished Name while the other doesn't. The impacts of these differences on the referral should be clear.
クライアントは、メッシュをナビゲートする方法を紹介することですので、文書が与えられたアクセスプロトコルがインデックスからの紹介を生成する方法に対処しなければなりません。著者は、インデックスが異なるプロトコルおよびそれらの間の相互作用によってアクセスされた場合には特に注意を払う必要があります。例えば、RWhoisおよびLDAPの両方のために生成された照会をサポートインデックスが他にはないながら1は、識別名を使用していることを理解する必要があります。紹介にこれらの違いの影響は明らかです。
In order to generate a referral the decision of whether or not to do so must be handled by the access protocol. The semantics surrounding this decision have a large impact on the efficiency of searches as well as the requirements on aggregation. Thus, index specification authors must be very clear about how a match is determined.
紹介を生成するためにそうするか否かの決定は、アクセスプロトコルによって扱われなければなりません。この決定を取り巻くセマンティクスは、検索の効率に大きく影響だけでなく、集計上の要件を持っています。このように、インデックス仕様の作者は試合がどのように決定されるかについて非常に明確でなければなりません。
As is customary with Internet protocol documentation, a brief review of security implications of the proposed object must be included. This section may need to do little more than echo the considerations expressed in this document's Security Considerations section.
インターネットプロトコルドキュメントと通例であるとして、提案オブジェクトのセキュリティへの影響の簡単なレビューが含まれている必要があります。このセクションでは、このドキュメントのSecurity Considerations部で表現配慮をエコーより少しを行う必要があります。
Because indexing algorithms, stop-lists, and data reduction technologies are considered by some index object designers to be proprietary, it is not necessary to discuss the process used to derive indexing information from a body of source material. When proprietary indexing technologies are used in a public mesh, all CIP servers in the mesh should be able to parse the index object (and perform aggregation operations, if necessary), though not all of them need to be able to create these proprietary indices from source data.
インデックスアルゴリズム、ストップリスト、およびデータ削減技術は、独自のように、いくつかのインデックスオブジェクトの設計者によって考慮されているので、原料の本体からインデックス情報を導出するために使用されるプロセスを議論する必要はありません。独自のインデックス技術は、公共のメッシュに使用されている場合には、メッシュ内のすべてのCIPサーバは、それらのすべてではないがするから、これらの独自のインデックスを作成できるようにする必要があり、（必要に応じて、および集計操作を実行する）インデックスオブジェクトを解析することができるはずですソースデータ。
Thus, index object designers may choose to remain silent on the algorithms used for the generation of indices, as long as they adequately document how to participate in a mesh of servers passing these proprietary indices.
このように、インデックスオブジェクトの設計者は、限り、彼らは十分にこれらの独自の指標を渡すサーバのメッシュに参加する方法を文書として、インデックスの生成に使用されるアルゴリズムに沈黙することもできます。
Designers should also seriously consider including useful examples of source data, the generated index, and the expected results from example matches. When the aggregation algorithm is complex, it is recommended that a table showing two indices and the resultant aggregate index be included.
また、設計者は真剣例からソースデータの有用な例、生成されたインデックス、および期待される結果を含めて一致して検討すべきです。集約アルゴリズムが複雑である場合、2つのインデックスと、得られた凝集率を示す表が含まれることが推奨されます。
Security considerations come into play in at least the following two scenarios. Indexing information can leak undesirable amounts of proprietary information, unless carefully controlled. At a more fundamental level, the CIP protocol itself requires external security services to operate in a safe manner. Both topics are covered below.
セキュリティの考慮事項は、少なくとも以下の2つのシナリオで遊びに来ます。慎重に制御しない限り、インデックス情報は、専有情報の望ましくない量をリークすることができます。より基本的なレベルでは、CIPプロトコル自体は安全な方法で動作するように外部のセキュリティサービスを必要とします。どちらのトピックについて説明しています。
CIP is designed to index all kinds of data. Some of this data might be considered valuable, proprietary, or even highly sensitive by the data maintainer. Take, for example, a human resources database. Certain bits of data, in moderation, can be very helpful for a company to make public. However, the database in its entirety is a very valuable asset, which the company must protect. Much experience has been gained in the directory service community over the years as to how best to walk this fine line between completely revealing the database and making useful pieces of it available.
CIPは、インデックスデータのすべての種類に設計されています。このデータの一部は、貴重なプロプライエタリ、またはデータのメンテナによっても、機密性の高いと考えられるかもしれません。例えば、人事データベースを取ります。データの特定のビットは、ほどほどに、公共作るために、会社のために非常に役立ちます。しかし、その全体のデータベースは、同社が保護しなければならない非常に貴重な資産です。多くの経験は完全にデータベースを明らかにし、それの有益な部分を利用可能にする間、この微妙な境界線を歩くする最善の方法に関して、長年にわたって、ディレクトリサービスのコミュニティで得られています。
Another example where security becomes a problem is for a data publisher who would like to participate in a CIP mesh. The data that publisher creates and manages is the prime asset of the company. There is a financial incentive to participate in a CIP mesh, since exporting indices of the data will make it more likely that people will search your database. (Making profit off of the search activity is left as an exercise to the entrepreneur.) Once again, the index must be designed carefully to protect the database while providing a useful synopsis of the data.
セキュリティが問題となるもう一つの例は、CIPメッシュに参加したいデータの出版社のためです。出版社が作成して管理するデータは、同社の主要な資産です。データのエクスポート指標は、人々が自分のデータベースを検索れやすくなりますので、CIPメッシュに参加する金融インセンティブが、あります。 （検索活動のオフ作る利益は起業家への課題として残されている。）もう一度、インデックスは、データの便利な概要を提供しながら、データベースを保護するために慎重に設計する必要があります。
One of the basic premises of CIP is that data providers will be willing to provide indices of their data to peer indexing servers. Unless they are carefully constructed, these indices could constitute a threat to the security of the database. Thus, security of the data must be a prime consideration when developing a new index object type. The risk of reverse engineering a database based only on the index exported from it must be kept to a level consistent with the value of the data and the need for fine-grained indexing.
CIPの基本的な前提の一つは、データプロバイダは、インデックスサーバをピアに自分のデータのインデックスを提供することをいとわないだろうということです。彼らは慎重に構築されていない限り、これらのインデックスは、データベースのセキュリティに対する脅威を構成することができます。新しいインデックスオブジェクトタイプを開発する際にこのように、データのセキュリティはプライム考慮しなければなりません。リバースエンジニアリングのリスクはそれだけからエクスポートされたインデックスに基づいて、データベースは、データの値とファイングレインインデックスの必要性と一貫性のレベルに維持されなければなりません。
Since CIP is encoded as MIME objects, MIME security solutions should be used whenever possible. Specifically when dealing with security between index servers.
CIPは、MIMEオブジェクトとして符号化されるので、MIMEセキュリティソリューションは、可能な限り使用すべきです。具体的にインデックスサーバー間のセキュリティを扱うとき。
CIP protocol exchanges, taking the form of MIME messages, can be secured using any technology available for securing MIME objects. In particular, use of RFC-1847's Security Multiparts are recommended. A solid application of RFC-1847 using widely available encryption software is PGP/MIME, RFC-2016. Implementors are encouraged to support PGP/MIME, as it is the first viable application of the MIME Security Multiparts architecture. As other technologies become available, they may be incorporated into the CIP mesh.
MIMEメッセージの形態をとるCIPプロトコル交換は、MIMEオブジェクトを確保するための利用可能な任意の技術を使用して固定することができます。具体的には、RFC-1847のセキュリティマルチパートの使用が推奨されています。広く利用可能な暗号化ソフトウェアを使用して、RFC-1847の固体アプリケーションは、PGP / MIME、RFC-2016です。それはMIMEマルチパートセキュリティアーキテクチャの最初の実行可能なアプリケーションであるとして実装者は、PGP / MIMEをサポートすることをお勧めします。他の技術が利用できるようになると、彼らはCIPメッシュに組み込むことができます。
If an incoming request does not have a valid signature, it must be considered anonymous for the purposes of access control. Servers may choose to allow certain requests from anonymous peers, especially when the request cannot cause permanent damage to the local server. In particular, answering anonymous poll requests encourages index builders to poll a server, making the server's resources better known.
着信要求が有効な署名がない場合は、アクセス制御の目的のために匿名考慮されなければなりません。サーバは、要求がローカルサーバーに永続的な損傷を与えることができない場合は特に、匿名のピアからの特定の要求を許可することもできます。具体的には、匿名のポーリング要求に答えることはよく知られているサーバーのリソースを作り、サーバーをポーリングするために、インデックスビルダーを奨励しています。
The explicit security policy with respect to incoming requests is outside the scope of this specification. Implementors are free to accept or reject any request based on the security attributes of the incoming message. When a request is rejected due to authentication reasons, a response code from the 530 series must be issued.
着信要求に対する明示的なセキュリティポリシーは、本明細書の範囲外です。実装者は、着信メッセージのセキュリティ属性に基づいて、すべての要求を受け入れるか拒否するのは自由です。要求が原因認証の理由に拒否された場合、530シリーズからの応答コードを発行する必要があります。
Acknowledgments
謝辞
Thanks to the many helpful members of the FIND working group for discussions leading to this specification.
この仕様につながる議論のためのFINDワーキンググループの多くの有用なメンバーに感謝します。
Specific acknowledgment is given to Jeff Allen formerly of Bunyip Information Systems. His original version of these documents helped enormously in crystallizing the debate and consensus. Most of the actual text in this document was originally authored by Jeff.
具体的な確認は、以前バニップ情報システムのジェフ・アレンに与えられています。これらの文書の彼の元のバージョンは、議論とコンセンサスを結晶化に非常に役立ちました。この文書の実際のテキストのほとんどは、もともとジェフによって作成されました。
Authors' Addresses
著者のアドレス
Jeff R. Allen 246 Hawthorne St. Palo Alto, CA 94301
ジェフ・R.アレン246ホーソーンセントパロアルト、CA 94301
EMail: jeff.allen@acm.org
メールアドレス：jeff.allen@acm.org
Michael Mealling Network Solutions, Inc. 505 Huntmar Park Drive Herndon, VA 22070
マイケル・メオーリングネットワークソリューション株式会社505 Huntmarパークドライブハーンドン、VA 22070
Phone: +1-703-742-0400 EMail: michael.mealling@RWhois.net
電話：+ 1-703-742-0400 Eメール：michael.mealling@RWhois.net
References
リファレンス
[FRAMEWORK] Allen, J. and M. Mealling, "The Architecture of the Common Indexing Protocol (CIP)", RFC 2651, August 1999.
【FRAMEWORK]アレン、J.とM. Mealling、RFC 2651、1999年8月 "共通インデックスプロトコル（CIP）のアーキテクチャ"。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, January 1996.
[RFC2046]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年1月。
[RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: MIME Registration Procedures", RFC 2048, January 1996.
[RFC2048]解放され、N.、Klensin、J.とJ.ポステル、 "多目的インターネットメール拡張（MIME）第四部：MIMEの登録手順"、RFC 2048、1996年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1992.
[RFC821]ポステル、J.、 "簡易メール転送プロトコル"、STD 10、RFC 821、1992年8月。
Appendix A: Media Type Registration Templates
付録A：メディアタイプ登録テンプレート
The following templates have been registered with the IANA:
以下のテンプレートは、IANAに登録されています：
Index tree
インデックスツリー
To: ietf-types@iana.org Subject: Registration of MIME media type tree application/index
To：ietf-types@iana.org件名：MIMEメディアタイプのツリーアプリケーション/インデックスの登録
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: index
MIMEサブタイプ名：インデックス
Required parameters: none
必須パラメータ：なし
Optional parameters: none
オプションのパラメータ：なし
Encoding considerations: none
エンコードの考慮事項：なし
Security considerations:
セキュリティの考慮事項：
Security considerations come into play in at least the following two scenarios. Indexing information can leak undesirable amounts of proprietary information, unless carefully controlled. At a more fundamental level, the CIP protocol itself requires external security services to operate in a safe manner. Both topics are covered below.
セキュリティの考慮事項は、少なくとも以下の2つのシナリオで遊びに来ます。慎重に制御しない限り、インデックス情報は、専有情報の望ましくない量をリークすることができます。より基本的なレベルでは、CIPプロトコル自体は安全な方法で動作するように外部のセキュリティサービスを必要とします。どちらのトピックについて説明しています。
Interoperability considerations:
相互運用性の考慮事項：
Published specification:
公開された仕様：
RFC 2652
RFC 2652
Applications which use this media type:
このメディアタイプを使用するアプリケーション：
This media type is used to contain information about indices and how they inter-operate to form meshes of index servers.
このメディアタイプは、インデックスとそれらがどのようにインデックスサーバのメッシュを形成するために、相互運用に関する情報を格納するために使用されます。
Additional information:
追加情報：
This media type is not a standalone type. It is the top level of a tree similar to the vnd or prs trees specified in Section 2.1 of RFC2048. There are four specified branches to this tree: application/index.cmd application/index.response application/index.obj application/index.vnd
このメディアタイプは、スタンドアロンタイプではありません。これは、RFC2048のセクション2.1で指定さVNDまたはPRS木に似たツリーのトップレベルです。この木に指定した4つの支店があります：アプリケーション/ index.cmdアプリケーション/ index.responseアプリケーション/ index.objアプリケーション/ index.vnd
Each of these branches is a tree in its own right with types registered below them. See those registrations for more information on the types allowed below those branches.
これらの枝のそれぞれは、それらの下に登録されたタイプと、独自の右のツリーです。これらの枝の下に許可されたタイプの詳細については、それらの登録を参照してください。
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
Intended usage: LIMITED USE
意図している用法：限定使用
Author/Change controller:
著者/変更コントローラ：
Command tree
コマンドツリー
To: ietf-types@iana.org Subject: Registration of MIME media type application/index.cmd
To：ietf-types@iana.org件名：MIMEメディアタイプアプリケーションの登録/ index.cmd
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: index.cmd
MIMEサブタイプ名：index.cmd
Required parameters: none
必須パラメータ：なし
Optional parameters: none
オプションのパラメータ：なし
Encoding considerations: none
エンコードの考慮事項：なし
Security considerations:
セキュリティの考慮事項：
Security considerations come into play in at least the following two scenarios. Indexing information can leak undesirable amounts of proprietary information, unless carefully controlled. At a more fundamental level, the CIP protocol itself requires external security services to operate in a safe manner. Both topics are covered below.
セキュリティの考慮事項は、少なくとも以下の2つのシナリオで遊びに来ます。慎重に制御しない限り、インデックス情報は、専有情報の望ましくない量をリークすることができます。より基本的なレベルでは、CIPプロトコル自体は安全な方法で動作するように外部のセキュリティサービスを必要とします。どちらのトピックについて説明しています。
Interoperability considerations:
相互運用性の考慮事項：
Implementors should handle unknown commands gracefully.
実装者は、優雅に、未知のコマンドを処理する必要があります。
Published specification:
公開された仕様：
RFC 2652
RFC 2652
Applications which use this media type:
このメディアタイプを使用するアプリケーション：
This media type is the top of a tree of media types that express commands between hosts that exchange indices for the purpose of routing referrals.
このメディアタイプは、ルーティング紹介の目的のためにインデックスを交換するホスト間でコマンドを表現するメディアタイプのツリーのトップです。
Additional information:
追加情報：
This media type is not a standalone type. It is the top of a tree similar to the vnd and prs trees specified in Section 2.1 of RFC2048. Types registered within this tree are limited to being commands as specified in the document(s) referenced in the "Published specifications" section.
このメディアタイプは、スタンドアロンタイプではありません。これは、RFC2048のセクション2.1で指定さVNDとPRSの木に似たツリーの最上位です。このツリー内に登録タイプは「公開された仕様書」セクションで参照文書（S）で指定されたコマンドに限定されています。
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
Intended usage: LIMITED USE
意図している用法：限定使用
Author/Change controller:
著者/変更コントローラ：
Response tree
レスポンスツリー
To: ietf-types@iana.org Subject: Registration of MIME media type application/index.response
To：ietf-types@iana.org件名：MIMEメディアタイプapplication / index.responseの登録
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: index.response
MIMEサブタイプ名：index.response
Required parameters: code
必須パラメータ：コード
Optional parameters: none
オプションのパラメータ：なし
Encoding considerations: none
エンコードの考慮事項：なし
Security considerations:
セキュリティの考慮事項：
Security considerations come into play in at least the following two scenarios. Indexing information can leak undesirable amounts of proprietary information, unless carefully controlled. At a more fundamental level, the CIP protocol itself requires external security services to operate in a safe manner. Both topics are covered below.
セキュリティの考慮事項は、少なくとも以下の2つのシナリオで遊びに来ます。慎重に制御しない限り、インデックス情報は、専有情報の望ましくない量をリークすることができます。より基本的なレベルでは、CIPプロトコル自体は安全な方法で動作するように外部のセキュリティサービスを必要とします。どちらのトピックについて説明しています。
Interoperability considerations:
相互運用性の考慮事項：
Implementors should handle unknown responses gracefully.
実装者は、優雅に、未知の応答を処理する必要があります。
Published specification:
公開された仕様：
RFC 2652
RFC 2652
Applications which use this media type:
このメディアタイプを使用するアプリケーション：
This media type is used to encode responses to CIP commands passed between hosts that exchange indices for the purpose of routing referrals.
このメディアタイプは、ルーティング紹介の目的のためにインデックスを交換するホストとの間を通過CIPコマンドへの応答を符号化するために使用されます。
Additional information:
追加情報：
This media type _is_ a standalone type. The code parameter contains the specific response code as specified by Appendix B of the specification document.
このメディアタイプは、スタンドアロンタイプを_is_。仕様書の付録Bで指定されたコードのパラメータは、特定の応答コードを含みます。
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
Intended usage: LIMITED USE
意図している用法：限定使用
Author/Change controller:
著者/変更コントローラ：
Index Object tree
インデックスオブジェクトツリー
To: ietf-types@iana.org Subject: Registration of MIME media type application/index.obj
To：ietf-types@iana.org件名：MIMEメディアタイプapplication / index.objの登録
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: index.obj
MIMEサブタイプ名：index.obj
Required parameters: type, dsi, base-uri
必須パラメータ：タイプ、DSI、ベースURI
Optional parameters: none
オプションのパラメータ：なし
Encoding considerations: none
エンコードの考慮事項：なし
Security considerations:
セキュリティの考慮事項：
Security considerations come into play in at least the following two scenarios. Indexing information can leak undesirable amounts of proprietary information, unless carefully controlled. At a more fundamental level, the CIP protocol itself requires external security services to operate in a safe manner. Both topics are covered below.
セキュリティの考慮事項は、少なくとも以下の2つのシナリオで遊びに来ます。慎重に制御しない限り、インデックス情報は、専有情報の望ましくない量をリークすることができます。より基本的なレベルでは、CIPプロトコル自体は安全な方法で動作するように外部のセキュリティサービスを必要とします。どちらのトピックについて説明しています。
Interoperability considerations:
相互運用性の考慮事項：
Implementors should handle unknown index objects according to rules specified in the published specification.
実装者は、公開された仕様で指定されたルールに従って、未知のインデックスオブジェクトを処理する必要があります。
Published specification:
公開された仕様：
RFC 2652
RFC 2652
Applications which use this media type:
このメディアタイプを使用するアプリケーション：
This media type is the top of a tree of media types that express indexes that are exchanged between hosts that operate within a referral mesh.
このメディアタイプは、参照メッシュ内で動作するホストとの間で交換されるインデックスを表現するメディアタイプのツリーのトップです。
Additional information:
追加情報：
This media type is not a standalone type. It is the top of a tree similar to the vnd and prs trees specified in Section 2.1 of RFC2048. Types registered within this tree are limited to being representations of indexes that contain some summary of the data found in some database and is used to generate referrals as specified in the above specified publication.
このメディアタイプは、スタンドアロンタイプではありません。これは、RFC2048のセクション2.1で指定さVNDとPRSの木に似たツリーの最上位です。このツリーに登録タイプは、いくつかのデータベースで見つかったデータのいくつかの要約を含み、上記指定された出版物に指定されている照会を生成するために使用されるインデックスの表現であることに限定されています。
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
Intended usage: LIMITED USE
意図している用法：限定使用
Author/Change controller:
著者/変更コントローラ：
Vendor tree
ベンダーツリー
To: ietf-types@iana.org Subject: Registration of MIME media type application/index.vnd
To：ietf-types@iana.org件名：MIMEメディアタイプapplication / index.vndの登録
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: index.vnd
MIMEサブタイプ名：index.vnd
Required parameters: none
必須パラメータ：なし
Optional parameters: none
オプションのパラメータ：なし
Encoding considerations: none
エンコードの考慮事項：なし
Security considerations:
セキュリティの考慮事項：
Security considerations come into play in at least the following two scenarios. Indexing information can leak undesirable amounts of proprietary information, unless carefully controlled. At a more fundamental level, the CIP protocol itself requires external security services to operate in a safe manner. Both topics are covered below.
セキュリティの考慮事項は、少なくとも以下の2つのシナリオで遊びに来ます。慎重に制御しない限り、インデックス情報は、専有情報の望ましくない量をリークすることができます。より基本的なレベルでは、CIPプロトコル自体は安全な方法で動作するように外部のセキュリティサービスを必要とします。どちらのトピックについて説明しています。
Interoperability considerations:
相互運用性の考慮事項：
Implementors should handle unknown objects gracefully.
実装者は、優雅に、未知のオブジェクトを処理する必要があります。
Published specification:
公開された仕様：
RFC 2652
RFC 2652
Applications which use this media type:
このメディアタイプを使用するアプリケーション：
This media type is the top of a tree of media types that express vendor specific extensions to the framework specified in the published specifications.
このメディアタイプは、公開仕様書で指定されたフレームワークに、ベンダー固有の拡張機能を表現するメディアタイプのツリーの最上位です。
Additional information:
追加情報：
This media type is not a standalone type. It is the top of a tree similar to the vnd and prs trees specified in Section 2.1 of RFC2048. Types registered within this tree are limited to being vendor specific extensions to the CIP framework as specified in the publications. Any registrations within this tree are still limited to dealing with indexes, meshes and referrals.
このメディアタイプは、スタンドアロンタイプではありません。これは、RFC2048のセクション2.1で指定さVNDとPRSの木に似たツリーの最上位です。このツリー内に登録タイプは出版物に指定されているCIPの枠組みにベンダー固有の拡張であることに限定されています。このツリー内の任意の登録がまだのインデックス、メッシュや紹介を扱うに限定されています。
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
Intended usage: LIMITED USE
意図している用法：限定使用
Appendix B: Response Codes
付録B：レスポンスコード
The meaning of the various digits in the response codes is discussed in RFC-821, Appendix E.
応答コード内の様々な数字の意味は、RFC-821、付録Eに記載されています
The following response codes are defined for use by CIPv3 servers. Implementors must use these exact codes; undefined codes should be interpreted by CIP servers as fatal protocol errors. Instead of defining new codes for unforeseen situations, implementors must adapt one of the given codes. The implementation should attach a useful alternative comment to the reused response code.
以下の応答コードはCIPv3サーバで使用するために定義されています。実装者は、これらの正確なコードを使用しなければなりません。未定義のコードは、致命的なプロトコルエラーとしてCIPサーバによって解釈されるべきです。代わりに、不測の事態のために新しいコードを定義する、実装者は、与えられたコードのいずれかを適応させる必要があります。実装は、再利用のレスポンスコードに有用な代替のコメントを添付しなければなりません。
Code Suggested description text
Sender-CIP action
--------------------------------------------------------
220 Initial server banner message
300 Requested CIP version accepted Continue with CIP transaction, in the specified version.
受け入れられた300要求されたCIPのバージョンが指定されたバージョンでは、CIPのトランザクションを続行します。
222 Connection closing (in response to sender-CIP close) Done with transaction.
トランザクションを完了（送信者-CIPの近くに応答して）222の接続を閉じます。
200 MIME request received and processed Expect no output, continue session (or close)
セッション（または近い）を続け、何も出力を期待しない受信され、処理200 MIME要求
201 MIME request received and processed, output follows Read a response, delimited by SMTP-style message delimiter.
201 MIME要求が受信され処理、出力はSMTP形式のメッセージ・デリミタで区切ら応答を読み取る以下。
400 Temporarily unable to process request Retry at a later time. May be used to indicate that the server does not currently have the resources available to accept an index.
400後で再試行要求を処理することが一時的にできません。サーバーが現在のインデックスを受け入れるために利用可能なリソースを持っていないことを示すために使用することができます。
500 Bad MIME message format Retry with correctly formatted MIME request.
500不正なMIMEメッセージ・フォーマットは、正しくフォーマットMIME要求で再試行してください。
501 Unknown or missing request in application/index.cmd Retry with correct CIP command.
アプリケーション内の501不明または不足している要求/ index.cmd正しいCIPコマンドで再試行してください。
502 Request is missing required CIP attributes Retry with correct CIP attributes.
502要求が必要なCIPが正しいCIP属性で再試行属性がありません。
520 Aborting connection for some unexpected reason Retry and/or alert local administrator.
520は、いくつかの予期しない理由の再試行および/または警告ローカル管理者のための接続を中止します。
530 Request requires valid signature Sign the request, if possible, and retry. Otherwise, report problem to the administrator.
530リクエストは、有効な署名が可能な場合は、要求に署名し、再試行が必要です。そうでない場合は、管理者に問題を報告。
531 Request has invalid signature Report problem to the administrator.
531リクエストは、管理者に無効な署名通報を持っています。
532 Cannot check signature Alert local administrator, who should cooperate with remote administrator to diagnose and resolve the problem. (Probably missing a public key.)
532は、問題の診断と解決をリモート管理者と協力すべき署名の警告ローカル管理者を、チェックすることはできません。 （おそらく公開鍵を欠落しています。）
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。