[要約] RFC 7071は、評判のやり取りのためのメディアタイプを定義しています。このRFCの目的は、異なるシステム間で評判情報を共有するための標準化を提供することです。
Internet Engineering Task Force (IETF) N. Borenstein
Request for Comments: 7071 Mimecast
Category: Standards Track M. Kucherawy
ISSN: 2070-1721 November 2013
A Media Type for Reputation Interchange
レピュテーションインターチェンジのメディアタイプ
Abstract
概要
This document defines the format of reputation response data ("reputons"), the media type for packaging it, and definition of a registry for the names of reputation applications and response sets.
このドキュメントでは、レピュテーションレスポンスデータ（「レピュトン」）のフォーマット、それをパッケージ化するためのメディアタイプ、およびレピュテーションアプリケーションとレスポンスセットの名前のレジストリの定義を定義します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7071.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7071で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology and Definitions .....................................3
2.1. Reputon ....................................................3
2.2. Key Words ..................................................3
2.3. Other Definitions ..........................................3
3. Description .....................................................3
3.1. Reputon Attributes .........................................4
4. Ratings .........................................................5
5. Caching .........................................................5
6. Reputons ........................................................6
6.1. Syntax .....................................................6
6.2. Formal Definition ..........................................6
6.2.1. Imported JSON Terms .................................6
6.2.2. Reputon Structure ...................................7
6.3. Examples ...................................................9
7. IANA Considerations ............................................11
7.1. application/reputon+json Media Type Registration ..........11
7.2. Reputation Applications Registry ..........................13
8. Security Considerations ........................................15
9. References .....................................................15
9.1. Normative References ......................................15
9.2. Informative References ....................................15
Appendix A. Acknowledgments .......................................16
This document defines a data object for use when answering a reputation query. It also defines a media type to carry the response set data when using a transport method that follows the media type framework, such as the query method based on the HyperText Transfer Protocol (HTTP) defined in [RFC7072]. Any future query methods that might be developed are expected to use the same data object.
このドキュメントは、レピュテーションクエリに応答するときに使用するデータオブジェクトを定義します。また、[RFC7072]で定義されているハイパーテキスト転送プロトコル（HTTP）に基づくクエリメソッドなど、メディアタイプフレームワークに従うトランスポートメソッドを使用するときに、応答セットデータを運ぶメディアタイプを定義します。今後開発される可能性のあるクエリメソッドは、同じデータオブジェクトを使用することが期待されています。
Also included is the specification for an IANA registry to contain definitions and symbolic names for known reputation applications and corresponding response sets.
また、既知のレピュテーションアプリケーションと対応する応答セットの定義とシンボル名を含むIANAレジストリの仕様も含まれています。
This section defines terms used in the rest of the document.
このセクションでは、ドキュメントの残りの部分で使用される用語を定義します。
A "reputon" is a single independent object containing reputation information. A particular query about a subject of interest will receive one or more reputons in response, depending on the nature of the data collected and reported by the server.
「レピュトン」は、レピュテーション情報を含む単一の独立したオブジェクトです。関心のある対象に関する特定のクエリは、サーバーによって収集および報告されるデータの性質に応じて、1つまたは複数のレピュトンを受け取ります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [キーワード]で説明されているように解釈されます。
Other terms of importance in this document are defined in [RFC7070], the base document in this document series.
このドキュメントの他の重要な用語は、このドキュメントシリーズのベースドキュメントである[RFC7070]で定義されています。
The meta-format selected for the representation of a reputon is JavaScript Object Notation (JSON), defined in [JSON]. Accordingly, a new media type, "application/reputon+json", is defined for the JSON representation of reputational data, typically in response to a client making a request for such data about some subject. This media type takes no parameters.
レピュトンの表現に選択されたメタフォーマットは、[JSON]で定義されたJavaScript Object Notation（JSON）です。したがって、レピュテーションデータのJSON表現に対して、通常はクライアントが何らかのサブジェクトに関するそのようなデータを要求することに応答して、新しいメディアタイプ「application / reputon + json」が定義されます。このメディアタイプはパラメーターを取りません。
The body of the media type consists of a JSON document that contains the reputation information requested. A detailed description of the expected structure of the reply is provided below.
メディアタイプの本体は、要求されたレピュテーション情報を含むJSONドキュメントで構成されています。応答の予想される構造の詳細な説明を以下に示します。
The media type comprises a single member indicating the name of the application context (see Section 5.1 of [RFC7070]) in which the reputational data are being returned. The application name refers to a registration as described in Section 7.2, which defines the valid assertions and any extensions that might also be valid (i.e., the response set) for that application.
メディアタイプは、評判データが返されるアプリケーションコンテキストの名前を示す単一のメンバーで構成されます（[RFC7070]のセクション5.1を参照）。アプリケーション名は、セクション7.2で説明されている登録を参照します。これは、そのアプリケーションに対して有効である可能性がある有効なアサーションおよび拡張（つまり、応答セット）を定義します。
The key pieces of data found in a reputon for all reputation applications are defined as follows:
すべてのレピュテーションアプリケーションのレピュトンにある主要なデータは、次のように定義されています。
rater: The identity of the entity aggregating, computing, and providing the reputation information, typically expressed as a DNS domain name.
評価者：レピュテーション情報を集約、計算、提供するエンティティのID。通常はDNSドメイン名として表現されます。
assertion: A key word indicating the specific assertion or claim being rated.
アサーション：評価される特定のアサーションまたはクレームを示すキーワード。
rated: The identity of the entity being rated. The nature of this field is application specific; it could be domain names, email addresses, driver's license numbers, or anything that uniquely identifies the entity being rated. Documents that define specific reputation applications are required to define syntax and semantics for this field.
評価：評価されるエンティティのID。このフィールドの性質はアプリケーション固有です。ドメイン名、電子メールアドレス、運転免許証番号、または評価対象のエンティティを一意に識別するものであれば何でもかまいません。このフィールドの構文とセマンティクスを定義するには、特定のレピュテーションアプリケーションを定義するドキュメントが必要です。
rating: The overall rating score for that entity, expressed as a floating-point number between 0.0 and 1.0 inclusive. See Section 4 for discussion.
評価：そのエンティティの全体的な評価スコア。0.0〜1.0の浮動小数点数として表されます。説明については、セクション4を参照してください。
The following are OPTIONAL for all applications, to be used in contexts where they are appropriate:
以下は、すべてのアプリケーションでオプションであり、適切なコンテキストで使用されます。
confidence: the level of certainty the reputation provider has that the value presented is appropriate, expressed as a floating-point number between 0.0 and 1.0 inclusive.
信頼性：提示された値が適切であるという評判プロバイダーの確実性のレベル。0.0〜1.0の浮動小数点数として表されます。
normal-rating: An indication of what the reputation provider would normally expect as a rating for the subject. This allows the client to note that the current rating is or is not in line with expectations.
normal-rating：評判プロバイダーがサブジェクトの評価として通常期待するものの指標。これにより、クライアントは現在の評価が期待と一致するかどうかを確認できます。
sample-size: The number of data points used to compute the rating, possibly an approximation. Expressed as an unsigned 64-bit integer. Consumers can assume that the count refers to distinct data points rather than a count of aggregations (for example, individual votes rather than aggregated vote counts) unless it is specified out-of-band that some other interpretation is more appropriate. The units are deliberately not normatively specified, since not all reputation service providers will collect data the same way.
sample-size：評価を計算するために使用されるデータポイントの数。符号なし64ビット整数として表現されます。消費者は、他の何らかの解釈がより適切であると帯域外で指定されていない限り、集計は集計の数ではなく個別のデータポイント（たとえば、集計された投票数ではなく個々の投票）を指すと想定できます。すべてのレピュテーションサービスプロバイダーが同じ方法でデータを収集するわけではないため、ユニットは意図的に規定されていません。
generated: A timestamp indicating when this value was generated. Expressed as the number of seconds since January 1, 1970 00:00 UTC.
generated：この値がいつ生成されたかを示すタイムスタンプ。 1970年1月1日00:00 UTCからの秒数で表されます。
expires: A timestamp indicating a time beyond which the score reported is likely not to be valid. Expressed as the number of seconds since January 1, 1970 00:00 UTC. See Section 5 for discussion.
期限切れ：レポートされたスコアが有効でない可能性が高い時間を示すタイムスタンプ。 1970年1月1日00:00 UTCからの秒数で表されます。説明については、セクション5を参照してください。
A particular application that registers itself with IANA (per Section 7.2, below) can define additional application-specific attribute/value pairs beyond these standard ones.
IANAに自身を登録する特定のアプリケーション（以下のセクション7.2に従って）は、これらの標準的なもの以外に、アプリケーション固有の追加の属性/値のペアを定義できます。
An application service provider might operate with an enhanced form of common services, which might in turn prompt development and reporting of specialized reputation information. The details of the enhancements and specialized information are beyond the scope of this document, except that the underlying JSON syntax is extensible for encoding such provider-specific information.
アプリケーションサービスプロバイダーは、強化された形式の共通サービスで動作する場合があり、これにより、専門のレピュテーション情報の迅速な開発とレポートが可能になります。拡張機能と特殊情報の詳細は、このドキュメントの範囲外です。ただし、基になるJSON構文は、そのようなプロバイダー固有の情報をエンコードするために拡張可能です。
The score presented as the value in the rating attribute appears as a floating-point value between 0.0 and 1.0 inclusive. The intent is that the definition of an assertion within an application will declare what the anchor values 0.0 and 1.0 specifically mean. Generally speaking, 1.0 implies full agreement with the assertion, while 0.0 indicates no support for the assertion.
rating属性の値として表示されるスコアは、0.0〜1.0の浮動小数点値として表示されます。その意図は、アプリケーション内のアサーションの定義が、アンカー値0.0および1.0が具体的に何を意味するかを宣言することです。一般的に言って、1.0はアサーションとの完全な合意を意味し、0.0はアサーションのサポートがないことを示します。
The definition will also specify the type of scale in use when generating scores, to which all reputation service providers for that application space must adhere. Further discussion can be found in [RFC7070].
この定義では、スコアを生成するときに使用するスケールのタイプも指定します。スコアには、そのアプリケーションスペースのすべてのレピュテーションサービスプロバイダーが準拠する必要があります。さらなる議論は[RFC7070]で見つけることができます。
A reputon can contain an "expires" field indicating a timestamp after which the client SHOULD NOT use the rating it contains and SHOULD issue a new query.
レピュトンには、タイムスタンプを示す「expires」フィールドを含めることができます。その後、クライアントはそれが含む評価を使用してはならず（SHOULD NOT）、新しいクエリを発行する必要があります（SHOULD）。
This specification does not mandate any caching of ratings on the part of the client, but there are obvious operational benefits to doing so. In the context of reputation, a cached (and hence, stale) rating can cause desirable traffic to be identified as undesirable, or vice versa.
この仕様は、クライアント側での評価のキャッシュを義務付けていませんが、そうすることには明らかな運用上の利点があります。レピュテーションのコンテキストでは、キャッシュされた（つまり古くなった）レーティングにより、望ましいトラフィックが望ましくないトラフィックとして識別されたり、その逆の場合があります。
Reputation data is typically most volatile when the subject of the reputation is young. Accordingly, if a service chooses to include expiration timestamps as part a reply, these values SHOULD be lower for subjects about which little data has been collected.
レピュテーションの対象が若い場合、レピュテーションデータは通常最も変動します。したがって、サービスが応答の一部として有効期限タイムスタンプを含めることを選択した場合、これらの値は、ほとんどデータが収集されていないサブジェクトに対しては低くする必要があります。
A reputon expressed in JSON is a set of key-value pairs, where the keys are the names of particular attributes that comprise a reputon (as listed above, or as provided with specific applications), and values are the content associated with those keys. The set of keys that make up a reputon within a given application are known as that application's "response set".
JSONで表現されるレピュトンは、キーと値のペアのセットです。キーは、レピュトンを構成する特定の属性の名前であり（上記のリスト、または特定のアプリケーションで提供されるもの）、値はそれらのキーに関連付けられたコンテンツです。特定のアプリケーション内でレピュトンを構成するキーのセットは、そのアプリケーションの「応答セット」と呼ばれます。
A reputon object typically contains a reply corresponding to the assertion for which a client made a specific request. For example, a client asking for assertion "sends-spam" about domain "example.com" would expect a reply consisting of a reputon making a "sends-spam" assertion about "example.com" and nothing more. If a client makes a request about a subject but does not specify an assertion of interest, the server can return reputons about any assertion for which it has data; in effect, the client has asked for any available information about the subject. A client that receives an irrelevant reputon simply ignores it.
通常、reputonオブジェクトには、クライアントが特定の要求を行ったアサーションに対応する応答が含まれています。たとえば、ドメイン "example.com"に関するアサーション "sends-spam"を要求するクライアントは、 "example.com"に関する "sends-spam"アサーションを作成するレピュトンからなる応答のみを期待します。クライアントがサブジェクトに関するリクエストを行ったが、関心のあるアサーションを指定していない場合、サーバーは、データがあるアサーションについての評判を返すことができます。事実上、クライアントは対象について入手可能な情報を求めています。無関係な評判を受け取ったクライアントは単にそれを無視します。
An empty reputon is an acknowledgment by the server that the request has been received, and serves as a positive indication that the server does not have the information requested. This is semantically equivalent to returning a reputon with a "sample-size" of zero.
空のレピュトンは、要求が受信されたことをサーバーが確認したことであり、サーバーが要求された情報を持っていないことを示す前兆です。これは、意味的には、「サンプルサイズ」がゼロのレピュトンを返すことと同じです。
[JSON] defines the structure of JSON objects and arrays using a set of primitive elements. Those elements will be used to describe the JSON structure of a reputation object.
[JSON]は、一連のプリミティブ要素を使用してJSONオブジェクトと配列の構造を定義します。これらの要素は、レピュテーションオブジェクトのJSON構造を記述するために使用されます。
OBJECT: a JSON object, defined in Section 2.2 of [JSON]
OBJECT：[JSON]のセクション2.2で定義されたJSONオブジェクト
MEMBER: a member of a JSON object, defined in Section 2.2 of [JSON]
MEMBER：[JSON]のセクション2.2で定義されたJSONオブジェクトのメンバー
MEMBER-NAME: the name of a MEMBER, defined as a "string" in Section 2.2 of [JSON]
メンバー名：[JSON]のセクション2.2で「文字列」として定義されたメンバーの名前
MEMBER-VALUE: the value of a MEMBER, defined as a "value" in Section 2.2 of [JSON]
MEMBER-VALUE：[JSON]のセクション2.2で「値」として定義されたMEMBERの値
ARRAY: an array, defined in Section 2.3 of [JSON]
ARRAY：[JSON]のセクション2.3で定義された配列
ARRAY-VALUE: an element of an ARRAY, defined in Section 2.3 of [JSON]
ARRAY-VALUE：[JSON]のセクション2.3で定義されたARRAYの要素
NUMBER: a "number" as defined in Section 2.4 of [JSON]
NUMBER：[JSON]のセクション2.4で定義されている「番号」
INTEGER: an "integer" as defined in Section 2.4 of [JSON]
INTEGER：[JSON]のセクション2.4で定義されている「整数」
STRING: a "string" as defined in Section 2.5 of [JSON]
STRING：[JSON]のセクション2.5で定義されている「文字列」
Using the above terms for the JSON structures, the syntax of a reputation object is defined as follows:
JSON構造について上記の用語を使用すると、レピュテーションオブジェクトの構文は次のように定義されます。
reputation-object: an OBJECT containing a MEMBER reputation-context and a MEMBER reputon-list
reputation-object：MEMBER reputation-contextとMEMBER reputon-listを含むOBJECT
reputation-context: a MEMBER with MEMBER-NAME "application" and MEMBER-VALUE a STRING (see Section 3)
reputation-context：MEMBER-NAME "application"およびMEMBER-VALUE a STRINGを持つMEMBER（セクション3を参照）
reputon-list: a MEMBER with MEMBER-NAME "reputons" and MEMBER-VALUE a reputon-array
reputon-list：MEMBER-NAMEが「reputons」で、MEMBER-VALUEがreputon-arrayのMEMBER
reputon-array: an ARRAY, where each ARRAY-VALUE is a reputon
reputon-array：ARRAY。各ARRAY-VALUEはレピュトンです
reputon: an OBJECT, where each MEMBER is a reputon-element
reputon：各MEMBERがreputon要素であるOBJECT
reputon-element: one of the following, defined below: rater-value, assertion-value, rated-value, rating-value, conf-value, normal-value, sample-value, gen-value, expire-value, ext-value; note the following:
reputon-element：以下のいずれか、以下で定義：rater-value、assertion-value、rated-value、rating-value、conf-value、normal-value、sample-value、gen-value、expire-value、ext-値;次の点に注意してください。
* The order of reputon-element members is not significant.
* reputon-elementメンバーの順序は重要ではありません。
* A specific reputon-element MUST NOT appear more than once.
* 特定のreputon-elementは2回以上出現してはなりません。
* rater-value, assertion-value, rated-value, and rating-value are REQUIRED.
* 評価者値、アサーション値、評価値、および評価値は必須です。
rater-value: a MEMBER with MEMBER-NAME "rater" and MEMBER-VALUE a STRING (see "rater" in Section 3.1)
rater-value：MEMBER-NAME "rater"を持つMEMBERとMEMBER-VALUE a STRING（セクション3.1の "rater"を参照）
assertion-value: a MEMBER with MEMBER-NAME "assertion" and MEMBER-VALUE a STRING (see "assertion" in Section 3.1)
assertion-value：MEMBER-NAMEが「アサーション」であるMEMBERとMEMBER-VALUEが文字列である（セクション3.1の「アサーション」を参照）
rated-value: a MEMBER with MEMBER-NAME "rated" and MEMBER-VALUE a STRING (see "rated" in Section 3.1)
定格値：MEMBER-NAMEが「定格」であるMEMBERとMEMBER-VALUEが文字列である（セクション3.1の「定格」を参照）
rating-value: a MEMBER with MEMBER-NAME "rating" and MEMBER-VALUE a NUMBER between 0.0 and 1.0 inclusive (see "rating" in Section 3.1); the number SHOULD NOT not have more than three decimal places of precision
rating-value：MEMBER-NAMEが "rating"のMEMBERとMEMBER-VALUEが0.0から1.0までの数値（3.1節の "rating"を参照）。数値は小数点以下3桁を超えてはいけません（SHOULD NOT）
conf-value: a MEMBER with MEMBER-NAME "confidence" and MEMBER-VALUE a NUMBER between 0.0 and 1.0 inclusive (see "confidence" in Section 3.1); the number SHOULD NOT not have more than three decimal places of precision
conf-value：MEMBER-NAMEが「confidence」のMEMBERとMEMBER-VALUEが0.0から1.0までの数値（3.1節の「confidence」を参照）。数値は小数点以下3桁を超えてはいけません（SHOULD NOT）
normal-value: a MEMBER with MEMBER-NAME "normal-rating" and MEMBER-VALUE a NUMBER between 0.0 and 1.0 inclusive (see "normal" in Section 3.1); the number SHOULD NOT not have more than three decimal places of precision
normal-value：MEMBER-NAMEが "normal-rating"のMEMBERとMEMBER-VALUEが0.0から1.0までの数値（3.1節の "normal"を参照）。数値は小数点以下3桁を超えてはいけません（SHOULD NOT）
sample-value: a MEMBER with MEMBER-NAME "sample-size" and MEMBER-VALUE a non-negative INTEGER (see "sample-size" in "normal" in Section 3.1)
sample-value：MEMBER-NAMEが "sample-size"のMEMBERとMEMBER-VALUEが負でないINTEGER（セクション3.1の「通常」の「sample-size」を参照）
gen-value: a MEMBER with MEMBER-NAME "generated" and MEMBER-VALUE a non-negative INTEGER (see "generated" in Section 3.1)
gen-value：MEMBER-NAMEが "生成された" MEMBERとMEMBER-VALUEが負でないINTEGER（セクション3.1の "generated"を参照）
expire-value: a MEMBER with MEMBER-NAME "expires" and MEMBER-VALUE a non-negative INTEGER (see "expires" in Section 3.1)
expire-value：MEMBER-NAMEが「expires」であるMEMBERとMEMBER-VALUEが負でないINTEGERである（セクション3.1の「expires」を参照）
ext-value: a MEMBER, for extension purposes; MEMBER-NAME and MEMBER-VALUE will be defined in separate application registrations
ext-value：拡張を目的としたMEMBER。 MEMBER-NAMEとMEMBER-VALUEは、個別のアプリケーション登録で定義されます
The following simple example:
次の簡単な例：
Content-Type: application/reputon+json
{
"application": "baseball",
"reputons": [
{
"rater": "RatingsRUs.example.com",
"assertion": "is-good",
"rated": "Alex Rodriguez",
"rating": 0.99,
"sample-size": 50000
}
]
}
...indicates to the client that "RatingsRUs.example.com" consolidated 50000 data points (perhaps from everyone in Yankee Stadium) and concluded that Alex Rodriguez is very, very good (0.99) at something. It doesn't tell us what he's good at, and while it might be playing baseball, it could just as well be paying his taxes on time.
...「RatingsRUs.example.com」が50000データポイント（おそらくヤンキースタジアムの全員から）を統合したことをクライアントに示し、Alex Rodriguezが非常に優れている（0.99）と結論付けました。それは彼の得意分野を教えてくれません。野球をしているかもしれませんが、時間どおりに彼の税金を払っているのかもしれません。
A more sophisticated usage would define a baseball application with a response set of specific assertions, so that this example:
より洗練された使用法は、特定のアサーションの応答セットで野球アプリケーションを定義するため、この例は次のようになります。
Content-Type: application/reputon+json
{
"application": "baseball",
"reputons:" [
{
"rater": "baseball-reference.example.com",
"assertion": "hits-for-power",
"rated": "Alex Rodriguez",
"rating": 0.99,
"sample-size": 50000
}
]
}
...would indicate that 50000 fans polled by the entity baseball-reference.example.com rate Alex Rodriguez very highly in hitting for power, whereas this example:
...エンティティbaseball-reference.example.comによって投票された50000人のファンが力を打つことでAlex Rodriguezを非常に高く評価しているのに対し、この例では：
Content-Type: application/reputon+json
{
"application": "baseball",
"reputons": [
{
"rater": "baseball-reference.example.com",
"assertion": "strong-hitter",
"rated": "Alex Rodriguez",
"rating": 0.4,
"confidence": 0.2,
"sample-size": 50000
}
]
}
...would indicate that a similar poll indicated a somewhat weak consensus that Alex Rodriguez tends to fail in critical batting situations during baseball games.
...同様の世論調査は、アレックスロドリゲスが野球の試合中に重要な打撃状況で失敗する傾向があるというやや弱いコンセンサスを示したことを示します。
The following is an example reputon generated using this schema, including the media type definition line that identifies a specific reputation application context. Here, reputation agent "rep.example.net" is asserting within the context of the "email-id" application (see [RFC7073]) that "example.com" appears to be associated with spam 1.2% of the time, based on just short of 17 million messages analyzed or reported to date. The "email-id" application has declared the extension key "email-id-identity" to indicate how the subject identifier was used in the observed data, establishing some more-specific semantics for the "rating" value. In this case, the extension is used to show the identity "example.com", the subject of the query, is extracted from the analyzed messages using the DomainKeys Identified Mail [DKIM] "d=" parameter for messages where signatures validate. The reputation agent is 95% confident of this result. A second reputon is also present indicating similar information for the same domain as it is used in the context of Sender Policy Framework [SPF] evaluations. (See [RFC7073] for details about the registered email identifiers application.)
以下は、特定のレピュテーションアプリケーションコンテキストを識別するメディアタイプ定義行を含め、このスキーマを使用して生成されたレプトンの例です。ここで、レピュテーションエージェント「rep.example.net」は、「email-id」アプリケーション（[RFC7073]を参照）のコンテキスト内で、「example.com」が1.2％の時間、スパムに関連付けられているように見えることをアサートしています。これまでに分析または報告されたメッセージは1,700万件に達していません。 「email-id」アプリケーションは、拡張データ「email-id-identity」を宣言して、観測されたデータで件名IDがどのように使用されたかを示し、「rating」値の特定のセマンティクスを確立しています。この場合、拡張機能は、クエリの件名であるID「example.com」を表示するために使用され、署名が検証されるメッセージのDomainKeys Identified Mail [DKIM] "d ="パラメータを使用して、分析されたメッセージから抽出されます。評判エージェントは、この結果に95％自信を持っています。送信者ポリシーフレームワーク[SPF]評価のコンテキストで使用されるのと同じドメインの同様の情報を示す2番目の評判も存在します。 （登録されたEメールIDアプリケーションの詳細については、[RFC7073]を参照してください。）
Content-Type: application/reputon+json
{
"application": "email-id",
"reputons": [
{
"rater": "rep.example.net",
"assertion": "spam",
"identity": "dkim",
"rated": "example.com",
"confidence": 0.95,
"rating": 0.012,
"sample-size": 16938213,
"updated": 1317795852
},
{
"rater": "rep.example.net",
"assertion": "spam",
"identity": "spf",
"rated": "example.com",
"confidence": 0.98,
"rating": 0.023,
"sample-size": 16938213,
"updated": 1317795852
}
]
}
This document presents two actions for IANA -- namely, the creation of the new media type "application/reputon+json" and the creation of a registry for reputation application types. Another document in this series creates an initial registry entry for the latter.
このドキュメントでは、IANAの2つのアクション、つまり、新しいメディアタイプ「application / reputon + json」の作成とレピュテーションアプリケーションタイプのレジストリの作成について説明します。このシリーズの別のドキュメントでは、後者の初期レジストリエントリを作成しています。
This section provides the media type registration application from [MIME-REG] for processing by IANA.
このセクションは、IANAによる処理のための[MIME-REG]からのメディアタイプ登録アプリケーションを提供します。
To: media-types@iana.org
と： めぢあーｔｙぺｓ＠いあな。おｒｇ
Subject: Registration of media type application/reputon+json
Type name: application
タイプ名：アプリケーション
Subtype name: reputon+json Required parameters: none
サブタイプ名：reputon + json必須パラメーター：なし
Optional parameters: none
オプションのパラメーター：なし
Encoding considerations: "7bit" encoding is sufficient and is used to maintain readability when viewed by non-MIME mail readers.
エンコーディングに関する考慮事項：「7ビット」エンコーディングで十分であり、MIME以外のメールリーダーで表示したときに読みやすさを維持するために使用されます。
Security considerations: See Section 8 of [RFC7071].
セキュリティに関する考慮事項：[RFC7071]のセクション8をご覧ください。
Interoperability considerations: Implementers may encounter "app" values, attribute/value pairs, or response set items that they do not support, which are to be ignored.
相互運用性の考慮事項：実装者は、「アプリ」の値、属性/値のペア、またはサポートされていない応答セット項目を検出する可能性がありますが、無視されます。
Published specification: [RFC7071]
公開された仕様：[RFC7071]
Applications that use this media type: Any application that wishes to query a service that provides reputation data using the form defined in [RFC7072]. The example application is one that provides reputation data about DNS domain names and other identifiers found in email messages.
このメディアタイプを使用するアプリケーション：[RFC7072]で定義されたフォームを使用して、レピュテーションデータを提供するサービスにクエリを実行する必要があるアプリケーション。サンプルアプリケーションは、DNSドメイン名および電子メールメッセージに含まれるその他の識別子に関するレピュテーションデータを提供するアプリケーションです。
Fragment identifier considerations: N/A
フラグメント識別子の考慮事項：なし
Additional information: The value of the "app" parameter is registered with IANA.
追加情報：「app」パラメーターの値はIANAに登録されています。
Deprecated alias names for this type: N/A
このタイプの非推奨のエイリアス名：N / A
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information:
詳細について連絡する人とメールアドレス：
Murray S. Kucherawy <superuser@gmail.com>
Intended usage: COMMON
使用目的：COMMON
Restrictions on usage: N/A
使用上の制限：N / A
Author: Nathaniel Borenstein Murray S. Kucherawy
著者：ナサニエルボレンシュタインマレーS.クチェラウィ
Change controller: IESG Provisional registration?: no
コントローラの変更：IESG仮登録？：いいえ
IANA has created the "Reputation Applications" registry. This registry contains names of applications used with the application/reputon+json media type (and other media types that carry reputons), as defined by this document.
IANAは「レピュテーションアプリケーション」レジストリを作成しました。このレジストリには、このドキュメントで定義されているように、application / reputon + jsonメディアタイプ（およびレピュトンを運ぶ他のメディアタイプ）で使用されるアプリケーションの名前が含まれています。
New registrations or updates are published in accordance with either the "IETF Review" or "Specification Required" guidelines as described in [IANA-CONSIDERATIONS].
[IANA-CONSIDERATIONS]で説明されている「IETFレビュー」または「仕様が必要」のガイドラインに従って、新規登録または更新が公開されます。
New registrations and updates are to contain the following information:
新規登録と更新には、次の情報が含まれています。
1. Symbolic name of the application being registered or updated. Valid names conform to the ABNF construction "token" as defined in Multipurpose Internet Mail Extensions (MIME) Part One [MIME]
1. 登録または更新されるアプリケーションの記号名。有効な名前は、多目的インターネットメール拡張機能（MIME）パート1 [MIME]で定義されているABNF構造「トークン」に準拠しています。
2. Short description of the application (i.e., the class of entity about which it reports reputation data)
2. アプリケーションの簡単な説明（つまり、レピュテーションデータを報告するエンティティのクラス）
3. The document in which the application is defined
3. アプリケーションが定義されているドキュメント
4. New or updated status, which is to be one of:
4. 新規または更新されたステータス。次のいずれかになります。
current: The application is in current use
current：アプリケーションは現在使用中です
deprecated: The application is in current use but its use is discouraged
非推奨：アプリケーションは現在使用中ですが、その使用は推奨されません
historic: The application is no longer in current use
歴史的：アプリケーションは現在使用されていません
A specification for an application space needs to be specific and clear enough to allow interoperability, and include at least the following details:
アプリケーションスペースの仕様は、相互運用性を可能にするのに十分具体的で明確である必要があり、少なくとも以下の詳細が含まれます。
o The application's symbolic name, as it appears in the registration (see above)
o 登録に表示されるアプリケーションの記号名（上記を参照）
o A description of the subject of a query within this reputation, and a legal syntax for the same
o このレピュテーション内のクエリの件名の説明、およびそのための有効な構文
o An optional table of query parameters that are specific to this application; each table entry must include:
o このアプリケーションに固有のクエリパラメータのオプションのテーブル。各テーブルエントリには、
Name: Name of the query parameter
名前：クエリパラメータの名前
Status: (as above)
ステータス：（上記）
Description: A short description of the purpose of this parameter
説明：このパラメーターの目的の短い説明
Syntax: A reference to a description of valid syntax for the parameter's value
構文：パラメーターの値の有効な構文の説明への参照
Required: "yes" if the parameter is mandatory; "no" otherwise
必須：パラメーターが必須の場合は「はい」。それ以外の場合は「いいえ」
o A list of one or more assertions registered within this application; each table entry is to include:
o このアプリケーション内に登録されている1つ以上のアサーションのリスト。各テーブルエントリには以下が含まれます。
Name: Name of the assertion
名前：アサーションの名前
Description: A short description of the assertion, with specific meanings for values of 0.0 and 1.0
説明：0.0と1.0の値の特定の意味を持つアサーションの短い説明
Scale: A short description of the scale used in computing the value (see Section 4 of this document)
スケール：値の計算に使用されるスケールの簡単な説明（このドキュメントのセクション4を参照）
o An optional list of one or more response set extension keys for use within this application; each table entry is to include:
o このアプリケーション内で使用する1つ以上の応答セット拡張キーのオプションリスト。各テーブルエントリには以下が含まれます。
Name: Name of the extension key
名前：拡張キーの名前
Description: A short description of the key's intended meaning
説明：キーの意図する意味の短い説明
Syntax: A description of valid values that can appear associated with the key
構文：キーに関連して表示される有効な値の説明
The names of attributes registered should be prefixed by the name of the application itself (e.g., the "foo" application registering a "bar" attribute should call it "foo-bar") to avoid namespace collisions.
登録された属性の名前には、アプリケーション自体の名前をプレフィックスとして付ける必要があります（たとえば、「bar」属性を登録する「foo」アプリケーションは「foo-bar」と呼ぶ必要があります）。名前空間の衝突を回避するためです。
For registrations qualifying under "Specification Required" rules, the Designated Expert [IANA-CONSIDERATIONS] should confirm the document meets the minima described above and otherwise looks generally acceptable, and then approve the registration.
「Specification Required」ルールの対象となる登録の場合、Designated Expert [IANA-CONSIDERATIONS]は、ドキュメントが上記の最小要件を満たしていることを確認する必要があります。そうでない場合は、一般的に受け入れ可能と思われ、登録を承認します。
This document is primarily an IANA action registering a media type. It does not describe a new protocol that might introduce security considerations.
このドキュメントは、主にメディアタイプを登録するIANAアクションです。セキュリティに関する考慮事項を導入する可能性のある新しいプロトコルについては説明していません。
Discussion of the security and operational impacts of using reputation services in general can be found throughout [CONSIDERATIONS].
レピュテーションサービスの一般的な使用によるセキュリティと運用への影響については、[検討事項]全体で説明されています。
[JSON] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[JSON] Crockford、D。、「JavaScript Object Notation（JSON）のアプリケーション/ jsonメディアタイプ」、RFC 4627、2006年7月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC7070] Borenstein, N., Kucherawy, M., and A. Sullivan, "An Architecture for Reputation Reporting", RFC 7070, November 2013.
[RFC7070] Borenstein、N.、Kucherawy、M.、and A. Sullivan、 "An Architecture for Reputation Reporting"、RFC 7070、2013年11月。
[RFC7072] Borenstein, N. and M. Kucherawy, "A Reputation Query Protocol", RFC 7072, November 2013.
[RFC7072] Borenstein、N.およびM. Kucherawy、「A Reputation Query Protocol」、RFC 7072、2013年11月。
[CONSIDERATIONS] Kucherawy, M., "Operational Considerations Regarding Reputation Services", Work in Progress, May 2013.
[考慮事項] Kucherawy、M。、「評判サービスに関する運用上の考慮事項」、進行中の作業、2013年5月。
[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, September 2011.
[DKIM] Crocker、D。、編、Hansen、T。、編、およびM. Kucherawy、編、「DomainKeys Identified Mail（DKIM）Signatures」、STD 76、RFC 6376、2011年9月。
[IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[IANA-CONSIDERATIONS] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[MIME-REG] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013.
[MIME-REG] Freed、N.、Klensin、J。、およびT. Hansen、「メディアタイプの仕様と登録手順」、BCP 13、RFC 6838、2013年1月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年11月。
[RFC7073] Borenstein, N. and M. Kucherawy, "A Reputation Response Set for Email Identifiers", RFC 7073, November 2013.
[RFC7073] Borenstein、N。およびM. Kucherawy、「A Email Reidentation Response Set for Email Identifiers」、RFC 7073、2013年11月。
[SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006.
[SPF] Wong、M。およびW. Schlitt、「電子メールでのドメインの使用を許可するための送信者ポリシーフレームワーク（SPF）、バージョン1」、RFC 4408、2006年4月。
The authors wish to acknowledge the contributions of the following to this specification: Frank Ellermann, Tony Hansen, Jeff Hodges, Simon Hunt, John Levine, David F. Skoll, and Mykyta Yevstifeyev.
著者は、この仕様に対する次の貢献を認めたいと思います：フランクエラーマン、トニーハンセン、ジェフホッジス、サイモンハント、ジョンレバイン、デビッドF.スコール、およびミキタイェフスティフェエフ。
Authors' Addresses
著者のアドレス
Nathaniel Borenstein Mimecast 203 Crescent St., Suite 303 Waltham, MA 02453 USA
Nathaniel Borenstein Mimecast 203 Crescent St.、Suite 303 Waltham、MA 02453 USA
Phone: +1 781 996 5340
EMail: nsb@guppylake.com
Murray S. Kucherawy 270 Upland Drive San Francisco, CA 94127 USA
マレーS.クチェラウィ270アップランドドライブサンフランシスコ、カリフォルニア94127アメリカ
EMail: superuser@gmail.com