Internet Engineering Task Force (IETF) A. Castellani
Request for Comments: 8075 University of Padova
Category: Standards Track S. Loreto
ISSN: 2070-1721 Ericsson
A. Rahman
InterDigital Communications, LLC
T. Fossati
Nokia
E. Dijk
Philips Lighting
February 2017
Internet Engineering Task Force (IETF) A. Castellani
Request for Comments: 8075 University of Padova
Category: Standards Track S. Loreto
ISSN: 2070-1721 Ericsson
A. Rahman
InterDigital Communications, LLC
T. Fossati
Nokia
E. Dijk
Philips Lighting
February 2017
Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)
映射实现指南：HTTP到受约束应用程序协议（CoAP）
Abstract
摘要
This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the Constrained Application Protocol (CoAP). This will enable an HTTP client to access resources on a CoAP server through the proxy. This document describes how an HTTP request is mapped to a CoAP request and how a CoAP response is mapped back to an HTTP response. This includes guidelines for status code, URI, and media type mappings, as well as additional interworking advice.
本文档提供了实现跨协议网络代理的参考信息，该代理执行从HTTP协议到受限应用程序协议（CoAP）的转换。这将使HTTP客户端能够通过代理访问CoAP服务器上的资源。本文档描述如何将HTTP请求映射到CoAP请求，以及如何将CoAP响应映射回HTTP响应。这包括状态代码、URI和媒体类型映射的指导原则，以及其他交互建议。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc8075.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8075.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. HTTP-to-CoAP Proxy . . . . . . . . . . . . . . . . . . . . . 6
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. URI Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. URI Terminology . . . . . . . . . . . . . . . . . . . . . 8
5.2. Null Mapping . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Default Mapping . . . . . . . . . . . . . . . . . . . . . 9
5.3.1. Optional Scheme Omission . . . . . . . . . . . . . . 9
5.3.2. Encoding Caveats . . . . . . . . . . . . . . . . . . 10
5.4. URI Mapping Template . . . . . . . . . . . . . . . . . . 10
5.4.1. Simple Form . . . . . . . . . . . . . . . . . . . . . 10
5.4.2. Enhanced Form . . . . . . . . . . . . . . . . . . . . 12
5.5. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 13
5.5.1. Examples . . . . . . . . . . . . . . . . . . . . . . 14
6. Media Type Mapping . . . . . . . . . . . . . . . . . . . . . 15
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. 'application/coap-payload' Media Type . . . . . . . . . . 16
6.3. Loose Media Type Mapping . . . . . . . . . . . . . . . . 17
6.4. Media Type to Content-Format Mapping Algorithm . . . . . 18
6.5. Content Transcoding . . . . . . . . . . . . . . . . . . . 19
6.5.1. General . . . . . . . . . . . . . . . . . . . . . . . 19
6.5.2. CoRE Link Format . . . . . . . . . . . . . . . . . . 20
6.6. Diagnostic Payloads . . . . . . . . . . . . . . . . . . . 20
7. Response Code Mapping . . . . . . . . . . . . . . . . . . . . 21
8. Additional Mapping Guidelines . . . . . . . . . . . . . . . . 23
8.1. Caching and Congestion Control . . . . . . . . . . . . . 23
8.2. Cache Refresh via Observe . . . . . . . . . . . . . . . . 24
8.3. Use of CoAP Block-Wise Transfer . . . . . . . . . . . . . 24
8.4. CoAP Multicast . . . . . . . . . . . . . . . . . . . . . 25
8.5. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9.1. New 'core.hc' Resource Type . . . . . . . . . . . . . . . 26
9.2. New 'coap-payload' Internet Media Type . . . . . . . . . 26
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
10.1. Multicast . . . . . . . . . . . . . . . . . . . . . . . 29
10.2. Traffic Overflow . . . . . . . . . . . . . . . . . . . . 29
10.3. Handling Secured Exchanges . . . . . . . . . . . . . . . 30
10.4. URI Mapping . . . . . . . . . . . . . . . . . . . . . . 30
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Media Type Mapping Source Code . . . . . . . . . . . 35
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. HTTP-to-CoAP Proxy . . . . . . . . . . . . . . . . . . . . . 6
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. URI Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. URI Terminology . . . . . . . . . . . . . . . . . . . . . 8
5.2. Null Mapping . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Default Mapping . . . . . . . . . . . . . . . . . . . . . 9
5.3.1. Optional Scheme Omission . . . . . . . . . . . . . . 9
5.3.2. Encoding Caveats . . . . . . . . . . . . . . . . . . 10
5.4. URI Mapping Template . . . . . . . . . . . . . . . . . . 10
5.4.1. Simple Form . . . . . . . . . . . . . . . . . . . . . 10
5.4.2. Enhanced Form . . . . . . . . . . . . . . . . . . . . 12
5.5. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 13
5.5.1. Examples . . . . . . . . . . . . . . . . . . . . . . 14
6. Media Type Mapping . . . . . . . . . . . . . . . . . . . . . 15
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. 'application/coap-payload' Media Type . . . . . . . . . . 16
6.3. Loose Media Type Mapping . . . . . . . . . . . . . . . . 17
6.4. Media Type to Content-Format Mapping Algorithm . . . . . 18
6.5. Content Transcoding . . . . . . . . . . . . . . . . . . . 19
6.5.1. General . . . . . . . . . . . . . . . . . . . . . . . 19
6.5.2. CoRE Link Format . . . . . . . . . . . . . . . . . . 20
6.6. Diagnostic Payloads . . . . . . . . . . . . . . . . . . . 20
7. Response Code Mapping . . . . . . . . . . . . . . . . . . . . 21
8. Additional Mapping Guidelines . . . . . . . . . . . . . . . . 23
8.1. Caching and Congestion Control . . . . . . . . . . . . . 23
8.2. Cache Refresh via Observe . . . . . . . . . . . . . . . . 24
8.3. Use of CoAP Block-Wise Transfer . . . . . . . . . . . . . 24
8.4. CoAP Multicast . . . . . . . . . . . . . . . . . . . . . 25
8.5. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9.1. New 'core.hc' Resource Type . . . . . . . . . . . . . . . 26
9.2. New 'coap-payload' Internet Media Type . . . . . . . . . 26
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
10.1. Multicast . . . . . . . . . . . . . . . . . . . . . . . 29
10.2. Traffic Overflow . . . . . . . . . . . . . . . . . . . . 29
10.3. Handling Secured Exchanges . . . . . . . . . . . . . . . 30
10.4. URI Mapping . . . . . . . . . . . . . . . . . . . . . . 30
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Media Type Mapping Source Code . . . . . . . . . . . 35
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
The Constrained Application Protocol (CoAP) [RFC7252] has been designed with a twofold aim: it's an application protocol specialized for constrained environments and it's easily used in architectures based on Representational State Transfer (REST) [Fielding], such as the web. The latter goal has led to defining CoAP to easily interoperate with HTTP [RFC7230] through an intermediary proxy that performs cross-protocol conversion.
受限应用程序协议（CoAP）[RFC7252]的设计有两个目的：它是一种专用于受限环境的应用程序协议，并且易于在基于表示状态传输（REST）[部署]的体系结构中使用，例如web。后一个目标导致定义CoAP，以便通过执行跨协议转换的中间代理轻松地与HTTP[RFC7230]互操作。
Section 10 of [RFC7252] describes the fundamentals of the CoAP-to-HTTP and the HTTP-to-CoAP cross-protocol mapping process. However, [RFC7252] focuses on the basic mapping of request methods and simple response code mapping between HTTP and CoAP, while leaving many details of the cross-protocol proxy for future definition. Therefore, a primary goal of this document is to define a consistent set of guidelines that an HTTP-to-CoAP proxy implementation should adhere to. The key benefit to adhering to such guidelines is to reduce variation between proxy implementations, thereby increasing interoperability between an HTTP client and a CoAP server independent of the proxy that implements the cross-protocol mapping. (For example, a proxy conforming to these guidelines made by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines without breaking API semantics.)
[RFC7252]的第10节描述了CoAP到HTTP和HTTP到CoAP跨协议映射过程的基本原理。然而，[RFC7252]侧重于请求方法的基本映射和HTTP与CoAP之间的简单响应代码映射，同时将跨协议代理的许多细节留给未来的定义。因此，本文档的主要目标是定义一组一致的指导原则，HTTP到CoAP代理实现应该遵守这些指导原则。遵守这些指导原则的关键好处是减少代理实现之间的差异，从而提高HTTP客户端和CoAP服务器之间的互操作性，而不依赖于实现跨协议映射的代理。（例如，供应商a制定的符合这些准则的代理可以很容易地被供应商B制定的也符合这些准则的代理替换，而不会破坏API语义。）
This document describes HTTP mappings that apply to protocol elements defined in the base CoAP specification [RFC7252] and in the CoAP block-wise transfer specification [RFC7959]. It is up to CoAP protocol extensions (new methods, response codes, options, content-formats) to describe their own HTTP mappings, if applicable.
本文档描述了适用于CoAP基本规范[RFC7252]和CoAP分块传输规范[RFC7959]中定义的协议元素的HTTP映射。如果适用，由CoAP协议扩展（新方法、响应代码、选项、内容格式）来描述它们自己的HTTP映射。
The rest of this document is organized as follows:
本文件其余部分的组织如下：
o Section 2 defines proxy terminology;
o 第2节定义了代理术语；
o Section 3 introduces the HTTP-to-CoAP proxy;
o 第3节介绍了HTTP到CoAP代理；
o Section 4 lists use cases in which HTTP clients need to contact CoAP servers;
o 第4节列出了HTTP客户端需要联系CoAP服务器的用例；
o Section 5 introduces a null, default, and advanced HTTP-to-CoAP URI mapping syntax;
o 第5节介绍了空、默认和高级HTTP到CoAP URI映射语法；
o Section 6 describes how to map HTTP media types to CoAP content-formats, and vice versa;
o 第6节描述了如何将HTTP媒体类型映射到CoAP内容格式，反之亦然；
o Section 7 describes how to map CoAP responses to HTTP responses;
o 第7节描述了如何将CoAP响应映射到HTTP响应；
o Section 8 describes additional mapping guidelines related to caching, congestion, multicast, timeouts, etc.; and
o 第8节描述了与缓存、拥塞、多播、超时等相关的其他映射指南。；和
o Section 10 discusses the possible security impact of HTTP-to-CoAP protocol mapping.
o 第10节讨论HTTP到CoAP协议映射可能产生的安全影响。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
This specification requires readers to be familiar with the vocabulary and concepts discussed in [RFC7228], in particular, the terms "constrained nodes" and "constrained networks". Readers must also be familiar with all of the terminology of the normative references listed in this document, in particular [RFC7252] (CoAP) and [RFC7230] (HTTP). In addition, this specification makes use of the following terms:
本规范要求读者熟悉[RFC7228]中讨论的词汇和概念，尤其是术语“受限节点”和“受限网络”。读者还必须熟悉本文件中列出的规范性参考文件的所有术语，尤其是[RFC7252]（CoAP）和[RFC7230]（HTTP）。此外，本规范使用了以下术语：
HC Proxy A proxy performing a cross-protocol mapping, in the context of this document an HTTP-to-CoAP (HC) mapping. Specifically, the HC Proxy acts as an HTTP server and a CoAP client. The HC Proxy can take on the role of a forward, reverse, or interception Proxy.
HC Proxy执行跨协议映射的代理，在本文档中是HTTP到CoAP（HC）映射。具体来说，HC代理充当HTTP服务器和CoAP客户端。HC代理可以扮演正向、反向或拦截代理的角色。
Application Level Gateway (ALG) An application-specific translation agent that allows an application on a host in one address realm to connect to its counterpart running on a host in a different realm transparently. See Section 2.9 of [RFC2663].
应用程序级网关（ALG）是一种特定于应用程序的转换代理，它允许一个地址域中主机上的应用程序透明地连接到另一个地址域中主机上运行的对应程序。参见[RFC2663]第2.9节。
forward-proxy A message-forwarding agent that is selected by the HTTP client, usually via local configuration rules, to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI. The user agent decides (is willing) to use the proxy as the forwarding/dereferencing agent for a predefined subset of the URI space. In [RFC7230], this is called a "proxy". [RFC7252] defines forward-proxy similarly.
转发代理HTTP客户端通常通过本地配置规则选择的消息转发代理，用于接收某些类型的绝对URI的请求，并尝试通过转换为绝对URI指示的协议来满足这些请求。用户代理决定（愿意）使用代理作为URI空间预定义子集的转发/解引用代理。在[RFC7230]中，这称为“代理”。[RFC7252]类似地定义了转发代理。
reverse-proxy As in [RFC7230], a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying server's protocol. A reverse-proxy behaves as an origin (HTTP) server on its connection from the HTTP client. The
反向代理，如[RFC7230]中所述，是一种接收代理，充当其他服务器上的一层，并将接收到的请求转换为底层服务器的协议。反向代理在其与HTTP客户端的连接上充当源（HTTP）服务器。这个
HTTP client uses the "origin-form" (Section 5.3.1 of [RFC7230]) as a request-target URI. (Note that a reverse-proxy appears to an HTTP client as an origin server while a forward-proxy does not. So, when communicating with a reverse-proxy, a client may be unaware it is communicating with a proxy at all.)
HTTP客户端使用“原始表单”（RFC7230的第5.3.1节）作为请求目标URI。（请注意，反向代理在HTTP客户端看来是源服务器，而正向代理则不是。因此，当与反向代理通信时，客户端可能根本不知道它正在与代理通信。）
interception proxy As in [RFC3040], a proxy that receives inbound HTTP traffic flows through the process of traffic redirection, transparent to the HTTP client.
[RFC3040]中的拦截代理，一个通过流量重定向过程接收入站HTTP流量的代理，对HTTP客户端是透明的。
An HC Proxy is accessed by an HTTP client that needs to fetch a resource on a CoAP server. The HC Proxy handles the HTTP request by mapping it to the equivalent CoAP request, which is then forwarded to the appropriate CoAP server. The received CoAP response is then mapped to an appropriate HTTP response and finally sent back to the originating HTTP client.
HC代理由需要获取CoAP服务器上的资源的HTTP客户端访问。HC代理通过将HTTP请求映射到等效的CoAP请求来处理HTTP请求，然后将该请求转发到相应的CoAP服务器。然后将接收到的CoAP响应映射到适当的HTTP响应，并最终发送回原始HTTP客户端。
Section 10.2 of [RFC7252] defines basic normative requirements on HTTP-to-CoAP mapping. This document provides additional details and guidelines for the implementation of an HC Proxy.
[RFC7252]第10.2节定义了HTTP到CoAP映射的基本规范性要求。本文件提供了HC代理实施的其他详细信息和指南。
Constrained Network
.-------------------.
/ .------. \
/ | CoAP | \
/ |server| \
|| '------' ||
|| ||
.--------. HTTP Request .------------. CoAP Req .------. ||
| HTTP |---------------->|HTTP-to-CoAP|----------->| CoAP | ||
| Client |<----------------| Proxy |<-----------|server| ||
'--------' HTTP Response '------------' CoAP Resp '------' ||
|| ||
|| .------. ||
|| | CoAP | ||
\ |server| .------. /
\ '------' | CoAP | /
\ |server| /
\ '------' /
'-----------------'
Constrained Network
.-------------------.
/ .------. \
/ | CoAP | \
/ |server| \
|| '------' ||
|| ||
.--------. HTTP Request .------------. CoAP Req .------. ||
| HTTP |---------------->|HTTP-to-CoAP|----------->| CoAP | ||
| Client |<----------------| Proxy |<-----------|server| ||
'--------' HTTP Response '------------' CoAP Resp '------' ||
|| ||
|| .------. ||
|| | CoAP | ||
\ |server| .------. /
\ '------' | CoAP | /
\ |server| /
\ '------' /
'-----------------'
Figure 1: HTTP-To-CoAP Proxy Deployment Scenario
图1:HTTP到CoAP代理部署场景
Figure 1 illustrates an example deployment scenario. There, an HC Proxy is located at the boundary of the constrained network domain and acts as an ALG that allows only a very specific type of traffic (i.e., authorized inbound HTTP requests and their associated outbound CoAP responses) to pass through. All other kinds of traffic are segregated within the respective network segments.
图1展示了一个示例部署场景。其中，HC代理位于受限网络域的边界处，充当ALG，仅允许非常特定类型的流量（即授权的入站HTTP请求及其相关的出站CoAP响应）通过。所有其他类型的流量在各自的网段内被隔离。
To illustrate a few situations in which HTTP-to-CoAP protocol translation may be used, three use cases are described below.
为了说明可以使用HTTP到CoAP协议转换的几种情况，下面描述三种用例。
1. Legacy building control application without CoAP: A building control application that uses HTTP but not CoAP can check the status of CoAP sensors and/or control actuators via an HC Proxy.
1. 没有CoAP的传统建筑控制应用程序：使用HTTP但不使用CoAP的建筑控制应用程序可以通过HC代理检查CoAP传感器和/或控制执行器的状态。
2. Making sensor data available to third parties on the web: For demonstration or public interest purposes, an HC Proxy may be configured to expose the contents of a CoAP sensor to the world via the web (HTTP and/or HTTPS). Some sensors may only accept secure 'coaps' requests; therefore, the proxy is configured to translate requests to those devices accordingly. The HC Proxy is furthermore configured to only pass through GET requests in order to protect the constrained network.
2. 使传感器数据在web上可供第三方使用：出于演示或公共利益目的，HC代理可配置为通过web（HTTP和/或HTTPS）向世界公开CoAP传感器的内容。某些传感器可能只接受安全的“COAP”请求；因此，代理被配置为相应地将请求转换到这些设备。HC代理进一步配置为仅通过GET请求，以保护受约束的网络。
3. Smartphone and home sensor: A smartphone can access directly a CoAP home sensor using a mutually authenticated 'https' request, provided its home router runs an HC Proxy and is configured with the appropriate certificate. An HTML5 [W3C.REC-html5-20141028] application on the smartphone can provide a friendly UI using the standard (HTTP) networking functions of HTML5.
3. 智能手机和家庭传感器：智能手机可以使用相互认证的“https”请求直接访问CoAP家庭传感器，前提是其家庭路由器运行HC代理并配置了相应的证书。智能手机上的HTML5[W3C.REC-HTML5-20141028]应用程序可以使用HTML5的标准（HTTP）网络功能提供友好的用户界面。
A key point in the above use cases is the expected nature of the URI to be used by the HTTP client initiating the HTTP request to the HC Proxy. Specifically, in use case #1, there will be no information related to 'coap' or 'coaps' embedded in the HTTP URI as it is a legacy HTTP client sending the request. Use case #2 is also expected to be similar. In contrast, in use case #3, it is likely that the HTTP client will specifically embed information related to 'coap' or 'coaps' in the HTTP URI of the HTTP request to the HC Proxy.
上述用例中的一个关键点是HTTP客户端向HC代理发起HTTP请求所使用的URI的预期性质。具体来说，在用例#1中，HTTP URI中不会嵌入与“coap”或“coap”相关的信息，因为它是发送请求的传统HTTP客户端。用例2也应该是类似的。相反，在用例#3中，HTTP客户端很可能会在HTTP请求的HTTP URI中向HC代理专门嵌入与“coap”或“coap”相关的信息。
Though, in principle, a CoAP URI could be directly used by an HTTP client to dereference a CoAP resource through an HC Proxy; the reality is that all major web browsers, networking libraries, and command-line tools do not allow making HTTP requests using URIs with a scheme 'coap' or 'coaps'.
不过，原则上，HTTP客户端可以直接使用CoAP URI通过HC代理解除对CoAP资源的引用；事实上，所有主要的web浏览器、网络库和命令行工具都不允许使用带有“coap”或“coap”方案的URI发出HTTP请求。
Thus, there is a need for web applications to embed or "pack" a CoAP URI into an HTTP URI so that it can be (non-destructively) transported from the HTTP client to the HC Proxy. The HC Proxy can then "unpack" the CoAP URI and finally dereference it via a CoAP request to the target server.
因此，web应用程序需要将CoAP URI嵌入或“打包”到HTTP URI中，以便可以（非破坏性地）将其从HTTP客户端传输到HC代理。HC代理然后可以“解包”CoAP URI，并最终通过CoAP请求将其解引用到目标服务器。
URI mapping is the term used in this document to describe the process through which the URI of a CoAP resource is transformed into an HTTP URI so that:
URI映射是本文档中使用的术语，用于描述将CoAP资源的URI转换为HTTP URI的过程，以便：
o The requesting HTTP client can handle it; and
o 请求HTTP客户端可以处理它；和
o The receiving HC Proxy can extract the intended CoAP URI unambiguously.
o 接收HC代理可以毫不含糊地提取预期的CoAP URI。
To this end, the remainder of this section will identify:
为此，本节剩余部分将确定：
o The default mechanism to map a CoAP URI into an HTTP URI;
o 将CoAP URI映射到HTTP URI的默认机制；
o The URI Template format to express a class of CoAP-HTTP URI mapping functions; and
o URI模板格式，用于表示一类CoAP HTTP URI映射函数；和
o The discovery mechanism based on "Constrained RESTful Environments (CoRE) Link Format" [RFC6690] through which clients of an HC Proxy can dynamically learn about the supported URI mapping template(s), as well as the URI where the HC Proxy function is anchored.
o 基于“受限RESTful环境（CoRE）链接格式”[RFC6690]的发现机制，通过该机制，HC代理的客户端可以动态了解受支持的URI映射模板，以及HC代理函数锚定的URI。
In the remainder of this section, the following terms will be used with a distinctive meaning:
在本节剩余部分中，以下术语将具有独特的含义：
HC Proxy URI: URI that refers to the HC Proxy function. It conforms to syntax defined in Section 2.7 of [RFC7230].
HC代理URI：引用HC代理函数的URI。它符合[RFC7230]第2.7节中定义的语法。
Target CoAP URI: URI that refers to the (final) CoAP resource that has to be dereferenced. It conforms to syntax defined in Section 6 of [RFC7252]. Specifically, its scheme is either 'coap' or 'coaps'.
目标CoAP URI：引用必须取消引用的（最终）CoAP资源的URI。它符合[RFC7252]第6节中定义的语法。具体而言，其方案为“coap”或“coap”。
Hosting HTTP URI: URI that conforms to syntax in Section 2.7 of [RFC7230]. Its authority component refers to an HC Proxy, whereas a path and/or query component(s) embed the information used by an HC Proxy to extract the Target CoAP URI.
托管HTTP URI：符合[RFC7230]第2.7节语法的URI。其授权组件引用HC代理，而路径和/或查询组件嵌入HC代理用于提取目标CoAP URI的信息。
The null mapping is the case where there is no Target CoAP URI appended to the HC Proxy URI. In other words, it is a "pure" HTTP URI that is sent to the HC Proxy. This would typically occur in situations like use case #1 described in Section 4, and the proxy would typically be a reverse-proxy. In this scenario, the HC Proxy will determine through its own private algorithms what the Target CoAP URI should be.
空映射是指没有目标CoAP URI附加到HC代理URI的情况。换句话说，它是发送到HC代理的“纯”HTTP URI。这通常发生在第4节中描述的用例#1中，并且代理通常是反向代理。在这种情况下，HC代理将通过自己的私有算法确定目标CoAP URI应该是什么。
The default mapping is for the Target CoAP URI to be appended as is (with the only caveat discussed in Section 5.3.2) to the HC Proxy URI, to form the Hosting HTTP URI. This is the effective request URI (see Section 5.5 of [RFC7230]) that will then be sent by the HTTP client in the HTTP request to the HC Proxy.
默认映射是将目标CoAP URI按原样（第5.3.2节中讨论的唯一警告）附加到HC代理URI，以形成托管HTTP URI。这是有效的请求URI（参见[RFC7230]的第5.5节），HTTP客户端将在HTTP请求中将其发送到HC代理。
For example: given an HC Proxy URI https://p.example.com/hc/ and a Target CoAP URI coap://s.example.com/light, the resulting Hosting HTTP URI would be https://p.example.com/hc/coap://s.example.com/ light.
例如：给定一个HC代理URIhttps://p.example.com/hc/ 和一个目标CoAP URIcoap://s.example.com/light，生成的托管HTTP URI将是https://p.example.com/hc/coap://s.example.com/ 光
Provided a correct Target CoAP URI, the Hosting HTTP URI resulting from the default mapping will be a syntactically valid HTTP URI. Furthermore, the Target CoAP URI can always be extracted unambiguously from the Hosting HTTP URI.
如果提供了正确的目标CoAP URI，则由默认映射生成的托管HTTP URI将是语法上有效的HTTP URI。此外，目标CoAP URI始终可以从托管HTTP URI中明确提取。
There is no default for the HC Proxy URI. Therefore, it is either known in advance, e.g., as a configuration preset, or dynamically discovered using the mechanism described in Section 5.5.
HC代理URI没有默认值。因此，它或者是预先知道的，例如，作为配置预设，或者是使用第5.5节中描述的机制动态发现的。
The default URI mapping function SHOULD be implemented and SHOULD be activated by default in an HC Proxy, unless there are valid reasons (e.g., application specific) to use a different mapping function.
除非有正当理由（例如，特定于应用程序）使用不同的映射函数，否则应在HC代理中实现并默认激活默认URI映射函数。
When constructing a Hosting HTTP URI by embedding a Target CoAP URI, the scheme (i.e., 'coap' or 'coaps'), the scheme component delimiter (":"), and the double slash ("//") preceding the authority MAY be omitted if a local default -- not defined by this document -- applies. If no prior mutual agreement exists between the client and the HC Proxy, then a Target CoAP URI without the scheme component is syntactically incorrect, and therefore:
当通过嵌入目标CoAP URI来构建宿主HTTP URI时，如果本地默认值（本文档未定义）适用，则可以省略授权前面的方案（即“CoAP”或“CoAP”）、方案组件分隔符（“：”）和双斜杠（“/”）。如果客户机和HC代理之间不存在事先的相互协议，那么没有scheme组件的目标CoAP URI在语法上是不正确的，因此：
o It MUST NOT be emitted by clients; and
o 不得由客户发出；和
o It MUST elicit a suitable client error status (i.e., 4xx) by the HC Proxy.
o 它必须通过HC代理获取适当的客户端错误状态（即4xx）。
When the authority of the Target CoAP URI is given as an IPv6address, then the surrounding square brackets must be percent-encoded in the Hosting HTTP URI, in order to comply with the syntax defined in Section 3.3. of [RFC3986] for a URI path segment. For example: coap://[2001:db8::1]/light?on becomes https://p.example.com/hc/coap://%5B2001:db8::1%5D/light?on. (Note that the percent-encoded square brackets shall be reverted to their non-percent-encoded form when the HC Proxy unpacks the Target CoAP URI.)
当目标CoAP URI的权限作为IPV6地址给出时，则周围的方括号必须在承载HTTP URI中进行百分比编码，以符合第3.3节中定义的语法。URI路径段的[RFC3986]。例如：coap://[2001:db8:：1]/light？on变为https://p.example.com/hc/coap://%5B2001:db8::1%5D/light?on. （注意，当HC代理解压缩目标CoAP URI时，百分比编码方括号应恢复为非百分比编码形式。）
Everything else can be safely copied verbatim from the Target CoAP URI to the Hosting HTTP URI.
其他所有内容都可以安全地从目标CoAP URI复制到宿主HTTP URI。
This section defines a format for the URI Template [RFC6570] used by an HC Proxy to inform its clients about the expected syntax for the Hosting HTTP URI. This can then be used by the HTTP client to construct the effective request URI to be sent in the HTTP request to the HC Proxy.
本节定义了HC代理使用的URI模板[RFC6570]的格式，以通知其客户端托管HTTP URI的预期语法。然后，HTTP客户机可以使用它来构造将在HTTP请求中发送到HC代理的有效请求URI。
When instantiated, a URI mapping template is always concatenated to an HC Proxy URI provided by the HC Proxy via discovery (see Section 5.5), or by other means.
实例化时，URI映射模板始终通过发现（参见第5.5节）或其他方式连接到HC代理提供的HC代理URI。
A simple form (Section 5.4.1) and an enhanced form (Section 5.4.2) are provided to fit different users' requirements.
提供了一个简单表格（第5.4.1节）和一个增强表格（第5.4.2节），以满足不同用户的要求。
Both forms are expressed as Level 2 URI Templates [RFC6570] to take care of the expansion of values that are allowed to include reserved URI characters. The syntax of all URI formats is specified in this section in Augmented Backus-Naur Form (ABNF) [RFC5234].
这两种形式都表示为2级URI模板[RFC6570]，以处理允许包含保留URI字符的值的扩展。所有URI格式的语法在本节中以扩充的Backus Naur格式（ABNF）[RFC5234]指定。
The simple form MUST be used for mappings where the Target CoAP URI is going to be copied (using rules of Section 5.3.2) at some fixed position into the Hosting HTTP URI.
如果要将目标CoAP URI（使用第5.3.2节的规则）在某个固定位置复制到宿主HTTP URI中，则必须使用简单表单进行映射。
The "tu" template variable is defined below using the ABNF rules from [RFC3986], Sections 3.2.2, 3.2.3, 3.3, and 3.4. It is intended to be used in a template definition to represent a Target CoAP URI:
下面使用[RFC3986]第3.2.2、3.2.3、3.3和3.4节中的ABNF规则定义“tu”模板变量。它用于模板定义中，以表示目标CoAP URI：
tu = [ ( "coap:" / "coaps:" ) "//" ] host [ ":" port ] path-abempty
[ "?" query ]
tu = [ ( "coap:" / "coaps:" ) "//" ] host [ ":" port ] path-abempty
[ "?" query ]
Note that the same considerations as in Section 5.3.1 apply, in that the CoAP scheme may be omitted from the Hosting HTTP URI.
请注意，第5.3.1节中的注意事项同样适用，因为可以从托管HTTP URI中省略CoAP方案。
All the following examples (given as a specific URI mapping template, a Target CoAP URI, and the produced Hosting HTTP URI) use https://p.example.com/hc/ as the HC Proxy URI. Note that these examples all define mapping templates that deviate from the default template of Section 5.3 in order to illustrate the use of the above template variables.
以下所有示例（作为特定URI映射模板、目标CoAP URI和生成的托管HTTP URI提供）都使用https://p.example.com/hc/ 作为HC代理URI。请注意，这些示例都定义了偏离第5.3节默认模板的映射模板，以说明上述模板变量的使用。
1. Target CoAP URI is a query argument of the Hosting HTTP URI:
1. 目标CoAP URI是承载HTTP URI的查询参数：
?target_uri={+tu}
?target_uri={+tu}
coap://s.example.com/light
coap://s.example.com/light
=> https://p.example.com/hc/?target_uri=coap://s.example.com/light
=> https://p.example.com/hc/?target_uri=coap://s.example.com/light
whereas
鉴于
coaps://s.example.com/light
coaps://s.example.com/light
=> https://p.example.com/hc/?target_uri=coaps://s.example.com/light
=> https://p.example.com/hc/?target_uri=coaps://s.example.com/light
2. Target CoAP URI in the path component of the Hosting HTTP URI:
2. 托管HTTP URI的路径组件中的目标CoAP URI：
forward/{+tu}
forward/{+tu}
coap://s.example.com/light
coap://s.example.com/light
=> https://p.example.com/hc/forward/coap://s.example.com/light
=> https://p.example.com/hc/forward/coap://s.example.com/light
whereas
鉴于
coaps://s.example.com/light
coaps://s.example.com/light
=> https://p.example.com/hc/forward/coaps://s.example.com/light
=> https://p.example.com/hc/forward/coaps://s.example.com/light
3. Target CoAP URI is a query argument of the Hosting HTTP URI; client decides to omit the scheme because a default is agreed beforehand between client and proxy:
3. 目标CoAP URI是承载HTTP URI的查询参数；客户决定省略该方案，因为客户和代理之间事先约定了违约：
?coap_uri={+tu}
?coap_uri={+tu}
coap://s.example.com/light
coap://s.example.com/light
=> https://p.example.com/hc/?coap_uri=s.example.com/light
=> https://p.example.com/hc/?coap_uri=s.example.com/light
The enhanced form can be used to express more sophisticated mappings of the Target CoAP URI into the Hosting HTTP URI, i.e., mappings that do not fit into the simple form.
增强形式可用于表示目标CoAP URI到宿主HTTP URI的更复杂的映射，即不适合简单形式的映射。
There MUST be at most one instance of each of the following template variables in a URI mapping template definition:
URI映射模板定义中必须最多有以下每个模板变量的一个实例：
s = "coap" / "coaps" ; from [RFC7252], Sections 6.1 and 6.2
hp = host [":" port] ; from [RFC3986], Sections 3.2.2 and 3.2.3
p = path-abempty ; from [RFC3986], Section 3.3
q = query ; from [RFC3986], Section 3.4
qq = [ "?" query ] ; qq is empty if and only if 'query' is empty
s = "coap" / "coaps" ; from [RFC7252], Sections 6.1 and 6.2
hp = host [":" port] ; from [RFC3986], Sections 3.2.2 and 3.2.3
p = path-abempty ; from [RFC3986], Section 3.3
q = query ; from [RFC3986], Section 3.4
qq = [ "?" query ] ; qq is empty if and only if 'query' is empty
The qq form is used when the path and the (optional) query components are to be copied verbatim from the Target CoAP URI into the Hosting HTTP URI, i.e., as "{+p}{+qq}". Instead, the q form is used when the query and path are mapped as separate entities, e.g., as in "coap_path={+p}&coap_query={+q}". So q and qq MUST be used in mutual exclusion in a template definition.
当路径和（可选）查询组件要从目标CoAP URI逐字复制到宿主HTTP URI时，使用qq表单，即“{+p}{+qq}”。相反，当查询和路径作为单独的实体映射时，使用q形式，例如“coap_path={+p}&coap_query={+q}”。所以q和qq必须在模板定义中互斥使用。
All the following examples (given as a specific URI mapping template, a Target CoAP URI, and the produced Hosting HTTP URI) use https://p.example.com/hc/ as the HC Proxy URI.
以下所有示例（作为特定URI映射模板、目标CoAP URI和生成的托管HTTP URI提供）都使用https://p.example.com/hc/ 作为HC代理URI。
1. Target CoAP URI components in path segments and optional query in query component:
1. 路径段中的目标CoAP URI组件和查询组件中的可选查询：
{+s}/{+hp}{+p}{+qq}
{+s}/{+hp}{+p}{+qq}
coap://s.example.com/light
coap://s.example.com/light
=> https://p.example.com/hc/coap/s.example.com/light
=> https://p.example.com/hc/coap/s.example.com/light
whereas
鉴于
coap://s.example.com/light?on
coap://s.example.com/light?on
=> https://p.example.com/hc/coap/s.example.com/light?on
=> https://p.example.com/hc/coap/s.example.com/light?on
2. Target CoAP URI components split in individual query arguments:
2. 在单个查询参数中拆分的目标CoAP URI组件：
?s={+s}&hp={+hp}&p={+p}&q={+q}
?s={+s}&hp={+hp}&p={+p}&q={+q}
coap://s.example.com/light
coap://s.example.com/light
=> https://p.example.com/hc/?s=coap&hp=s.example.com&p=/light&q=
=> https://p.example.com/hc/?s=coap&hp=s.example.com&p=/light&q=
whereas
鉴于
coaps://s.example.com/light?on
coaps://s.example.com/light?on
=> https://p.example.com/hc/?s=coaps&hp=s.example.com&p=/light&q=on
=> https://p.example.com/hc/?s=coaps&hp=s.example.com&p=/light&q=on
In order to accommodate site-specific needs while allowing third parties to discover the proxy function, the HC Proxy SHOULD publish information related to the location and syntax of the HC Proxy function using the CoRE Link Format [RFC6690] interface.
为了满足特定站点的需求，同时允许第三方发现代理功能，HC代理应使用核心链接格式[RFC6690]界面发布与HC代理功能位置和语法相关的信息。
To this aim, a new Resource Type, "core.hc", is defined in this document. It can be used as the value for the "rt" attribute in a query to the "/.well-known/core" resource in order to locate the URI where the HC Proxy function is anchored, i.e., the HC Proxy URI.
为此，本文定义了一种新的资源类型“core.hc”。它可以用作“/.well-known/core”资源查询中“rt”属性的值，以定位HC代理函数锚定的URI，即HC代理URI。
Along with it, the new target attribute "hct" is defined in this document. This attribute MAY be returned in a "core.hc" link to provide the URI mapping template associated with the mapping resource. The default template given in Section 5.3, i.e., {+tu}, MUST be assumed if no "hct" attribute is found in a returned link. If a "hct" attribute is present in a returned link, the client MUST use it to create a Hosting HTTP URI.
除此之外，本文还定义了新的目标属性“hct”。此属性可以在“core.hc”链接中返回，以提供与映射资源关联的URI映射模板。如果在返回的链接中找不到“hct”属性，则必须假定第5.3节中给出的默认模板，即{+tu}。如果返回的链接中存在“hct”属性，则客户端必须使用它来创建托管HTTP URI。
The URI mapping SHOULD be discoverable (as specified in [RFC6690]) on both the HTTP and the CoAP side of the HC Proxy, with one important difference: on the CoAP side, the link associated with the "core.hc" resource always needs an explicit anchor parameter referring to the HTTP origin [RFC6454], while on the HTTP interface, the context URI of the link may be equal to the HTTP origin of the discovery request: in that case, the anchor parameter is not needed.
URI映射在HC代理的HTTP和CoAP端都应该是可发现的（如[RFC6690]中所述），有一个重要的区别：在CoAP端，与“core.HC”资源关联的链接始终需要一个引用HTTP源[RFC6454]的显式锚参数，而在HTTP接口上，链接的上下文URI可能等于发现请求的HTTP源：在这种情况下，不需要锚参数。
o The first example exercises the CoAP interface and assumes that the default template, {+tu}, is used. For example, a smartphone may discover the public HC Proxy before leaving the home network. Then, when outside the home network, the smartphone will be able to query the appropriate home sensor.
o 第一个示例练习CoAP接口，并假设使用默认模板{+tu}。例如，智能手机可能在离开家庭网络之前发现公共HC代理。然后，当离开家庭网络时，智能手机将能够查询相应的家庭传感器。
Req: GET coap://[ff02::fd]/.well-known/core?rt=core.hc
Req: GET coap://[ff02::fd]/.well-known/core?rt=core.hc
Res: 2.05 Content
</hc/>;anchor="https://p.example.com";rt="core.hc"
Res: 2.05 Content
</hc/>;anchor="https://p.example.com";rt="core.hc"
o The second example -- also on the CoAP side of the HC Proxy -- uses a custom template, i.e., one where the CoAP URI is carried inside the query component, thus the returned link carries the URI Template to be used in an explicit "hct" attribute:
o 第二个示例（也在HC代理的CoAP端）使用自定义模板，即CoAP URI携带在查询组件中的模板，因此返回的链接携带URI模板，以便在显式“hct”属性中使用：
Req: GET coap://[ff02::fd]/.well-known/core?rt=core.hc
Req: GET coap://[ff02::fd]/.well-known/core?rt=core.hc
Res: 2.05 Content
</hc/>;anchor="https://p.example.com";
rt="core.hc";hct="?uri={+tu}"
Res: 2.05 Content
</hc/>;anchor="https://p.example.com";
rt="core.hc";hct="?uri={+tu}"
On the HTTP side, link information can be serialized in more than one way:
在HTTP端，链接信息可以通过多种方式序列化：
o using the 'application/link-format' content type:
o 使用“应用程序/链接格式”内容类型：
Req: GET /.well-known/core?rt=core.hc HTTP/1.1
Host: p.example.com
Req: GET /.well-known/core?rt=core.hc HTTP/1.1
Host: p.example.com
Res: HTTP/1.1 200 OK
Content-Type: application/link-format
Content-Length: 19
Res: HTTP/1.1 200 OK
Content-Type: application/link-format
Content-Length: 19
</hc/>;rt="core.hc"
</hc/>;rt="core.hc"
o using the 'application/link-format+json' content type as defined in [CoRE-JSON-CBOR]:
o 使用[CoRE json CBOR]中定义的“应用程序/链接格式+json”内容类型：
Req: GET /.well-known/core?rt=core.hc HTTP/1.1
Host: p.example.com
Req: GET /.well-known/core?rt=core.hc HTTP/1.1
Host: p.example.com
Res: HTTP/1.1 200 OK
Content-Type: application/link-format+json
Content-Length: 32
Res: HTTP/1.1 200 OK
Content-Type: application/link-format+json
Content-Length: 32
[{"href":"/hc/","rt":"core.hc"}]
[{"href":"/hc/","rt":"core.hc"}]
An HC Proxy needs to translate HTTP media types (Section 3.1.1.1 of [RFC7231]) and content codings (Section 3.1.2.2 of [RFC7231]) into CoAP content-formats (Section 12.3 of [RFC7252]), and vice versa.
HC代理需要将HTTP媒体类型（RFC7231第3.1.1.1节）和内容编码（RFC7231第3.1.2.2节）转换为CoAP内容格式（RFC7252第12.3节），反之亦然。
Media type translation can happen in GET, PUT, or POST requests going from HTTP to CoAP, in 2.xx (i.e., successful) responses going from CoAP to HTTP, and in 4.xx/5.xx error responses with a diagnostic payload. Specifically, PUT and POST need to map both the Content-Type and Content-Encoding HTTP headers into a single CoAP Content-Format option, whereas GET needs to map Accept and Accept-Encoding HTTP headers into a single CoAP Accept option. To generate the HTTP response, the CoAP Content-Format option is mapped back to a suitable HTTP Content-Type and Content-Encoding combination.
媒体类型转换可以在从HTTP到CoAP的GET、PUT或POST请求、从CoAP到HTTP的2.xx（即成功）响应以及带有诊断负载的4.xx/5.xx错误响应中发生。具体来说，PUT和POST需要将内容类型和内容编码HTTP头映射到单个CoAP内容格式选项中，而GET需要将接受和接受编码HTTP头映射到单个CoAP接受选项中。为了生成HTTP响应，CoAP内容格式选项被映射回合适的HTTP内容类型和内容编码组合。
An HTTP request carrying a Content-Type and Content-Encoding combination that the HC Proxy is unable to map to an equivalent CoAP Content-Format SHALL elicit a 415 (Unsupported Media Type) response by the HC Proxy.
承载HC代理无法映射到等效CoAP内容格式的内容类型和内容编码组合的HTTP请求应引发HC代理的415（不支持的媒体类型）响应。
On the content negotiation side, failure to map Accept and Accept-*
headers SHOULD be silently ignored: the HC Proxy SHOULD therefore
forward as a CoAP request with no Accept option. The HC Proxy thus
disregards the Accept/Accept-* header fields by treating the response
as if it is not subject to content negotiation, as mentioned in
Section 5.3 of [RFC7231]. However, an HC Proxy implementation is
free to attempt mapping a single Accept header in a GET request to
multiple CoAP GET requests, each with a single Accept option, which
are then tried in sequence until one succeeds. Note that an HTTP
Accept */* MUST be mapped to a CoAP request without an Accept option.
On the content negotiation side, failure to map Accept and Accept-*
headers SHOULD be silently ignored: the HC Proxy SHOULD therefore
forward as a CoAP request with no Accept option. The HC Proxy thus
disregards the Accept/Accept-* header fields by treating the response
as if it is not subject to content negotiation, as mentioned in
Section 5.3 of [RFC7231]. However, an HC Proxy implementation is
free to attempt mapping a single Accept header in a GET request to
multiple CoAP GET requests, each with a single Accept option, which
are then tried in sequence until one succeeds. Note that an HTTP
Accept */* MUST be mapped to a CoAP request without an Accept option.
While the CoAP-to-HTTP direction always has a well-defined mapping (with the exception examined in Section 6.2), the HTTP-to-CoAP
虽然CoAP到HTTP方向始终有一个定义良好的映射（第6.2节中检查的例外情况除外），但HTTP到CoAP
direction is more problematic because the source set, i.e., potentially 1000+ IANA-registered media types, is much bigger than the destination set, i.e., the mere six values initially defined in Section 12.3 of [RFC7252].
方向问题更大，因为源集（即可能1000+IANA注册的媒体类型）比目标集（即[RFC7252]第12.3节中最初定义的六个值）大得多。
Depending on the tight/loose coupling with the application(s) for which it proxies, the HC Proxy could implement different media type mappings.
根据与it代理的应用程序的紧密/松散耦合，HC代理可以实现不同的媒体类型映射。
When tightly coupled, the HC Proxy knows exactly which content-formats are supported by the applications and can be strict when enforcing its forwarding policies in general, and the media type mapping in particular.
当紧密耦合时，HC代理确切地知道应用程序支持哪些内容格式，并且通常在强制执行其转发策略时，尤其是在强制执行媒体类型映射时，HC代理可能会非常严格。
On the other hand, when the HC Proxy is a general purpose ALG, being too strict could significantly reduce the amount of traffic that it would be able to successfully forward. In this case, the "loose" media type mapping detailed in Section 6.3 MAY be implemented.
另一方面，当HC代理是通用ALG时，过于严格可能会显著减少它能够成功转发的通信量。在这种情况下，可实施第6.3节详述的“松散”介质类型映射。
The latter grants more evolution of the surrounding ecosystem, at the cost of allowing more attack surface. In fact, as a result of such strategy, payloads would be forwarded more liberally across the unconstrained/constrained network boundary of the communication path.
后者赋予周围生态系统更多的进化，代价是允许更多的攻击面。事实上，由于这种策略，有效负载将更自由地跨通信路径的无约束/约束网络边界转发。
If the HC Proxy receives a CoAP response with a Content-Format that it does not recognize (e.g., because the value has been registered after the proxy has been deployed, or the CoAP server uses an experimental value that is not registered), then the HC Proxy SHALL return a generic "application/coap-payload" media type with numeric parameter "cf" as defined in Section 9.2.
如果HC代理收到内容格式不可识别的CoAP响应（例如，因为在部署代理后已注册该值，或CoAP服务器使用未注册的实验值），则HC代理应返回带有数字参数“cf”的通用“应用程序/CoAP有效载荷”媒体类型如第9.2节所定义。
For example, the CoAP content-format '60' ("application/cbor") would be represented by "application/coap-payload;cf=60", if the HC Proxy doesn't recognize the content-format '60'.
例如，如果HC代理无法识别内容格式“60”，则CoAP内容格式“60”（“应用程序/cbor”）将由“应用程序/CoAP有效负载；cf=60”表示。
An HTTP client may use the media type "application/coap-payload" as a means to send a specific content-format to a CoAP server via an HC Proxy if the client has determined that the HC Proxy does not directly support the type mapping it needs. This case may happen when dealing, for example, with newly registered, yet to be registered, or experimental CoAP content-formats. However, unless explicitly configured to allow pass-through of unknown content-formats, the HC Proxy SHOULD NOT forward requests carrying a Content-Type or Accept header with an "application/coap-payload", and return an appropriate client error instead.
如果HTTP客户端已确定HC代理不直接支持其所需的类型映射，则HTTP客户端可使用媒体类型“应用程序/coap有效负载”作为通过HC代理向coap服务器发送特定内容格式的手段。例如，在处理新注册、尚未注册或实验性CoAP内容格式时，可能会发生这种情况。但是，除非明确配置为允许传递未知内容格式，否则HC代理不应转发带有内容类型的请求或接受带有“应用程序/coap有效负载”的标头，而应返回相应的客户端错误。
By structuring the type information in a super-class (e.g., "text") followed by a finer-grained sub-class (e.g., "html"), and optional parameters (e.g., "charset=utf-8"), Internet media types provide a rich and scalable framework for encoding the type of any given entity.
通过在一个超类（例如，“文本”）后接一个更细粒度的子类（例如，“html”）和可选参数（例如“charset=utf-8”）中构造类型信息，Internet媒体类型为编码任何给定实体的类型提供了一个丰富且可扩展的框架。
This approach is not applicable to CoAP, where content-formats conflate an Internet media type (potentially with specific parameters) and a content coding into one small integer value.
这种方法不适用于CoAP，在CoAP中，内容格式将互联网媒体类型（可能带有特定参数）和内容编码合并为一个小整数值。
To remedy this loss of flexibility, we introduce the concept of a "loose" media type mapping, where media types that are specializations of a more generic media type can be aliased to their super-class and then mapped (if possible) to one of the CoAP content-formats. For example, "application/soap+xml" can be aliased to "application/xml", which has a known conversion to CoAP. In the context of this "loose" media type mapping, "application/ octet-stream" can be used as a fallback when no better alias is found for a specific media type.
为了弥补这种灵活性的损失，我们引入了“松散”媒体类型映射的概念，在这种映射中，作为更通用的媒体类型的专门化的媒体类型可以被别名到它们的超类，然后映射（如果可能）到CoAP内容格式之一。例如，“application/soap+xml”可以化名为“application/xml”，它具有到CoAP的已知转换。在这种“松散”媒体类型映射的上下文中，当找不到特定媒体类型的更好别名时，“应用程序/八位字节流”可以用作回退。
Table 1 defines the default lookup table for the "loose" media type mapping. It is expected that an implementation can refine it because either application-specific knowledge is given or new Content-Formats are defined. Given an input media type, the table returns its best generalized media type using the most specific match, i.e., the table entries are compared to the input in top to bottom order until an entry matches.
表1定义了“松散”介质类型映射的默认查找表。由于给定了特定于应用程序的知识或定义了新的内容格式，因此实现可以对其进行细化。给定一个输入媒体类型，表将使用最特定的匹配返回其最佳通用媒体类型，即，表条目将按从上到下的顺序与输入进行比较，直到条目匹配为止。
+-----------------------------+--------------------------+
| Internet media type pattern | Generalized media type |
+-----------------------------+--------------------------+
| application/*+xml | application/xml |
| application/*+json | application/json |
| application/*+cbor | application/cbor |
| text/xml | application/xml |
| text/* | text/plain |
| */* | application/octet-stream |
+-----------------------------+--------------------------+
+-----------------------------+--------------------------+
| Internet media type pattern | Generalized media type |
+-----------------------------+--------------------------+
| application/*+xml | application/xml |
| application/*+json | application/json |
| application/*+cbor | application/cbor |
| text/xml | application/xml |
| text/* | text/plain |
| */* | application/octet-stream |
+-----------------------------+--------------------------+
Table 1: Media Type Generalization Lookup Table
表1：媒体类型泛化查找表
The "loose" media type mapping is an OPTIONAL feature. Implementations supporting this kind of mapping should provide a flexible way to define the set of media type generalizations allowed.
“松散”介质类型映射是可选功能。支持这种映射的实现应该提供一种灵活的方式来定义允许的媒体类型泛化集。
This section defines the algorithm used to map an HTTP Internet media type to its correspondent CoAP content-format; it can be used as a building block for translating HTTP Content-Type and Accept headers into CoAP Content-Format and Accept Options.
本节定义了用于将HTTP Internet媒体类型映射到相应CoAP内容格式的算法；它可以用作将HTTP内容类型和Accept标头转换为CoAP内容格式和Accept选项的构建块。
The algorithm uses an IANA-maintained table, "CoAP Content-Formats", as established by Section 12.3 of [RFC7252] plus, possibly, any locally defined extension of it. Optionally, the table and lookup mechanism described in Section 6.3 can be used if the implementation chooses so.
该算法使用IANA维护的表格“CoAP内容格式”，如[RFC7252]第12.3节所述，加上任何本地定义的扩展。或者，如果实现选择，可以使用第6.3节中描述的表和查找机制。
Note that the algorithm assumes an "identity" Content-Encoding and expects the resource body has been already successfully content decoded or transcoded to the desired format.
请注意，该算法假定“标识”内容编码，并期望资源主体已成功地将内容解码或转码为所需格式。
In the following (Figure 2):
如下所示（图2）：
o media_type is the media type to translate;
o 媒体类型是要翻译的媒体类型；
o coap_cf_registry is a lookup table matching the "CoAP Content-Formats" registry; and
o coap_cf_注册表是与“coap内容格式”注册表匹配的查找表；和
o loose_mapper is an optional lookup table describing the loose media type mappings (e.g., the one defined in Table 1).
o loose_mapper是一个可选的查找表，用于描述松散介质类型映射（例如，表1中定义的映射）。
The full source code is provided in Appendix A.
完整的源代码见附录A。
def mt2cf(media_type, encoding=None, coap_cf_registry=CoAPContentFormatRegistry(), loose_mapper=None): """Return a CoAP Content-Format given an Internet media type and its optional encoding. The current (as of 2016/10/24) "CoAP Content-Formats" registry is supplied by default. An optional 'loose-mapping' implementation can be supplied by the caller.""" assert media_type is not None assert coap_cf_registry is not None
def mt2cf（媒体类型，编码=无，coap\U cf\U注册表=CoAPContentFormatRegistry（），loose\u mapper=无）：“返回给定Internet媒体类型及其可选编码的coap内容格式。当前（自2016/10/24起）”coap内容格式“默认情况下提供注册表。调用者可以提供可选的“松散映射”实现。“”断言媒体类型不是无断言coap\u cf\u注册表不是无
# Lookup the "CoAP Content-Formats" registry content_format = coap_cf_registry.lookup(media_type, encoding)
#查找“CoAP内容格式”注册表内容\u格式=CoAP\u cf\u注册表。查找（媒体类型，编码）
# If an exact match is not found and a loose mapper has been # supplied, try to use it to get a media type with which to # retry the "CoAP Content-Formats" registry lookup. if content_format is None and loose_mapper is not None: content_format = coap_cf_registry.lookup( loose_mapper.lookup(media_type), encoding)
#如果未找到完全匹配且提供了松散映射器，请尝试使用它获取媒体类型，以便重试“CoAP内容格式”注册表查找。如果content\u format为None，loose\u mapper为None：content\u format=coap\u cf\u registry.lookup（loose\u mapper.lookup（媒体类型），编码）
return content_format
返回内容格式
Figure 2
图2
Payload content transcoding is an OPTIONAL feature. Implementations supporting this feature should provide a flexible way to define the set of transcodings allowed.
有效负载内容转码是可选功能。支持此功能的实现应该提供一种灵活的方式来定义允许的代码转换集。
The HC Proxy might decide to transcode the received representation to a different (compatible) format when an optimized version of a specific format exists. For example, an XML-encoded resource could be transcoded to Efficient XML Interchange (EXI) format, or a JSON-encoded resource into Concise Binary Object Representation (CBOR) [RFC7049], effectively achieving compression without losing any information.
当存在特定格式的优化版本时，HC代理可能会决定将接收到的表示转换为不同（兼容）格式。例如，可以将XML编码的资源转换为高效XML交换（EXI）格式，或将JSON编码的资源转换为简明二进制对象表示法（CBOR）[RFC7049]，有效地实现压缩而不丢失任何信息。
However, there are a few important factors to keep in mind when enabling a transcoding function:
然而，在启用转码功能时，需要记住几个重要因素：
1. Maliciously crafted inputs coming from the HTTP side might inflate in size (see, for example, Section 4.2 of [RFC7049]), therefore creating a security threat for both the HC Proxy and the target resource.
1. 来自HTTP端的恶意精心编制的输入可能会膨胀（例如，请参见[RFC7049]第4.2节），从而对HC代理和目标资源造成安全威胁。
2. Transcoding can lose information in non-obvious ways. For example, encoding an XML document using schema-informed EXI encoding leads to a loss of information when the destination does not know the exact schema version used by the encoder. That means that whenever the HC Proxy transcodes "application/xml" to "application/exi", in-band metadata could be lost.
2. 转码可能以不明显的方式丢失信息。例如，当目标不知道编码器使用的确切模式版本时，使用模式通知EXI编码对XML文档进行编码会导致信息丢失。这意味着，每当HC代理将“application/xml”转码为“application/exi”时，带内元数据都可能丢失。
3. When the Content-Type is mapped, there is a risk that the content with the destination type would have malware not active in the source type.
3. 映射内容类型时，存在目标类型的内容在源类型中没有活动恶意软件的风险。
It is crucial that these risks are well understood and carefully weighed against the actual benefits before deploying the transcoding function.
在部署代码转换功能之前，必须充分理解这些风险，并仔细权衡其实际好处。
The CoRE Link Format [RFC6690] is a set of links (i.e., URIs and their formal relationships) that is carried as content payload in a CoAP response. These links usually include CoAP URIs that might be translated by the HC Proxy to the correspondent HTTP URIs using the implemented URI mapping function (see Section 5). Such a translation process would inspect the forwarded traffic and attempt to rewrite the body of resources with an application/link-format media type, mapping the embedded CoAP URIs to their HTTP counterparts. Some potential issues with this approach are:
核心链接格式[RFC6690]是一组链接（即URI及其正式关系），在CoAP响应中作为内容有效负载携带。这些链接通常包括CoAP URI，HC代理可以使用实现的URI映射功能将其转换为相应的HTTP URI（参见第5节）。这样的转换过程将检查转发的通信量，并尝试用应用程序/链接格式的媒体类型重写资源体，将嵌入的CoAP URI映射到它们的HTTP对应项。这种方法的一些潜在问题是：
1. The client may be interested in retrieving original (unaltered) CoAP payloads through the HC Proxy, not modified versions.
1. 客户可能有兴趣通过HC代理检索原始（未更改）CoAP有效载荷，而不是修改版本。
2. Tampering with payloads is incompatible with resources that are integrity protected (although this is a problem with transcoding in general).
2. 篡改有效负载与受完整性保护的资源不兼容（尽管这通常是代码转换的问题）。
3. The HC Proxy needs to fully understand syntax and semantics defined in [RFC6690], otherwise there is an inherent risk to corrupt the payloads.
3. HC代理需要完全理解[RFC6690]中定义的语法和语义，否则存在损坏有效负载的固有风险。
Therefore, CoRE Link Format payload should only be transcoded at the risk and discretion of the proxy implementer.
因此，核心链路格式有效负载的转码应由代理实现者自行决定。
CoAP responses may, in certain error cases, contain a diagnostic message in the payload explaining the error situation, as described in Section 5.5.2 of [RFC7252]. If present, the CoAP diagnostic payload SHOULD be copied into the HTTP response body with the media type of the response set to "text/plain;charset=utf-8". The CoAP
在某些错误情况下，CoAP响应可能在有效载荷中包含解释错误情况的诊断消息，如[RFC7252]第5.5.2节所述。如果存在，应将CoAP诊断有效负载复制到HTTP响应正文中，并将响应的媒体类型设置为“text/plain；charset=utf-8”。CoAP
diagnostic payload MUST NOT be copied into the HTTP reason-phrase, since it potentially contains CR-LF characters that are incompatible with HTTP reason-phrase syntax.
不得将诊断负载复制到HTTP原因短语中，因为它可能包含与HTTP原因短语语法不兼容的CR-LF字符。
Table 2 defines the HTTP response status codes to which each CoAP response code SHOULD be mapped. Multiple HTTP status codes in the second column for a given CoAP response code indicates that multiple HTTP responses are possible for the same CoAP response code, depending on the conditions cited in the Notes (see the third column and text below the table).
表2定义了每个CoAP响应代码应映射到的HTTP响应状态代码。给定CoAP响应代码第二列中的多个HTTP状态代码表明，根据注释中引用的条件，同一CoAP响应代码可能有多个HTTP响应（见下表第三列和文本）。
+-------------------------------+----------------------------+------+
| CoAP Response Code | HTTP Status Code | Note |
+-------------------------------+----------------------------+------+
| 2.01 Created | 201 Created | 1 |
| 2.02 Deleted | 200 OK | 2 |
| | 204 No Content | 2 |
| 2.03 Valid | 304 Not Modified | 3 |
| | 200 OK | 4 |
| 2.04 Changed | 200 OK | 2 |
| | 204 No Content | 2 |
| 2.05 Content | 200 OK | |
| 2.31 Continue | N/A | 10 |
| 4.00 Bad Request | 400 Bad Request | |
| 4.01 Unauthorized | 403 Forbidden | 5 |
| 4.02 Bad Option | 400 Bad Request | 6 |
| | 500 Internal Server Error | 6 |
| 4.03 Forbidden | 403 Forbidden | |
| 4.04 Not Found | 404 Not Found | |
| 4.05 Method Not Allowed | 400 Bad Request | 7 |
| | 405 Method Not Allowed | 7 |
| 4.06 Not Acceptable | 406 Not Acceptable | |
| 4.08 Request Entity Incomplt. | N/A | 10 |
| 4.12 Precondition Failed | 412 Precondition Failed | |
| 4.13 Request Ent. Too Large | 413 Payload Too Large | 11 |
| 4.15 Unsupported Content-Fmt. | 415 Unsupported Media Type | |
| 5.00 Internal Server Error | 500 Internal Server Error | |
| 5.01 Not Implemented | 501 Not Implemented | |
| 5.02 Bad Gateway | 502 Bad Gateway | |
| 5.03 Service Unavailable | 503 Service Unavailable | 8 |
| 5.04 Gateway Timeout | 504 Gateway Timeout | |
| 5.05 Proxying Not Supported | 502 Bad Gateway | 9 |
+-------------------------------+----------------------------+------+
+-------------------------------+----------------------------+------+
| CoAP Response Code | HTTP Status Code | Note |
+-------------------------------+----------------------------+------+
| 2.01 Created | 201 Created | 1 |
| 2.02 Deleted | 200 OK | 2 |
| | 204 No Content | 2 |
| 2.03 Valid | 304 Not Modified | 3 |
| | 200 OK | 4 |
| 2.04 Changed | 200 OK | 2 |
| | 204 No Content | 2 |
| 2.05 Content | 200 OK | |
| 2.31 Continue | N/A | 10 |
| 4.00 Bad Request | 400 Bad Request | |
| 4.01 Unauthorized | 403 Forbidden | 5 |
| 4.02 Bad Option | 400 Bad Request | 6 |
| | 500 Internal Server Error | 6 |
| 4.03 Forbidden | 403 Forbidden | |
| 4.04 Not Found | 404 Not Found | |
| 4.05 Method Not Allowed | 400 Bad Request | 7 |
| | 405 Method Not Allowed | 7 |
| 4.06 Not Acceptable | 406 Not Acceptable | |
| 4.08 Request Entity Incomplt. | N/A | 10 |
| 4.12 Precondition Failed | 412 Precondition Failed | |
| 4.13 Request Ent. Too Large | 413 Payload Too Large | 11 |
| 4.15 Unsupported Content-Fmt. | 415 Unsupported Media Type | |
| 5.00 Internal Server Error | 500 Internal Server Error | |
| 5.01 Not Implemented | 501 Not Implemented | |
| 5.02 Bad Gateway | 502 Bad Gateway | |
| 5.03 Service Unavailable | 503 Service Unavailable | 8 |
| 5.04 Gateway Timeout | 504 Gateway Timeout | |
| 5.05 Proxying Not Supported | 502 Bad Gateway | 9 |
+-------------------------------+----------------------------+------+
Table 2: CoAP-HTTP Response Code Mappings
表2:CoAP HTTP响应代码映射
Notes:
笔记：
1. A CoAP server may return an arbitrary format payload along with this response. If present, this payload MUST be returned as an entity in the HTTP 201 response. Section 6.3.2 of [RFC7231] does not put any requirement on the format of the entity. (In the past, [RFC2616] did. Note that [RFC2616] has been obsoleted by [RFC7230].)
1. CoAP服务器可以随此响应返回任意格式的有效负载。如果存在，该有效负载必须作为HTTP 201响应中的实体返回。[RFC7231]第6.3.2节未对实体的格式提出任何要求。（在过去，[RFC2616]确实如此。请注意，[RFC2616]已被[RFC7230]淘汰。）
2. The HTTP code is 200 or 204, respectively, for the case where a CoAP server returns a payload or not. [RFC7231], Section 6.3 requires code 200 in case a representation of the action result is returned for DELETE/POST/PUT, and code 204 if not. Hence, a proxy MUST transfer any CoAP payload contained in a CoAP 2.02 response to the HTTP client using a 200 OK response.
2. 对于CoAP服务器是否返回有效负载的情况，HTTP代码分别为200或204。[RFC7231]，第6.3节要求在为DELETE/POST/PUT返回操作结果表示时使用代码200，否则使用代码204。因此，代理必须使用200OK响应将CoAP 2.02响应中包含的任何CoAP有效负载传输到HTTP客户端。
3. HTTP code 304 (Not Modified) is sent if the HTTP client performed a conditional HTTP request and the CoAP server responded with 2.03 (Valid) to the corresponding CoAP validation request. Note that Section 4.1 of [RFC7232] puts some requirements on header fields that must be present in the HTTP 304 response.
3. 如果HTTP客户端执行有条件的HTTP请求，并且CoAP服务器以2.03（有效）响应相应的CoAP验证请求，则发送HTTP代码304（未修改）。请注意，[RFC7232]的第4.1节对HTTP 304响应中必须存在的头字段提出了一些要求。
4. A 200 response to a CoAP 2.03 occurs only when the HC Proxy, for efficiency reasons, is running a local cache. An unconditional HTTP GET that produces a cache-hit could trigger a revalidation (i.e., a conditional GET) on the CoAP side. The proxy receiving 2.03 updates the freshness of its cached representation and returns it to the HTTP client.
4. 仅当HC代理出于效率原因正在运行本地缓存时，才会对CoAP 2.03做出200响应。产生缓存命中的无条件HTTP GET可能会在CoAP端触发重新验证（即条件GET）。接收2.03的代理更新其缓存表示的新鲜度，并将其返回给HTTP客户端。
5. An HTTP 401 Unauthorized (Section 3.1 of [RFC7235]) response is not applicable because there is no equivalent of WWW-Authenticate in CoAP, which is mandatory in an HTTP 401 response.
5. HTTP 401 Unauthorized（RFC7235第3.1节）响应不适用，因为CoAP中没有等效的WWW身份验证，这在HTTP 401响应中是强制性的。
6. If the proxy has a way to determine that the Bad Option is due to the straightforward mapping of a client request header into a CoAP option, then returning HTTP 400 (Bad Request) is appropriate. In all other cases, the proxy MUST return HTTP 500 (Internal Server Error) stating its inability to provide a suitable translation to the client's request.
6. 如果代理能够确定错误选项是由于客户机请求头直接映射到CoAP选项造成的，那么返回HTTP 400（错误请求）是合适的。在所有其他情况下，代理必须返回HTTP 500（内部服务器错误），说明其无法为客户端的请求提供适当的翻译。
7. A CoAP 4.05 (Method Not Allowed) response SHOULD normally be mapped to an HTTP 400 (Bad Request) code, because the HTTP 405 response would require specifying the supported methods -- which are generally unknown. In this case, the HC Proxy SHOULD also return an HTTP reason-phrase in the HTTP status line that starts with the string "CoAP server returned 4.05" in order to
7. CoAP 4.05（不允许方法）响应通常应映射到HTTP 400（错误请求）代码，因为HTTP 405响应需要指定支持的方法，这些方法通常是未知的。在这种情况下，HC代理还应在HTTP状态行中返回以字符串“CoAP server returned 4.05”开头的HTTP原因短语，以便
facilitate troubleshooting. However, if the HC Proxy has more granular information about the supported methods for the requested resource (e.g., via a Resource Directory ([CoRE-RD])), then it MAY send back an HTTP 405 (Method Not Allowed) with a properly filled in "Allow" response-header field (Section 7.4.1 of [RFC7231]).
便于故障排除。但是，如果HC代理具有关于所请求资源的支持方法的更详细信息（例如，通过资源目录（[CoRE RD]），则它可以发送回HTTP 405（不允许方法），并正确填写“允许”响应头字段（RFC7231的第7.4.1节）。
8. The value of the HTTP "Retry-After" response-header field is taken from the value of the CoAP Max-Age Option, if present.
8. HTTP“重试后”响应标头字段的值取自CoAP Max Age选项（如果存在）的值。
9. This CoAP response can only happen if the proxy itself is configured to use a CoAP forward-proxy (Section 5.7 of [RFC7252]) to execute some, or all, of its CoAP requests.
9. 只有当代理本身被配置为使用CoAP转发代理（RFC7252第5.7节）来执行其部分或全部CoAP请求时，才会发生此CoAP响应。
10. Only used in CoAP block-wise transfer [RFC7959] between HC Proxy and CoAP server; never translated into an HTTP response.
10. 仅用于HC代理和CoAP服务器之间的CoAP分块传输[RFC7959]；从未转换为HTTP响应。
11. Only returned to the HTTP client if the HC Proxy was unable to successfully complete the request by retrying it with CoAP block-wise transfer; see Section 8.3.
11. 仅当HC代理无法通过CoAP分块传输重试成功完成请求时，才返回HTTP客户端；见第8.3节。
An HC Proxy should cache CoAP responses and reply whenever applicable with a cached representation of the requested resource.
HC代理应该缓存CoAP响应，并在任何情况下使用请求资源的缓存表示进行应答。
If the HTTP client drops the connection after the HTTP request was made, an HC Proxy should wait for the associated CoAP response and cache it if possible. Subsequent requests to the HC Proxy for the same resource can use the result present in cache, or, if a response has still to come, the HTTP requests will wait on the open CoAP request.
如果HTTP客户端在发出HTTP请求后断开连接，HC代理应该等待相关的CoAP响应，并在可能的情况下缓存它。对同一资源的HC代理的后续请求可以使用缓存中的结果，或者，如果仍然需要响应，HTTP请求将等待open CoAP请求。
According to [RFC7252], a proxy must limit the number of outstanding requests to a given CoAP server to NSTART. To limit the amount of aggregate traffic to a constrained network, the HC Proxy should also put a limit on the number of concurrent CoAP requests pending on the same constrained network; further incoming requests may either be queued or be dropped (returning 503 Service Unavailable). This limit and the proxy queueing/dropping behavior should be configurable.
根据[RFC7252]，代理必须限制对NSTART给定CoAP服务器的未完成请求数。为了限制受限网络的聚合流量，HC代理还应限制同一受限网络上挂起的并发CoAP请求的数量；进一步的传入请求可以排队或丢弃（返回503服务不可用）。此限制和代理排队/丢弃行为应该是可配置的。
Highly volatile resources that are being frequently requested may be observed [RFC7641] by the HC Proxy to keep their cached representation fresh while minimizing the amount of CoAP traffic in the constrained network (see Section 8.2).
HC代理可以观察到频繁请求的高度易失性资源[RFC7641]，以保持其缓存表示的新鲜性，同时最小化受限网络中的CoAP流量（参见第8.2节）。
There are cases where using the CoAP observe protocol [RFC7641] to handle proxy cache refresh is preferable to the validation mechanism based on the entity-tag (ETag) as defined in [RFC7252]. Such scenarios include sleepy CoAP nodes -- with possibly high variance in requests' distribution -- which would greatly benefit from a server-driven cache update mechanism. Ideal candidates for CoAP observe are also crowded or very low throughput networks, where reduction of the total number of exchanged messages is an important requirement.
在某些情况下，使用CoAP观察协议[RFC7641]来处理代理缓存刷新比基于[RFC7252]中定义的实体标记（ETag）的验证机制更可取。这样的场景包括休眠的CoAP节点——请求分布可能差异很大——这将从服务器驱动的缓存更新机制中获益匪浅。CoAP观测的理想候选网络也是拥挤或吞吐量极低的网络，其中减少交换的消息总数是一项重要要求。
This subsection aims at providing a practical evaluation method to decide whether refreshing a cached resource R is more efficiently handled via ETag validation or by establishing an observation on R. The idea being that the HC Proxy proactively installs an observation on a "popular enough" resource and actively monitors:
本小节旨在提供一种实用的评估方法，以确定是通过ETag验证还是通过在R上建立观察来更有效地处理刷新缓存资源R。其思想是HC代理主动在“足够流行”的资源上安装观察，并主动监视：
a. Its update pattern on the CoAP side
a. 它在CoAP侧的更新模式
b. The request pattern on the HTTP side
b. HTTP端的请求模式
and uses the formula below to determine whether the observation should be kept alive or shut down.
并使用下面的公式来确定观测是应该保持活动还是应该关闭。
Let T_R be the mean time between two client requests to resource R, let T_C be the mean time between two representation changes of R, and let M_R be the mean number of CoAP messages per second exchanged to and from resource R. If we assume that the initial cost for establishing the observation is negligible, an observation on R reduces M_R if and only if T_R < 2*T_C with respect to using ETag validation, that is, if and only if the mean arrival rate of requests for resource R is greater than half the change rate of R.
T_R是两个客户端请求到资源R之间的平均时间，T_C是R的两个表示更改之间的平均时间，M_R是每秒与资源R交换的CoAP消息的平均数量。如果我们假设建立观测的初始成本可以忽略不计，当且仅当与使用ETag验证相关的T_R<2*T_C时，对R的观察减少了M_R，即，当且仅当资源R的请求的平均到达率大于R的变化率的一半时。
When observing the resource R, M_R is always upper bounded by 2/T_C.
当观察资源R时，M_R总是由2/T_C上界。
An HC Proxy SHOULD support CoAP block-wise transfers [RFC7959] to allow transport of large CoAP payloads while avoiding excessive link-layer fragmentation in constrained networks and to cope with small datagram buffers in CoAP endpoints as described in [RFC7252], Section 4.6.
HC代理应支持CoAP分块传输[RFC7959]，以允许传输大型CoAP有效负载，同时避免受限网络中的过度链路层碎片，并处理CoAP端点中的小型数据报缓冲区，如[RFC7252]第4.6节所述。
An HC Proxy SHOULD attempt to retry a payload-carrying CoAP PUT or POST request with block-wise transfer if the destination CoAP server responded with 4.13 (Request Entity Too Large) to the original request. An HC Proxy SHOULD attempt to use block-wise transfer when sending a CoAP PUT or POST request message that is larger than
如果目标CoAP服务器对原始请求的响应为4.13（请求实体太大），HC代理应尝试通过分块传输重试承载CoAP PUT或POST请求的有效负载。HC代理在发送大于的CoAP PUT或POST请求消息时应尝试使用分块传输
BLOCKWISE_THRESHOLD bytes. The value of BLOCKWISE_THRESHOLD is implementation specific; for example, it can be:
分块_阈值字节。分块_阈值的值是特定于实现的；例如，它可以是：
o Calculated based on a known or typical UDP datagram buffer size for CoAP endpoints, or
o 基于CoAP端点的已知或典型UDP数据报缓冲区大小计算，或
o Set to N times the known size of a link-layer frame in a constrained network where, e.g., N=5, or
o 设置为受约束网络中链路层帧的已知大小的N倍，例如，N=5，或
o Preset to a known IP MTU value, or
o 预设为已知的IP MTU值，或
o Set to a known Path MTU value.
o 设置为已知路径MTU值。
The value BLOCKWISE_THRESHOLD, or the parameters from which it is calculated, should be configurable in a proxy implementation. The maximum block size the proxy will attempt to use in CoAP requests should also be configurable.
应在代理实现中配置值分块_阈值或计算阈值的参数。代理将尝试在CoAP请求中使用的最大块大小也应该是可配置的。
The HC Proxy SHOULD detect CoAP endpoints not supporting block-wise transfers. This can be done by checking for a 4.02 (Bad Option) response returned by an endpoint in response to a CoAP request with a Block* Option, and subsequent absence of the 4.02 in response to the same request without Block* Options. This allows the HC Proxy to be more efficient, not attempting repeated block-wise transfers to CoAP servers that do not support it.
HC代理应该检测不支持分块传输的CoAP端点。这可以通过检查端点返回的4.02（坏选项）响应来完成，该响应是对带有Block*选项的CoAP请求的响应，以及随后不带Block*选项的相同请求的响应中没有4.02。这使得HC代理更高效，而不需要尝试重复向不支持它的CoAP服务器进行分块传输。
An HC Proxy MAY support CoAP multicast. If it does, the HC Proxy sends out a multicast CoAP request if the Target CoAP URI's authority is a multicast IP literal or resolves to a multicast IP address. If the HC Proxy does not support CoAP multicast, it SHOULD respond 403 (Forbidden) to any valid HTTP request that maps to a CoAP multicast request.
HC代理可以支持CoAP多播。如果确实如此，则如果目标CoAP URI的权限是多播IP文本或解析为多播IP地址，HC代理将发送多播CoAP请求。如果HC代理不支持CoAP多播，它应该对映射到CoAP多播请求的任何有效HTTP请求做出403（禁止）响应。
Details related to supporting CoAP multicast are currently out of scope of this document since in a proxy scenario, an HTTP client typically expects to receive a single response, not multiple. However, an HC Proxy that implements CoAP multicast may include application-specific functions to aggregate multiple CoAP responses into a single HTTP response. We suggest using the "application/http" Internet media type (Section 8.3.2 of [RFC7230]) to enclose a set of one or more HTTP response messages, each representing the mapping of one CoAP response.
与支持CoAP多播相关的详细信息目前不在本文档的范围内，因为在代理场景中，HTTP客户端通常希望收到单个响应，而不是多个响应。然而，实现CoAP多播的HC代理可以包括特定于应用程序的功能，以将多个CoAP响应聚合为单个HTTP响应。我们建议使用“应用程序/http”互联网媒体类型（RFC7230的第8.3.2节）来封装一组一个或多个http响应消息，每个消息表示一个CoAP响应的映射。
For further considerations related to the handling of multicast requests, see Section 10.1.
有关处理多播请求的更多注意事项，请参见第10.1节。
If the CoAP server takes a long time in responding, the HTTP client or any other proxy in between may timeout. Further discussion of timeouts in HTTP is available in Section 6.5 of [RFC7230].
如果CoAP服务器需要很长时间响应，HTTP客户端或其间的任何其他代理可能会超时。[RFC7230]的第6.5节提供了关于HTTP超时的进一步讨论。
An HC Proxy MUST define an internal timeout for each pending CoAP request, because the CoAP server may silently die before completing the request. Assuming the proxy uses confirmable CoAP requests, such timeout value T SHOULD be
HC代理必须为每个挂起的CoAP请求定义一个内部超时，因为CoAP服务器在完成请求之前可能会自动关闭。假设代理使用可确认的CoAP请求，则该超时值T应为
T = MAX_RTT + MAX_SERVER_RESPONSE_DELAY
T=最大RTT+最大服务器响应延迟
where MAX_RTT is defined in [RFC7252] and MAX_SERVER_RESPONSE_DELAY is defined as the worst-case expected response delay of the CoAP server. If unknown, a default value of 250 seconds can be used for MAX_SERVER_RESPONSE_DELAY as in Section 2.5 of [RFC7390].
其中，[RFC7252]中定义了MAX_RTT，MAX_SERVER_RESPONSE_DELAY定义为CoAP服务器最坏情况下的预期响应延迟。如果未知，默认值250秒可用于最大服务器响应延迟，如[RFC7390]第2.5节所述。
This document registers a new Resource Type (rt=) Link Target Attribute, 'core.hc', in the "Resource Type (rt=) Link Target Attribute Values" subregistry under the "Constrained RESTful Environments (CoRE) Parameters" registry.
本文档在“受限RESTful环境（core）参数”注册表下的“资源类型（rt=）链接目标属性值”子注册表中注册一个新的资源类型（rt=）链接目标属性“core.hc”。
Attribute Value: core.hc
属性值：core.hc
Description: HTTP-to-CoAP mapping base resource.
描述：HTTP到CoAP映射基础资源。
Reference: See Section 5.5 of RFC 8075.
参考：见RFC 8075第5.5节。
This document defines the "application/coap-payload" media type with a single parameter "cf". This media type represents any payload that a CoAP message can carry, having a content-format that can be identified by an integer in range 0-65535 corresponding to a CoAP Content-Format parameter ([RFC7252], Section 12.3). The parameter "cf" is the integer defining the CoAP content-format.
本文档使用单个参数“cf”定义“应用程序/coap有效负载”介质类型。此媒体类型表示CoAP消息可以承载的任何有效负载，其内容格式可以由范围0-65535内的整数标识，该整数对应于CoAP内容格式参数（[RFC7252]，第12.3节）。参数“cf”是定义CoAP内容格式的整数。
Type name: application
类型名称：应用程序
Subtype name: coap-payload
子类型名称：coap有效负载
Required parameters: "cf" (CoAP Content-Format integer in range 0-65535 denoting the content-format of the CoAP payload carried, as
所需参数：“cf”（范围为0-65535的CoAP内容格式整数，表示所携带的CoAP有效载荷的内容格式，如下所示
defined by the "CoAP Content-Formats" subregistry that is part of the "Constrained RESTful Environments (CoRE) Parameters" registry).
由“CoAP内容格式”子区定义，该子区是“受限RESTful环境（核心）参数”注册表的一部分）。
Optional parameters: None
可选参数：无
Encoding considerations: Common use is BINARY. The specific CoAP content-format encoding considerations for the selected Content-Format ("cf" parameter) apply. The encoding can vary based on the value of the "cf" parameter.
编码注意事项：常用的是二进制。所选内容格式（“cf”参数）的特定CoAP内容格式编码注意事项适用。根据“cf”参数的值，编码可能会有所不同。
Security considerations: The specific CoAP content-format security considerations for the selected Content-Format ("cf" parameter) apply.
安全注意事项：所选内容格式（“cf”参数）的特定CoAP内容格式安全注意事项适用。
Interoperability considerations: This media type can never be used directly in CoAP messages because there are no means available to encode the mandatory "cf" parameter in CoAP.
互操作性注意事项：此媒体类型永远不能直接用于CoAP消息中，因为没有任何方法可用于编码CoAP中的强制“cf”参数。
Published specification: RFC 8075
已发布规范：RFC 8075
Applications that use this media type: HTTP-to-CoAP proxies.
使用此媒体类型的应用程序：HTTP到CoAP代理。
Fragment identifier considerations: CoAP does not support URI fragments; therefore, a CoAP payload fragment cannot be identified. Fragments are not applicable for this media type.
片段标识符注意事项：CoAP不支持URI片段；因此，无法识别CoAP有效载荷片段。片段不适用于此媒体类型。
Additional information:
其他信息：
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:
联系人和电子邮件地址，以获取更多信息：
Esko Dijk ("esko@ieee.org")
艾斯科·迪克（“esko@ieee.org")
Intended usage: COMMON
预期用途：普通
Restrictions on usage:
使用限制：
An application (or user) can only use this media type if it has to represent a CoAP payload of which the specified CoAP Content-Format is an unrecognized number, such that a proper translation directly to the equivalent HTTP media type is not possible.
只有当应用程序（或用户）必须表示指定的CoAP内容格式是无法识别的数字的CoAP有效负载时，应用程序（或用户）才能使用此媒体类型，从而无法直接正确转换为等效的HTTP媒体类型。
Author: CoRE WG
作者：核心工作组
Change controller: IETF
更改控制器：IETF
Provisional registration: No
临时注册：否
The security considerations in Section 9.2 of [RFC7230] apply in full to the HC Proxy. This section discusses security aspects and requirements that are specific to the deployment and operation of an HC Proxy.
[RFC7230]第9.2节中的安全注意事项完全适用于HC代理。本节讨论特定于HC代理的部署和操作的安全方面和要求。
An HC Proxy located at the boundary of a constrained network is an easy single point of failure for reducing availability. As such, special care should be taken in designing, developing, and operating it, keeping in mind that, in most cases, it has fewer limitations than the constrained devices it is serving. In particular, its quality of implementation and operation -- i.e., use of current software development practices, careful selection of third-party libraries, sane configuration defaults, and an expedited way to upgrade a running instance -- are all essential attributes of the HC Proxy.
位于受限网络边界处的HC代理是降低可用性的一个容易的单点故障。因此，在设计、开发和操作它时应特别小心，记住，在大多数情况下，它比它所服务的受限设备具有更少的限制。特别是，它的实现和操作质量——即使用当前的软件开发实践、仔细选择第三方库、合理的配置默认值以及快速升级正在运行的实例——都是HC代理的基本属性。
The correctness of request parsing in general (including any content transcoding), and of URI translation in particular, is essential to the security of the HC Proxy function. This is especially true when the constrained network hosts devices with genuinely limited capabilities. For this purpose, see also Sections 9.3, 9.4, 9.5 and 9.6 of [RFC7230] for well-known issues related to HTTP request parsing and Section 11.1 of [RFC7252] for an overview of CoAP-specific concerns related to URI processing -- in particular, the potential impact on access control mechanisms that are based on URIs.
请求解析（包括任何内容转码）的正确性，特别是URI转换的正确性，对于HC代理函数的安全性至关重要。当受约束的网络承载具有真正有限功能的设备时，尤其如此。为此，请参见[RFC7230]第9.3、9.4、9.5和9.6节，了解与HTTP请求解析相关的众所周知的问题；参见[RFC7252]第11.1节，了解与URI处理相关的CoAP特定问题的概述，特别是对基于URI的访问控制机制的潜在影响。
An HC Proxy MUST implement Transport Layer Security (TLS) with a Pre-Shared Key (PSK) [RFC4279] and SHOULD implement TLS [RFC5246] with support for client authentication using X.509 certificates. A prerequisite of the latter is the availability of a Certification Authority (CA) to issue suitable certificates. Although this can be a challenging requirement in certain application scenarios, it is worth noting that there exist open-source tools (e.g., [OpenSSL]) that can be used to set up and operate an application-specific CA.
HC代理必须使用预共享密钥（PSK）[RFC4279]实现传输层安全性（TLS），并应实现TLS[RFC5246]，支持使用X.509证书进行客户端身份验证。后者的先决条件是有证书颁发机构（CA）颁发适当的证书。尽管这在某些应用场景中可能是一个具有挑战性的要求，但值得注意的是，存在可用于设置和操作特定于应用程序的CA的开源工具（例如[OpenSSL]）。
By default, the HC Proxy MUST authenticate all incoming requests prior to forwarding them to the CoAP server. This default behavior MAY be explicitly disabled by an administrator.
默认情况下，HC代理必须在将所有传入请求转发到CoAP服务器之前对其进行身份验证。管理员可以显式禁用此默认行为。
The following subparagraphs categorize and discuss a set of specific security issues related to the translation, caching, and forwarding functionality exposed by an HC Proxy.
以下各小节对HC代理公开的转换、缓存和转发功能相关的一组特定安全问题进行了分类和讨论。
Multicast requests impose a non-trivial cost on the constrained network and endpoints and might be exploited as a DoS attack vector (see also Section 10.2). From a privacy perspective, they can be used to gather detailed information about the resources hosted in the constrained network. For example, an outsider that is able to successfully query the "/.well-known/core" resource could obtain a comprehensive list of the target's home appliances and devices. From a security perspective, they can be used to carry out a network reconnaissance attack to gather information about possible vulnerabilities that could be exploited at a later point in time. For these reasons, it is RECOMMENDED that requests to multicast resources are access controlled with a default-deny policy. It is RECOMMENDED that the requestor of a multicast resource be strongly authenticated. If privacy and/or security are first class requirements, for example, whenever the HTTP request transits through the public Internet, the request SHOULD be transported over a mutually authenticated and encrypted TLS connection.
组播请求在受限网络和端点上施加非平凡的成本，并且可以被用作DoS攻击向量（参见第10.2节）。从隐私角度来看，它们可用于收集受约束网络中承载的资源的详细信息。例如，能够成功查询“/.well-known/core”资源的外部人员可以获得目标公司家用电器和设备的综合列表。从安全角度来看，它们可用于执行网络侦察攻击，以收集有关可能在稍后时间被利用的漏洞的信息。出于这些原因，建议使用默认的拒绝策略对多播资源的请求进行访问控制。建议对多播资源的请求者进行强身份验证。如果隐私和/或安全是头等要求，例如，每当HTTP请求通过公共互联网传输时，该请求应通过相互认证和加密的TLS连接传输。
Due to the typically constrained nature of CoAP nodes, particular attention should be given to the implementation of traffic reduction mechanisms (see Section 8.1), because an inefficient proxy implementation can be targeted by unconstrained Internet attackers. Bandwidth or complexity involved in such attacks is very low.
由于CoAP节点的典型约束性质，应特别注意流量减少机制的实施（见第8.1节），因为效率低下的代理实施可能会成为无约束互联网攻击者的目标。此类攻击涉及的带宽或复杂性非常低。
An amplification attack to the constrained network may be triggered by a multicast request generated by a single HTTP request that is mapped to a CoAP multicast resource, as discussed in Section 11.3 of [RFC7252].
如[RFC7252]第11.3节所述，由映射到CoAP多播资源的单个HTTP请求生成的多播请求可能会触发对受约束网络的放大攻击。
The risk likelihood of this amplification technique is higher than an amplification attack carried out by a malicious constrained device (e.g., ICMPv6 flooding, like Packet Too Big, or Parameter Problem on a multicast destination [RFC4732]) since it does not require direct access to the constrained network.
这种放大技术的风险可能性高于恶意受限设备实施的放大攻击（例如，ICMPv6泛洪，如数据包过大，或多播目的地[RFC4732]上的参数问题），因为它不需要直接访问受限网络。
The feasibility of this attack, which disrupts availability of the targeted CoAP server, can be limited by access controlling the exposed multicast resources, so that only known/authorized users can access such URIs.
这种攻击破坏目标CoAP服务器的可用性，其可行性可以通过访问控制公开的多播资源来限制，因此只有已知/授权用户可以访问此类URI。
An HTTP request can be sent to the HC Proxy over a secured connection. However, there may not always exist a secure connection mapping to CoAP. For example, a secure distribution method for multicast traffic is complex and may not be implemented (see [RFC7390]).
HTTP请求可以通过安全连接发送到HC代理。但是，可能并不总是存在到CoAP的安全连接映射。例如，多播流量的安全分发方法很复杂，可能无法实现（请参见[RFC7390]）。
An HC Proxy should implement rules for security context translations. For example, all 'https' unicast requests are translated to 'coaps' requests, or 'https' requests are translated to unsecured 'coap' requests. Another rule could specify the security policy and parameters used for Datagram Transport Layer Security (DTLS) sessions [RFC7925]. Such rules will largely depend on the application and network context in which the HC Proxy operates. These rules should be configurable.
HC代理应该实现安全上下文转换的规则。例如，所有“https”单播请求被转换为“coap”请求，或者“https”请求被转换为不安全的“coap”请求。另一条规则可以指定用于数据报传输层安全（DTLS）会话的安全策略和参数[RFC7925]。此类规则在很大程度上取决于HC代理运行的应用程序和网络上下文。这些规则应该是可配置的。
It is RECOMMENDED that, by default, accessing a 'coaps' URI is only allowed from a corresponding 'https' URI.
建议在默认情况下，仅允许从相应的“https”URI访问“coaps”URI。
By default, an HC Proxy SHOULD reject any secured CoAP client request (i.e., one with a 'coaps' scheme) if there is no configured security policy mapping. This recommendation may be relaxed in case the destination network is believed to be secured by other means. Assuming that CoAP nodes are isolated behind a firewall as in the HC Proxy deployment shown in Figure 1, the HC Proxy may be configured to translate the incoming HTTPS request using plain CoAP (NoSec mode).
默认情况下，如果没有配置的安全策略映射，HC代理应该拒绝任何安全的CoAP客户端请求（即具有“CoAP”方案的请求）。如果认为目的地网络通过其他方式安全，则可放宽该建议。假设CoAP节点隔离在防火墙后面，如图1所示的HC代理部署中所示，HC代理可以配置为使用普通CoAP（NOSC模式）转换传入的HTTPS请求。
The following risks related to the URI mapping described in Section 5 and its use by an HC Proxy have been identified:
已确定与第5节中描述的URI映射及其由HC代理使用相关的以下风险：
DoS attack on the constrained/CoAP network. Mitigation: by default, deny any Target CoAP URI whose authority is (or maps to) a multicast address. Then explicitly whitelist multicast resources/authorities that are allowed to be dereferenced. See also Section 8.4.
受约束/CoAP网络上的DoS攻击。缓解：默认情况下，拒绝授权为（或映射到）多播地址的任何目标CoAP URI。然后明确列出允许取消引用的多播资源/权限。另见第8.4节。
Leaking information on the constrained/CoAP network resources and topology. Mitigation: by default, deny any Target CoAP URI (especially "/.well-known/core" is a resource to be protected), and then explicitly whitelist resources that are allowed to be seen by clients outside the constrained network.
泄漏有关受限/CoAP网络资源和拓扑的信息。缓解措施：默认情况下，拒绝任何目标CoAP URI（特别是“/.well-known/core”是要保护的资源），然后明确列出受约束网络之外的客户端可以看到的资源的白名单。
The CoAP target resource is totally transparent from outside the constrained network. Mitigation: implement an HTTPS-only interface, which makes the Target CoAP URI totally opaque to a passive attacker outside the constrained network.
CoAP目标资源在受限网络外部是完全透明的。缓解措施：实现一个仅HTTPS的接口，使目标CoAP URI对受约束网络之外的被动攻击者完全不透明。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<http://www.rfc-editor.org/info/rfc3986>.
[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, DOI 10.17487/RFC4279, December 2005, <http://www.rfc-editor.org/info/rfc4279>.
[RFC4279]Eronen，P.，Ed.和H.Tschofenig，Ed.，“用于传输层安全（TLS）的预共享密钥密码套件”，RFC 4279，DOI 10.17487/RFC4279，2005年12月<http://www.rfc-editor.org/info/rfc4279>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, <http://www.rfc-editor.org/info/rfc6570>.
[RFC6570]Gregorio，J.，Fielding，R.，Hadley，M.，Nottingham，M.，和D.Orchard，“URI模板”，RFC 6570，DOI 10.17487/RFC657012年3月<http://www.rfc-editor.org/info/rfc6570>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, <http://www.rfc-editor.org/info/rfc6690>.
[RFC6690]Shelby，Z.“受限RESTful环境（核心）链接格式”，RFC 6690，DOI 10.17487/RFC6690，2012年8月<http://www.rfc-editor.org/info/rfc6690>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 7231，DOI 10.17487/RFC72312014年6月<http://www.rfc-editor.org/info/rfc7231>.
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, <http://www.rfc-editor.org/info/rfc7232>.
[RFC7232]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：有条件请求”，RFC 7232，DOI 10.17487/RFC72322014年6月<http://www.rfc-editor.org/info/rfc7232>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>.
[RFC7235]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：认证”，RFC 7235，DOI 10.17487/RFC7235，2014年6月<http://www.rfc-editor.org/info/rfc7235>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <http://www.rfc-editor.org/info/rfc7252>.
[RFC7252]Shelby，Z.，Hartke，K.，和C.Bormann，“受限应用协议（CoAP）”，RFC 7252，DOI 10.17487/RFC7252，2014年6月<http://www.rfc-editor.org/info/rfc7252>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, <http://www.rfc-editor.org/info/rfc7641>.
[RFC7641]Hartke，K.，“受限应用协议（CoAP）中的观测资源”，RFC 7641，DOI 10.17487/RFC7641，2015年9月<http://www.rfc-editor.org/info/rfc7641>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, <http://www.rfc-editor.org/info/rfc7959>.
[RFC7959]Bormann，C.和Z.Shelby，编辑，“受限应用协议（CoAP）中的分块传输”，RFC 7959，DOI 10.17487/RFC7959，2016年8月<http://www.rfc-editor.org/info/rfc7959>.
[CoRE-JSON-CBOR] Li, K., Rahman, A., and C. Bormann, "Representing CoRE Formats in JSON and CBOR", Work in Progress, draft-ietf-core-links-json-06, July 2016.
[CoRE JSON CBOR]Li，K.，Rahman，A.，和C.Bormann，“以JSON和CBOR表示核心格式”，正在进行的工作，草稿-ietf-CoRE-links-JSON-062016年7月。
[CoRE-RD] Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE Resource Directory", Work in Progress, draft-ietf-core-resource-directory-09, October 2016.
[核心研发]谢尔比，Z.，科斯特，M.，鲍曼，C.，和P.斯托克，“核心资源目录”，正在进行的工作，草稿-ietf-CoRE-Resource-Directory-092016年10月。
[Fielding] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", PhD Dissertation, University of California, Irvine, ISBN 0-599-87118-0, 2000.
菲尔丁，R，“Architectural Styles和基于网络的软件架构设计”，博士论文，加利福尼亚大学，尔湾，ISBN 05998118-0，2000。
[OpenSSL] The OpenSSL Project, , "ca - sample minimal CA application", 2000-2016, <https://www.openssl.org/docs/manmaster/man1/ca.html>.
[OpenSSL]OpenSSL项目，“ca-样本最小ca应用程序”，2000-2016年<https://www.openssl.org/docs/manmaster/man1/ca.html>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/RFC2616, June 1999, <http://www.rfc-editor.org/info/rfc2616>.
[RFC2616]Fielding，R.，Gettys，J.，Mogul，J.，Frystyk，H.，Masinter，L.，Leach，P.，和T.Berners Lee，“超文本传输协议——HTTP/1.1”，RFC 2616，DOI 10.17487/RFC2616，1999年6月<http://www.rfc-editor.org/info/rfc2616>.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, DOI 10.17487/RFC2663, August 1999, <http://www.rfc-editor.org/info/rfc2663>.
[RFC2663]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，DOI 10.17487/RFC2663，1999年8月<http://www.rfc-editor.org/info/rfc2663>.
[RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, DOI 10.17487/RFC3040, January 2001, <http://www.rfc-editor.org/info/rfc3040>.
[RFC3040]Cooper，I.，Melve，I.，和G.Tomlinson，“互联网Web复制和缓存分类法”，RFC 3040，DOI 10.17487/RFC3040，2001年1月<http://www.rfc-editor.org/info/rfc3040>.
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, DOI 10.17487/RFC4732, December 2006, <http://www.rfc-editor.org/info/rfc4732>.
[RFC4732]Handley，M.，Ed.，Rescorla，E.，Ed.，和IAB，“互联网拒绝服务注意事项”，RFC 4732，DOI 10.17487/RFC4732，2006年12月<http://www.rfc-editor.org/info/rfc4732>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, <http://www.rfc-editor.org/info/rfc6454>.
[RFC6454]Barth，A.，“网络起源概念”，RFC 6454，DOI 10.17487/RFC6454，2011年12月<http://www.rfc-editor.org/info/rfc6454>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, <http://www.rfc-editor.org/info/rfc7049>.
[RFC7049]Bormann，C.和P.Hoffman，“简明二进制对象表示法（CBOR）”，RFC 7049，DOI 10.17487/RFC7049，2013年10月<http://www.rfc-editor.org/info/rfc7049>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <http://www.rfc-editor.org/info/rfc7228>.
[RFC7228]Bormann，C.，Ersue，M.和A.Keranen，“受限节点网络的术语”，RFC 7228，DOI 10.17487/RFC7228，2014年5月<http://www.rfc-editor.org/info/rfc7228>.
[RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for the Constrained Application Protocol (CoAP)", RFC 7390, DOI 10.17487/RFC7390, October 2014, <http://www.rfc-editor.org/info/rfc7390>.
[RFC7390]Rahman，A.，Ed.和E.Dijk，Ed.，“受限应用协议（CoAP）的组通信”，RFC 7390，DOI 10.17487/RFC7390，2014年10月<http://www.rfc-editor.org/info/rfc7390>.
[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things", RFC 7925, DOI 10.17487/RFC7925, July 2016, <http://www.rfc-editor.org/info/rfc7925>.
[RFC7925]Tschofenig，H.，Ed.和T.Fossati，“物联网的传输层安全（TLS）/数据报传输层安全（DTLS）配置文件”，RFC 7925，DOI 10.17487/RFC79252016年7月<http://www.rfc-editor.org/info/rfc7925>.
[W3C.REC-html5-20141028] Hickson, I., Berjon, R., Faulkner, S., Leithead, T., Navara, E., O'Connor, E., and S. Pfeiffer, "HTML5", World Wide Web Consortium Recommendation REC-html5-20141028, October 2014, <http://www.w3.org/TR/2014/REC-html5-20141028>.
[W3C.REC-html5-20141028]希克森，I.，伯容，R.，福克纳，S.，莱西亚特，T.，纳瓦拉，E.，奥康纳，E.，和S.普菲弗，“html5”，万维网联盟建议REC-html5-20141028，2014年10月<http://www.w3.org/TR/2014/REC-html5-20141028>.
#!/usr/bin/env python
#!/usr/bin/env python
import unittest import re
导入单元测试导入re
class CoAPContentFormatRegistry(object): """Map an Internet media type (and optional inherent encoding) to a CoAP Content-Format. """ TEXT_PLAIN = 0 LINK_FORMAT = 40 XML = 41 OCTET_STREAM = 42 EXI = 47 JSON = 50 CBOR = 60 GROUP_JSON = 256
类CoAPContentFormatRegistry（对象）：“将Internet媒体类型（以及可选的固有编码）映射到CoAP内容格式。”“TEXT\u PLAIN=0 LINK\u Format=40 XML=41 OCTET\u STREAM=42 EXI=47 JSON=50 CBOR=60 GROUP\u JSON=256
# http://www.iana.org/assignments/core-parameters
# as of 2016/10/24.
LOOKUP_TABLE = {
("text/plain;charset=utf-8", None): TEXT_PLAIN,
("application/link-format", None): LINK_FORMAT,
("application/xml", None): XML,
("application/octet-stream", None): OCTET_STREAM,
("application/exi", None): EXI,
("application/json", None): JSON,
("application/cbor", None): CBOR,
("application/coap-group+json", "utf-8"): GROUP_JSON,
}
# http://www.iana.org/assignments/core-parameters
# as of 2016/10/24.
LOOKUP_TABLE = {
("text/plain;charset=utf-8", None): TEXT_PLAIN,
("application/link-format", None): LINK_FORMAT,
("application/xml", None): XML,
("application/octet-stream", None): OCTET_STREAM,
("application/exi", None): EXI,
("application/json", None): JSON,
("application/cbor", None): CBOR,
("application/coap-group+json", "utf-8"): GROUP_JSON,
}
def lookup(self, media_type, encoding): """Return the CoAP Content-Format matching the supplied media type (and optional encoding), or None if no match can be found.""" return CoAPContentFormatRegistry.LOOKUP_TABLE.get( (media_type, encoding), None)
def查找（自我，媒体类型，编码）：“返回与提供的媒体类型（和可选编码）匹配的CoAP内容格式，如果找不到匹配项，则返回None。”“返回CoAPContentFormatRegistry.lookup\u TABLE.get（（媒体类型，编码），None）
class LooseMediaTypeMapper(object):
# Order matters in this table: more specific types have higher rank
# compared to less specific types.
# This code only performs a shallow validation of acceptable
# characters and assumes overall validation of the media type and
# subtype has been done beforehand.
LOOKUP_TABLE = [
(re.compile("application/.+\+xml$"), "application/xml"),
(re.compile("application/.+\+json$"), "application/json"),
(re.compile("application/.+\+cbor$"), "application/cbor"),
(re.compile("text/xml$"), "application/xml"),
(re.compile("text/[a-z\.\-\+]+$"), "text/plain;charset=utf-8"),
(re.compile("[a-z]+/[a-z\.\-\+]+$"), "application/octet-stream")
]
class LooseMediaTypeMapper(object):
# Order matters in this table: more specific types have higher rank
# compared to less specific types.
# This code only performs a shallow validation of acceptable
# characters and assumes overall validation of the media type and
# subtype has been done beforehand.
LOOKUP_TABLE = [
(re.compile("application/.+\+xml$"), "application/xml"),
(re.compile("application/.+\+json$"), "application/json"),
(re.compile("application/.+\+cbor$"), "application/cbor"),
(re.compile("text/xml$"), "application/xml"),
(re.compile("text/[a-z\.\-\+]+$"), "text/plain;charset=utf-8"),
(re.compile("[a-z]+/[a-z\.\-\+]+$"), "application/octet-stream")
]
def lookup(self, media_type): """Return the best loose media type match available using the contents of LOOKUP_TABLE.""" for entry in LooseMediaTypeMapper.LOOKUP_TABLE: if entry[0].match(media_type) is not None: return entry[1] return None
def lookup（自我，媒体类型）：“使用lookup_表的内容返回可用的最佳松散媒体类型匹配。”“对于LookeMediaTypeMapper中的条目。lookup_表：如果条目[0]。匹配（媒体类型）不是无：返回条目[1]返回无
def mt2cf(media_type, encoding=None, coap_cf_registry=CoAPContentFormatRegistry(), loose_mapper=None): """Return a CoAP Content-Format given an Internet media type and its optional encoding. The current (as of 2016/10/24) "CoAP Content-Formats" registry is supplied by default. An optional 'loose-mapping' implementation can be supplied by the caller.""" assert media_type is not None assert coap_cf_registry is not None
def mt2cf（媒体类型，编码=无，coap\U cf\U注册表=CoAPContentFormatRegistry（），loose\u mapper=无）：“返回给定Internet媒体类型及其可选编码的coap内容格式。当前（自2016/10/24起）”coap内容格式“默认情况下提供注册表。调用者可以提供可选的“松散映射”实现。“”断言媒体类型不是无断言coap\u cf\u注册表不是无
# Lookup the "CoAP Content-Formats" registry content_format = coap_cf_registry.lookup(media_type, encoding)
#查找“CoAP内容格式”注册表内容\u格式=CoAP\u cf\u注册表。查找（媒体类型，编码）
# If an exact match is not found and a loose mapper has been # supplied, try to use it to get a media type with which to # retry the "CoAP Content-Formats" registry lookup. if content_format is None and loose_mapper is not None: content_format = coap_cf_registry.lookup( loose_mapper.lookup(media_type), encoding)
#如果未找到完全匹配且提供了松散映射器，请尝试使用它获取媒体类型，以便重试“CoAP内容格式”注册表查找。如果content\u format为None，loose\u mapper为None：content\u format=coap\u cf\u registry.lookup（loose\u mapper.lookup（媒体类型），编码）
return content_format
返回内容格式
class TestMT2CF(unittest.TestCase):
类TestMT2CF（unittest.TestCase）：
def testMissingContentType(self):
with self.assertRaises(AssertionError):
mt2cf(None)
def testMissingContentType(self):
with self.assertRaises(AssertionError):
mt2cf(None)
def testMissingContentFormatRegistry(self):
with self.assertRaises(AssertionError):
mt2cf(None, coap_cf_registry=None)
def testMissingContentFormatRegistry(self):
with self.assertRaises(AssertionError):
mt2cf(None, coap_cf_registry=None)
def testTextPlain(self):
self.assertEqual(mt2cf("text/plain;charset=utf-8"),
CoAPContentFormatRegistry.TEXT_PLAIN)
def testTextPlain(self):
self.assertEqual(mt2cf("text/plain;charset=utf-8"),
CoAPContentFormatRegistry.TEXT_PLAIN)
def testLinkFormat(self):
self.assertEqual(mt2cf("application/link-format"),
CoAPContentFormatRegistry.LINK_FORMAT)
def testLinkFormat(self):
self.assertEqual(mt2cf("application/link-format"),
CoAPContentFormatRegistry.LINK_FORMAT)
def testXML(self):
self.assertEqual(mt2cf("application/xml"),
CoAPContentFormatRegistry.XML)
def testXML(self):
self.assertEqual(mt2cf("application/xml"),
CoAPContentFormatRegistry.XML)
def testOctetStream(self):
self.assertEqual(mt2cf("application/octet-stream"),
CoAPContentFormatRegistry.OCTET_STREAM)
def testOctetStream(self):
self.assertEqual(mt2cf("application/octet-stream"),
CoAPContentFormatRegistry.OCTET_STREAM)
def testEXI(self):
self.assertEqual(mt2cf("application/exi"),
CoAPContentFormatRegistry.EXI)
def testEXI(self):
self.assertEqual(mt2cf("application/exi"),
CoAPContentFormatRegistry.EXI)
def testJSON(self):
self.assertEqual(mt2cf("application/json"),
CoAPContentFormatRegistry.JSON)
def testJSON(self):
self.assertEqual(mt2cf("application/json"),
CoAPContentFormatRegistry.JSON)
def testCBOR(self):
self.assertEqual(mt2cf("application/cbor"),
CoAPContentFormatRegistry.CBOR)
def testCBOR(self):
self.assertEqual(mt2cf("application/cbor"),
CoAPContentFormatRegistry.CBOR)
def testCoAPGroupJSON(self):
self.assertEqual(mt2cf("application/coap-group+json",
"utf-8"),
CoAPContentFormatRegistry.GROUP_JSON)
def testCoAPGroupJSON(self):
self.assertEqual(mt2cf("application/coap-group+json",
"utf-8"),
CoAPContentFormatRegistry.GROUP_JSON)
def testUnknownMediaType(self):
self.assertFalse(mt2cf("unknown/media-type"))
def testUnknownMediaType(self):
self.assertFalse(mt2cf("unknown/media-type"))
def testLooseXML1(self):
self.assertEqual(
mt2cf(
"application/somesubtype+xml",
loose_mapper=LooseMediaTypeMapper()),
CoAPContentFormatRegistry.XML)
def testLooseXML1(self):
self.assertEqual(
mt2cf(
"application/somesubtype+xml",
loose_mapper=LooseMediaTypeMapper()),
CoAPContentFormatRegistry.XML)
def testLooseXML2(self): self.assertEqual( mt2cf( "text/xml", loose_mapper=LooseMediaTypeMapper()), CoAPContentFormatRegistry.XML)
def testlooseMPL2（self）：self.assertEqual（mt2cf（“text/xml”，loose\u mapper=LooseMediaTypeMapper（）），CoAPContentFormatRegistry.xml）
def testLooseJSON(self):
self.assertEqual(
mt2cf(
"application/somesubtype+json",
loose_mapper=LooseMediaTypeMapper()),
CoAPContentFormatRegistry.JSON)
def testLooseJSON(self):
self.assertEqual(
mt2cf(
"application/somesubtype+json",
loose_mapper=LooseMediaTypeMapper()),
CoAPContentFormatRegistry.JSON)
def testLooseCBOR(self):
self.assertEqual(
mt2cf(
"application/somesubtype+cbor",
loose_mapper=LooseMediaTypeMapper()),
CoAPContentFormatRegistry.CBOR)
def testLooseCBOR(self):
self.assertEqual(
mt2cf(
"application/somesubtype+cbor",
loose_mapper=LooseMediaTypeMapper()),
CoAPContentFormatRegistry.CBOR)
def testLooseText(self): self.assertEqual( mt2cf( "text/somesubtype", loose_mapper=LooseMediaTypeMapper()), CoAPContentFormatRegistry.TEXT_PLAIN)
def testLooseText（self）：self.assertEqual（mt2cf（“text/somesubtype”，loose\u mapper=LooseMediaTypeMapper（）），CoAPContentFormatRegistry.text\u PLAIN）
def testLooseUnknown(self):
self.assertEqual(
mt2cf(
"application/somesubtype-of-some-sort+format",
loose_mapper=LooseMediaTypeMapper()),
CoAPContentFormatRegistry.OCTET_STREAM)
def testLooseUnknown(self):
self.assertEqual(
mt2cf(
"application/somesubtype-of-some-sort+format",
loose_mapper=LooseMediaTypeMapper()),
CoAPContentFormatRegistry.OCTET_STREAM)
def testLooseInvalidStartsWithNonAlpha(self):
self.assertFalse(
mt2cf(
" application/somesubtype",
loose_mapper=LooseMediaTypeMapper()))
def testLooseInvalidStartsWithNonAlpha(self):
self.assertFalse(
mt2cf(
" application/somesubtype",
loose_mapper=LooseMediaTypeMapper()))
def testLooseInvalidEndsWithUnexpectedChar(self):
self.assertFalse(
mt2cf(
"application/somesubtype ",
loose_mapper=LooseMediaTypeMapper()))
def testLooseInvalidEndsWithUnexpectedChar(self):
self.assertFalse(
mt2cf(
"application/somesubtype ",
loose_mapper=LooseMediaTypeMapper()))
def testLooseInvalidUnexpectedCharInTheMiddle(self):
self.assertFalse(
mt2cf(
"application /somesubtype",
loose_mapper=LooseMediaTypeMapper()))
def testLooseInvalidUnexpectedCharInTheMiddle(self):
self.assertFalse(
mt2cf(
"application /somesubtype",
loose_mapper=LooseMediaTypeMapper()))
def testLooseInvalidNoSubType1(self): self.assertFalse( mt2cf( "application", loose_mapper=LooseMediaTypeMapper()))
def testLooseInvalidNoSubType1（self）：self.assertFalse（mt2cf（“应用程序”，loose\u mapper=LooseMediaTypeMapper（））
def testLooseInvalidNoSubType2(self):
self.assertFalse(
mt2cf(
"application/",
loose_mapper=LooseMediaTypeMapper()))
def testLooseInvalidNoSubType2(self):
self.assertFalse(
mt2cf(
"application/",
loose_mapper=LooseMediaTypeMapper()))
if __name__ == "__main__":
unittest.main(verbosity=2)
if __name__ == "__main__":
unittest.main(verbosity=2)
Acknowledgments
致谢
An initial version of Table 2 in Section 7 has been provided in revision -05 of the CoRE CoAP I-D. Special thanks to Peter van der Stok for countless comments and discussions on this document that contributed to its current structure and text.
第7节表2的初始版本已在核心CoAP I-D的第05版中提供。特别感谢Peter van der Stok对本文件的无数评论和讨论，这些评论和讨论有助于其当前结构和文本。
Thanks to Abhijan Bhattacharyya, Alexey Melnikov, Brian Frank, Carsten Bormann, Christian Amsuess, Christian Groves, Cullen Jennings, Dorothy Gellert, Francesco Corazza, Francis Dupont, Hannes Tschofenig, Jaime Jimenez, Kathleen Moriarty, Kepeng Li, Kerry Lynn, Klaus Hartke, Larry Masinter, Linyi Tian, Michele Rossi, Michele Zorzi, Nicola Bui, Peter Saint-Andre, Sean Leonard, Spencer Dawkins, Stephen Farrell, Suresh Krishnan, and Zach Shelby for helpful comments and discussions that have shaped the document.
感谢Abhijan Bhattacharyya，Alexey Melnikov，Brian Frank，Carsten Bormann，Christian Amsuess，Christian Groves，Cullen Jennings，Dorothy Gellert，Francesco Corazza，Francis Dupont，Hannes Tschofenig，Jaime Jimenez，Kathleen Moriarty，Keppeng Li，Kerry Lynn，Klaus Hartke，Larry Masinter，Linyi Tian，Michele Rossi，Michele Zorzi，Nicola Bui，彼得·圣安德烈、肖恩·伦纳德、斯宾塞·道金斯、斯蒂芬·法雷尔、苏雷什·克里希南和扎克·谢尔比为形成该文件提供了有益的评论和讨论。
The research leading to these results has received funding from the European Community's Seventh Framework Programme [FP7/2007-2013] under grant agreement n.251557.
导致这些结果的研究已收到欧洲共同体第七框架计划[FP7/2007-2013]根据第251557号赠款协议提供的资金。
Authors' Addresses
作者地址
Angelo P. Castellani University of Padova Via Gradenigo 6/B Padova 35131 Italy
安吉洛P.Caselina大学PADOVA经由格莱德尼戈6／B Padova 35131意大利
Email: angelo@castellani.net
Email: angelo@castellani.net
Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland
萨尔瓦托·洛雷托·爱立信·赫萨兰蒂11 Jorvas 02420芬兰
Email: salvatore.loreto@ericsson.com
Email: salvatore.loreto@ericsson.com
Akbar Rahman InterDigital Communications, LLC 1000 Sherbrooke Street West Montreal H3A 3G4 Canada
Akbar Rahman InterDigital Communications，LLC加拿大蒙特利尔西谢尔布鲁克街1000号H3A 3G4
Phone: +1 514 585 0761
Email: Akbar.Rahman@InterDigital.com
Phone: +1 514 585 0761
Email: Akbar.Rahman@InterDigital.com
Thomas Fossati Nokia 3 Ely Road Milton, Cambridge CB24 6DD United Kingdom
英国剑桥CB24 6DD米尔顿伊利路3号托马斯·福萨蒂诺基亚
Email: thomas.fossati@nokia.com
Email: thomas.fossati@nokia.com
Esko Dijk Philips Lighting High Tech Campus 7 Eindhoven 5656 AE The Netherlands
Esko Dijk飞利浦照明高科技园区7埃因霍温5656荷兰AE
Email: esko.dijk@philips.com
Email: esko.dijk@philips.com