Internet Engineering Task Force (IETF) N. Borenstein
Request for Comments: 7071 Mimecast
Category: Standards Track M. Kucherawy
ISSN: 2070-1721 November 2013
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.
本文档定义了声誉响应数据（“reputons”）的格式、打包的媒体类型，以及声誉应用程序和响应集名称注册的定义。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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.
“信誉”是包含信誉信息的单个独立对象。根据服务器收集和报告的数据的性质，有关感兴趣主题的特定查询将收到一个或多个响应。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
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.
为表示reputon而选择的元格式是JavaScript对象表示法（JSON），在[JSON]中定义。因此，定义了一种新的媒体类型“application/reputon+json”，用于声誉数据的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.
评级者：聚合、计算和提供信誉信息的实体的身份，通常表示为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.
评级：被评级实体的标识。该领域的性质是特定于应用的；它可以是域名、电子邮件地址、驾照号码，或者任何唯一标识被评级实体的信息。需要定义特定声誉应用程序的文档来定义此字段的语法和语义。
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（含0.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（含0.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.
正常评级：表明声誉提供者通常期望对受试者的评级。这使客户能够注意到当前评级是否符合预期。
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.
样本量：用于计算评级的数据点数量，可能是近似值。表示为无符号64位整数。消费者可以假设计数指的是不同的数据点，而不是聚合计数（例如，单个投票计数而不是聚合投票计数），除非在带外指定其他解释更合适。由于并非所有声誉服务提供商都会以相同的方式收集数据，因此故意不规范地指定这些单位。
generated: A timestamp indicating when this value was generated. Expressed as the number of seconds since January 1, 1970 00:00 UTC.
已生成：指示此值生成时间的时间戳。表示为自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.
expires：一个时间戳，指示超过该时间报告的分数可能无效。表示为自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.
评分属性中显示为值的分数显示为介于0.0和1.0之间（含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.
reputon可以包含一个“expires”字段，该字段指示一个时间戳，在该时间戳之后，客户端不应使用它包含的评级，并应发出一个新的查询。
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表示的reputon是一组键-值对，其中键是组成reputon的特定属性的名称（如上所列，或与特定应用程序一起提供），值是与这些键关联的内容。在给定的应用程序中组成reputon的密钥集称为该应用程序的“响应集”。
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”的断言“发送垃圾邮件”的客户机将期望得到一个回复，该回复包含一个关于“example.com”的“发送垃圾邮件”断言的reputon，仅此而已。如果客户机发出关于主题的请求，但没有指定感兴趣的断言，则服务器可以返回关于其拥有数据的任何断言的声明；实际上，客户要求提供有关该主题的任何可用信息。接收到不相关的reputon的客户机只是忽略它。
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.
空的reputon是服务器确认已收到请求，并作为服务器没有请求的信息的肯定指示。这在语义上等同于返回“样本大小”为零的reputon。
[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对象，在[JSON]的第2.2节中定义
MEMBER: a member of a JSON object, defined in Section 2.2 of [JSON]
成员：JSON对象的成员，在[JSON]的第2.2节中定义
MEMBER-NAME: the name of a MEMBER, defined as a "string" in Section 2.2 of [JSON]
MEMBER-NAME：成员的名称，在[JSON]第2.2节中定义为“字符串”
MEMBER-VALUE: the value of a MEMBER, defined as a "value" in Section 2.2 of [JSON]
成员值：成员的值，在[JSON]的第2.2节中定义为“值”
ARRAY: an array, defined in Section 2.3 of [JSON]
数组：在[JSON]第2.3节中定义的数组
ARRAY-VALUE: an element of an ARRAY, defined in Section 2.3 of [JSON]
ARRAY-VALUE：数组的一个元素，在[JSON]的第2.3节中定义
NUMBER: a "number" as defined in Section 2.4 of [JSON]
编号：在[JSON]第2.4节中定义的“编号”
INTEGER: an "integer" as defined in Section 2.4 of [JSON]
整数：在[JSON]第2.4节中定义的“整数”
STRING: a "string" as defined in Section 2.5 of [JSON]
字符串：在[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-context: a MEMBER with MEMBER-NAME "application" and MEMBER-VALUE a STRING (see Section 3)
声誉上下文：成员名为“application”且成员值为字符串的成员（参见第3节）
reputon-list: a MEMBER with MEMBER-NAME "reputons" and MEMBER-VALUE a reputon-array
reputon列表：成员名为“reputons”且成员值为reputon数组的成员
reputon-array: an ARRAY, where each ARRAY-VALUE is a reputon
reputon数组：一个数组，其中每个数组值都是reputon
reputon: an OBJECT, where each MEMBER is a reputon-element
reputon：一个对象，其中每个成员都是reputon元素
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元素：下列元素之一，定义如下：评级值、断言值、评级值、评级值、配置值、正常值、样本值、gen值、过期值、ext值；注意以下几点：
* The order of reputon-element members is not significant.
* reputon元素成员的顺序不重要。
* A specific reputon-element MUST NOT appear more than once.
* 特定reputon元素不能出现多次。
* 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：成员名为“rater”且成员值为字符串的成员（参见第3.1节中的“rater”）
assertion-value: a MEMBER with MEMBER-NAME "assertion" and MEMBER-VALUE a STRING (see "assertion" in Section 3.1)
断言值：成员名为“断言”且成员值为字符串的成员（参见第3.1节中的“断言”）
rated-value: a MEMBER with MEMBER-NAME "rated" and MEMBER-VALUE a STRING (see "rated" in Section 3.1)
额定值：成员名称为“额定”且成员值为字符串的成员（见第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
评级值：成员名称为“评级”且成员值为0.0至1.0之间（含0.0至1.0）的成员（见第3.1节中的“评级”）；数字的精度不应超过小数点后三位
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：成员名为“confidence”，成员值为0.0到1.0之间的数字（见第3.1节中的“confidence”）；数字的精度不应超过小数点后三位
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
正常值：成员名称为“正常评级”且成员值为0.0到1.0之间（包括0.0和1.0）的成员（见第3.1节中的“正常”）；数字的精度不应超过小数点后三位
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)
样本值：成员名为“样本大小”且成员值为非负整数的成员（参见第3.1节“正常”中的“样本大小”）
gen-value: a MEMBER with MEMBER-NAME "generated" and MEMBER-VALUE a non-negative INTEGER (see "generated" in Section 3.1)
gen value：成员名称为“已生成”且成员值为非负整数的成员（参见第3.1节中的“已生成”）
expire-value: a MEMBER with MEMBER-NAME "expires" and MEMBER-VALUE a non-negative INTEGER (see "expires" in Section 3.1)
expire value：成员名为“expires”且成员值为非负整数的成员（参见第3.1节中的“expires”）
ext-value: a MEMBER, for extension purposes; MEMBER-NAME and MEMBER-VALUE will be defined in separate application registrations
ext值：用于扩展的成员；成员名称和成员值将在单独的应用程序注册中定义
The following simple example:
下面是一个简单的例子：
Content-Type: application/reputon+json
Content-Type: application/reputon+json
{
"application": "baseball",
"reputons": [
{
"rater": "RatingsRUs.example.com",
"assertion": "is-good",
"rated": "Alex Rodriguez",
"rating": 0.99,
"sample-size": 50000
}
]
}
{
"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个数据点（可能来自扬基球场的每个人），并得出结论，亚历克斯·罗德里格斯在某些方面非常出色（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
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
}
]
}
{
"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:
…表明实体BATTALE-reference.example.com调查的50000名球迷对亚历克斯·罗德里格斯（Alex Rodriguez）的击球能力评价非常高，而这个例子：
Content-Type: application/reputon+json
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
}
]
}
{
"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.)
下面是使用此模式生成的reputon示例，包括标识特定声誉应用程序上下文的媒体类型定义行。在这里，声誉代理“rep.example.net”在“email id”应用程序（参见[RFC7073]）的上下文中断言，“example.com”似乎有1.2%的时间与垃圾邮件相关，这是基于迄今为止分析或报告的1700万条短消息。“email id”应用程序声明了扩展键“email id identity”，以指示主题标识符在观察数据中的使用方式，从而为“rating”值建立了一些更具体的语义。在这种情况下，扩展名用于显示身份“example.com”，即查询的主题，它是使用DomainKeys Identified Mail[DKIM]”d=“签名有效的消息的参数从分析的消息中提取的。声誉代理对此结果有95%的信心。还存在第二个reputon，指示在发送方策略框架[SPF]评估的上下文中使用的相同域的类似信息。（有关已注册电子邮件标识符应用程序的详细信息，请参阅[RFC7073]）
Content-Type: application/reputon+json
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
}
]
}
{
"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的两个操作——即创建新的媒体类型“application/reputon+json”和创建信誉应用程序类型的注册表。本系列中的另一个文档为后者创建初始注册表项。
This section provides the media type registration application from [MIME-REG] for processing by IANA.
本节提供[MIME-REG]中的媒体类型注册应用程序，供IANA处理。
To: media-types@iana.org
致:传媒-types@iana.org
Subject: Registration of media type application/reputon+json
Subject: Registration of media type application/reputon+json
Type name: application
类型名称：应用程序
Subtype name: reputon+json
子类型名称：reputon+json
Required parameters: none
所需参数：无
Optional parameters: none
可选参数：无
Encoding considerations: "7bit" encoding is sufficient and is used to maintain readability when viewed by non-MIME mail readers.
编码注意事项：“7bit”编码已足够，用于在非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
此类型的已弃用别名：不适用
Magic number(s): N/A
Magic number(s): N/A
File extension(s): N/A
File extension(s): N/A
Macintosh file type code(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>
Murray S. Kucherawy <superuser@gmail.com>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: N/A
使用限制：不适用
Author: Nathaniel Borenstein Murray S. Kucherawy
作者：Nathaniel Borenstein Murray S.Kucherawy
Change controller: IESG
更改控制器：IESG
Provisional registration?: no
临时注册：否
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媒体类型（以及携带reputon的其他媒体类型）一起使用的应用程序的名称。
New registrations or updates are published in accordance with either the "IETF Review" or "Specification Required" guidelines as described in [IANA-CONSIDERATIONS].
根据[IANA-注意事项]中所述的“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. 正在注册或更新的应用程序的符号名称。有效名称符合多用途Internet邮件扩展（MIME）第一部分[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
当前：应用程序正在使用中
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
Name：查询参数的名称
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 在此应用程序中注册的一个或多个断言的列表；每个表格条目应包括：
Name: Name of the assertion
Name：断言的名称
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 在此应用程序中使用的一个或多个响应集扩展键的可选列表；每个表格条目应包括：
Name: Name of the extension key
Name：扩展密钥的名称
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.
对于符合“规范要求”规则的注册，指定专家[IANA-注意事项]应确认文件符合上述最低要求，否则看起来一般可以接受，然后批准注册。
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对象表示法（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.和A.Sullivan，“声誉报告架构”，RFC 70702013年11月。
[RFC7072] Borenstein, N. and M. Kucherawy, "A Reputation Query Protocol", RFC 7072, November 2013.
[RFC7072]Borenstein，N.和M.Kucherawy，“声誉查询协议”，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.，Ed.，Hansen，T.，Ed.，和M.Kucherawy，Ed.，“域密钥识别邮件（DKIM）签名”，STD 76，RFC 63762011年9月。
[IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[IANA注意事项]Narten，T.和H.Alvestrand，“在RFCs中编写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，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC7073] Borenstein, N. and M. Kucherawy, "A Reputation Response Set for Email Identifiers", RFC 7073, November 2013.
[RFC7073]Borenstein，N.和M.Kucherawy，“电子邮件标识符的声誉响应集”，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.
作者希望感谢以下人员对本规范的贡献：Frank Ellermann、Tony Hansen、Jeff Hodges、Simon Hunt、John Levine、David F.Skoll和Mykyta Yevstifeyev。
Authors' Addresses
作者地址
Nathaniel Borenstein Mimecast 203 Crescent St., Suite 303 Waltham, MA 02453 USA
美国马萨诸塞州沃尔瑟姆新月街203号303室Nathaniel Borenstein Mimecast 02453
Phone: +1 781 996 5340
EMail: nsb@guppylake.com
Phone: +1 781 996 5340
EMail: nsb@guppylake.com
Murray S. Kucherawy 270 Upland Drive San Francisco, CA 94127 USA
Murray S. Kucherawy 270高地驱动旧金山，CA 94127美国
EMail: superuser@gmail.com
EMail: superuser@gmail.com