Internet Engineering Task Force (IETF) N. Borenstein
Request for Comments: 7072 Mimecast
Category: Standards Track M. Kucherawy
ISSN: 2070-1721 November 2013
Internet Engineering Task Force (IETF) N. Borenstein
Request for Comments: 7072 Mimecast
Category: Standards Track M. Kucherawy
ISSN: 2070-1721 November 2013
A Reputation Query Protocol
信誉查询协议
Abstract
摘要
This document defines a mechanism to conduct queries for reputation information over the HyperText Transfer Protocol (HTTP) using JavaScript Object Notation (JSON) as the payload meta-format.
本文档定义了一种使用JavaScript对象表示法（JSON）作为有效负载元格式，通过超文本传输协议（HTTP）查询信誉信息的机制。
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/rfc7072.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7072.
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 .....................................2
2.1. Key Words ..................................................2
2.2. Other Definitions ..........................................3
3. Description .....................................................3
3.1. Overview ...................................................3
3.2. URI Template ...............................................3
3.3. Syntax .....................................................4
3.4. Response ...................................................6
3.5. Protocol Support ...........................................6
4. IANA Considerations .............................................7
5. Security Considerations .........................................7
6. References ......................................................8
6.1. Normative References .......................................8
6.2. Informative References .....................................8
Appendix A. Acknowledgements .......................................9
1. Introduction ....................................................2
2. Terminology and Definitions .....................................2
2.1. Key Words ..................................................2
2.2. Other Definitions ..........................................3
3. Description .....................................................3
3.1. Overview ...................................................3
3.2. URI Template ...............................................3
3.3. Syntax .....................................................4
3.4. Response ...................................................6
3.5. Protocol Support ...........................................6
4. IANA Considerations .............................................7
5. Security Considerations .........................................7
6. References ......................................................8
6.1. Normative References .......................................8
6.2. Informative References .....................................8
Appendix A. Acknowledgements .......................................9
This document defines a method to query a reputation data service for information about an entity, using the HyperText Transfer Protocol (HTTP) as the transport mechanism and JSON as the payload meta-format.
本文档定义了一种查询信誉数据服务以获取实体信息的方法，使用超文本传输协议（HTTP）作为传输机制，JSON作为有效负载元格式。
The mechanism is a two-stage query:
该机制是一个两阶段查询：
1. A client retrieves a template from a server that describes the construction of a Universal Resource Identifier (URI) that will be the actual query;
1. 客户机从服务器检索模板，该模板描述将作为实际查询的通用资源标识符（URI）的构造；
2. The client then uses the constructed URI to request the reputation data from the server.
2. 然后，客户端使用构造的URI从服务器请求信誉数据。
This section defines terms used in the rest of the document.
本节定义了文档其余部分中使用的术语。
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] and [RFC7071].
[RFC7070]和[RFC7071]中定义了本文件中的其他重要术语。
The components to the question being asked are the following:
所问问题的组成部分如下：
o The subject of the query;
o 查询的主题；
o The name of the host, or the IP address, at which the reputation service is available;
o 信誉服务可用的主机名或IP地址；
o The name of the reputation application, i.e., the context within which the subject is being evaluated;
o 声誉申请的名称，即评估对象的上下文；
o Optionally, names of the specific reputation assertions or attributes that are being requested.
o （可选）请求的特定信誉断言或属性的名称。
There is no discovery protocol for finding reputation services. These are typically subscription services, negotiated between operators through some out-of-band method.
没有用于查找信誉服务的发现协议。这些通常是订阅服务，由运营商通过一些带外方法进行协商。
Assertions are discussed in [RFC7071].
断言在[RFC7071]中讨论。
The name of the application, if given, is expected to be one registered with IANA in the "Reputation Applications" registry, which is defined in [RFC7071]. A server receiving a query about an application it does not recognize or explicitly support (e.g., by virtue of private agreements or experimental extensions) MUST return a 404 error code.
应用程序的名称（如果给定）应为在IANA的“声誉应用程序”注册中心注册的名称，该注册中心在[RFC7071]中定义。接收到关于其不识别或不明确支持的应用程序的查询的服务器（例如，通过私有协议或实验扩展）必须返回404错误代码。
A reputation query made via [HTTP] encodes the question being asked in an HTTP GET method. The specific syntax of the query itself is specified by retrieving a URI template from the reputation service, completing the template, and then issuing the query.
通过[HTTP]进行的信誉查询对HTTP GET方法中提出的问题进行编码。查询本身的特定语法是通过从信誉服务检索URI模板、完成模板，然后发出查询来指定的。
The template file is retrieved by requesting the [WELL-KNOWN-URI] "repute-template" from the host providing reputation service, using HTTP. (The registration for this well-known URI is in Section 4.) The server returns the template file in a reply that MUST use the
通过使用HTTP从提供声誉服务的主机请求[WELL-KNOWN-URI]“声誉模板”来检索模板文件。（这个众所周知的URI的注册在第4节中。）服务器在回复中返回模板文件，该文件必须使用
text/plain media type (see [MIME]) and SHOULD include an Expires field (see Section 14.21 of [HTTP]) indicating a duration for which the template is to be considered valid by clients and not re-queried.
文本/纯媒体类型（请参见[MIME]），并应包括一个Expires字段（请参见[HTTP]第14.21节），指示客户端认为模板有效且不重新查询的持续时间。
If an Expires field is present, the client SHOULD NOT send another query to the same server prior to the timestamp in the field. If no Expires field is present, the client SHOULD wait at least one day before sending another query to the same server (i.e., the client assumes a default expiration of one day).
如果存在Expires字段，则客户端不应在字段中的时间戳之前向同一服务器发送另一个查询。如果不存在Expires字段，则客户端应至少等待一天，然后再向同一服务器发送另一个查询（即，客户端假定默认过期一天）。
The template file might contain more than one template. Such a file MUST have each template separated by a carriage return (ASCII 0x0D) and newline (ASCII 0x0A) character, as is typical for most text-based Internet protocols.
模板文件可能包含多个模板。这样的文件必须使用回车符（ASCII 0x0D）和换行符（ASCII 0x0A）分隔每个模板，这对于大多数基于文本的Internet协议来说是典型的。
Each template in the file is expanded using the variables that are the parameters to the query. These parameters are either the subject about which reputation information is sought (or details associated with it) or other parameters that are established out-of-band with the reputation service; they are not established by any automated discovery described here. The client then attempts to query each expanded template that uses a URI scheme it is capable of querying, in the order presented in the file, until the client finds one to which it can establish a usable connection and issue the query.
文件中的每个模板都使用作为查询参数的变量展开。这些参数要么是寻求声誉信息的主题（或与之相关的详细信息），要么是在声誉服务的频带外建立的其他参数；它们不是通过此处描述的任何自动发现建立的。然后，客户机尝试按照文件中显示的顺序查询每个使用URI方案的扩展模板，直到客户机找到一个可以建立可用连接的模板并发出查询。
For example, given the following template:
例如，给定以下模板：
http://{service}/{application}/{subject}/{assertion}
http://{service}/{application}/{subject}/{assertion}
A query about the use of the domain "example.org" in the "email-id" application context to a service run at "example.com", where that application declares a required "subject" parameter, requesting the "SPAM" reputation assertion, would be formed as follows:
关于在“email id”应用程序上下文中将域“example.org”用于“example.com”上运行的服务的查询，其中该应用程序声明所需的“subject”参数，请求“SPAM”信誉断言，将按如下方式形成：
http://example.com/email-id/example.org/spam
http://example.com/email-id/example.org/spam
The syntax for the [URI] of the query is constructed using a template as per [URI-TEMPLATE]. (See Section 3.2.) Clients MUST provide the following values in the expansion of the template:
查询的[URI]的语法是根据[URI-template]使用模板构造的。（参见第3.2节。）客户必须在模板扩展中提供以下值：
application: The name of the application reputation in whose context the request is being made. These names are registered with IANA, and conform to the ABNF "token" found in [MIME].
应用程序：在其上下文中发出请求的应用程序的名称。这些名称在IANA注册，并符合[MIME]中的ABNF“标记”。
service: The hostname or IP address to which the query is being sent. This MUST be the same as the host to which the template query was issued.
服务：将查询发送到的主机名或IP地址。这必须与向其发出模板查询的主机相同。
subject: The subject of the query, extracted from some content to be evaluated. The subject portion of the template conforms to the ABNF "value" found in [MIME].
主题：查询的主题，从要评估的某些内容中提取。模板的主题部分符合[MIME]中的ABNF“值”。
The following variable can also be provided. It is not mandatory in this model, but a specific application (defined in its own extension document) might declare it mandatory in a specific context:
还可以提供以下变量。在该模型中，它不是强制性的，但特定应用程序（在其自己的扩展文档中定义）可能会在特定上下文中声明它是强制性的：
assertion: The name of the specific assertion of interest to the client. Assertion names conform to the ABNF "token" found in [MIME]. If absent, the client is indicating that it requests all available assertion information.
断言：客户端感兴趣的特定断言的名称。断言名称符合[MIME]中的ABNF“标记”。如果不存在，客户端将指示它请求所有可用的断言信息。
If a template contains a variable that is not required and the client does not have a value to insert, it substitutes the empty string into the template in place of that variable. Service providers crafting templates MUST do so such that a client doing an empty variable expansion will still produce a syntactically and semantically valid and unambiguous URI. For example, given this template:
如果模板包含不需要的变量，并且客户端没有要插入的值，则会将空字符串替换为模板中的该变量。制作模板的服务提供商必须这样做，以便执行空变量扩展的客户端仍然会生成语法和语义上有效且明确的URI。例如，给定此模板：
http://{service}/{application}/{subject}/{assertion}/{a}/{b}
http://{service}/{application}/{subject}/{assertion}/{a}/{b}
If "{a}" and "{b}" are optional and "{a}" expands to the empty string, then the resulting URI will have adjacent backslash ("/", ASCII 0x2F) characters and one path component after the assertion. If the server interpreting the URI's path component removes or ignores adjacent backslash characters (such as is done with the UNIX filesystem), the server will be unable to distinguish an empty "{a}" from an empty "{b}", and it could serve the wrong response. Where possible, the template needs to be constructed such that expansion of optional variables yields an unambiguous result. For example, an unambiguous version of the above would be:
如果“{a}”和“{b}”是可选的，并且“{a}”扩展为空字符串，则生成的URI将具有相邻的反斜杠（“/”，ASCII 0x2F）字符和断言后的一个路径组件。如果解释URI路径组件的服务器删除或忽略相邻的反斜杠字符（例如UNIX文件系统），服务器将无法区分空的“{a}”和空的“{b}”，并且它可能提供错误的响应。在可能的情况下，模板的构造需要使可选变量的扩展产生明确的结果。例如，上述内容的明确版本为：
http://{service}/{application}/{subject}/{assertion}/a={a}/b={b}
http://{service}/{application}/{subject}/{assertion}/a={a}/b={b}
...or, even better, using URI template set expansions:
…或者，更好的是，使用URI模板集扩展：
http://{service}/{application}/{subject}/{assertion}{?a,b}
http://{service}/{application}/{subject}/{assertion}{?a,b}
Every application space has a set of assertions applicable to its own context. [RFC7071] defines a single assertion assumed to exist in any application that does not define its own assertion set.
每个应用程序空间都有一组适用于其自身上下文的断言。[RFC7071]定义一个假定存在于任何未定义自己的断言集的应用程序中的断言。
Reputation applications can extend the set of optional or required query parameters as part of their IANA registration actions. The set enumerated above establishes the base set common to all of them. Further, additional required or optional extension query parameters might be defined by specific reputation service providers, though these are private arrangements between client and server and will not be registered with IANA.
声誉应用程序可以扩展可选或必需的查询参数集，作为其IANA注册操作的一部分。上面列举的集合建立了它们共同的基集合。此外，其他必需或可选的扩展查询参数可能由特定的声誉服务提供商定义，尽管这些是客户端和服务器之间的私人协议，不会在IANA注册。
Authentication between reputation client and server is outside the scope of this specification. It could be provided through a variety of available transport-based or object-based mechanisms, including a later extension of this specification.
信誉客户端和服务器之间的身份验证不在本规范的范围内。它可以通过各种可用的基于传输或基于对象的机制提供，包括本规范的后续扩展。
The response is expected to be contained in a media type designed to deliver reputons. A media type designed for this purpose, "application/reputon+json", is defined in [RFC7071].
预期响应将包含在一种设计用于提供reputons的媒体类型中。[RFC7071]中定义了为此目的而设计的媒体类型“application/reputon+json”。
If the server generates responses that contain an Expires field (see Section 14.21 of [HTTP]), that timestamp MUST align with the "expires" field within the response, if any. Failing to do so can result in a state where the response has expired, but the HTTP reply has not, and the client would in that case be unable to get a fresh answer from the reputation server.
如果服务器生成的响应包含Expires字段（请参阅[HTTP]第14.21节），则该时间戳必须与响应中的“Expires”字段（如果有）对齐。如果不这样做，可能会导致响应已过期，但HTTP应答尚未过期，在这种情况下，客户端将无法从信誉服务器获得新的响应。
A client has to implement HTTP in order to retrieve the query template as described in Section 3.2. Accordingly, a server can assume the client will be able to handle a URI template that produces a URI for the query using the "http" URI scheme. The template could yield a query string that uses some other URI scheme, in which case the client could try that URI as well if it supports issuing queries with that URI scheme.
客户机必须实现HTTP才能检索查询模板，如第3.2节所述。因此，服务器可以假设客户端将能够处理使用“http”URI方案为查询生成URI的URI模板。模板可以生成一个使用其他URI方案的查询字符串，在这种情况下，如果客户端支持使用该URI方案发出查询，那么客户端也可以尝试该URI。
A server SHOULD include support for providing service over HTTP, and publish templates indicating support for this, as a baseline for interoperability with arbitrary clients.
服务器应包括对通过HTTP提供服务的支持，并发布指示对此支持的模板，作为与任意客户端互操作性的基准。
This document registers the "repute-template" well-known URI in the "Well-Known URI" registry as defined by [WELL-KNOWN-URI], as follows:
本文档在[well-known-URI]定义的“well-known-URI”注册表中注册“声誉模板”众所周知的URI，如下所示：
URI suffix: repute-template
URI后缀：声誉模板
Change controller: IETF
更改控制器：IETF
Specification document(s): [RFC7072]
规范文件：[RFC7072]
Related information: none
相关信息：无
This document defines particular uses of existing protocols for a specific application. In particular, the basic protocol used for this service to retrieve a URI template from a well-known location is basic HTTP, which is not secure without certain extensions. Security issues relevant to use of URI templates are discussed in [URI-TEMPLATE], and those relevant to well-known URI definitions and retrieval are discussed in [WELL-KNOWN-URI].
本文档定义了现有协议在特定应用中的特定用途。特别是，此服务用于从已知位置检索URI模板的基本协议是基本HTTP，如果没有某些扩展，它是不安全的。与URI模板使用相关的安全问题在[URI-TEMPLATE]中讨论，与众所周知的URI定义和检索相关的安全问题在[well-known-URI]中讨论。
The reputation service itself will use HTTP or other transport methods to issue queries and receive replies. Those protocols have registered URI schemes and, as such, presumably have documented security considerations. The protocol described here operates atop those URI schemes, and does not itself present new security considerations.
信誉服务本身将使用HTTP或其他传输方法来发出查询和接收回复。这些协议已经注册了URI方案，因此可能已经记录了安全注意事项。这里描述的协议在这些URI方案之上运行，并且本身没有提出新的安全考虑。
Reputation mechanisms represent an obvious security concern, in terms of the validity and use of the reputation information. These issues are beyond the scope of this specification. General information pertaining to using or providing reputation services can be found in [CONSIDERATIONS].
声誉机制在声誉信息的有效性和使用方面表现出明显的安全问题。这些问题超出了本规范的范围。有关使用或提供声誉服务的一般信息，请参见[注意事项]。
The security considerations applicable to HTTP (see Section 15 of [HTTP] apply, since this query mechanism for reputation uses that protocol. If it is desirable to conceal the content of the query and its response, use of encryption techniques such as HTTP over TLS [HTTPS] can be used.
适用于HTTP的安全注意事项（见[HTTP]第15节）适用，因为此声誉查询机制使用该协议。如果需要隐藏查询内容及其响应，可以使用加密技术，如HTTP over TLS[HTTPS]。
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[HTTP]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[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月。
[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月。
[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月。
[RFC7071] Borenstein, N. and M. Kucherawy, "A Media Type for Reputation Interchange", RFC 7071, November 2013.
[RFC7071]Borenstein，N.和M.Kucherawy，“声誉交换的媒体类型”，RFC 7071，2013年11月。
[URI-TEMPLATE] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, March 2012.
[URI-TEMPLATE]Gregorio，J.，Fielding，R.，Hadley，M.，Nottingham，M.，和D.Orchard，“URI模板”，RFC 65702012年3月。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[URI]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[WELL-KNOWN-URI] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010.
[WELL-KNOWN-URI]诺丁汉，M.和E.Hammer Lahav，“定义众所周知的统一资源标识符（URI）”，RFC 57852010年4月。
[CONSIDERATIONS] Kucherawy, M., "Operational Considerations Regarding Reputation Services", Work in Progress, May 2013.
[考虑]Kucherawy，M.“声誉服务的运营考虑”，正在进行的工作，2013年5月。
[HTTPS] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[HTTPS]Rescorla，E.，“TLS上的HTTP”，RFC 28182000年5月。
The authors would like to thank the following for their contributions to this work: Simon Hunt, Mark Nottingham, David F. Skoll, and Mykyta Yevstifeyev.
作者要感谢以下对这项工作的贡献：西蒙·亨特、马克·诺丁汉、大卫·F·斯科尔和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