[要約] RFC 2652は、Common Indexing Protocol（CIP）のためのMIMEオブジェクトの定義に関するものです。このRFCの目的は、CIPを使用して電子メールやその他の情報を索引付けするための標準的な方法を提供することです。
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)
共通インデックスプロトコル（CIP）のMIMEオブジェクト定義
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
概要
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フレームワークドキュメント[フレームワーク]で指定されています。ここでは完全には説明されていないフレームワークに含まれる基本的な概念があるため、このドキュメントはそのドキュメントのコンテキスト内で読み取る必要があります。
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には、登録のためにIANAに送信された実際のMIME [RFC2046]登録テンプレート[RFC2048]が含まれています。
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].
このドキュメントでは、「要件レベルを示すためにRFCで使用するためのキーワード」[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オブジェクトは独自のエンコードを指定できるため、各ボディに含まれるラインブレークはエンコードによって定義されます。したがって、それらをキャリッジリターンおよび/またはラインフィードとして指定する代わりに、識別子<linebreak>が使用されます。ヘッダーのラインブレイクとヘッダーから身体を分離することは、既存の標準に従います。
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のルールに従います。さらに、コマンド、応答、およびタイプは、このドキュメントによって制限され、セット[A-ZA-Z0-9-]の1〜20文字で構成されています。つまり、すべての高級文字と小文字、すべての数字、およびASCIIからの文字（10進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
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.
実装は、任意の長さの整数を処理する準備ができていない限り、個々の整数を解析しようとしてはなりません。DSIを、us-asciiキャラクターの不透明な文字列以外のものとして扱うことは推奨されません。
Two CIP DSI's are considered to match if both conform to the above rules and every number matches.
2つの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を運びます。Base-URIパラメーターには、Whitespaceが削除された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 }
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 type name: application MIME subtype name: index.response Required parameters: code Optional parameters: charset Security considerations: (See Section 4)
MIMEタイプ名：アプリケーションMIMEサブタイプ名：index.Response必要なパラメーター：コードオプションパラメーター：charsetセキュリティに関する考慮事項：（セクション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 }
The charset parameter has its normal MIME meaning. Below are several examples:
CharSetパラメーターには、通常のMIMEの意味があります。以下にいくつかの例があります：
[begin MIME]
Content-type: application/index.response; code=220
CIP Server v1.0 ready!<linebreak> [end MIME]
CIPサーバーv1.0準備ができました！<ラインブレイク> [エンドマイム]
[begin MIME]
Content-type: application/index.response; code=500
MIME formatting problem<linebreak> [end MIME]
mimeのフォーマット問題<LineBreak> [エンドマイム]
[begin MIME]
Content-type: application/index.response; code=520
<linebreak> [end MIME]
<LineBreak> [エンドマイム]
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
Request is missing required CIP attributes Missing-Attribute: attribute1 Missing-Attribute: attribute2 Missing-Attribute: attribute3 [end MIME]
リクエストが欠落している必要なcip属性不足アトリブ：属性1不足アトリブ：属性2不足アトリブ：属性3 [end 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コマンドは、 "Application/index.cmd._command_"のタイプのmimeメッセージとして送信されます。このマイムタイプのツリーの定義は次のとおりです。
MIME type name: application MIME subtype name: index.cmd._command_ Optional parameters: type, dsi Security considerations: (See Section 4)
MIMEタイプ名：アプリケーションMIMEサブタイプ名：index.cmd._command_オプションパラメーター：タイプ、DSIセキュリティに関する考慮事項：（セクション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)
コマンド名：application/index.cmd.noop必要なパラメーター：（なし）
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を開始] Content-Type：Application/index.cmd.noop
[end MIME]
[エンドミメ]
Note the lack of a body but how the <linebreak> pair is still preserved after the Content-type header.
ボディの欠如に注意してくださいが、コンテンツタイプのヘッダーの後に<linebreak>ペアがまだ保存されている方法に注意してください。
Request Name: application/index.cmd.poll Required parameters: type, dsi
リクエスト名：application/index.cmd.poll必要なパラメーター：タイプ、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"
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]
Request Name: application/index.cmd.datachanged Required parameters: type, dsi
リクエスト名：application/index.cmd.datachanged必要なパラメーター：タイプ、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コマンドのセキュリティポリシーは、完全に実装されています。実装は、匿名のデータチャンジ付きコマンドを受け入れるか拒否するように構成される場合があります。
Example:
例：
[begin MIME]
Content-type: application/index.cmd.datachanged;
type="simple"; dsi= "1.3.5.7.9"<linebreak>
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]
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:
「Poll」コマンドへの返信では、サーバーは1つ以上のインデックスオブジェクトを送信することを選択できます。返されるインデックスオブジェクトの数に関係なく、応答はMIMEマルチパート/混合メッセージの形を取る必要があります。各部分自体は、「application/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.
Base-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.
インデックスタイプの定義は、世論調査のタイプ固有の本文とデータチャンジのリクエストに対処する必要があります。本体に含まれるすべてのパラメーターを指定する必要があります。
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の両方に対して生成される紹介をサポートするインデックスは、一方が著名な名前を使用しているが、もう一方が識別していないことを理解する必要があります。紹介に対するこれらの違いの影響は明らかです。
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.
インターネットプロトコルのドキュメントでは慣習的であるように、提案されたオブジェクトのセキュリティへの意味の簡単なレビューを含める必要があります。このセクションでは、このドキュメントのセキュリティに関する考慮事項セクションで表明された考慮事項を反映するだけではないかもしれません。
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.
セキュリティが問題になるもう1つの例は、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の基本的な前提の1つは、データプロバイダーがピアインデックスサーバーにデータのインデックスを提供することをいとわないことです。それらが慎重に構築されない限り、これらのインデックスはデータベースのセキュリティに対する脅威を構成する可能性があります。したがって、新しいインデックスオブジェクトタイプを開発する際には、データのセキュリティが主要な考慮事項でなければなりません。リバースエンジニアリングのリスクデータベースからのみに基づいて、それからエクスポートされたインデックスに基づいていることは、データの値と微調整されたインデックスの必要性と一致するレベルに保つ必要があります。
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.
この仕様につながる議論のために、発見ワーキンググループの多くの役立つメンバーに感謝します。
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.
以前はBunyIP情報システムのジェフ・アレンに具体的な謝辞が与えられています。これらの文書の彼の元のバージョンは、議論とコンセンサスを結晶化するのに非常に役立ちました。このドキュメントの実際のテキストのほとんどは、もともとJeffが作成しました。
Authors' Addresses
著者のアドレス
Jeff R. Allen 246 Hawthorne St. Palo Alto, CA 94301
ジェフ・R・アレン246ホーソーンセントパロアルト、カリフォルニア94301
EMail: jeff.allen@acm.org
Michael Mealling Network Solutions, Inc. 505 Huntmar Park Drive Herndon, VA 22070
Michael Mealling Network Solutions、Inc。505 Huntmar Park Drive Herndon、VA 22070
Phone: +1-703-742-0400
EMail: michael.mealling@RWhois.net
References
参考文献
[FRAMEWORK] Allen, J. and M. Mealling, "The Architecture of the Common Indexing Protocol (CIP)", RFC 2651, August 1999.
[フレームワーク]アレン、J。およびM.ミールリング、「共通インデックスプロトコル（CIP）のアーキテクチャ」、RFC 2651、1999年8月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, January 1996.
[RFC2046] Freed、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] Freed、N.、Klensin、J。、J。Postel、「多目的インターネットメールエクステンション（MIME）パート4：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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1992.
[RFC821] Postel、J。、「Simple Mail Transfer Protocol」、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
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
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 application/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:
詳細については、連絡先への個人およびメールアドレス：
Intended usage: LIMITED USE
意図された使用法：使用されています
Author/Change controller:
著者/変更コントローラー：
Command tree
コマンドツリー
To: ietf-types@iana.org
Subject: Registration of MIME media type application/index.cmd
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
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ツリーに似たツリーの上部です。このツリー内に登録されているタイプは、「公開された仕様」セクションで参照されているドキュメントで指定されているようにコマンドに限定されます。
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Intended usage: LIMITED USE
意図された使用法：使用されています
Author/Change controller:
著者/変更コントローラー：
Response tree
応答ツリー
To: ietf-types@iana.org
Subject: Registration of MIME media type application/index.response
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
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:
詳細については、連絡先への個人およびメールアドレス：
Intended usage: LIMITED USE
意図された使用法：使用されています
Author/Change controller:
著者/変更コントローラー：
Index Object tree
インデックスオブジェクトツリー
To: ietf-types@iana.org
Subject: Registration of MIME media type application/index.obj
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
MIME subtype name: index.obj
mimeサブタイプ名：index.obj
Required parameters: type, dsi, base-uri
必要なパラメーター：Type、DSI、Base-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:
詳細については、連絡先への個人およびメールアドレス：
Intended usage: LIMITED USE
意図された使用法：使用されています
Author/Change controller:
著者/変更コントローラー：
Vendor tree
ベンダーツリー
To: ietf-types@iana.org
Subject: Registration of MIME media type application/index.vnd
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
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:
詳細については、連絡先への個人およびメールアドレス：
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.
指定されたバージョンのCIPトランザクションを継続する300 CIPバージョンが承認されました。
222 Connection closing (in response to sender-CIP close) Done with transaction.
222接続クロージング（Sender-Cip Closingに応じて）トランザクションで行われます。
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スタイルのメッセージDelimiterによって区切られた応答を読み取ります。
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リクエストで再試行します。
501 Unknown or missing request in application/index.cmd Retry with correct CIP command.
501 application/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.
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エディター機能の資金は現在、インターネット協会によって提供されています。