RFC2652 日本語訳
2652 MIME Object Definitions for the Common Indexing Protocol (CIP).J. Allen, M. Mealling. August 1999. (Format: TXT=42464 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Allen
Request for Comments: 2652 WebTV Networks, Inc.
Category: Standards Track M. Mealling
Network Solutions, Inc.
August 1999
コメントを求めるワーキンググループJ.アレンの要求をネットワークでつないでください: 2652年のWebTV Networks Inc.カテゴリ: ネットワークソリューションズ社1999年8月に食事する標準化過程M.
MIME Object Definitions for the Common Indexing Protocol (CIP)
一般的なインデックスのためのMIMEオブジェクト定義は議定書を作ります。(CIP)
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
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.
Common Indexingプロトコル(CIP)は、質問ルーティングを容易にするためにサーバからサーバまで情報に索引をつけながら通るのに使用されます。 プロトコルはサーバからサーバまで渡される数個のMIMEオブジェクトから成ります。このドキュメントは新しいインデックスタイプを定義するのに必要であるメソッドと要件と同様にそれらのオブジェクトの定義について説明します。
1. Introduction
1. 序論
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.
Common Indexingプロトコル(CIP)は、それらのインデックスに基づく複数のインデックス、そして/または、ルート質問を結合するサーバの間でインデックスを通過するのに使用されます。 プロトコルのための総合的なフレームワークはCIP Frameworkドキュメント[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ラッパーの中でインデックスをカプセル化することによって、扱われます。
Allen & Mealling Standards Track [Page 1] RFC 2652 MIME Definitions for CIP August 1999
アレンと1999年8月にCIPのために標準化過程[1ページ]RFC2652MIME定義を荒びきにすること。
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].
このドキュメントは「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」[RFC2119]での指定されるとしての特別な意味を持っているSHOULDとSHALLのように言語を使用します。
2.0 CIP Transactions
2.0 CIPトランザクション
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作成者はサーバアドミニストレータ最大configurabilityに陰湿に送られた匿名の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>は使用されています。 ヘッダーのLinebreaksとヘッダーとボディーを切り離すと、既存の規格は続きます。
Allen & Mealling Standards Track [Page 2] RFC 2652 MIME Definitions for CIP August 1999
アレンと1999年8月にCIPのために標準化過程[2ページ]RFC2652MIME定義を荒びきにすること。
2.1 Common syntactic definitions
2.1 一般的な構文の定義
There are certain syntactic elements common to all of the CIP transactions. These include type, DSI and the Base-URI.
CIPトランザクションのすべてに共通のある構文の要素があります。 これらはタイプ、DSI、および基地URIを含んでいます。
2.1.1 The "application/index" MIME type tree
2.1.1 「アプリケーション/インデックス」MIMEの種類木
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_コマンド_アプリケーション/index.responseアプリケーション/index.obj_タイプ_アプリケーション/index.vnd_xxx_
_command_ is a command as specified here. It contains commands and
their arguments.
_コマンド_はここで指定されるとしてコマンドです。 それはコマンドと彼らの議論を含んでいます。
_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.
_タイプ_は、どんなタイプの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のキャラクタから成る、[a zA-Z0-9、-、]、。 キャラクタ(10進45)を引いたすなわちすべての大文字と小文字手紙、すべてのケタ、およびASCII。 型名は敏感に指定されたケースであるかもしれませんが、それらは無神経に比較されて別の方法で処理されたケースであるに違いありません。
Appendix A contains the registration template for the application/index tree.
付録Aはアプリケーション/インデックス木のための登録テンプレートを含んでいます。
2.1.2 DSI
2.1.2 DSI
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によって索引をつけられたすべてのデータセットの中で唯一与えられたデータセットを特定します。
Allen & Mealling Standards Track [Page 3] RFC 2652 MIME Definitions for CIP August 1999
アレンと1999年8月にCIPのために標準化過程[3ページ]RFC2652MIME定義を荒びきにすること。
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〜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のキャラクタを決して、超えていないものとします。 CIPデータセット識別子としてそれらの長さのためこれらの規則に従うことができないOIDのものを使用してはいけません。
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.
任意の長さの整数を扱うのが準備されていない場合、実装は、個々の整数を分析するのを試みてはいけません。 米国-ASCII文字の不透明なストリング以外の何としてもDSIを扱うのは推薦されません。
Two CIP DSI's are considered to match if both conform to the above rules and every number matches.
両方が上の規則に従うなら2CIP DSIのものが合っていると考えられて、あらゆる数が合っています。
2.1.3. Base-URI
2.1.3. 基地URI
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 }
genericurl*(1*空白genericurl)ベース-uri=空白=「<スペース>」(10進32)/「<タブ>」(10進9)/「<cr>」(10進13)/「<lf>」(10進10)genericurl=RFC-1738で指定されるように、5を区分してください。
2.2 Response format
2.2 応答形式
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の種類のための定義は以下の通りです。
Allen & Mealling Standards Track [Page 4] RFC 2652 MIME Definitions for CIP August 1999
アレンと1999年8月にCIPのために標準化過程[4ページ]RFC2652MIME定義を荒びきにすること。
MIME type name: application
MIME subtype name: index.response
Required parameters: code
Optional parameters: charset
Security considerations: (See Section 4)
MIMEの種類名: アプリケーションMIME「副-タイプ」は以下を命名します。 index.response Requiredパラメタ: Optionalパラメタをコード化してください: charset Security問題: (セクション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.
ボディーの形式がそのようなものであるので、最初の系列はコードに対応するコメントとして解釈されます。 ほとんどの応答コードなら、このコメントに人間の消費で意図して、存在しないかもしれなくて、プロトコルによって依存されてはいけません。 ボディーのその後の系列は定義する各応答のために予約されます。 コメントが与えられていない場合では、1番目は空の系列であるに違いありません。
body = comment linebreak payload
comment = { any text }
linebreak = (decimal 13) (decimal 10)
payload = { any text }
どんなボディー=コメントlinebreakペイロードコメント=テキストlinebreakもペイロード=と等しいです(10進13)(10進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 Server v1.0は<linebreak>を準備します。[終わりのMIME]
[begin MIME] Content-type: application/index.response; code=500
[MIME] 文書内容を始めてください: アプリケーション/index.response。 コード=500
MIME formatting problem<linebreak> [end MIME]
MIME形式問題<linebreak>。[終わりのMIME]
[begin MIME] Content-type: application/index.response; code=520
[MIME] 文書内容を始めてください: アプリケーション/index.response。 コード=520
<linebreak> [end MIME]
<linebreak>。[終わりの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:
本書では説明された応答は応答作成者のボディーの系列の残りを利用しませんが、将来それを禁じないように注意するべきです。 好例は投票要求が必要な属性を含まなかったと指定するメッセージでしょう。 このメッセージはこれに似るかもしれません:
Allen & Mealling Standards Track [Page 5] RFC 2652 MIME Definitions for CIP August 1999
アレンと1999年8月にCIPのために標準化過程[5ページ]RFC2652MIME定義を荒びきにすること。
[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属性Missing-属性です: attribute1 Missing-属性: attribute2 Missing-属性: attribute3[終わりのMIME]
The meaning of the various digits in the response codes is discussed in RFC-821, Appendix E.
RFC-821、Appendix Eで応答コードの様々なケタの意味について議論します。
See Appendix B for a list of the valid response codes.
有効回答コードのリストに関してAppendix Bを見てください。
2.3 Command format
2.3 コマンド形式
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:
「アプリケーション/index.cmd_コマンド_」というタイプに関するMIMEメッセージとしてCIPコマンドを送ります。 このMIMEの種類木のための定義は続きます:
MIME type name: application
MIME subtype name: index.cmd._command_
Optional parameters: type, dsi
Security considerations: (See Section 4)
MIMEの種類名: アプリケーションMIME「副-タイプ」は以下を命名します。 index.cmd__Optionalパラメタを命令してください: タイプ、dsi Security問題: (セクション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.
静かに認識されていない任意の付加的なパラメタを無視しなければなりません。
Allen & Mealling Standards Track [Page 6] RFC 2652 MIME Definitions for CIP August 1999
アレンと1999年8月にCIPのために標準化過程[6ページ]RFC2652MIME定義を荒びきにすること。
2.3.1 No-operation
2.3.1 操作がありません。
Command Name: application/index.cmd.noop
Required parameters: (none)
コマンド名: アプリケーション/index.cmd.noop Requiredパラメタ: (なにも)
A CIP command with the "command" parameter set to "noop" must be acknowledged with response type code 200 (command OK, no response forthcoming).
応答タイプコード200で"noop"に設定された「コマンド」パラメタがあるCIPコマンドを承諾しなければなりません(用意されていた状態で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.
ボディーにもかかわらず、<linebreak>組が文書内容ヘッダーの後にどうまだ保存されているか不足に注意してください。
2.3.2 Poll
2.3.2 投票
Request Name: application/index.cmd.poll
Required parameters: type, dsi
名前を要求してください: アプリケーション/index.cmd.poll Requiredパラメタ: タイプ、dsi
The "poll" command is used by a poller to request the transfer of an index object. It requires the following parameters:
「投票」コマンドは、インデックスオブジェクトの転送を要求するのにpollerによって使用されます。 それは以下のパラメタを必要とします:
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を考えて、aに利用可能などんなインデックスオブジェクトもないか、または受信機-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 0.9インチ」
Allen & Mealling Standards Track [Page 7] RFC 2652 MIME Definitions for CIP August 1999
アレンと1999年8月にCIPのために標準化過程[7ページ]RFC2652MIME定義を荒びきにすること。
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]
テンプレート: 名前アドレス電話<linebreak>Start-時間に連絡してください: 5月30日金曜日の1997年の<linebreak>終わり-時間東部夏時間14時25分30秒: 5月31日土曜日の東部夏時間14時25分30秒の1997<linebreak>。[終わりのMIME]
2.3.3 DataChanged
2.3.3 DataChanged
Request Name: application/index.cmd.datachanged
Required parameters: type, dsi
名前を要求してください: アプリケーション/index.cmd.datachanged Requiredパラメタ: タイプ、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する"のコマンドは、インデックスの中のデータが変化したことをpollerに通知するのに世論調査の対象者によって使用されます。 それは以下のパラメタを必要とします:
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を考えて、aに利用可能などんなインデックスオブジェクトもないか、または受信機-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の0.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]
最新の変化の時間: 5月30日金曜日の1997年のメッセージ世代の<linebreak>時間東部夏時間14時25分30秒: 5月30日金曜日の東部夏時間14時25分30秒の1997<linebreak>ホスト名: cip.rwhois.net<linebreak>Host-ポート: 4322年の<linebreak>プロトコル: RWhois2.0<linebreak>。[終わりのMIME]
Allen & Mealling Standards Track [Page 8] RFC 2652 MIME Definitions for CIP August 1999
アレンと1999年8月にCIPのために標準化過程[8ページ]RFC2652MIME定義を荒びきにすること。
2.3.4 Additional Requests
2.3.4 追加要求
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.
上で指定された要求は簡単なメッシュを実装するのに必要であるものです。 他の要求が要求を集めながらメッシュ管理と統計の問題を扱うために開発されると予想されます。 ここに、これは追加仕事の領域です。 メッシュが、彼らのインデックスタイプの特性の周りで組織化される傾向があるとき、明確により多くの仕事がメッシュ管理の領域で必要です。
2.4. Index Object format
2.4. インデックスObject形式
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の複合の、または、複雑なメッセージの形を取らなければなりません。 それぞれがタイプのMIMEオブジェクトが「アプリケーション/index.obj_タイプ_」であったなら必須自体を分けます。 このタイプのための定義は続きます:
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__Requiredパラメタをタイプしてください: dsi、ベース-uri Optionalパラメタ: なにも、Security問題: (セクション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: URIの1つ以上のものがこのインデックスオブジェクトに基づいた状態で作成されたどんな紹介のベースも形成するでしょう。
3. Index Type Definition Requirements
3. インデックス型定義要件
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インデックスオブジェクトは抽象的です。 別々の仕様でそれらを定義しなければなりません。 インデックス物体を動かすための基本プロトコルは広く適切であり、唯一の詳細はインデックスのデザインです、そして、特定のタイプのインデックスを通過するサーバのメッシュの構造がアプリケーションドメインに依存しています。 仲間ドキュメントはインデックスオブジェクトについて説明するでしょうが、1セットのベース要件とそれらのドキュメントが扱わなければならない質問があります。 これは、CIPプロトコルがインデックスに関してするベース仮定が実際にインデックスの中で表現できるのを保証するためのものです。
Allen & Mealling Standards Track [Page 9] RFC 2652 MIME Definitions for CIP August 1999
アレンと1999年8月にCIPのために標準化過程[9ページ]RFC2652MIME定義を荒びきにすること。
Since each type is a MIME type all its own, registration of new types follows the standard registration policies specified in RFC2048.
各タイプ以来、新しいことの登録は、MIMEの種類がすべてそれ自身のものであることをタイプします。RFC2048で指定されて、標準の登録方針に従います。
3.1 Type specific requests
3.1は特定の要求をタイプします。
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.
どんなインデックス型定義もPollとDataChanged要求の特定のボディーをタイプに扱わなければなりません。 ボディーにすべてのパラメタを含んでいるのを指定しなければなりません。
3.2 The index.obj parameters
3.2 index.objパラメタ
3.2.1 Type
3.2.1 タイプ
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.
インデックスオブジェクト・タイプを説明するドキュメントへのどんな変化も完全に後方に割り当てないとき、新しい名前を割り当てなければなりません。互換性がある。
3.2.2 DSI
3.2.2 DSI
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がどう発生しているように方針を定義するべきであるか。 これはデータセットが与えられたインデックスのために意味することに関する概念を含んでいます。
3.2.3. Base-URI
3.2.3. 基地URI
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がどのように対象指標に適用されるか、そして、それが集合プロセスの間、どのように変えられるかを定義するべきです。
Allen & Mealling Standards Track [Page 10] RFC 2652 MIME Definitions for CIP August 1999
アレンと1999年8月にCIPのために標準化過程[10ページ]RFC2652MIME定義を荒びきにすること。
3.3 Aggregation
3.3 集合
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.
インデックスオブジェクトドキュメント作者は、どんな種類の集合も過度の数の逃された結果を避けている間に正しく質問を発送する能力に感染しないで実行されるべきであったのを覚えているべきです。 aでアプリケーションドメイン単位で有病誤診の許容できる見込みを確立しなければならない、基礎、それのために特記仕様書で定義されたインデックスと集合規則の粒状で、制御されます。
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.
これらのドキュメントの何も明確に異なったインデックスオブジェクト・タイプに対応する集合規則を禁じません。 このタイプの異種のメッシュは、せいぜい定式化するのが難しく、その結果、これらのドキュメントでカバーされていません。 ドキュメント作者がそのようなメッシュを試みたいなら、彼らはそれがメッシュビルダーにとっての多くの落とし穴を含む病気の理解されている概念であると考えられるのを意識しているべきです。
3.4 Referral Generation Semantics
3.4 紹介世代意味論
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つがDistinguished Nameを使用するのを理解しなければなりません。 紹介のこれらの違いの影響は明確であるはずです。
3.5 Matching Semantics
3.5 合っている意味論
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.
紹介を生成するために、アクセス・プロトコルでそうするかどうかに関する決定を扱わなければなりません。 この決定を囲む意味論は集合に関する要件と同様に検索の効率に大きい影響力を持っています。 したがって、インデックス仕様作者はマッチがどう断固としているかが非常にわからなければなりません。
Allen & Mealling Standards Track [Page 11] RFC 2652 MIME Definitions for CIP August 1999
アレンと1999年8月にCIPのために標準化過程[11ページ]RFC2652MIME定義を荒びきにすること。
3.6 Security Considerations
3.6 セキュリティ問題
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部で言い表された問題をただ反映する必要があるかもしれません。
3.7 Optional Coverage
3.7 任意の適用範囲
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つのインデックスリストと結果の集合インデックスを示しているテーブルが含まれているのは、お勧めです。
4. Security Considerations
4. セキュリティ問題
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プロトコル自体は、安全な方法で作動するために対外安全保障サービスを必要とします。 両方の話題は以下にカバーされています。
4.1 Secure Indexing
4.1 安全なインデックス
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は、すべての種類のデータに索引をつけるように設計されています。 このいくつかのデータがデータ維持装置によって貴重であるか、独占である、または非常に敏感でさえあると考えられるかもしれません。 例えば人的資源データベースを取ってください。 会社が公表するように、あるビットのデータは適度に非常に有用である場合があります。 しかしながら、データベースは全体としてそうです。非常に貴重な資産。(会社はその資産を保護しなければなりません)。 データベースを完全に明らかにして、役に立つ片のそれを利用可能にすることの間に数年間ディレクトリサービス共同体でどのように最も上手にこの細い線を歩くかに関して多くの経験をしています。
Allen & Mealling Standards Track [Page 12] RFC 2652 MIME Definitions for CIP August 1999
アレンと1999年8月にCIPのために標準化過程[12ページ]RFC2652MIME定義を荒びきにすること。
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の根本的な前提の1つは情報提供業者が、サーバに索引をつけながらじっと見るためにそれらのデータのインデックスリストを提供しても構わないと思うということです。 それらが慎重に組み立てられない場合、これらのインデックスリストはデータベースのセキュリティへの脅威を構成するかもしれません。 新しいインデックスオブジェクト・タイプを発生するとき、したがって、データのセキュリティは主要な考慮であるに違いありません。 データベースがそれからエクスポートされたインデックスだけに基礎づけたリバースエンジニアリングの危険をデータの値ときめ細かに粒状のインデックスの必要性と一致したレベルに保たなければなりません。
Since CIP is encoded as MIME objects, MIME security solutions should be used whenever possible. Specifically when dealing with security between index servers.
MIMEが反対するようにCIPがコード化されるので、可能であるときはいつも、MIMEセキュリティ解決は使用されるべきです。 特にインデックスサーバの間のセキュリティに対処するとき。
4.2 Protocol Security
4.2 プロトコルセキュリティ
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メッセージの形を取って、MIMEがオブジェクトであると機密保護するのに利用可能などんな技術も使用することでCIPプロトコル交換を保証できます。 RFC-1847のSecurity Multipartsの使用は特に、お勧めです。 RFC-2016、広く利用可能な暗号化ソフトウェアを使用するRFC-1847の確実なアプリケーションはPGP/MIMEです。 それがMIME Security Multipartsアーキテクチャの最初の実行可能な応用であるので、作成者が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のシリーズからの応答コードを発行しなければなりません。
Allen & Mealling Standards Track [Page 13] RFC 2652 MIME Definitions for CIP August 1999
アレンと1999年8月にCIPのために標準化過程[13ページ]RFC2652MIME定義を荒びきにすること。
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.
特定の承認は以前、Bunyip情報システムをジェフ・アレンに与えます。彼のこれらのドキュメントのオリジナルバージョンは、討論とコンセンサスを結晶させるのを途方もないほど手伝いました。 実際のテキストの大部分は元々、ジェフによって本書では書かれました。
Authors' Addresses
作者のアドレス
Jeff R. Allen 246 Hawthorne St. Palo Alto, CA 94301
聖パロアルト、ジェフ・R.アレン246・Hawthorneカリフォルニア 94301
EMail: jeff.allen@acm.org
メール: jeff.allen@acm.org
Michael Mealling Network Solutions, Inc. 505 Huntmar Park Drive Herndon, VA 22070
ネットワークソリューションズ社505Huntmar公園Driveハーンドン、ヴァージニア 22070を荒びきにするマイケル
Phone: +1-703-742-0400 EMail: michael.mealling@RWhois.net
以下に電話をしてください。 +1-703-742-0400 メールしてください: 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)のアーキテクチャ」、RFC2651、1999年8月。
[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を分けます」。 「メディアタイプ」、RFC2046、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)は4を分けます」。 「MIME登録手順」、RFC2048、1996年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
821, August 1992.
[RFC821] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、1992年8月。
Allen & Mealling Standards Track [Page 14] RFC 2652 MIME Definitions for CIP August 1999
アレンと1999年8月にCIPのために標準化過程[14ページ]RFC2652MIME定義を荒びきにすること。
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 Subject: MIMEメディアの登録は木のアプリケーション/インデックスをタイプします。
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
RFC2652
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
Allen & Mealling Standards Track [Page 15] RFC 2652 MIME Definitions for CIP August 1999
アレンと1999年8月にCIPのために標準化過程[15ページ]RFC2652MIME定義を荒びきにすること。
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 Subject: MIMEメディアタイプアプリケーション/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
RFC2652
Allen & Mealling Standards Track [Page 16] RFC 2652 MIME Definitions for CIP August 1999
アレンと1999年8月にCIPのために標準化過程[16ページ]RFC2652MIME定義を荒びきにすること。
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.
このメディアタイプはそんなスタンドアロン人間ではありません。 それは、vndと同様の梢とRFC2048のセクション2.1で指定されたprs木です。 この木の中に示されたタイプは「広められた仕様」セクションで参照をつけられるドキュメントにおける指定されるとしてのコマンドに制限されます。
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 Subject: MIMEメディアタイプアプリケーション/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.
作成者は優雅に未知の応答を扱うべきです。
Allen & Mealling Standards Track [Page 17] RFC 2652 MIME Definitions for CIP August 1999
アレンと1999年8月にCIPのために標準化過程[17ページ]RFC2652MIME定義を荒びきにすること。
Published specification:
広められた仕様:
RFC 2652
RFC2652
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.
このメディアタイプ_はスタンドアロンがタイプする_です。 コード・パラメータは仕様ドキュメントのAppendix Bによる指定されるとしての特定の応答コードを含んでいます。
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス:
Intended usage: LIMITED USE
意図している用法: 限られた使用
Author/Change controller:
コントローラを書くか、または変えてください:
Index Object tree
インデックスObject木
To: ietf-types@iana.org Subject: Registration of MIME media type application/index.obj
To: ietf-types@iana.org Subject: MIMEメディアタイプアプリケーション/index.objの登録
MIME media type name: application
MIMEメディア型名: アプリケーション
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プロトコル自体は、安全な方法で作動するために対外安全保障サービスを必要とします。 両方の話題は以下にカバーされています。
Allen & Mealling Standards Track [Page 18] RFC 2652 MIME Definitions for CIP August 1999
アレンと1999年8月にCIPのために標準化過程[18ページ]RFC2652MIME定義を荒びきにすること。
Interoperability considerations:
相互運用性問題:
Implementors should handle unknown index objects according to
rules specified in the published specification.
広められた仕様で指定された規則に従って、作成者は未知のインデックスオブジェクトを扱うべきです。
Published specification:
広められた仕様:
RFC 2652
RFC2652
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.
このメディアタイプはそんなスタンドアロン人間ではありません。 それは、vndと同様の梢とRFC2048のセクション2.1で指定された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 Subject: MIMEメディアタイプアプリケーション/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
問題をコード化します: なし
Allen & Mealling Standards Track [Page 19] RFC 2652 MIME Definitions for CIP August 1999
アレンと1999年8月にCIPのために標準化過程[19ページ]RFC2652MIME定義を荒びきにすること。
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
RFC2652
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.
このメディアタイプはそんなスタンドアロン人間ではありません。 それは、vndと同様の梢とRFC2048のセクション2.1で指定された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、Appendix 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サーバによって解釈されるべきです。 予期しない状況のために新法を定義することの代わりに、作成者は与えられたコードの1つを適合させなければなりません。 実装は役に立つ代替のコメントを再利用された応答コードに付けるべきです。
Allen & Mealling Standards Track [Page 20] RFC 2652 MIME Definitions for CIP August 1999
アレンと1999年8月にCIPのために標準化過程[20ページ]RFC2652MIME定義を荒びきにすること。
Code Suggested description text
Sender-CIP action
--------------------------------------------------------
220 Initial server banner message
コードSuggested記述テキストSender-CIP動作-------------------------------------------------------- 220の初期のサーババナーメッセージ
300 Requested CIP version accepted
Continue with CIP transaction, in the specified
version.
CIPトランザクションが指定されたバージョンにある状態で、300の要求されたCIPバージョンはContinueを受け入れました。
222 Connection closing (in response to sender-CIP close)
Done with transaction.
トランザクションで行われた222接続閉鎖(送付者-CIPに対応して、閉じてください)。
200 MIME request received and processed
Expect no output, continue session (or close)
MIME要求が受け取った200と出力されなかった処理Expect、セッションを続けてください。(近い)
201 MIME request received and processed, output follows
Read a response, delimited by SMTP-style message
delimiter.
201MIME要求が受け取られて、処理されて、出力はSMTP-スタイルメッセージデリミタによって応答であって、区切られたReadに続きます。
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が後でRetryを要求します。 サーバにはインデックスを受け入れるために利用可能なリソースが現在ないのを示すのに使用されるかもしれません。
500 Bad MIME message format
Retry with correctly formatted MIME request.
500 正しくフォーマットされたMIME要求がある悪いMIMEメッセージ・フォーマットRetry。
501 Unknown or missing request in application/index.cmd
Retry with correct CIP command.
アプリケーション/index.cmd Retryでの正しいCIPコマンドによる501の未知の、または、なくなった要求。
502 Request is missing required CIP attributes
Retry with correct CIP attributes.
502要求は正しいCIP属性があるなくなった必要なCIP属性Retryです。
520 Aborting connection for some unexpected reason
Retry and/or alert local administrator.
520 予期していなかった理由Retry、そして/または、注意深い地元の管理者のための接続を中止します。
530 Request requires valid signature
Sign the request, if possible, and retry.
Otherwise, report problem to the administrator.
530は、要求であって、可能な有効な署名Signが必要であるよう要求して、再試行されます。 さもなければ、問題を管理者に報告してください。
531 Request has invalid signature
Report problem to the administrator.
531要求は無効の署名Report問題を管理者に持っています。
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は署名のAlert地元の管理者をチェックできません。(その管理者は、問題を診断して、解決するためにリモート管理者と協力するべきです)。 (たぶん、公開鍵を逃します。)
Allen & Mealling Standards Track [Page 21] RFC 2652 MIME Definitions for CIP August 1999
アレンと1999年8月にCIPのために標準化過程[21ページ]RFC2652MIME定義を荒びきにすること。
5. Full Copyright Statement
5. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Allen & Mealling Standards Track [Page 22]
アレンと標準化過程を荒びきにすること。[22ページ]
一覧
スポンサーリンク
