Internet Engineering Task Force (IETF) C. Bormann
Request for Comments: 8323 Universitaet Bremen TZI
Updates: 7641, 7959 S. Lemay
Category: Standards Track Zebra Technologies
ISSN: 2070-1721 H. Tschofenig
ARM Ltd.
K. Hartke
Universitaet Bremen TZI
B. Silverajan
Tampere University of Technology
B. Raymor, Ed.
February 2018
Internet Engineering Task Force (IETF) C. Bormann
Request for Comments: 8323 Universitaet Bremen TZI
Updates: 7641, 7959 S. Lemay
Category: Standards Track Zebra Technologies
ISSN: 2070-1721 H. Tschofenig
ARM Ltd.
K. Hartke
Universitaet Bremen TZI
B. Silverajan
Tampere University of Technology
B. Raymor, Ed.
February 2018
CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets
TCP、TLS和WebSocket上的CoAP（受限应用程序协议）
Abstract
摘要
The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control.
受限应用程序协议（CoAP）虽然受到HTTP的启发，但其设计目的是使用UDP而不是TCP。UDP上的CoAP的消息层包括对可靠传递、简单拥塞控制和流量控制的支持。
Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport.
某些环境受益于通过可靠传输（如TCP或传输层安全性（TLS））实现的CoAP的可用性。本文档概述了通过TCP、TLS和WebSocket传输使用CoAP所需的更改。它还正式更新RFC 7641以用于这些传输，并更新RFC 7959以支持通过可靠传输使用较大的消息。
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 https://www.rfc-editor.org/info/rfc8323.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8323.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions and Terminology .....................................6
3. CoAP over TCP ...................................................7
3.1. Messaging Model ............................................7
3.2. Message Format .............................................9
3.3. Message Transmission ......................................11
3.4. Connection Health .........................................12
4. CoAP over WebSockets ...........................................13
4.1. Opening Handshake .........................................15
4.2. Message Format ............................................15
4.3. Message Transmission ......................................16
4.4. Connection Health .........................................17
5. Signaling ......................................................17
5.1. Signaling Codes ...........................................17
5.2. Signaling Option Numbers ..................................18
5.3. Capabilities and Settings Messages (CSMs) .................18
5.4. Ping and Pong Messages ....................................20
5.5. Release Messages ..........................................21
5.6. Abort Messages ............................................23
5.7. Signaling Examples ........................................24
6. Block-Wise Transfer and Reliable Transports ....................25
6.1. Example: GET with BERT Blocks .............................27
6.2. Example: PUT with BERT Blocks .............................27
7. Observing Resources over Reliable Transports ...................28
7.1. Notifications and Reordering ..............................28
7.2. Transmission and Acknowledgments ..........................28
7.3. Freshness .................................................28
7.4. Cancellation ..............................................29
1. Introduction ....................................................3
2. Conventions and Terminology .....................................6
3. CoAP over TCP ...................................................7
3.1. Messaging Model ............................................7
3.2. Message Format .............................................9
3.3. Message Transmission ......................................11
3.4. Connection Health .........................................12
4. CoAP over WebSockets ...........................................13
4.1. Opening Handshake .........................................15
4.2. Message Format ............................................15
4.3. Message Transmission ......................................16
4.4. Connection Health .........................................17
5. Signaling ......................................................17
5.1. Signaling Codes ...........................................17
5.2. Signaling Option Numbers ..................................18
5.3. Capabilities and Settings Messages (CSMs) .................18
5.4. Ping and Pong Messages ....................................20
5.5. Release Messages ..........................................21
5.6. Abort Messages ............................................23
5.7. Signaling Examples ........................................24
6. Block-Wise Transfer and Reliable Transports ....................25
6.1. Example: GET with BERT Blocks .............................27
6.2. Example: PUT with BERT Blocks .............................27
7. Observing Resources over Reliable Transports ...................28
7.1. Notifications and Reordering ..............................28
7.2. Transmission and Acknowledgments ..........................28
7.3. Freshness .................................................28
7.4. Cancellation ..............................................29
8. CoAP over Reliable Transport URIs ..............................29
8.1. coap+tcp URI Scheme .......................................30
8.2. coaps+tcp URI Scheme ......................................31
8.3. coap+ws URI Scheme ........................................32
8.4. coaps+ws URI Scheme .......................................33
8.5. Uri-Host and Uri-Port Options .............................33
8.6. Decomposing URIs into Options .............................34
8.7. Composing URIs from Options ...............................35
9. Securing CoAP ..................................................35
9.1. TLS Binding for CoAP over TCP .............................36
9.2. TLS Usage for CoAP over WebSockets ........................37
10. Security Considerations .......................................37
10.1. Signaling Messages .......................................37
11. IANA Considerations ...........................................38
11.1. Signaling Codes ..........................................38
11.2. CoAP Signaling Option Numbers Registry ...................38
11.3. Service Name and Port Number Registration ................40
11.4. Secure Service Name and Port Number Registration .........40
11.5. URI Scheme Registration ..................................41
11.6. Well-Known URI Suffix Registration .......................43
11.7. ALPN Protocol Identifier .................................44
11.8. WebSocket Subprotocol Registration .......................44
11.9. CoAP Option Numbers Registry .............................44
12. References ....................................................45
12.1. Normative References .....................................45
12.2. Informative References ...................................47
Appendix A. Examples of CoAP over WebSockets ......................49
Acknowledgments ...................................................52
Contributors ......................................................52
Authors' Addresses ................................................53
8. CoAP over Reliable Transport URIs ..............................29
8.1. coap+tcp URI Scheme .......................................30
8.2. coaps+tcp URI Scheme ......................................31
8.3. coap+ws URI Scheme ........................................32
8.4. coaps+ws URI Scheme .......................................33
8.5. Uri-Host and Uri-Port Options .............................33
8.6. Decomposing URIs into Options .............................34
8.7. Composing URIs from Options ...............................35
9. Securing CoAP ..................................................35
9.1. TLS Binding for CoAP over TCP .............................36
9.2. TLS Usage for CoAP over WebSockets ........................37
10. Security Considerations .......................................37
10.1. Signaling Messages .......................................37
11. IANA Considerations ...........................................38
11.1. Signaling Codes ..........................................38
11.2. CoAP Signaling Option Numbers Registry ...................38
11.3. Service Name and Port Number Registration ................40
11.4. Secure Service Name and Port Number Registration .........40
11.5. URI Scheme Registration ..................................41
11.6. Well-Known URI Suffix Registration .......................43
11.7. ALPN Protocol Identifier .................................44
11.8. WebSocket Subprotocol Registration .......................44
11.9. CoAP Option Numbers Registry .............................44
12. References ....................................................45
12.1. Normative References .....................................45
12.2. Informative References ...................................47
Appendix A. Examples of CoAP over WebSockets ......................49
Acknowledgments ...................................................52
Contributors ......................................................52
Authors' Addresses ................................................53
The Constrained Application Protocol (CoAP) [RFC7252] was designed for Internet of Things (IoT) deployments, assuming that UDP [RFC768] can be used unimpeded as can the Datagram Transport Layer Security (DTLS) protocol [RFC6347] over UDP. The use of CoAP over UDP is focused on simplicity, has a low code footprint, and has a small over-the-wire message size.
受限应用程序协议（CoAP）[RFC7252]是为物联网（IoT）部署而设计的，假设UDP[RFC768]可以不受阻碍地使用，UDP上的数据报传输层安全（DTLS）协议[RFC6347]也可以不受阻碍地使用。CoAP over UDP的使用侧重于简单性，具有较低的代码占用，并且具有较小的跨线消息大小。
The primary reason for introducing CoAP over TCP [RFC793] and TLS [RFC5246] is that some networks do not forward UDP packets. Complete blocking of UDP happens in between about 2% and 4% of terrestrial access networks, according to [EK2016]. UDP impairment is especially concentrated in enterprise networks and networks in geographic regions with otherwise challenged connectivity. Some networks also
通过TCP[RFC793]和TLS[RFC5246]引入CoAP的主要原因是某些网络不转发UDP数据包。根据[EK2016]，UDP完全阻塞发生在大约2%到4%的地面接入网络中。UDP损害尤其集中在企业网络和连接受到挑战的地理区域的网络中。一些网络也
rate-limit UDP traffic, as reported in [BK2015], and deployment investigations related to the standardization of Quick UDP Internet Connections (QUIC) revealed numbers around 0.3% [SW2016].
[BK2015]中报告的速率限制UDP流量，以及与快速UDP互联网连接（QUIC）标准化相关的部署调查显示，数字约为0.3%[SW2016]。
The introduction of CoAP over TCP also leads to some additional effects that may be desirable in a specific deployment:
在TCP上引入CoAP还会带来一些在特定部署中可能需要的额外效果：
o Where NATs are present along the communication path, CoAP over TCP leads to different NAT traversal behavior than CoAP over UDP. NATs often calculate expiration timers based on the transport-layer protocol being used by application protocols. Many NATs maintain TCP-based NAT bindings for longer periods based on the assumption that a transport-layer protocol, such as TCP, offers additional information about the session lifecycle. UDP, on the other hand, does not provide such information to a NAT and timeouts tend to be much shorter [HomeGateway]. According to [HomeGateway], the mean for TCP and UDP NAT binding timeouts is 386 minutes (TCP) and 160 seconds (UDP). Shorter timeout values require keepalive messages to be sent more frequently. Hence, the use of CoAP over TCP requires less-frequent transmission of keepalive messages.
o 当通信路径上存在NAT时，TCP上的CoAP会导致与UDP上的CoAP不同的NAT遍历行为。NAT通常根据应用程序协议使用的传输层协议计算过期计时器。基于传输层协议（如TCP）提供有关会话生命周期的附加信息的假设，许多NAT会在更长的时间内维护基于TCP的NAT绑定。另一方面，UDP不向NAT提供此类信息，超时时间往往短得多[HomeGateway]。根据[HomeGateway]，TCP和UDP NAT绑定超时的平均值为386分钟（TCP）和160秒（UDP）。较短的超时值要求更频繁地发送keepalive消息。因此，通过TCP使用CoAP需要较少的keepalive消息传输频率。
o TCP utilizes mechanisms for congestion control and flow control that are more sophisticated than the default mechanisms provided by CoAP over UDP; these TCP mechanisms are useful for the transfer of larger payloads. (However, work is ongoing to add advanced congestion control to CoAP over UDP as well; see [CoCoA].)
o TCP利用比CoAP通过UDP提供的默认机制更复杂的拥塞控制和流量控制机制；这些TCP机制对于传输更大的有效负载非常有用。（不过，通过UDP向CoAP添加高级拥塞控制的工作仍在进行中；请参见[CoCoA]。）
Note that the use of CoAP over UDP (and CoAP over DTLS over UDP) is still the recommended transport for use in constrained node networks, particularly when used in concert with block-wise transfer. CoAP over TCP is applicable for those cases where the networking infrastructure leaves no other choice. The use of CoAP over TCP leads to a larger code size, more round trips, increased RAM requirements, and larger packet sizes. Developers implementing CoAP over TCP are encouraged to consult [TCP-in-IoT] for guidance on low-footprint TCP implementations for IoT devices.
请注意，在受约束的节点网络中，建议使用UDP上的CoAP（以及UDP上的DTLS上的CoAP），特别是在与分块传输配合使用时。TCP上的CoAP适用于网络基础设施没有其他选择的情况。在TCP上使用CoAP会导致更大的代码大小、更多的往返、更高的RAM要求和更大的数据包大小。鼓励通过TCP实施CoAP的开发人员参考[TCP in IoT]，以获得关于IoT设备低占用TCP实施的指导。
Standards based on CoAP, such as Lightweight Machine to Machine [LWM2M], currently use CoAP over UDP as a transport; adding support for CoAP over TCP enables them to address the issues above for specific deployments and to protect investments in existing CoAP implementations and deployments.
基于CoAP的标准，如轻量级机器对机器[LWM2M]，目前使用UDP上的CoAP作为传输；通过添加对TCP上的CoAP的支持，他们可以针对特定部署解决上述问题，并保护对现有CoAP实施和部署的投资。
Although HTTP/2 could also potentially address the need for enterprise firewall traversal, there would be additional costs and delays introduced by such a transition from CoAP to HTTP/2. Currently, there are also fewer HTTP/2 implementations available for
虽然HTTP/2也可能解决企业防火墙穿越的需求，但从CoAP到HTTP/2的这种转换会带来额外的成本和延迟。目前，可供用户使用的HTTP/2实现也较少
constrained devices in comparison to CoAP. Since CoAP also supports group communication using IP-layer multicast and unreliable communication, IoT devices would have to support HTTP/2 in addition to CoAP.
与CoAP相比，受约束的设备。由于CoAP还支持使用IP层多播和不可靠通信的组通信，因此除了CoAP之外，物联网设备还必须支持HTTP/2。
Furthermore, CoAP may be integrated into a web environment where the front end uses CoAP over UDP from IoT devices to a cloud infrastructure and then CoAP over TCP between the back-end services. A TCP-to-UDP gateway can be used at the cloud boundary to communicate with the UDP-based IoT device.
此外，CoAP可以集成到web环境中，其中前端使用CoAP over UDP从物联网设备到云基础设施，然后在后端服务之间使用CoAP over TCP。TCP到UDP网关可在云边界处用于与基于UDP的物联网设备通信。
Finally, CoAP applications running inside a web browser may be without access to connectivity other than HTTP. In this case, the WebSocket Protocol [RFC6455] may be used to transport CoAP requests and responses, as opposed to cross-proxying them via HTTP to an HTTP-to-CoAP cross-proxy. This preserves the functionality of CoAP without translation -- in particular, the Observe Option [RFC7641].
最后，在web浏览器中运行的CoAP应用程序可能无法访问HTTP以外的连接。在这种情况下，WebSocket协议[RFC6455]可用于传输CoAP请求和响应，而不是通过HTTP将它们交叉代理到HTTP-to-CoAP交叉代理。这保留了CoAP的功能，而无需翻译——特别是观察选项[RFC7641]。
To address the above-mentioned deployment requirements, this document defines how to transport CoAP over TCP, CoAP over TLS, and CoAP over WebSockets. For these cases, the reliability offered by the transport protocol subsumes the reliability functions of the message layer used for CoAP over UDP. (Note that for both a reliable transport and the message layer for CoAP over UDP, the reliability offered is per transport hop: where proxies -- see Sections 5.7 and 10 of [RFC7252] -- are involved, that layer's reliability function does not extend end to end.) Figure 1 illustrates the layering:
为了满足上述部署需求，本文档定义了如何通过TCP传输CoAP、通过TLS传输CoAP和通过WebSocket传输CoAP。对于这些情况，传输协议提供的可靠性包含用于UDP上CoAP的消息层的可靠性功能。（注意，对于UDP上的CoAP的可靠传输和消息层，提供的可靠性是每个传输跃点的可靠性：如果涉及代理（参见[RFC7252]第5.7节和第10节），则该层的可靠性功能不会扩展到端到端。）图1说明了分层：
+--------------------------------+
| Application |
+--------------------------------+
+--------------------------------+
| Requests/Responses/Signaling | CoAP (RFC 7252) / This Document
|--------------------------------|
| Message Framing | This Document
+--------------------------------+
| Reliable Transport |
+--------------------------------+
+--------------------------------+
| Application |
+--------------------------------+
+--------------------------------+
| Requests/Responses/Signaling | CoAP (RFC 7252) / This Document
|--------------------------------|
| Message Framing | This Document
+--------------------------------+
| Reliable Transport |
+--------------------------------+
Figure 1: Layering of CoAP over Reliable Transports
图1:CoAP在可靠传输上的分层
This document specifies how to access resources using CoAP requests and responses over the TCP, TLS, and WebSocket protocols. This allows connectivity-limited applications to obtain end-to-end CoAP connectivity either (1) by communicating CoAP directly with a CoAP server accessible over a TCP, TLS, or WebSocket connection or (2) via a CoAP intermediary that proxies CoAP requests and responses between different transports, such as between WebSockets and UDP.
本文档指定如何通过TCP、TLS和WebSocket协议使用CoAP请求和响应访问资源。这允许连接受限的应用程序获得端到端的CoAP连接，（1）通过TCP、TLS或WebSocket连接直接与可访问的CoAP服务器通信，或（2）通过代理不同传输之间（如WebSocket和UDP之间）的CoAP请求和响应的CoAP中介。
Section 7 updates [RFC7641] ("Observing Resources in the Constrained Application Protocol (CoAP)") for use with CoAP over reliable transports. [RFC7641] is an extension to CoAP that enables CoAP clients to "observe" a resource on a CoAP server. (The CoAP client retrieves a representation of a resource and registers to be notified by the CoAP server when the representation is updated.)
第7节更新了[RFC7641]（“受限应用程序协议（CoAP）中的观测资源”），以便通过可靠传输与CoAP一起使用。[RFC7641]是CoAP的扩展，使CoAP客户端能够“观察”CoAP服务器上的资源。（CoAP客户端检索资源的表示，并在更新表示时注册由CoAP服务器通知。）
The key words "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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This document assumes that readers are familiar with the terms and concepts that are used in [RFC6455], [RFC7252], [RFC7641], and [RFC7959].
本文档假设读者熟悉[RFC6455]、[RFC7252]、[RFC7641]和[RFC7959]中使用的术语和概念。
The term "reliable transport" is used only to refer to transport protocols, such as TCP, that provide reliable and ordered delivery of a byte stream.
术语“可靠传输”仅用于指传输协议，如TCP，它提供可靠且有序的字节流传输。
Block-wise Extension for Reliable Transport (BERT): Extends [RFC7959] to enable the use of larger messages over a reliable transport.
可靠传输的分块扩展（BERT）：扩展[RFC7959]以支持在可靠传输上使用较大的消息。
BERT Option: A Block1 or Block2 option that includes an SZX (block size) value of 7.
BERT选项：包含SZX（块大小）值7的块1或块2选项。
BERT Block: The payload of a CoAP message that is affected by a BERT Option in descriptive usage (see Section 2.1 of [RFC7959]).
BERT块：CoAP报文的有效载荷，在描述性用法中受BERT选项的影响（见[RFC7959]第2.1节）。
Transport Connection: Underlying reliable byte-stream connection, as directly provided by TCP or indirectly provided via TLS or WebSockets.
传输连接：底层可靠的字节流连接，由TCP直接提供或通过TLS或WebSocket间接提供。
Connection: Transport Connection, unless explicitly qualified otherwise.
连接：传输连接，除非另有明确限定。
Connection Initiator: The peer that opens a Transport Connection, i.e., the TCP active opener, TLS client, or WebSocket client.
连接发起方：打开传输连接的对等方，即TCP活动开启器、TLS客户端或WebSocket客户端。
Connection Acceptor: The peer that accepts the Transport Connection opened by the other peer, i.e., the TCP passive opener, TLS server, or WebSocket server.
连接接受者：接受由另一个对等方打开的传输连接的对等方，即TCP被动开启器、TLS服务器或WebSocket服务器。
The request/response interaction model of CoAP over TCP is the same as CoAP over UDP. The primary differences are in the message layer. The message layer of CoAP over UDP supports optional reliability by defining four types of messages: Confirmable, Non-confirmable, Acknowledgment, and Reset. In addition, messages include a Message ID to relate Acknowledgments to Confirmable messages and to detect duplicate messages.
TCP上的CoAP的请求/响应交互模型与UDP上的CoAP相同。主要区别在于消息层。UDP上的CoAP的消息层通过定义四种类型的消息来支持可选的可靠性：可确认、不可确认、确认和重置。此外，消息还包括一个消息ID，用于将确认与可确认消息关联起来，并检测重复消息。
Management of the transport connections is left to the application, i.e., the present specification does not describe how an application decides to open a connection or to reopen another one in the presence of failures (or what it would deem to be a failure; see also Section 5.4). In particular, the Connection Initiator need not be the client of the first request placed on the connection. Some implementations will want to implement dynamic connection management similar to the technique described in Section 6 of [RFC7230] for HTTP: opening a connection when the first client request is ready to be sent, reusing that connection for subsequent messages until no more messages are sent for a certain time period and no requests are outstanding (possibly with a configurable idle time), and then starting a release process (orderly shutdown) (see Section 5.5). In implementations of this kind, connection releases or aborts may not be indicated as errors to the application but may simply be handled by automatic reconnection once the need arises again. Other implementations may be based on configured connections that are kept open continuously and lead to management system notifications on release or abort. The protocol defined in the present specification is intended to work with either model (or other, application-specific connection management models).
传输连接的管理由应用程序负责，即，本规范未描述应用程序在出现故障时如何决定打开一个连接或重新打开另一个连接（或将其视为故障；另见第5.4节）。特别是，连接发起方不必是放置在连接上的第一个请求的客户端。一些实现需要实现动态连接管理，类似于[RFC7230]第6节中描述的HTTP技术：在第一个客户端请求准备好发送时打开连接，对后续消息重复使用该连接，直到在特定时间段内不再发送任何消息，并且没有未完成的请求（可能具有可配置的空闲时间），然后启动释放过程（有序关闭）（参见第5.5节）。在这种类型的实现中，连接释放或中止可能不会被指示为应用程序的错误，而是可以在需要时通过自动重新连接来处理。其他实现可能基于持续打开的配置连接，并在发布或中止时发出管理系统通知。本规范中定义的协议用于任一模型（或其他特定于应用程序的连接管理模型）。
Conceptually, CoAP over TCP replaces most of the message layer of CoAP over UDP with a framing mechanism on top of the byte stream provided by TCP/TLS, conveying the length information for each message that, on datagram transports, is provided by the UDP/DTLS datagram layer.
从概念上讲，TCP上的CoAP用TCP/TLS提供的字节流之上的帧机制取代了UDP上的CoAP的大部分消息层，用于传输UDP/DTLS数据报层提供的数据报传输的每条消息的长度信息。
TCP ensures reliable message transmission, so the message layer of CoAP over TCP is not required to support Acknowledgment messages or to detect duplicate messages. As a result, both the Type and Message ID fields are no longer required and are removed from the message format for CoAP over TCP.
TCP确保了可靠的消息传输，因此TCP上的CoAP的消息层不需要支持确认消息或检测重复消息。因此，类型和消息ID字段不再是必需的，并且从TCP上的CoAP的消息格式中删除。
Figure 2 illustrates the difference between CoAP over UDP and CoAP over reliable transports. The removed Type and Message ID fields are indicated by dashes.
图2说明了UDP上的CoAP和可靠传输上的CoAP之间的区别。删除的类型和消息ID字段用破折号表示。
CoAP Client CoAP Server CoAP Client CoAP Server
| | | |
| CON [0xbc90] | | (-------) [------] |
| GET /temperature | | GET /temperature |
| (Token 0x71) | | (Token 0x71) |
+------------------->| +------------------->|
| | | |
| ACK [0xbc90] | | (-------) [------] |
| 2.05 Content | | 2.05 Content |
| (Token 0x71) | | (Token 0x71) |
| "22.5 C" | | "22.5 C" |
|<-------------------+ |<-------------------+
| | | |
CoAP Client CoAP Server CoAP Client CoAP Server
| | | |
| CON [0xbc90] | | (-------) [------] |
| GET /temperature | | GET /temperature |
| (Token 0x71) | | (Token 0x71) |
+------------------->| +------------------->|
| | | |
| ACK [0xbc90] | | (-------) [------] |
| 2.05 Content | | 2.05 Content |
| (Token 0x71) | | (Token 0x71) |
| "22.5 C" | | "22.5 C" |
|<-------------------+ |<-------------------+
| | | |
CoAP over UDP CoAP over reliable transports
UDP上的CoAP可靠传输上的CoAP
Figure 2: Comparison between CoAP over Unreliable Transports and CoAP over Reliable Transports
图2：不可靠传输条件下的CoAP与可靠传输条件下的CoAP之间的比较
The CoAP message format defined in [RFC7252], as shown in Figure 3, relies on the datagram transport (UDP, or DTLS over UDP) for keeping the individual messages separate and for providing length information.
[RFC7252]中定义的CoAP消息格式，如图3所示，依赖于数据报传输（UDP或UDP上的DTLS），以保持单个消息的独立性并提供长度信息。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T | TKL | Code | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (if any, TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T | TKL | Code | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (if any, TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: CoAP Message Format as Defined in RFC 7252
图3:RFC 7252中定义的CoAP消息格式
The message format for CoAP over TCP is very similar to the format specified for CoAP over UDP. The differences are as follows:
TCP上的CoAP的消息格式与UDP上的CoAP指定的格式非常相似。区别如下：
o Since the underlying TCP connection provides retransmissions and deduplication, there is no need for the reliability mechanisms provided by CoAP over UDP. The Type (T) and Message ID fields in the CoAP message header are elided.
o 由于底层TCP连接提供重传和重复数据消除，因此不需要CoAP通过UDP提供的可靠性机制。CoAP消息头中的类型（T）和消息ID字段被省略。
o The Version (Vers) field is elided as well. In contrast to the message format of CoAP over UDP, the message format for CoAP over TCP does not include a version number. CoAP is defined in [RFC7252] with a version number of 1. At this time, there is no known reason to support version numbers different from 1. If version negotiation needs to be addressed in the future, Capabilities and Settings Messages (CSMs) (see Section 5.3) have been specifically designed to enable such a potential feature.
o 版本（Vers）字段也被省略。与UDP上的CoAP的消息格式不同，TCP上的CoAP的消息格式不包括版本号。CoAP在[RFC7252]中定义，版本号为1。目前，还没有已知的理由支持与1不同的版本号。如果将来需要解决版本协商问题，则已专门设计了功能和设置消息（CSM）（参见第5.3节），以启用此类潜在功能。
o In a stream-oriented transport protocol such as TCP, a form of message delimitation is needed. For this purpose, CoAP over TCP introduces a length field with variable size. Figure 4 shows the adjusted CoAP message format with a modified structure for the fixed header (first 4 bytes of the header for CoAP over UDP), which includes the length information of variable size.
o 在面向流的传输协议（如TCP）中，需要一种形式的消息定界。为此，TCP上的CoAP引入了一个大小可变的长度字段。图4显示了调整后的CoAP消息格式，其中包含可变大小的长度信息，固定报头（UDP上的CoAP报头的前4个字节）的结构已修改。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Len | TKL | Extended Length (if any, as chosen by Len) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Token (if any, TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Len | TKL | Extended Length (if any, as chosen by Len) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Token (if any, TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: CoAP Frame for Reliable Transports
图4：用于可靠运输的CoAP框架
Length (Len): 4-bit unsigned integer. A value between 0 and 12 inclusive indicates the length of the message in bytes, starting with the first bit of the Options field. Three values are reserved for special constructs:
长度（Len）：4位无符号整数。介于0和12（含0和12）之间的值表示以字节为单位的消息长度，从选项字段的第一位开始。为特殊构造保留三个值：
13: An 8-bit unsigned integer (Extended Length) follows the initial byte and indicates the length of options/payload minus 13.
13：初始字节后是一个8位无符号整数（扩展长度），表示选项/有效负载的长度减13。
14: A 16-bit unsigned integer (Extended Length) in network byte order follows the initial byte and indicates the length of options/payload minus 269.
14：网络字节顺序的16位无符号整数（扩展长度）位于初始字节之后，表示选项/有效负载的长度减去269。
15: A 32-bit unsigned integer (Extended Length) in network byte order follows the initial byte and indicates the length of options/payload minus 65805.
15：网络字节顺序的32位无符号整数（扩展长度）位于初始字节之后，表示选项/有效负载的长度减去65805。
The encoding of the Length field is modeled after the Option Length field of the CoAP Options (see Section 3.1 of [RFC7252]).
长度字段的编码按照CoAP选项的选项长度字段建模（见[RFC7252]第3.1节）。
For simplicity, a Payload Marker (0xFF) is shown in Figure 4; the Payload Marker indicates the start of the optional payload and is absent for zero-length payloads (see Section 3 of [RFC7252]). (If present, the Payload Marker is included in the message length, which counts from the start of the Options field to the end of the Payload field.)
为简单起见，图4中显示了有效负载标记（0xFF）；有效载荷标记指示可选有效载荷的开始，对于零长度有效载荷不存在该标记（见[RFC7252]第3节）。（如果存在，则有效负载标记包含在消息长度中，该长度从选项字段的开始到有效负载字段的结束计数。）
For example, a CoAP message just containing a 2.03 code with the Token 7f and no options or payload is encoded as shown in Figure 5.
例如，CoAP消息只包含一个带有令牌7f的2.03代码，并且没有选项或有效负载，如图5所示进行编码。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 | 0x43 | 0x7f |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 | 0x43 | 0x7f |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Len = 0 ------> 0x01
TKL = 1 ___/
Code = 2.03 --> 0x43
Token = 0x7f
Len = 0 ------> 0x01
TKL = 1 ___/
Code = 2.03 --> 0x43
Token = 0x7f
Figure 5: CoAP Message with No Options or Payload
图5：没有选项或有效载荷的CoAP消息
The semantics of the other CoAP header fields are left unchanged.
其他CoAP头字段的语义保持不变。
Once a Transport Connection is established, each endpoint MUST send a CSM (see Section 5.3) as its first message on the connection. This message establishes the initial settings and capabilities for the endpoint, such as maximum message size or support for block-wise transfers. The absence of options in the CSM indicates that base values are assumed.
一旦建立了传输连接，每个端点都必须发送一个CSM（参见第5.3节），作为连接上的第一条消息。此消息建立端点的初始设置和功能，例如最大消息大小或对分块传输的支持。CSM中没有选项表示假定了基准值。
To avoid a deadlock, the Connection Initiator MUST NOT wait for the Connection Acceptor to send its initial CSM before sending its own initial CSM. Conversely, the Connection Acceptor MAY wait for the Connection Initiator to send its initial CSM before sending its own initial CSM.
为了避免死锁，连接发起方不能在发送自己的初始CSM之前等待连接接受方发送其初始CSM。相反，连接接受者可以在发送其自己的初始CSM之前等待连接发起方发送其初始CSM。
To avoid unnecessary latency, a Connection Initiator MAY send additional messages after its initial CSM without waiting to receive the Connection Acceptor's CSM; however, it is important to note that the Connection Acceptor's CSM might indicate capabilities that impact how the Connection Initiator is expected to communicate with the Connection Acceptor. For example, the Connection Acceptor's CSM could indicate a Max-Message-Size Option (see Section 5.3.1) that is smaller than the base value (1152) in order to limit both buffering requirements and head-of-line blocking.
为了避免不必要的延迟，连接发起方可以在其初始CSM之后发送附加消息，而无需等待接收连接接收方的CSM；但是，需要注意的是，连接接受者的CSM可能指示影响连接启动器与连接接受者通信方式的功能。例如，连接接受者的CSM可以指示小于基值（1152）的最大消息大小选项（见第5.3.1节），以限制缓冲要求和线头阻塞。
Endpoints MUST treat a missing or invalid CSM as a connection error and abort the connection (see Section 5.6).
端点必须将丢失或无效的CSM视为连接错误并中止连接（参见第5.6节）。
CoAP requests and responses are exchanged asynchronously over the Transport Connection. A CoAP client can send multiple requests without waiting for a response, and the CoAP server can return responses in any order. Responses MUST be returned over the same connection as the originating request. Each concurrent request is differentiated by its Token, which is scoped locally to the connection.
CoAP请求和响应通过传输连接异步交换。CoAP客户端可以在不等待响应的情况下发送多个请求，CoAP服务器可以按任意顺序返回响应。响应必须通过与原始请求相同的连接返回。每个并发请求都通过其令牌进行区分，令牌的作用域在连接的本地。
The Transport Connection is bidirectional, so requests can be sent by both the entity that established the connection (Connection Initiator) and the remote host (Connection Acceptor). If one side does not implement a CoAP server, an error response MUST be returned for all CoAP requests from the other side. The simplest approach is to always return 5.01 (Not Implemented). A more elaborate mock server could also return 4.xx responses such as 4.04 (Not Found) or 4.02 (Bad Option) where appropriate.
传输连接是双向的，因此建立连接的实体（连接启动器）和远程主机（连接接受器）都可以发送请求。如果一方未实现CoAP服务器，则必须为另一方的所有CoAP请求返回错误响应。最简单的方法是始终返回5.01（未实现）。更复杂的模拟服务器还可以在适当的情况下返回4.xx响应，如4.04（未找到）或4.02（错误选项）。
Retransmission and deduplication of messages are provided by TCP.
消息的重传和重复数据消除由TCP提供。
Empty messages (Code 0.00) can always be sent and MUST be ignored by the recipient. This provides a basic keepalive function that can refresh NAT bindings.
空邮件（代码0.00）始终可以发送，收件人必须忽略它。这提供了一个基本的keepalive函数，可以刷新NAT绑定。
If a CoAP client does not receive any response for some time after sending a CoAP request (or, similarly, when a client observes a resource and it does not receive any notification for some time), it can send a CoAP Ping Signaling message (see Section 5.4) to test the Transport Connection and verify that the CoAP server is responsive.
如果CoAP客户端在发送CoAP请求后一段时间内没有收到任何响应（或者，类似地，当客户端观察到资源并且一段时间内没有收到任何通知时），它可以发送CoAP Ping信令消息（参见第5.4节），以测试传输连接并验证CoAP服务器是否有响应。
When the underlying Transport Connection is closed or reset, the signaling state and any observation state (see Section 7.4) associated with the connection are removed. Messages that are in flight may or may not be lost.
当基础传输连接关闭或重置时，与连接相关的信令状态和任何观察状态（见第7.4节）将被移除。飞行中的消息可能会丢失，也可能不会丢失。
CoAP over WebSockets is intentionally similar to CoAP over TCP; therefore, this section only specifies the differences between the transports.
WebSocket上的CoAP有意地类似于TCP上的CoAP；因此，本节仅规定了传输之间的差异。
CoAP over WebSockets can be used in a number of configurations. The most basic configuration is a CoAP client retrieving or updating a CoAP resource located on a CoAP server that exposes a WebSocket endpoint (see Figure 6). The CoAP client acts as the WebSocket client, establishes a WebSocket connection, and sends a CoAP request, to which the CoAP server returns a CoAP response. The WebSocket connection can be used for any number of requests.
在许多配置中都可以使用网匣上的CoAP。最基本的配置是CoAP客户端检索或更新位于公开WebSocket端点的CoAP服务器上的CoAP资源（参见图6）。CoAP客户端充当WebSocket客户端，建立WebSocket连接，并发送CoAP请求，CoAP服务器向该请求返回CoAP响应。WebSocket连接可用于任何数量的请求。
___________ ___________
| | | |
| _|___ requests ___|_ |
| CoAP / \ \ -------------> / / \ CoAP |
| Client \__/__/ <------------- \__\__/ Server |
| | responses | |
|___________| |___________|
WebSocket =============> WebSocket
Client Connection Server
___________ ___________
| | | |
| _|___ requests ___|_ |
| CoAP / \ \ -------------> / / \ CoAP |
| Client \__/__/ <------------- \__\__/ Server |
| | responses | |
|___________| |___________|
WebSocket =============> WebSocket
Client Connection Server
Figure 6: CoAP Client (WebSocket Client) Accesses CoAP Server (WebSocket Server)
图6:CoAP客户端（WebSocket客户端）访问CoAP服务器（WebSocket服务器）
The challenge with this configuration is how to identify a resource in the namespace of the CoAP server. When the WebSocket Protocol is used by a dedicated client directly (i.e., not from a web page through a web browser), the client can connect to any WebSocket endpoint. Sections 8.3 and 8.4 define new URI schemes that enable the client to identify both a WebSocket endpoint and the path and query of the CoAP resource within that endpoint.
此配置面临的挑战是如何在CoAP服务器的命名空间中标识资源。当专用客户端直接使用WebSocket协议时（即，不通过web浏览器从网页），客户端可以连接到任何WebSocket端点。第8.3节和第8.4节定义了新的URI方案，使客户端能够识别WebSocket端点以及该端点内CoAP资源的路径和查询。
Another possible configuration is to set up a CoAP forward proxy at the WebSocket endpoint. Depending on what transports are available to the proxy, it could forward the request to a CoAP server with a CoAP UDP endpoint (Figure 7), an SMS endpoint (a.k.a. mobile phone), or even another WebSocket endpoint. The CoAP client specifies the resource to be updated or retrieved in the Proxy-Uri Option.
另一种可能的配置是在WebSocket端点设置CoAP转发代理。根据代理可用的传输方式，它可以将请求转发到具有CoAP UDP端点（图7）、SMS端点（又称移动电话）甚至另一个WebSocket端点的CoAP服务器。CoAP客户端在代理Uri选项中指定要更新或检索的资源。
___________ ___________ ___________
| | | | | |
| _|___ ___|_ _|___ ___|_ |
| CoAP / \ \ ---> / / \ CoAP / \ \ ---> / / \ CoAP |
| Client \__/__/ <--- \__\__/ Proxy \__/__/ <--- \__\__/ Server |
| | | | | |
|___________| |___________| |___________|
WebSocket ===> WebSocket UDP UDP
Client Server Client Server
___________ ___________ ___________
| | | | | |
| _|___ ___|_ _|___ ___|_ |
| CoAP / \ \ ---> / / \ CoAP / \ \ ---> / / \ CoAP |
| Client \__/__/ <--- \__\__/ Proxy \__/__/ <--- \__\__/ Server |
| | | | | |
|___________| |___________| |___________|
WebSocket ===> WebSocket UDP UDP
Client Server Client Server
Figure 7: CoAP Client (WebSocket Client) Accesses CoAP Server (UDP Server) via a CoAP Proxy (WebSocket Server / UDP Client)
图7:CoAP客户端（WebSocket客户端）通过CoAP代理（WebSocket服务器/UDP客户端）访问CoAP服务器（UDP服务器）
A third possible configuration is a CoAP server running inside a web browser (Figure 8). The web browser initially connects to a WebSocket endpoint and is then reachable through the WebSocket server. When no connection exists, the CoAP server is unreachable. Because the WebSocket server is the only way to reach the CoAP server, the CoAP proxy should be a reverse-proxy.
第三种可能的配置是在web浏览器中运行的CoAP服务器（图8）。web浏览器最初连接到WebSocket端点，然后可通过WebSocket服务器访问。如果不存在连接，则无法访问CoAP服务器。因为WebSocket服务器是到达CoAP服务器的唯一途径，所以CoAP代理应该是反向代理。
___________ ___________ ___________
| | | | | |
| _|___ ___|_ _|___ ___|_ |
| CoAP / \ \ ---> / / \ CoAP / / \ ---> / \ \ CoAP |
| Client \__/__/ <--- \__\__/ Proxy \__\__/ <--- \__/__/ Server |
| | | | | |
|___________| |___________| |___________|
UDP UDP WebSocket <=== WebSocket
Client Server Server Client
___________ ___________ ___________
| | | | | |
| _|___ ___|_ _|___ ___|_ |
| CoAP / \ \ ---> / / \ CoAP / / \ ---> / \ \ CoAP |
| Client \__/__/ <--- \__\__/ Proxy \__\__/ <--- \__/__/ Server |
| | | | | |
|___________| |___________| |___________|
UDP UDP WebSocket <=== WebSocket
Client Server Server Client
Figure 8: CoAP Client (UDP Client) Accesses CoAP Server (WebSocket Client) via a CoAP Proxy (UDP Server / WebSocket Server)
图8:CoAP客户端（UDP客户端）通过CoAP代理（UDP服务器/WebSocket服务器）访问CoAP服务器（WebSocket客户端）
Further configurations are possible, including those where a WebSocket connection is established through an HTTP proxy.
还可以进行进一步的配置，包括通过HTTP代理建立WebSocket连接的配置。
Before CoAP requests and responses are exchanged, a WebSocket connection is established as defined in Section 4 of [RFC6455]. Figure 9 shows an example.
在交换CoAP请求和响应之前，按照[RFC6455]第4节的定义建立WebSocket连接。图9显示了一个示例。
The WebSocket client MUST include the subprotocol name "coap" in the list of protocols; this indicates support for the protocol defined in this document.
WebSocket客户端必须在协议列表中包含子目录名称“coap”；这表示支持本文档中定义的协议。
The WebSocket client includes the hostname of the WebSocket server in the Host header field of its handshake as per [RFC6455]. The Host header field also indicates the default value of the Uri-Host Option in requests from the WebSocket client to the WebSocket server.
根据[RFC6455]，WebSocket客户端在握手的主机头字段中包含WebSocket服务器的主机名。主机头字段还指示从WebSocket客户端到WebSocket服务器的请求中Uri主机选项的默认值。
GET /.well-known/coap HTTP/1.1
Host: example.org
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Protocol: coap
Sec-WebSocket-Version: 13
GET /.well-known/coap HTTP/1.1
Host: example.org
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Protocol: coap
Sec-WebSocket-Version: 13
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: coap
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: coap
Figure 9: Example of an Opening Handshake
图9：开场握手示例
Once a WebSocket connection is established, CoAP requests and responses can be exchanged as WebSocket messages. Since CoAP uses a binary message format, the messages are transmitted in binary data frames as specified in Sections 5 and 6 of [RFC6455].
一旦建立WebSocket连接，CoAP请求和响应就可以作为WebSocket消息进行交换。由于CoAP使用二进制消息格式，因此按照[RFC6455]第5节和第6节的规定，以二进制数据帧传输消息。
The message format shown in Figure 10 is the same as the message format for CoAP over TCP (see Section 3.2), with one change: the Length (Len) field MUST be set to zero, because the WebSocket frame contains the length.
图10所示的消息格式与TCP上的CoAP的消息格式相同（参见第3.2节），但有一个变化：长度（leng）字段必须设置为零，因为WebSocket框架包含长度。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Len=0 | TKL | Code | Token (TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Len=0 | TKL | Code | Token (TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: CoAP Message Format over WebSockets
图10:WebSocket上的CoAP消息格式
As with CoAP over TCP, the message format for CoAP over WebSockets eliminates the Version field defined in CoAP over UDP. If CoAP version negotiation is required in the future, CoAP over WebSockets can address the requirement by defining a new subprotocol identifier that is negotiated during the opening handshake.
与TCP上的CoAP一样，WebSocket上的CoAP的消息格式消除了在UDP上的CoAP中定义的版本字段。如果将来需要协商CoAP版本，则WebSocket上的CoAP可以通过定义在开始握手期间协商的新子策略标识符来满足该要求。
Requests and responses can be fragmented as specified in Section 5.4 of [RFC6455], though typically they are sent unfragmented, as they tend to be small and fully buffered before transmission. The WebSocket Protocol does not provide means for multiplexing. If it is not desirable for a large message to monopolize the connection, requests and responses can be transferred in a block-wise fashion as defined in [RFC7959].
请求和响应可以按照[RFC6455]第5.4节的规定进行分段，尽管它们通常是不分段发送的，因为它们往往很小，并且在传输之前已完全缓冲。WebSocket协议不提供多路复用的方法。如果不希望大消息独占连接，则可以按照[RFC7959]中的定义以块方式传输请求和响应。
As with CoAP over TCP, each endpoint MUST send a CSM (see Section 5.3) as its first message on the WebSocket connection.
与TCP上的CoAP一样，每个端点必须发送一个CSM（参见第5.3节），作为其在WebSocket连接上的第一条消息。
CoAP requests and responses are exchanged asynchronously over the WebSocket connection. A CoAP client can send multiple requests without waiting for a response, and the CoAP server can return responses in any order. Responses MUST be returned over the same connection as the originating request. Each concurrent request is differentiated by its Token, which is scoped locally to the connection.
CoAP请求和响应通过WebSocket连接异步交换。CoAP客户端可以在不等待响应的情况下发送多个请求，CoAP服务器可以按任意顺序返回响应。响应必须通过与原始请求相同的连接返回。每个并发请求都通过其令牌进行区分，令牌的作用域在连接的本地。
The connection is bidirectional, so requests can be sent by both the entity that established the connection and the remote host.
连接是双向的，因此建立连接的实体和远程主机都可以发送请求。
As with CoAP over TCP, retransmission and deduplication of messages are provided by the WebSocket Protocol. CoAP over WebSockets therefore does not make a distinction between Confirmable messages and Non-confirmable messages and does not provide Acknowledgment or Reset messages.
与TCP上的CoAP一样，消息的重传和重复数据消除由WebSocket协议提供。因此，WebSocket上的CoAP不区分可确认消息和不可确认消息，也不提供确认或重置消息。
As with CoAP over TCP, a CoAP client can test the health of the connection for CoAP over WebSockets by sending a CoAP Ping Signaling message (Section 5.4). To ensure that redundant maintenance traffic is not transmitted, WebSocket Ping and unsolicited Pong frames (Section 5.5 of [RFC6455]) SHOULD NOT be used.
与TCP上的CoAP一样，CoAP客户端可以通过发送CoAP Ping信令消息（第5.4节）来测试WebSocket上的CoAP连接的健康状况。为确保不传输冗余维护通信，不应使用WebSocket Ping和未经请求的Pong帧（RFC6455第5.5节）。
Signaling messages are specifically introduced only for CoAP over reliable transports to allow peers to:
信令消息仅针对通过可靠传输的CoAP引入，以允许对等方：
o Learn related characteristics, such as maximum message size for the connection.
o 了解相关特征，例如连接的最大消息大小。
o Shut down the connection in an orderly fashion.
o 有序地关闭连接。
o Provide diagnostic information when terminating a connection in response to a serious error condition.
o 在响应严重错误情况而终止连接时提供诊断信息。
Signaling is a third basic kind of message in CoAP, after requests and responses. Signaling messages share a common structure with the existing CoAP messages. There are a code, a Token, options, and an optional payload.
信令是CoAP中继请求和响应之后的第三种基本消息。信令消息与现有的CoAP消息共享一个公共结构。有代码、令牌、选项和可选负载。
(See Section 3 of [RFC7252] for the overall structure of the message format, option format, and option value formats.)
（有关消息格式、选项格式和选项值格式的总体结构，请参见[RFC7252]第3节。）
A code in the 7.00-7.31 range indicates a Signaling message. Values in this range are assigned by the "CoAP Signaling Codes" subregistry (see Section 11.1).
7.00-7.31范围内的代码表示信令消息。该范围内的值由“CoAP信号代码”子区域指定（见第11.1节）。
For each message, there are a sender and a peer receiving the message.
对于每条消息，都有一个发送方和一个对等方接收消息。
Payloads in Signaling messages are diagnostic payloads as defined in Section 5.5.2 of [RFC7252], unless otherwise defined by a Signaling message option.
除非信令消息选项另有规定，否则信令消息中的有效载荷为[RFC7252]第5.5.2节中定义的诊断有效载荷。
Option Numbers for Signaling messages are specific to the message code. They do not share the number space with CoAP options for request/response messages or with Signaling messages using other codes.
信令消息的选项号特定于消息代码。它们不与请求/响应消息的CoAP选项或使用其他代码的信令消息共享数字空间。
Option Numbers are assigned by the "CoAP Signaling Option Numbers" subregistry (see Section 11.2).
选项编号由“CoAP信令选项编号”子区域指定（见第11.2节）。
Signaling Options are elective or critical as defined in Section 5.4.1 of [RFC7252]. If a Signaling Option is critical and not understood by the receiver, it MUST abort the connection (see Section 5.6). If the option is understood but cannot be processed, the option documents the behavior.
信号选项是可选的或关键的，如[RFC7252]第5.4.1节所定义。如果一个信令选项是关键的，且接收器不理解，则必须中止连接（见第5.6节）。如果该选项已被理解但无法处理，则该选项将记录该行为。
CSMs are used for two purposes:
CSM用于两个目的：
o Each capability option indicates one capability of the sender to the recipient.
o 每个功能选项表示发送方对接收方的一种功能。
o Each setting option indicates a setting that will be applied by the sender.
o 每个设置选项都表示发件人将应用的设置。
One CSM MUST be sent by each endpoint at the start of the Transport Connection. Additional CSMs MAY be sent at any other time by either endpoint over the lifetime of the connection.
每个端点必须在传输连接开始时发送一个CSM。在连接的生命周期内，任何端点都可以在任何其他时间发送额外的CSM。
Both capability options and setting options are cumulative. A CSM does not invalidate a previously sent capability indication or setting even if it is not repeated. A capability message without any option is a no-operation (and can be used as such). An option that is sent might override a previous value for the same option. The option defines how to handle this case if needed.
功能选项和设置选项都是累积的。CSM不会使先前发送的能力指示或设置无效，即使没有重复。不带任何选项的功能消息是“无操作”（可以这样使用）。发送的选项可能会覆盖同一选项的先前值。该选项定义了在需要时如何处理此情况。
Base values are listed below for CSM options. These are the values for the capability and settings before any CSMs send a modified value.
下面列出了CSM选项的基本值。这些是任何CSM发送修改值之前的功能和设置值。
These are not default values (as defined in Section 5.4.4 in [RFC7252]) for the option. Default values apply on a per-message basis and are thus reset when the value is not present in a given CSM.
这些不是选项的默认值（如[RFC7252]第5.4.4节所定义）。默认值基于每条消息应用，因此在给定CSM中不存在该值时会重置。
CSMs are indicated by the 7.01 (CSM) code; see Table 1 (Section 11.1).
CSM由7.01（CSM）代码表示；见表1（第11.1节）。
The sender can use the elective Max-Message-Size Option to indicate the maximum size of a message in bytes that it can receive. The message size indicated includes the entire message, starting from the first byte of the message header and ending at the end of the message payload.
发送方可以使用可选的“最大邮件大小”选项来指示其可以接收的邮件的最大大小（以字节为单位）。指示的消息大小包括整个消息，从消息头的第一个字节开始，到消息有效负载的末尾结束。
(Note that there is no relationship of the message size to the overall request or response body size that may be achievable in block-wise transfer. For example, the exchange depicted in Figure 13 (Section 6.1) can be performed if the CoAP client indicates a value of around 6000 bytes for the Max-Message-Size Option, even though the total body size transferred to the client is 3072 + 5120 + 4711 = 12903 bytes.)
（请注意，消息大小与整体请求或响应正文大小之间不存在任何关系，这在按块传输中是可以实现的。例如，图13所示的交换（第6.1节）如果CoAP客户端指示最大消息大小选项的值约为6000字节，即使传输到客户端的正文总大小为3072+5120+4711=12903字节，也可以执行。）
+---+---+---+---------+------------------+--------+--------+--------+
| # | C | R | Applies | Name | Format | Length | Base |
| | | | to | | | | Value |
+---+---+---+---------+------------------+--------+--------+--------+
| 2 | | | CSM | Max-Message-Size | uint | 0-4 | 1152 |
+---+---+---+---------+------------------+--------+--------+--------+
+---+---+---+---------+------------------+--------+--------+--------+
| # | C | R | Applies | Name | Format | Length | Base |
| | | | to | | | | Value |
+---+---+---+---------+------------------+--------+--------+--------+
| 2 | | | CSM | Max-Message-Size | uint | 0-4 | 1152 |
+---+---+---+---------+------------------+--------+--------+--------+
C=Critical, R=Repeatable
C=临界，R=可重复
As per Section 4.6 of [RFC7252], the base value (and the value used when this option is not implemented) is 1152.
根据[RFC7252]第4.6节，基准值（以及未实施该选项时使用的值）为1152。
The active value of the Max-Message-Size Option is replaced each time the option is sent with a modified value. Its starting value is its base value.
每次使用修改后的值发送选项时，都会替换“最大消息大小”选项的活动值。其起始值是其基准值。
+---+---+---+---------+------------------+--------+--------+--------+
| # | C | R | Applies | Name | Format | Length | Base |
| | | | to | | | | Value |
+---+---+---+---------+------------------+--------+--------+--------+
| 4 | | | CSM | Block-Wise- | empty | 0 | (none) |
| | | | | Transfer | | | |
+---+---+---+---------+------------------+--------+--------+--------+
+---+---+---+---------+------------------+--------+--------+--------+
| # | C | R | Applies | Name | Format | Length | Base |
| | | | to | | | | Value |
+---+---+---+---------+------------------+--------+--------+--------+
| 4 | | | CSM | Block-Wise- | empty | 0 | (none) |
| | | | | Transfer | | | |
+---+---+---+---------+------------------+--------+--------+--------+
C=Critical, R=Repeatable
C=临界，R=可重复
A sender can use the elective Block-Wise-Transfer Option to indicate that it supports the block-wise transfer protocol [RFC7959].
发送方可以使用可选的分块传输选项指示其支持分块传输协议[RFC7959]。
If the option is not given, the peer has no information about whether block-wise transfers are supported by the sender or not. An implementation wishing to offer block-wise transfers to its peer therefore needs to indicate so via the Block-Wise-Transfer Option.
如果未给出该选项，则对等方没有关于发送方是否支持分块传输的信息。因此，希望向其对等方提供分块传输的实现需要通过分块传输选项指示。
If a Max-Message-Size Option is indicated with a value that is greater than 1152 (in the same CSM or a different CSM), the Block-Wise-Transfer Option also indicates support for BERT (see Section 6). Subsequently, if the Max-Message-Size Option is indicated with a value equal to or less than 1152, BERT support is no longer indicated. (Note that the indication of BERT support does not oblige either peer to actually choose to make use of BERT.)
如果“最大消息大小”选项的值大于1152（在同一个CSM或不同的CSM中），则“分块传输”选项也表示支持BERT（参见第6节）。随后，如果使用等于或小于1152的值指示最大消息大小选项，则不再指示BERT支持。（请注意，表示BERT支持并不要求任何一方实际选择使用BERT。）
Implementation note: When indicating a value of the Max-Message-Size Option with an intention to enable BERT, the indicating implementation may want to (1) choose a particular BERT block size it wants to encourage and (2) add a delta for the header and any options that may also need to be included in the message with a BERT block of that size. Section 4.6 of [RFC7252] adds 128 bytes to a maximum block size of 1024 to arrive at a default message size of 1152. A BERT-enabled implementation may want to indicate a BERT block size of 2048 or a higher multiple of 1024 and at the same time be more generous with the size of the header and options added (say, 256 or 512). However, adding 1024 or more to the base BERT block size may encourage the peer implementation to vary the BERT block size based on the size of the options included; this type of scenario might make it harder to establish interoperability.
实现说明：当指示最大消息大小选项的值以启用BERT时，指示实现可能希望（1）选择它想要鼓励的特定BERT块大小，以及（2）为头添加增量，以及可能还需要包含在具有该大小的BERT块的消息中的任何选项。[RFC7252]的第4.6节将128字节添加到1024的最大块大小，以获得1152的默认消息大小。启用BERT的实现可能希望指示2048的BERT块大小或1024的更高倍数，同时对添加的报头和选项（例如256或512）的大小更加慷慨。然而，向基本BERT块大小添加1024或更多可鼓励对等实现基于所包括的选项的大小改变BERT块大小；这种类型的场景可能会使建立互操作性变得更加困难。
In CoAP over reliable transports, Empty messages (Code 0.00) can always be sent and MUST be ignored by the recipient. This provides a basic keepalive function. In contrast, Ping and Pong messages are a bidirectional exchange.
在CoAP over reliable Transport中，空消息（代码0.00）始终可以发送，收件人必须忽略。这提供了一个基本的keepalive函数。相反，乒乓球和乒乓球消息是双向交换。
Upon receipt of a Ping message, the receiver MUST return a Pong message with an identical Token in response. Unless the Ping carries an option with delaying semantics such as the Custody Option, it SHOULD respond as soon as practical. As with all Signaling messages, the recipient of a Ping or Pong message MUST ignore elective options it does not understand.
在收到Ping消息后，接收方必须返回带有相同令牌的Pong消息作为响应。除非Ping带有延迟语义的选项（如保管选项），否则它应该尽快响应。与所有信令消息一样，Ping或Pong消息的接收者必须忽略其不理解的可选选项。
Ping and Pong messages are indicated by the 7.02 code (Ping) and the 7.03 code (Pong).
Ping和Pong消息由7.02代码（Ping）和7.03代码（Pong）表示。
Note that, as with similar mechanisms defined in [RFC6455] and [RFC7540], the present specification does not define any specific maximum time that the sender of a Ping message has to allow when waiting for a Pong reply. Any limitations on patience for this reply are a matter of the application making use of these messages, as is any approach to recover from a failure to respond in time.
注意，与[RFC6455]和[RFC7540]中定义的类似机制一样，本规范没有定义Ping消息的发送者在等待Pong应答时必须允许的任何特定最长时间。对这个回复的耐心的任何限制都是应用程序利用这些消息的问题，以及从未能及时响应中恢复的任何方法。
+---+---+---+----------+----------------+--------+--------+---------+
| # | C | R | Applies | Name | Format | Length | Base |
| | | | to | | | | Value |
+---+---+---+----------+----------------+--------+--------+---------+
| 2 | | | Ping, | Custody | empty | 0 | (none) |
| | | | Pong | | | | |
+---+---+---+----------+----------------+--------+--------+---------+
+---+---+---+----------+----------------+--------+--------+---------+
| # | C | R | Applies | Name | Format | Length | Base |
| | | | to | | | | Value |
+---+---+---+----------+----------------+--------+--------+---------+
| 2 | | | Ping, | Custody | empty | 0 | (none) |
| | | | Pong | | | | |
+---+---+---+----------+----------------+--------+--------+---------+
C=Critical, R=Repeatable
C=临界，R=可重复
When responding to a Ping message, the receiver can include an elective Custody Option in the Pong message. This option indicates that the application has processed all the request/response messages received prior to the Ping message on the current connection. (Note that there is no definition of specific application semantics for "processed", but there is an expectation that the receiver of a Pong message with a Custody Option should be able to free buffers based on this indication.)
当响应Ping消息时，接收器可以在Pong消息中包括选择性监护选项。此选项表示应用程序已处理在当前连接上Ping消息之前收到的所有请求/响应消息。（请注意，“已处理”没有特定应用程序语义的定义，但有一个期望，即具有保管选项的Pong消息的接收方应该能够基于此指示释放缓冲区。）
A sender can also include an elective Custody Option in a Ping message to explicitly request the inclusion of an elective Custody Option in the corresponding Pong message. In that case, the receiver SHOULD delay its Pong message until it finishes processing all the request/response messages received prior to the Ping message on the current connection.
发送方还可以在Ping消息中包含选择性托管选项，以明确请求在相应的Pong消息中包含选择性托管选项。在这种情况下，接收器应延迟其Pong消息，直到完成处理在当前连接上的Ping消息之前收到的所有请求/响应消息。
A Release message indicates that the sender does not want to continue maintaining the Transport Connection and opts for an orderly shutdown, but wants to leave it to the peer to actually start closing the connection. The details are in the options. A diagnostic payload (see Section 5.5.2 of [RFC7252]) MAY be included.
释放消息表示发送方不希望继续维护传输连接，并选择有序关闭，但希望让对等方实际开始关闭连接。详细信息在选项中。可包括诊断有效载荷（见[RFC7252]第5.5.2节）。
A peer will normally respond to a Release message by closing the Transport Connection. (In case that does not happen, the sender of the release may want to implement a timeout mechanism if getting rid of the connection is actually important to it.)
对等方通常会通过关闭传输连接来响应释放消息。（如果这种情况没有发生，那么发布的发送方可能希望实现一个超时机制，如果摆脱连接实际上对它很重要的话。）
Messages may be in flight or responses outstanding when the sender decides to send a Release message (which is one reason the sender had decided to wait before closing the connection). The peer responding to the Release message SHOULD delay the closing of the connection until it has responded to all requests received by it before the Release message. It also MAY wait for the responses to its own requests.
当发送方决定发送释放消息时，消息可能正在传输中或响应未完成（这是发送方决定在关闭连接之前等待的原因之一）。响应释放消息的对等方应延迟关闭连接，直到它响应了释放消息之前接收到的所有请求。它还可以等待对自己请求的响应。
It is NOT RECOMMENDED for the sender of a Release message to continue sending requests on the connection it already indicated to be released: the peer might close the connection at any time and miss those requests. The peer is not obligated to check for this condition, though.
不建议释放消息的发送方继续在已指示要释放的连接上发送请求：对等方可能随时关闭连接并错过这些请求。但是，对等方没有义务检查这种情况。
Release messages are indicated by the 7.04 code (Release).
释放消息由7.04代码（释放）指示。
Release messages can indicate one or more reasons using elective options. The following options are defined:
释放消息可以使用可选选项指示一个或多个原因。定义了以下选项：
+---+---+---+---------+------------------+--------+--------+--------+
| # | C | R | Applies | Name | Format | Length | Base |
| | | | to | | | | Value |
+---+---+---+---------+------------------+--------+--------+--------+
| 2 | | x | Release | Alternative- | string | 1-255 | (none) |
| | | | | Address | | | |
+---+---+---+---------+------------------+--------+--------+--------+
+---+---+---+---------+------------------+--------+--------+--------+
| # | C | R | Applies | Name | Format | Length | Base |
| | | | to | | | | Value |
+---+---+---+---------+------------------+--------+--------+--------+
| 2 | | x | Release | Alternative- | string | 1-255 | (none) |
| | | | | Address | | | |
+---+---+---+---------+------------------+--------+--------+--------+
C=Critical, R=Repeatable
C=临界，R=可重复
The elective Alternative-Address Option requests the peer to instead open a connection of the same scheme as the present connection to the alternative transport address given. Its value is in the form "authority" as defined in Section 3.2 of [RFC3986]. (Existing state related to the connection is not transferred from the present connection to the new connection.)
可选替代地址选项要求对等方打开与给定替代传输地址的当前连接相同方案的连接。其值采用[RFC3986]第3.2节中定义的“授权”形式。（与连接相关的现有状态不会从当前连接转移到新连接。）
The Alternative-Address Option is a repeatable option as defined in Section 5.4.5 of [RFC7252]. When multiple occurrences of the option are included, the peer can choose any of the alternative transport addresses.
备选地址选项是[RFC7252]第5.4.5节中定义的可重复选项。当包含多个选项时，对等方可以选择任何备选传输地址。
+---+---+---+---------+-----------------+--------+--------+---------+
| # | C | R | Applies | Name | Format | Length | Base |
| | | | to | | | | Value |
+---+---+---+---------+-----------------+--------+--------+---------+
| 4 | | | Release | Hold-Off | uint | 0-3 | (none) |
+---+---+---+---------+-----------------+--------+--------+---------+
+---+---+---+---------+-----------------+--------+--------+---------+
| # | C | R | Applies | Name | Format | Length | Base |
| | | | to | | | | Value |
+---+---+---+---------+-----------------+--------+--------+---------+
| 4 | | | Release | Hold-Off | uint | 0-3 | (none) |
+---+---+---+---------+-----------------+--------+--------+---------+
C=Critical, R=Repeatable
C=临界，R=可重复
The elective Hold-Off Option indicates that the server is requesting that the peer not reconnect to it for the number of seconds given in the value.
可选延迟选项表示服务器正在请求对等方在值中给定的秒数内不重新连接到它。
An Abort message indicates that the sender is unable to continue maintaining the Transport Connection and cannot even wait for an orderly release. The sender shuts down the connection immediately after the Abort message (and may or may not wait for a Release message, Abort message, or connection shutdown in the inverse direction). A diagnostic payload (see Section 5.5.2 of [RFC7252]) SHOULD be included in the Abort message. Messages may be in flight or responses outstanding when the sender decides to send an Abort message. The general expectation is that these will NOT be processed.
中止消息表示发送方无法继续维护传输连接，甚至不能等待有序释放。发送方在中止消息后立即关闭连接（并且可以或不可以等待释放消息、中止消息或反向连接关闭）。中止消息中应包括诊断有效载荷（见[RFC7252]第5.5.2节）。当发送方决定发送中止消息时，消息可能正在传输或响应未完成。一般的期望是这些将不会被处理。
Abort messages are indicated by the 7.05 code (Abort).
中止消息由7.05代码（中止）指示。
Abort messages can indicate one or more reasons using elective options. The following option is defined:
中止消息可以使用可选选项指示一个或多个原因。定义了以下选项：
+---+---+---+---------+-----------------+--------+--------+---------+
| # | C | R | Applies | Name | Format | Length | Base |
| | | | to | | | | Value |
+---+---+---+---------+-----------------+--------+--------+---------+
| 2 | | | Abort | Bad-CSM-Option | uint | 0-2 | (none) |
+---+---+---+---------+-----------------+--------+--------+---------+
+---+---+---+---------+-----------------+--------+--------+---------+
| # | C | R | Applies | Name | Format | Length | Base |
| | | | to | | | | Value |
+---+---+---+---------+-----------------+--------+--------+---------+
| 2 | | | Abort | Bad-CSM-Option | uint | 0-2 | (none) |
+---+---+---+---------+-----------------+--------+--------+---------+
C=Critical, R=Repeatable
C=临界，R=可重复
Bad-CSM-Option, which is elective, indicates that the sender is unable to process the CSM option identified by its Option Number, e.g., when it is critical and the Option Number is unknown by the sender, or when there is a parameter problem with the value of an elective option. More detailed information SHOULD be included as a diagnostic payload.
可选的坏CSM选项表示发送方无法处理由其选项号标识的CSM选项，例如，当它是关键的且发送方不知道选项号时，或者当可选选项的值存在参数问题时。更详细的信息应包括在诊断有效负载中。
For CoAP over UDP, messages that contain syntax violations are processed as message format errors. As described in Sections 4.2 and 4.3 of [RFC7252], such messages are rejected by sending a matching Reset message and otherwise ignoring the message.
对于UDP上的CoAP，包含语法冲突的消息将作为消息格式错误处理。如[RFC7252]第4.2节和第4.3节所述，通过发送匹配的重置消息并忽略该消息来拒绝此类消息。
For CoAP over reliable transports, the recipient rejects such messages by sending an Abort message and otherwise ignoring (not processing) the message. No specific Option has been defined for the Abort message in this case, as the details are best left to a diagnostic payload.
对于可靠传输上的CoAP，接收方通过发送中止消息并忽略（不处理）消息来拒绝此类消息。在这种情况下，没有为中止消息定义特定选项，因为详细信息最好留给诊断负载。
An encoded example of a Ping message with a non-empty Token is shown in Figure 11.
带有非空令牌的Ping消息的编码示例如图11所示。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 | 0xe2 | 0x42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 | 0xe2 | 0x42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Len = 0 -------> 0x01
TKL = 1 ___/
Code = 7.02 Ping --> 0xe2
Token = 0x42
Len = 0 -------> 0x01
TKL = 1 ___/
Code = 7.02 Ping --> 0xe2
Token = 0x42
Figure 11: Ping Message Example
图11:Ping消息示例
An encoded example of the corresponding Pong message is shown in Figure 12.
对应Pong消息的编码示例如图12所示。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 | 0xe3 | 0x42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 | 0xe3 | 0x42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Len = 0 -------> 0x01
TKL = 1 ___/
Code = 7.03 Pong --> 0xe3
Token = 0x42
Len = 0 -------> 0x01
TKL = 1 ___/
Code = 7.03 Pong --> 0xe3
Token = 0x42
Figure 12: Pong Message Example
图12：Pong消息示例
The message size restrictions defined in Section 4.6 of [RFC7252] to avoid IP fragmentation are not necessary when CoAP is used over a reliable transport. While this suggests that the block-wise transfer protocol [RFC7959] is also no longer needed, it remains applicable for a number of cases:
当通过可靠传输使用CoAP时，[RFC7252]第4.6节中定义的避免IP碎片的消息大小限制是不必要的。虽然这表明也不再需要块传输协议[RFC7959]，但它仍然适用于许多情况：
o Large messages, such as firmware downloads, may cause undesired head-of-line blocking when a single transport connection is used.
o 当使用单个传输连接时，大型消息（如固件下载）可能会导致不需要的线端阻塞。
o A UDP-to-TCP gateway may simply not have the context to convert a message with a Block Option into the equivalent exchange without any use of a Block Option (it would need to convert the entire block-wise exchange from start to end into a single exchange).
o UDP-to-TCP网关可能根本不具备在不使用块选项的情况下将带有块选项的消息转换为等效交换的上下文（它需要将整个按块交换从开始到结束转换为单个交换）。
BERT extends the block-wise transfer protocol to enable the use of larger messages over a reliable transport.
BERT扩展了分块传输协议，以支持通过可靠传输使用较大的消息。
The use of this new extension is signaled by sending Block1 or Block2 Options with SZX == 7 (a "BERT Option"). SZX == 7 is a reserved value in [RFC7959].
通过发送SZX==7的Block1或Block2选项（一个“BERT选项”）来表示此新扩展的使用。SZX==7是[RFC7959]中的保留值。
In control usage, a BERT Option is interpreted in the same way as the equivalent Option with SZX == 6, except that it also indicates the capability to process BERT blocks. As with the basic block-wise transfer protocol, the recipient of a CoAP request with a BERT Option in control usage is allowed to respond with a different SZX value, e.g., to send a non-BERT block instead.
在控件使用中，BERT选项的解释方式与SZX==6的等效选项相同，只是它还表示处理BERT块的能力。与基本的分块传输协议一样，允许在控制使用中具有BERT选项的CoAP请求的接收者使用不同的SZX值进行响应，例如，改为发送非BERT块。
In descriptive usage, a BERT Option is interpreted in the same way as the equivalent Option with SZX == 6, except that the payload is also allowed to contain multiple blocks. For non-final BERT blocks, the payload is always a multiple of 1024 bytes. For final BERT blocks, the payload is a multiple (possibly 0) of 1024 bytes plus a partial block of less than 1024 bytes.
在描述性用法中，BERT选项的解释方式与SZX==6的等效选项的解释方式相同，只是有效负载也允许包含多个块。对于非最终BERT块，有效负载始终是1024字节的倍数。对于最后的BERT块，有效负载是1024字节的倍数（可能是0）加上小于1024字节的部分块。
The recipient of a non-final BERT block (M=1) conceptually partitions the payload into a sequence of 1024-byte blocks and acts exactly as if it had received this sequence in conjunction with block numbers starting at, and sequentially increasing from, the block number given in the Block Option. In other words, the entire BERT block is positioned at the byte position that results from multiplying the block number by 1024. The position of further blocks to be transferred is indicated by incrementing the block number by the number of elements in this sequence (i.e., the size of the payload divided by 1024 bytes).
非最终BERT块（M＝1）的接收者在概念上将有效负载划分为1024字节块的序列，并且其行为完全如同其已接收到该序列以及从块选项中给出的块编号开始并从中依次增加的块编号一样。换句话说，整个BERT块被定位在块号乘以1024的字节位置。要传输的其他块的位置通过将块编号增加该序列中的元素数量（即，有效负载的大小除以1024字节）来指示。
As with SZX == 6, the recipient of a final BERT block (M=0) simply appends the payload at the byte position that is indicated by the block number multiplied by 1024.
与SZX==6一样，最终BERT块（M=0）的接收者只需将有效负载附加到由块号乘以1024表示的字节位置。
The following examples illustrate BERT Options. A value of SZX == 7 is labeled as "BERT" or as "BERT(nnn)" to indicate a payload of size nnn.
以下示例说明了这些选项。SZX==7的值被标记为“BERT”或“BERT（nnn）”以指示大小为nnn的有效载荷。
In all these examples, a Block Option is decomposed to indicate the kind of Block Option (1 or 2) followed by a colon, the block number (NUM), the more bit (M), and the block size (2**(SZX + 4)) separated by slashes. For example, a Block2 Option value of 33 would be shown as 2:2/0/32), or a Block1 Option value of 59 would be shown as 1:3/1/128.
在所有这些示例中，一个块选项被分解，以指示块选项的类型（1或2），后跟一个冒号、块编号（NUM）、多位（M）和块大小（2**（SZX+4））以斜杠分隔。例如，Block2选项值33将显示为2:2/0/32），或者Block1选项值59将显示为1:3/1/128。
Figure 13 shows a GET request with a response that is split into three BERT blocks. The first response contains 3072 bytes of payload; the second, 5120; and the third, 4711. Note how the block number increments to move the position inside the response body forward.
图13显示了一个GET请求，其响应被分为三个块。第一个响应包含3072字节的有效负载；第二，5120；第三个是4711。请注意，块编号是如何递增以向前移动响应主体内的位置的。
CoAP Client CoAP Server
| |
| GET, /status ------> |
| |
| <------ 2.05 Content, 2:0/1/BERT(3072) |
| |
| GET, /status, 2:3/0/BERT ------> |
| |
| <------ 2.05 Content, 2:3/1/BERT(5120) |
| |
| GET, /status, 2:8/0/BERT ------> |
| |
| <------ 2.05 Content, 2:8/0/BERT(4711) |
CoAP Client CoAP Server
| |
| GET, /status ------> |
| |
| <------ 2.05 Content, 2:0/1/BERT(3072) |
| |
| GET, /status, 2:3/0/BERT ------> |
| |
| <------ 2.05 Content, 2:3/1/BERT(5120) |
| |
| GET, /status, 2:8/0/BERT ------> |
| |
| <------ 2.05 Content, 2:8/0/BERT(4711) |
Figure 13: GET with BERT Blocks
图13:GetwithBert块
Figure 14 demonstrates a PUT exchange with BERT blocks.
图14展示了一个带有BERT块的看跌期权交换。
CoAP Client CoAP Server
| |
| PUT, /options, 1:0/1/BERT(8192) ------> |
| |
| <------ 2.31 Continue, 1:0/1/BERT |
| |
| PUT, /options, 1:8/1/BERT(16384) ------> |
| |
| <------ 2.31 Continue, 1:8/1/BERT |
| |
| PUT, /options, 1:24/0/BERT(5683) ------> |
| |
| <------ 2.04 Changed, 1:24/0/BERT |
| |
CoAP Client CoAP Server
| |
| PUT, /options, 1:0/1/BERT(8192) ------> |
| |
| <------ 2.31 Continue, 1:0/1/BERT |
| |
| PUT, /options, 1:8/1/BERT(16384) ------> |
| |
| <------ 2.31 Continue, 1:8/1/BERT |
| |
| PUT, /options, 1:24/0/BERT(5683) ------> |
| |
| <------ 2.04 Changed, 1:24/0/BERT |
| |
Figure 14: PUT with BERT Blocks
图14：带BERT块的PUT
This section describes how the procedures defined in [RFC7641] for observing resources over CoAP are applied (and modified, as needed) for reliable transports. In this section, "client" and "server" refer to the CoAP client and CoAP server.
本节描述了如何应用[RFC7641]中定义的通过CoAP观测资源的程序（并根据需要进行修改），以实现可靠传输。在本节中，“客户机”和“服务器”指的是CoAP客户机和CoAP服务器。
When using the Observe Option [RFC7641] with CoAP over UDP, notifications from the server set the option value to an increasing sequence number for reordering detection on the client, since messages can arrive in a different order than they were sent. This sequence number is not required for CoAP over reliable transports, since TCP ensures reliable and ordered delivery of messages. The value of the Observe Option in 2.xx notifications MAY be empty on transmission and MUST be ignored on reception.
通过UDP上的CoAP使用观察选项[RFC7641]时，来自服务器的通知将选项值设置为递增的序号，以便在客户端上进行重新排序检测，因为消息的到达顺序可能与发送顺序不同。CoAP在可靠传输上不需要此序列号，因为TCP确保消息的可靠和有序传递。2.xx通知中的观察选项值在传输时可能为空，在接收时必须忽略。
Implementation note: This means that a proxy from a reordering transport to a reliable (in-order) transport (such as a UDP-to-TCP proxy) needs to process the Observe Option in notifications according to the rules in Section 3.4 of [RFC7641].
实施说明：这意味着从重新排序传输到可靠（有序）传输（如UDP到TCP代理）的代理需要根据[RFC7641]第3.4节中的规则处理通知中的观察选项。
For CoAP over UDP, server notifications to the client can be Confirmable or Non-confirmable. A Confirmable message requires the client to respond with either an Acknowledgment message or a Reset message. An Acknowledgment message indicates that the client is alive and wishes to receive further notifications. A Reset message indicates that the client does not recognize the Token; this causes the server to remove the associated entry from the list of observers.
对于UDP上的CoAP，发送给客户端的服务器通知可以是可确认的，也可以是不可确认的。可确认消息要求客户端以确认消息或重置消息进行响应。确认消息表示客户端处于活动状态，并希望收到进一步的通知。重置消息指示客户端不识别令牌；这会导致服务器从观察者列表中删除关联的条目。
Since TCP eliminates the need for the message layer to support reliability, CoAP over reliable transports does not support Confirmable or Non-confirmable message types. All notifications are delivered reliably to the client with positive acknowledgment of receipt occurring at the TCP level. If the client does not recognize the Token in a notification, it MAY immediately abort the connection (see Section 5.6).
由于TCP消除了对消息层支持可靠性的需要，因此可靠传输上的CoAP不支持可确认或不可确认的消息类型。所有通知都可靠地传递给客户端，并在TCP级别进行肯定的接收确认。如果客户端无法识别通知中的令牌，它可能会立即中止连接（请参阅第5.6节）。
For CoAP over UDP, if a client does not receive a notification for some time, it can send a new GET request with the same Token as the original request to re-register its interest in a resource and verify that the server is still responsive. For CoAP over reliable transports, it is more efficient to check the health of the
对于UDP上的CoAP，如果客户端在一段时间内没有收到通知，它可以使用与原始请求相同的令牌发送新的GET请求，以重新注册其对资源的兴趣，并验证服务器是否仍有响应。对于通过可靠传输的CoAP，更有效的方法是检查设备的运行状况
connection (and all its active observations) by sending a single CoAP Ping Signaling message (Section 5.4) rather than individual requests to confirm each active observation. (Note that such a Ping/Pong only confirms a single hop: a proxy is not obligated or expected to react to a Ping by checking all its own registered interests or all the connections, if any, underlying them. A proxy MAY maintain its own schedule for confirming the interests that it relies on being registered toward the origin server; however, it is generally inadvisable for a proxy to generate a large number of outgoing checks based on a single incoming check.)
通过发送单个CoAP-Ping信令消息（第5.4节）而不是单个请求来确认每个活动观测的连接（及其所有活动观测）。（请注意，此类Ping/Pong仅确认单跳：代理没有义务或期望通过检查其所有已注册的权益或其基础的所有连接（如果有）来对Ping作出反应。代理可以维护其自己的时间表，以确认其所依赖的向源服务器注册的权益；但是，它是通常不建议代理基于单个传入检查生成大量传出检查。）
For CoAP over UDP, a client that is no longer interested in receiving notifications can "forget" the observation and respond to the next notification from the server with a Reset message to cancel the observation.
对于UDP上的CoAP，不再对接收通知感兴趣的客户端可以“忘记”观察，并使用重置消息响应来自服务器的下一个通知以取消观察。
For CoAP over reliable transports, a client MUST explicitly deregister by issuing a GET request that has the Token field set to the Token of the observation to be canceled and includes an Observe Option with the value set to 1 (deregister).
对于可靠传输上的CoAP，客户端必须通过发出GET请求显式取消注册，该请求将令牌字段设置为要取消的观察的令牌，并包括值设置为1（取消注册）的观察选项。
If the client observes one or more resources over a reliable transport, then the CoAP server (or intermediary in the role of the CoAP server) MUST remove all entries associated with the client endpoint from the lists of observers when the connection either times out or is closed.
如果客户端通过可靠传输观察到一个或多个资源，则当连接超时或关闭时，CoAP服务器（或充当CoAP服务器角色的中介）必须从观察者列表中删除与客户端端点相关的所有条目。
CoAP over UDP [RFC7252] defines the "coap" and "coaps" URI schemes. This document introduces four additional URI schemes for identifying CoAP resources and providing a means of locating the resource:
UDP上的CoAP[RFC7252]定义了“CoAP”和“CoAP”URI方案。本文档介绍了四种额外的URI方案，用于识别CoAP资源并提供查找资源的方法：
o The "coap+tcp" URI scheme for CoAP over TCP.
o tcp上的coap的“coap+tcp”URI方案。
o The "coaps+tcp" URI scheme for CoAP over TCP secured by TLS.
o 由TLS保护的CoAP over tcp的“CoAP+tcp”URI方案。
o The "coap+ws" URI scheme for CoAP over WebSockets.
o WebSocket上coap的“coap+ws”URI方案。
o The "coaps+ws" URI scheme for CoAP over WebSockets secured by TLS.
o TLS保护的WebSocket上的CoAP的“CoAP+ws”URI方案。
Resources made available via these schemes have no shared identity even if their resource identifiers indicate the same authority (the same host listening to the same TCP port). They are hosted in distinct namespaces because each URI scheme implies a distinct origin server.
通过这些方案提供的资源没有共享标识，即使它们的资源标识符指示相同的权限（同一主机侦听相同的TCP端口）。它们托管在不同的名称空间中，因为每个URI方案都意味着一个不同的源服务器。
In this section, the syntax for the URI schemes is specified using the Augmented Backus-Naur Form (ABNF) [RFC5234]. The definitions of "host", "port", "path-abempty", and "query" are adopted from [RFC3986].
在本节中，URI方案的语法是使用扩展的Backus Naur表单（ABNF）[RFC5234]指定的。“主机”、“端口”、“路径异常”和“查询”的定义采用[RFC3986]中的定义。
Section 8 ("Multicast CoAP") in [RFC7252] is not applicable to these schemes.
[RFC7252]中的第8节（“多播CoAP”）不适用于这些方案。
As with the "coap" and "coaps" schemes defined in [RFC7252], all URI schemes defined in this section also support the path prefix "/.well-known/" as defined by [RFC5785] for "well-known locations" in the namespace of a host. This enables discovery as per Section 7 of [RFC7252].
与[RFC7252]中定义的“coap”和“coap”方案一样，本节中定义的所有URI方案也支持[RFC5785]为主机命名空间中的“已知位置”定义的路径前缀“/.well-known/”。这使得能够按照[RFC7252]第7节进行查找。
The "coap+tcp" URI scheme identifies CoAP resources that are intended to be accessible using CoAP over TCP.
“coap+tcp”URI方案标识了打算使用coap over tcp访问的coap资源。
coap-tcp-URI = "coap+tcp:" "//" host [ ":" port ]
path-abempty [ "?" query ]
coap-tcp-URI = "coap+tcp:" "//" host [ ":" port ]
path-abempty [ "?" query ]
The syntax defined in Section 6.1 of [RFC7252] applies to this URI scheme, with the following change:
[RFC7252]第6.1节中定义的语法适用于此URI方案，但有以下更改：
o The port subcomponent indicates the TCP port at which the CoAP Connection Acceptor is located. (If it is empty or not given, then the default port 5683 is assumed, as with UDP.)
o port子组件表示CoAP连接接受器所在的TCP端口。（如果为空或未给定，则假定默认端口5683，与UDP相同。）
Encoding considerations: The scheme encoding conforms to the encoding rules established for URIs in [RFC3986].
编码注意事项：方案编码符合[RFC3986]中为URI建立的编码规则。
Interoperability considerations: None.
互操作性考虑：无。
Security considerations: See Section 11.1 of [RFC7252].
安全注意事项：见[RFC7252]第11.1节。
The "coaps+tcp" URI scheme identifies CoAP resources that are intended to be accessible using CoAP over TCP secured with TLS.
“CoAP+tcp”URI方案标识打算通过TLS保护的tcp上的CoAP访问的CoAP资源。
coaps-tcp-URI = "coaps+tcp:" "//" host [ ":" port ]
path-abempty [ "?" query ]
coaps-tcp-URI = "coaps+tcp:" "//" host [ ":" port ]
path-abempty [ "?" query ]
The syntax defined in Section 6.2 of [RFC7252] applies to this URI scheme, with the following changes:
[RFC7252]第6.2节中定义的语法适用于此URI方案，但有以下更改：
o The port subcomponent indicates the TCP port at which the TLS server for the CoAP Connection Acceptor is located. If it is empty or not given, then the default port 5684 is assumed.
o port子组件表示CoAP连接接受器的TLS服务器所在的TCP端口。如果为空或未给定，则假定默认端口5684。
o If a TLS server does not support the Application-Layer Protocol Negotiation (ALPN) extension [RFC7301] or wishes to accommodate TLS clients that do not support ALPN, it MAY offer a coaps+tcp endpoint on TCP port 5684. This endpoint MAY also be ALPN enabled. A TLS server MAY offer coaps+tcp endpoints on ports other than TCP port 5684, which MUST be ALPN enabled.
o 如果TLS服务器不支持应用层协议协商（ALPN）扩展[RFC7301]或希望容纳不支持ALPN的TLS客户端，则它可以在tcp端口5684上提供coaps+tcp端点。此端点也可以启用ALPN。TLS服务器可以在tcp端口5684以外的端口上提供COAP+tcp端点，tcp端口5684必须启用ALPN。
o For TCP ports other than port 5684, the TLS client MUST use the ALPN extension to advertise the "coap" protocol identifier (see Section 11.7) in the list of protocols in its ClientHello. If the TCP server selects and returns the "coap" protocol identifier using the ALPN extension in its ServerHello, then the connection succeeds. If the TLS server either does not negotiate the ALPN extension or returns a no_application_protocol alert, the TLS client MUST close the connection.
o 对于端口5684以外的TCP端口，TLS客户端必须使用ALPN扩展在其ClientHello中的协议列表中公布“coap”协议标识符（见第11.7节）。如果TCP服务器使用其ServerHello中的ALPN扩展选择并返回“coap”协议标识符，则连接成功。如果TLS服务器未协商ALPN扩展或返回no_application_协议警报，则TLS客户端必须关闭连接。
o For TCP port 5684, a TLS client MAY use the ALPN extension to advertise the "coap" protocol identifier in the list of protocols in its ClientHello. If the TLS server selects and returns the "coap" protocol identifier using the ALPN extension in its ServerHello, then the connection succeeds. If the TLS server returns a no_application_protocol alert, then the TLS client MUST close the connection. If the TLS server does not negotiate the ALPN extension, then coaps+tcp is implicitly selected.
o 对于TCP端口5684，TLS客户端可以使用ALPN扩展在其ClientHello中的协议列表中公布“coap”协议标识符。如果TLS服务器使用其ServerHello中的ALPN扩展选择并返回“coap”协议标识符，则连接成功。如果TLS服务器返回无应用程序协议警报，则TLS客户端必须关闭连接。如果TLS服务器不协商ALPN扩展，则隐式选择coaps+tcp。
o For TCP port 5684, if the TLS client does not use the ALPN extension to negotiate the protocol, then coaps+tcp is implicitly selected.
o 对于TCP端口5684，如果TLS客户端不使用ALPN扩展来协商协议，则隐式选择coaps+TCP。
Encoding considerations: The scheme encoding conforms to the encoding rules established for URIs in [RFC3986].
编码注意事项：方案编码符合[RFC3986]中为URI建立的编码规则。
Interoperability considerations: None.
互操作性考虑：无。
Security considerations: See Section 11.1 of [RFC7252].
安全注意事项：见[RFC7252]第11.1节。
The "coap+ws" URI scheme identifies CoAP resources that are intended to be accessible using CoAP over WebSockets.
“coap+ws”URI方案标识了打算使用coap over WebSocket访问的coap资源。
coap-ws-URI = "coap+ws:" "//" host [ ":" port ]
path-abempty [ "?" query ]
coap-ws-URI = "coap+ws:" "//" host [ ":" port ]
path-abempty [ "?" query ]
The port subcomponent is OPTIONAL. The default is port 80.
端口子组件是可选的。默认值为端口80。
The WebSocket endpoint is identified by a "ws" URI that is composed of the authority part of the "coap+ws" URI and the well-known path "/.well-known/coap" [RFC5785] [RFC8307]. Within the endpoint specified in a "coap+ws" URI, the path and query parts of the URI identify a resource that can be operated on by the methods defined by CoAP:
WebSocket端点由“ws”URI标识，该URI由“coap+ws”URI的授权部分和已知路径“/.well-known/coap”[RFC5785][RFC8307]组成。在“coap+ws”URI中指定的端点内，URI的路径和查询部分标识可由coap定义的方法操作的资源：
coap+ws://example.org/sensors/temperature?u=Cel
\______ ______/\___________ ___________/
\/ \/
Uri-Path: "sensors"
ws://example.org/.well-known/coap Uri-Path: "temperature"
Uri-Query: "u=Cel"
coap+ws://example.org/sensors/temperature?u=Cel
\______ ______/\___________ ___________/
\/ \/
Uri-Path: "sensors"
ws://example.org/.well-known/coap Uri-Path: "temperature"
Uri-Query: "u=Cel"
Figure 15: The "coap+ws" URI Scheme
图15：“coap+ws”URI方案
Encoding considerations: The scheme encoding conforms to the encoding rules established for URIs in [RFC3986].
编码注意事项：方案编码符合[RFC3986]中为URI建立的编码规则。
Interoperability considerations: None.
互操作性考虑：无。
Security considerations: See Section 11.1 of [RFC7252].
安全注意事项：见[RFC7252]第11.1节。
The "coaps+ws" URI scheme identifies CoAP resources that are intended to be accessible using CoAP over WebSockets secured by TLS.
“CoAP+ws”URI方案标识了打算通过TLS保护的WebSocket上的CoAP访问的CoAP资源。
coaps-ws-URI = "coaps+ws:" "//" host [ ":" port ]
path-abempty [ "?" query ]
coaps-ws-URI = "coaps+ws:" "//" host [ ":" port ]
path-abempty [ "?" query ]
The port subcomponent is OPTIONAL. The default is port 443.
端口子组件是可选的。默认为端口443。
The WebSocket endpoint is identified by a "wss" URI that is composed of the authority part of the "coaps+ws" URI and the well-known path "/.well-known/coap" [RFC5785] [RFC8307]. Within the endpoint specified in a "coaps+ws" URI, the path and query parts of the URI identify a resource that can be operated on by the methods defined by CoAP:
WebSocket端点由“wss”URI标识，该URI由“coaps+ws”URI的授权部分和已知路径“/.well-known/coap”[RFC5785][RFC8307]组成。在“CoAP+ws”URI中指定的端点内，URI的路径和查询部分标识可由CoAP定义的方法操作的资源：
coaps+ws://example.org/sensors/temperature?u=Cel
\______ ______/\___________ ___________/
\/ \/
Uri-Path: "sensors"
wss://example.org/.well-known/coap Uri-Path: "temperature"
Uri-Query: "u=Cel"
coaps+ws://example.org/sensors/temperature?u=Cel
\______ ______/\___________ ___________/
\/ \/
Uri-Path: "sensors"
wss://example.org/.well-known/coap Uri-Path: "temperature"
Uri-Query: "u=Cel"
Figure 16: The "coaps+ws" URI Scheme
图16：“coaps+ws”URI方案
Encoding considerations: The scheme encoding conforms to the encoding rules established for URIs in [RFC3986].
编码注意事项：方案编码符合[RFC3986]中为URI建立的编码规则。
Interoperability considerations: None.
互操作性考虑：无。
Security considerations: See Section 11.1 of [RFC7252].
安全注意事项：见[RFC7252]第11.1节。
CoAP over reliable transports maintains the property from Section 5.10.1 of [RFC7252]:
CoAP over reliable transports维护[RFC7252]第5.10.1节中的财产：
The default values for the Uri-Host and Uri-Port Options are sufficient for requests to most servers.
Uri主机和Uri端口选项的默认值足以满足大多数服务器的请求。
Unless otherwise noted, the default value of the Uri-Host Option is the IP literal representing the destination IP address of the request message. The default value of the Uri-Port Option is the destination TCP port.
除非另有说明，否则Uri主机选项的默认值是表示请求消息的目标IP地址的IP文本。Uri端口选项的默认值是目标TCP端口。
For CoAP over TLS, these default values are the same, unless Server Name Indication (SNI) [RFC6066] is negotiated. In this case, the default value of the Uri-Host Option in requests from the TLS client to the TLS server is the SNI host.
对于TLS上的CoAP，这些默认值是相同的，除非协商服务器名称指示（SNI）[RFC6066]。在这种情况下，从TLS客户端到TLS服务器的请求中Uri主机选项的默认值是SNI主机。
For CoAP over WebSockets, the default value of the Uri-Host Option in requests from the WebSocket client to the WebSocket server is indicated by the Host header field from the WebSocket handshake.
对于CoAP over WebSocket，WebSocket握手中的主机头字段表示从WebSocket客户端到WebSocket服务器的请求中Uri主机选项的默认值。
The steps are the same as those specified in Section 6.4 of [RFC7252], with minor changes:
这些步骤与[RFC7252]第6.4节中规定的步骤相同，但有一些细微的变化：
This step from [RFC7252]:
此步骤来自[RFC7252]：
3. If |url| does not have a <scheme> component whose value, when converted to ASCII lowercase, is "coap" or "coaps", then fail this algorithm.
3. 如果| url |没有一个<scheme>组件，其值在转换为ASCII小写时为“coap”或“coap”，则此算法失败。
is updated to:
更新至：
3. If |url| does not have a <scheme> component whose value, when converted to ASCII lowercase, is "coap+tcp", "coaps+tcp", "coap+ws", or "coaps+ws", then fail this algorithm.
3. 如果| url |没有一个<scheme>组件，其值在转换为ASCII小写时为“coap+tcp”、“coap+tcp”、“coap+ws”或“coap+ws”，则此算法失败。
This step from [RFC7252]:
此步骤来自[RFC7252]：
7. If |port| does not equal the request's destination UDP port, include a Uri-Port Option and let that option's value be |port|.
7. 如果| port |不等于请求的目标UDP端口，请包含Uri端口选项，并将该选项的值设为| port |。
is updated to:
更新至：
7. If |port| does not equal the request's destination TCP port, include a Uri-Port Option and let that option's value be |port|.
7. 如果| port |不等于请求的目标TCP端口，请包括一个Uri端口选项，并让该选项的值为| port |。
The steps are the same as those specified in Section 6.5 of [RFC7252], with minor changes:
这些步骤与[RFC7252]第6.5节中规定的步骤相同，但有一些细微的变化：
This step from [RFC7252]:
此步骤来自[RFC7252]：
1. If the request is secured using DTLS, let |url| be the string "coaps://". Otherwise, let |url| be the string "coap://".
1. 如果请求是使用DTLS保护的，则将| url |设为字符串“coaps://”。否则，将| url |设为字符串“coap://”。
is updated to:
更新至：
1. For CoAP over TCP, if the request is secured using TLS, let |url| be the string "coaps+tcp://". Otherwise, let |url| be the string "coap+tcp://". For CoAP over WebSockets, if the request is secured using TLS, let |url| be the string "coaps+ws://". Otherwise, let |url| be the string "coap+ws://".
1. 对于TCP上的CoAP，如果使用TLS保护请求，则将| url |设为字符串“CoAP+TCP://”。否则，将| url |设为字符串“coap+tcp://”。对于WebSockets上的CoAP，如果请求使用TLS进行保护，则将| url |设为字符串“coaps+ws://”。否则，将| url |设为字符串“coap+ws://”。
This step from [RFC7252]:
此步骤来自[RFC7252]：
4. If the request includes a Uri-Port Option, let |port| be that option's value. Otherwise, let |port| be the request's destination UDP port.
4. 如果请求包含Uri端口选项，则将| Port |作为该选项的值。否则，将| port |作为请求的目标UDP端口。
is updated to:
更新至：
4. If the request includes a Uri-Port Option, let |port| be that option's value. Otherwise, let |port| be the request's destination TCP port.
4. 如果请求包含Uri端口选项，则将| Port |作为该选项的值。否则，将| port |作为请求的目标TCP端口。
"Security Challenges For the Internet Of Things" [SecurityChallenges] recommends the following:
“物联网的安全挑战”[SecurityChallenges]建议如下：
... it is essential that IoT protocol suites specify a mandatory to implement but optional to use security solution. This will ensure security is available in all implementations, but configurable to use when not necessary (e.g., in closed environment). ... even if those features stretch the capabilities of such devices.
... 物联网协议套件必须指定强制实施但可选使用的安全解决方案。这将确保安全性在所有实现中都可用，但可配置为在不必要时使用（例如，在封闭环境中）。。。即使这些功能扩展了此类设备的功能。
A security solution MUST be implemented to protect CoAP over reliable transports and MUST be enabled by default. This document defines the TLS binding, but alternative solutions at different layers in the protocol stack MAY be used to protect CoAP over reliable transports
必须实施安全解决方案以通过可靠传输保护CoAP，并且必须在默认情况下启用。本文档定义了TLS绑定，但协议栈中不同层的替代解决方案可用于通过可靠传输保护CoAP
when appropriate. Note that there is ongoing work to support a data-object-based security model for CoAP that is independent of transport (see [OSCORE]).
在适当的时候。请注意，目前正在开展工作，以支持独立于传输的基于数据对象的CoAP安全模型（请参见[OSCORE]）。
The TLS usage guidance in [RFC7925] applies, including the guidance about cipher suites in that document that are derived from the mandatory-to-implement cipher suites defined in [RFC7252].
[RFC7925]中的TLS使用指南适用，包括该文档中关于密码套件的指南，该指南源自[RFC7252]中定义的强制实施密码套件。
This guidance assumes implementation in a constrained device or for communication with a constrained device. However, CoAP over TCP/TLS has a wider applicability. It may, for example, be implemented on a gateway or on a device that is less constrained (such as a smart phone or a tablet), for communication with a peer that is likewise less constrained, or within a back-end environment that only communicates with constrained devices via proxies. As an exception to the previous paragraph, in this case, the recommendations in [RFC7525] are more appropriate.
本指南假设在受约束设备中实施或与受约束设备通信。然而，TCP/TLS上的CoAP具有更广泛的适用性。例如，它可以在网关或约束较少的设备（例如智能手机或平板电脑）上实现，用于与约束较少的对等方通信，或者在仅通过代理与约束设备通信的后端环境中实现。作为上一段的例外，在这种情况下，[RFC7525]中的建议更合适。
Since the guidance offered in [RFC7925] differs from the guidance offered in [RFC7525] in terms of algorithms and credential types, it is assumed that an implementation of CoAP over TCP/TLS that needs to support both cases implements the recommendations offered by both specifications.
由于[RFC7925]中提供的指南在算法和凭证类型方面与[RFC7525]中提供的指南不同，因此假设需要支持这两种情况的TCP/TLS上的CoAP实现实现了两种规范提供的建议。
During the provisioning phase, a CoAP device is provided with the security information that it needs, including keying materials, access control lists, and authorization servers. At the end of the provisioning phase, the device will be in one of four security modes:
在配置阶段，CoAP设备将获得其所需的安全信息，包括密钥材料、访问控制列表和授权服务器。在资源调配阶段结束时，设备将处于四种安全模式之一：
NoSec: TLS is disabled.
NOSC:TLS已禁用。
PreSharedKey: TLS is enabled. The guidance in Section 4.2 of [RFC7925] applies.
预共享密钥：TLS已启用。[RFC7925]第4.2节中的指南适用。
RawPublicKey: TLS is enabled. The guidance in Section 4.3 of [RFC7925] applies.
RawPublicKey:TLS已启用。[RFC7925]第4.3节中的指南适用。
Certificate: TLS is enabled. The guidance in Section 4.4 of [RFC7925] applies.
证书：TLS已启用。[RFC7925]第4.4节中的指南适用。
The "NoSec" mode is optional to implement. The system simply sends the packets over normal TCP; this is indicated by the "coap+tcp" scheme and the TCP CoAP default port. The system is secured only by keeping attackers from being able to send or receive packets from the network with the CoAP nodes.
“NOSC”模式是可选的。系统只需通过普通TCP发送数据包；这由“coap+tcp”方案和tcp coap默认端口表示。只有通过阻止攻击者通过CoAP节点从网络发送或接收数据包，才能保护系统。
"PreSharedKey", "RawPublicKey", or "Certificate" is mandatory to implement for the TLS binding, depending on the credential type used with the device. These security modes are achieved using TLS and are indicated by the "coaps+tcp" scheme and TLS-secured CoAP default port.
根据设备使用的凭据类型，必须为TLS绑定实现“预共享密钥”、“RawPublicKey”或“证书”。这些安全模式是使用TLS实现的，由“CoAP+tcp”方案和TLS安全的CoAP默认端口表示。
A CoAP client requesting a resource identified by a "coaps+ws" URI negotiates a secure WebSocket connection to a WebSocket server endpoint with a "wss" URI. This is described in Section 8.4.
CoAP客户端请求由“coaps+ws”URI标识的资源，用“wss”URI协商到WebSocket服务器端点的安全WebSocket连接。第8.4节对此进行了说明。
The client MUST perform a TLS handshake after opening the connection to the server. The guidance in Section 4.1 of [RFC6455] applies. When a CoAP server exposes resources identified by a "coaps+ws" URI, the guidance in Section 4.4 of [RFC7925] applies towards mandatory-to-implement TLS functionality for certificates. For the server-side requirements for accepting incoming connections over an HTTPS (HTTP over TLS) port, the guidance in Section 4.2 of [RFC6455] applies.
客户端必须在打开与服务器的连接后执行TLS握手。[RFC6455]第4.1节中的指南适用。当CoAP服务器公开由“CoAP+ws”URI标识的资源时，[RFC7925]第4.4节中的指南适用于强制实施证书的TLS功能。对于通过HTTPS（HTTP over TLS）端口接受传入连接的服务器端要求，[RFC6455]第4.2节中的指南适用。
Note that the guidance above formally inherits the mandatory-to-implement cipher suites defined in [RFC5246]. However, modern browsers usually implement cipher suites that are more recent; these cipher suites are then automatically picked up via the JavaScript WebSocket API. WebSocket servers that provide secure CoAP over WebSockets for the browser use case will need to follow the browser preferences and MUST follow [RFC7525].
请注意，上述指南正式继承了实现[RFC5246]中定义的密码套件的强制要求。然而，现代浏览器通常实现较新的密码套件；然后通过JavaScript WebSocket API自动获取这些密码套件。为浏览器用例提供安全CoAP over WebSocket的WebSocket服务器需要遵循浏览器首选项，并且必须遵循[RFC7525]。
The security considerations of [RFC7252] apply. For CoAP over WebSockets and CoAP over TLS-secured WebSockets, the security considerations of [RFC6455] also apply.
The security considerations of [RFC7252] apply. For CoAP over WebSockets and CoAP over TLS-secured WebSockets, the security considerations of [RFC6455] also apply.translate error, please retry
The guidance given by an Alternative-Address Option cannot be followed blindly. In particular, a peer MUST NOT assume that a successful connection to the Alternative-Address inherits all the security properties of the current connection.
不能盲目遵循备选地址选项提供的指导。特别是，对等方不能假定到备用地址的成功连接继承了当前连接的所有安全属性。
IANA has created a third subregistry for values of the Code field in the CoAP header (Section 12.1 of [RFC7252]). The name of this subregistry is "CoAP Signaling Codes".
IANA已经为CoAP标题中的代码字段值创建了第三个子区域（RFC7252第12.1节）。该子区域的名称为“CoAP信号代码”。
Each entry in the subregistry must include the Signaling Code in the range 7.00-7.31, its name, and a reference to its documentation.
子区域中的每个条目必须包括7.00-7.31范围内的信号代码、名称及其文件参考。
Initial entries in this subregistry are as follows:
本次区域的初始条目如下：
+------+---------+-----------+
| Code | Name | Reference |
+------+---------+-----------+
| 7.01 | CSM | RFC 8323 |
| | | |
| 7.02 | Ping | RFC 8323 |
| | | |
| 7.03 | Pong | RFC 8323 |
| | | |
| 7.04 | Release | RFC 8323 |
| | | |
| 7.05 | Abort | RFC 8323 |
+------+---------+-----------+
+------+---------+-----------+
| Code | Name | Reference |
+------+---------+-----------+
| 7.01 | CSM | RFC 8323 |
| | | |
| 7.02 | Ping | RFC 8323 |
| | | |
| 7.03 | Pong | RFC 8323 |
| | | |
| 7.04 | Release | RFC 8323 |
| | | |
| 7.05 | Abort | RFC 8323 |
+------+---------+-----------+
Table 1: CoAP Signaling Codes
表1:CoAP信令代码
All other Signaling Codes are Unassigned.
所有其他信号代码均未分配。
The IANA policy for future additions to this subregistry is "IETF Review" or "IESG Approval" as described in [RFC8126].
本次区域未来新增的IANA政策为[RFC8126]中所述的“IETF审查”或“IESG批准”。
IANA has created a subregistry for Option Numbers used in CoAP Signaling Options within the "Constrained RESTful Environments (CoRE) Parameters" registry. The name of this subregistry is "CoAP Signaling Option Numbers".
IANA在“受限RESTful环境（核心）参数”注册表中为CoAP信令选项中使用的选项编号创建了一个子区域。该子区域的名称为“CoAP信令选项编号”。
Each entry in the subregistry must include one or more of the codes in the "CoAP Signaling Codes" subregistry (Section 11.1), the number for the Option, the name of the Option, and a reference to the Option's documentation.
子区域中的每个条目必须包括“CoAP信号代码”子区域（第11.1节）中的一个或多个代码、选项编号、选项名称以及选项文件参考。
Initial entries in this subregistry are as follows:
本次区域的初始条目如下：
+------------+--------+---------------------+-----------+
| Applies to | Number | Name | Reference |
+------------+--------+---------------------+-----------+
| 7.01 | 2 | Max-Message-Size | RFC 8323 |
| | | | |
| 7.01 | 4 | Block-Wise-Transfer | RFC 8323 |
| | | | |
| 7.02, 7.03 | 2 | Custody | RFC 8323 |
| | | | |
| 7.04 | 2 | Alternative-Address | RFC 8323 |
| | | | |
| 7.04 | 4 | Hold-Off | RFC 8323 |
| | | | |
| 7.05 | 2 | Bad-CSM-Option | RFC 8323 |
+------------+--------+---------------------+-----------+
+------------+--------+---------------------+-----------+
| Applies to | Number | Name | Reference |
+------------+--------+---------------------+-----------+
| 7.01 | 2 | Max-Message-Size | RFC 8323 |
| | | | |
| 7.01 | 4 | Block-Wise-Transfer | RFC 8323 |
| | | | |
| 7.02, 7.03 | 2 | Custody | RFC 8323 |
| | | | |
| 7.04 | 2 | Alternative-Address | RFC 8323 |
| | | | |
| 7.04 | 4 | Hold-Off | RFC 8323 |
| | | | |
| 7.05 | 2 | Bad-CSM-Option | RFC 8323 |
+------------+--------+---------------------+-----------+
Table 2: CoAP Signaling Option Codes
表2:CoAP信令选项代码
The IANA policy for future additions to this subregistry is based on number ranges for the option numbers, analogous to the policy defined in Section 12.2 of [RFC7252]. (The policy is analogous rather than identical because the structure of this subregistry includes an additional column ("Applies to"); however, the value of this column has no influence on the policy.)
本次区域未来新增的IANA政策基于选项编号的编号范围，类似于[RFC7252]第12.2节中定义的政策。（该政策是类似的，而不是完全相同的，因为该子地区的结构包括一个附加列（“适用”）；但是，该列的值对该政策没有影响。）
The documentation for a Signaling Option Number should specify the semantics of an option with that number, including the following properties:
信令选项编号的文档应指定具有该编号的选项的语义，包括以下属性：
o Whether the option is critical or elective, as determined by the Option Number.
o 选项是关键选项还是可选选项，取决于选项编号。
o Whether the option is repeatable.
o 该选项是否可重复。
o The format and length of the option's value.
o 选项值的格式和长度。
o The base value for the option, if any.
o 选项的基值（如果有）。
IANA has assigned the port number 5683 and the service name "coap", in accordance with [RFC6335].
IANA已根据[RFC6335]分配了端口号5683和服务名称“coap”。
Service Name: coap
服务名称：coap
Transport Protocol: tcp
传输协议：tcp
Assignee:
IESG <iesg@ietf.org>
Assignee:
IESG <iesg@ietf.org>
Contact:
IETF Chair <chair@ietf.org>
Contact:
IETF Chair <chair@ietf.org>
Description: Constrained Application Protocol (CoAP)
描述：受约束应用程序协议（CoAP）
Reference: RFC 8323
参考：RFC 8323
Port Number: 5683
端口号：5683
IANA has assigned the port number 5684 and the service name "coaps", in accordance with [RFC6335]. The port number is to address the exceptional case of TLS implementations that do not support the ALPN extension [RFC7301].
IANA已根据[RFC6335]分配了端口号5684和服务名称“coaps”。端口号用于解决不支持ALPN扩展的TLS实现的例外情况[RFC7301]。
Service Name: coaps
服务名称：coaps
Transport Protocol: tcp
传输协议：tcp
Assignee:
IESG <iesg@ietf.org>
Assignee:
IESG <iesg@ietf.org>
Contact:
IETF Chair <chair@ietf.org>
Contact:
IETF Chair <chair@ietf.org>
Description: Constrained Application Protocol (CoAP)
描述：受约束应用程序协议（CoAP）
Reference: [RFC7301], RFC 8323
参考文献：[RFC7301]，RFC 8323
Port Number: 5684
端口号：5684
URI schemes are registered within the "Uniform Resource Identifier (URI) Schemes" registry maintained at [IANA.uri-schemes].
URI方案在[IANA.URI schemes]维护的“统一资源标识符（URI）方案”注册表中注册。
Note: The following has been added as a note for each of the URI schemes defined in this document:
注意：以下内容已添加为本文档中定义的每个URI方案的注意事项：
CoAP registers different URI schemes for accessing CoAP resources via different protocols. This approach runs counter to the WWW principle that a URI identifies a resource and that multiple URIs for identifying the same resource should be avoided <https://www.w3.org/TR/webarch/#avoid-uri-aliases>.
CoAP注册不同的URI方案，用于通过不同的协议访问CoAP资源。这种方法与WWW原则背道而驰，即URI标识一个资源，并且应避免使用多个URI标识同一资源<https://www.w3.org/TR/webarch/#avoid-uri别名>。
This is not a problem for many of the usage scenarios envisioned for CoAP over reliable transports; additional URI schemes can be introduced to address additional usage scenarios (as being prepared, for example, in [Multi-Transport-URIs] and [CoAP-Alt-Transports]).
这对于CoAP在可靠传输上的许多使用场景来说都不是问题；可以引入额外的URI方案来解决额外的使用场景（例如，在[Multi-Transport URI]和[CoAP Alt Transports]中准备的）。
IANA has registered the URI scheme "coap+tcp". This registration request complies with [RFC7595].
IANA已注册URI方案“coap+tcp”。此注册请求符合[RFC7595]。
Scheme name: coap+tcp
方案名称：coap+tcp
Status: Permanent
地位：永久
Applications/protocols that use this scheme name: The scheme is used by CoAP endpoints to access CoAP resources using TCP.
使用此方案名称的应用程序/协议：CoAP端点使用该方案使用TCP访问CoAP资源。
Contact:
IETF Chair <chair@ietf.org>
Contact:
IETF Chair <chair@ietf.org>
Change controller:
IESG <iesg@ietf.org>
Change controller:
IESG <iesg@ietf.org>
Reference: Section 8.1 in RFC 8323
参考：RFC 8323第8.1节
IANA has registered the URI scheme "coaps+tcp". This registration request complies with [RFC7595].
IANA已注册URI方案“coaps+tcp”。此注册请求符合[RFC7595]。
Scheme name: coaps+tcp
方案名称：coaps+tcp
Status: Permanent
地位：永久
Applications/protocols that use this scheme name: The scheme is used by CoAP endpoints to access CoAP resources using TLS.
使用此方案名称的应用程序/协议：CoAP端点使用该方案使用TLS访问CoAP资源。
Contact:
IETF Chair <chair@ietf.org>
Contact:
IETF Chair <chair@ietf.org>
Change controller:
IESG <iesg@ietf.org>
Change controller:
IESG <iesg@ietf.org>
Reference: Section 8.2 in RFC 8323
参考：RFC 8323第8.2节
IANA has registered the URI scheme "coap+ws". This registration request complies with [RFC7595].
IANA已注册URI方案“coap+ws”。此注册请求符合[RFC7595]。
Scheme name: coap+ws
方案名称：coap+ws
Status: Permanent
地位：永久
Applications/protocols that use this scheme name: The scheme is used by CoAP endpoints to access CoAP resources using the WebSocket Protocol.
使用此方案名称的应用程序/协议：CoAP端点使用该方案使用WebSocket协议访问CoAP资源。
Contact:
IETF Chair <chair@ietf.org>
Contact:
IETF Chair <chair@ietf.org>
Change controller:
IESG <iesg@ietf.org>
Change controller:
IESG <iesg@ietf.org>
Reference: Section 8.3 in RFC 8323
参考：RFC 8323第8.3节
IANA has registered the URI scheme "coaps+ws". This registration request complies with [RFC7595].
IANA已经注册了URI方案“coaps+ws”。此注册请求符合[RFC7595]。
Scheme name: coaps+ws
方案名称：coaps+ws
Status: Permanent
地位：永久
Applications/protocols that use this scheme name: The scheme is used by CoAP endpoints to access CoAP resources using the WebSocket Protocol secured with TLS.
使用此方案名称的应用程序/协议：CoAP端点使用该方案，使用TLS保护的WebSocket协议访问CoAP资源。
Contact:
IETF Chair <chair@ietf.org>
Contact:
IETF Chair <chair@ietf.org>
Change controller:
IESG <iesg@ietf.org>
Change controller:
IESG <iesg@ietf.org>
References: Section 8.4 in RFC 8323
参考：RFC 8323第8.4节
IANA has registered "coap" in the "Well-Known URIs" registry. This registration request complies with [RFC5785].
IANA已在“知名URI”注册表中注册了“coap”。此注册请求符合[RFC5785]。
URI suffix: coap
URI后缀：coap
Change controller: IETF
更改控制器：IETF
Specification document(s): RFC 8323
规范文件：RFC 8323
Related information: None.
相关信息：无。
IANA has assigned the following value in the "Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry created by [RFC7301]. The "coap" string identifies CoAP when used over TLS.
IANA在[RFC7301]创建的“应用层协议协商（ALPN）协议ID”注册表中分配了以下值。在TLS上使用时，“coap”字符串标识coap。
Protocol: CoAP
协议：CoAP
Identification Sequence: 0x63 0x6f 0x61 0x70 ("coap")
标识顺序：0x63 0x6f 0x61 0x70（“coap”）
Reference: RFC 8323
参考：RFC 8323
IANA has registered the WebSocket CoAP subprotocol in the "WebSocket Subprotocol Name Registry":
IANA已在“WebSocket子目录名称注册表”中注册WebSocket CoAP子目录：
Subprotocol Identifier: coap
次级方案标识符：coap
Subprotocol Common Name: Constrained Application Protocol (CoAP)
子策略通用名称：受限应用程序协议（CoAP）
Subprotocol Definition: RFC 8323
次级方案定义：RFC 8323
IANA has added this document as a reference for the following entries registered by [RFC7959] in the "CoAP Option Numbers" subregistry defined by [RFC7252]:
IANA已添加本文件，作为[RFC7959]在[RFC7252]定义的“CoAP选项编号”子地区注册的以下条目的参考：
+--------+--------+--------------------+
| Number | Name | Reference |
+--------+--------+--------------------+
| 23 | Block2 | RFC 7959, RFC 8323 |
| | | |
| 27 | Block1 | RFC 7959, RFC 8323 |
+--------+--------+--------------------+
+--------+--------+--------------------+
| Number | Name | Reference |
+--------+--------+--------------------+
| 23 | Block2 | RFC 7959, RFC 8323 |
| | | |
| 27 | Block1 | RFC 7959, RFC 8323 |
+--------+--------+--------------------+
Table 3: CoAP Option Numbers
表3:CoAP选项编号
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，DOI 10.17487/RFC0793，1981年9月<https://www.rfc-editor.org/info/rfc793>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://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, <https://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月<https://www.rfc-editor.org/info/rfc3986>.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<https://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, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<https://www.rfc-editor.org/info/rfc5246>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010, <https://www.rfc-editor.org/info/rfc5785>.
[RFC5785]诺丁汉，M.和E.Hammer Lahav，“定义众所周知的统一资源标识符（URI）”，RFC 5785，DOI 10.17487/RFC5785，2010年4月<https://www.rfc-editor.org/info/rfc5785>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.
[RFC6066]Eastlake 3rd，D.，“传输层安全（TLS）扩展：扩展定义”，RFC 6066，DOI 10.17487/RFC6066，2011年1月<https://www.rfc-editor.org/info/rfc6066>.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, <https://www.rfc-editor.org/info/rfc6455>.
[RFC6455]Fette，I.和A.Melnikov，“WebSocket协议”，RFC 6455，DOI 10.17487/RFC6455，2011年12月<https://www.rfc-editor.org/info/rfc6455>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.
[RFC7252]Shelby，Z.，Hartke，K.，和C.Bormann，“受限应用协议（CoAP）”，RFC 7252，DOI 10.17487/RFC7252，2014年6月<https://www.rfc-editor.org/info/rfc7252>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7301]Friedl，S.，Popov，A.，Langley，A.，和E.Stephan，“传输层安全（TLS）应用层协议协商扩展”，RFC 7301，DOI 10.17487/RFC7301，2014年7月<https://www.rfc-editor.org/info/rfc7301>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<https://www.rfc-editor.org/info/rfc7525>.
[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, <https://www.rfc-editor.org/info/rfc7595>.
[RFC7595]Thaler，D.，Ed.，Hansen，T.和T.Hardie，“URI方案的指南和注册程序”，BCP 35，RFC 7595，DOI 10.17487/RFC7595，2015年6月<https://www.rfc-editor.org/info/rfc7595>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, <https://www.rfc-editor.org/info/rfc7641>.
[RFC7641]Hartke，K.，“受限应用协议（CoAP）中的观测资源”，RFC 7641，DOI 10.17487/RFC7641，2015年9月<https://www.rfc-editor.org/info/rfc7641>.
[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, <https://www.rfc-editor.org/info/rfc7925>.
[RFC7925]Tschofenig，H.，Ed.，和T.Fossati，“物联网的传输层安全（TLS）/数据报传输层安全（DTLS）配置文件”，RFC 7925，DOI 10.17487/RFC79252016年7月<https://www.rfc-editor.org/info/rfc7925>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, <https://www.rfc-editor.org/info/rfc7959>.
[RFC7959]Bormann，C.和Z.Shelby，编辑，“受限应用协议（CoAP）中的分块传输”，RFC 7959，DOI 10.17487/RFC7959，2016年8月<https://www.rfc-editor.org/info/rfc7959>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8307] Bormann, C., "Well-Known URIs for the WebSocket Protocol", RFC 8307, DOI 10.17487/RFC8307, January 2018, <https://www.rfc-editor.org/info/rfc8307>.
[RFC8307]Bormann，C.，“WebSocket协议的著名URI”，RFC 8307，DOI 10.17487/RFC8307，2018年1月<https://www.rfc-editor.org/info/rfc8307>.
[BK2015] Byrne, C. and J. Kleberg, "Advisory Guidelines for UDP Deployment", Work in Progress, draft-byrne-opsec-udp-advisory-00, July 2015.
[BK2015]Byrne，C.和J.Kleberg，“UDP部署咨询指南”，正在进行的工作，草稿-Byrne-opsec-UDP-Advisory-00，2015年7月。
[CoAP-Alt-Transports] Silverajan, B. and T. Savolainen, "CoAP Communication with Alternative Transports", Work in Progress, draft-silverajan-core-coap-alternative-transports-10, July 2017.
[CoAP Alt Transports]Silverajan，B.和T.Savolainen，“CoAP与替代运输的通信”，正在进行的工作，草稿-Silverajan-core-CoAP-Alternative-Transports-10，2017年7月。
[CoCoA] Bormann, C., Betzler, A., Gomez, C., and I. Demirkol, "CoAP Simple Congestion Control/Advanced", Work in Progress, draft-ietf-core-cocoa-02, October 2017.
[CoCoA]Bormann，C.，Betzler，A.，Gomez，C.，和I.Demirkol，“CoAP简单拥塞控制/高级”，正在进行的工作，草稿-ietf-core-CoCoA-02，2017年10月。
[EK2016] Edeline, K., Kuehlewind, M., Trammell, B., Aben, E., and B. Donnet, "Using UDP for Internet Transport Evolution", arXiv preprint 1612.07816, December 2016, <https://arxiv.org/abs/1612.07816>.
[EK2016]Edeline，K.，Kuehlewind，M.，Trammell，B.，Aben，E.，和B.Donnet，“使用UDP进行互联网传输演进”，arXiv预印本1612.07816，2016年12月<https://arxiv.org/abs/1612.07816>.
[HomeGateway] Haetoenen, S., Nyrhinen, A., Eggert, L., Strowes, S., Sarolahti, P., and N. Kojo, "An experimental study of home gateway characteristics", Proceedings of the 10th ACM SIGCOMM conference on Internet measurement, DOI 10.1145/1879141.1879174, November 2010.
[HomeGateway]Haetonen，S.，Nyrhinen，A.，Eggert，L.，Strowes，S.，Sarolahti，P.，和N.Kojo，“家庭网关特性的实验研究”，第十届ACM SIGCOMM互联网测量会议记录，DOI 10.1145/1879141.18791742010年11月。
[IANA.uri-schemes] IANA, "Uniform Resource Identifier (URI) Schemes", <https://www.iana.org/assignments/uri-schemes>.
[IANA.uri方案]IANA，“统一资源标识符（uri）方案”<https://www.iana.org/assignments/uri-schemes>.
[LWM2M] Open Mobile Alliance, "Lightweight Machine to Machine Technical Specification Version 1.0", February 2017, <http://www.openmobilealliance.org/release/LightweightM2M/ V1_0-20170208-A/ OMA-TS-LightweightM2M-V1_0-20170208-A.pdf>.
[LWM2M]开放式移动联盟，“轻量级机器对机器技术规范1.0版”，2017年2月<http://www.openmobilealliance.org/release/LightweightM2M/ V1_0-20170208-A/OMA-TS-LightweightM2M-V1_0-20170208-A.pdf>。
[Multi-Transport-URIs] Thaler, D., "Using URIs With Multiple Transport Stacks", Work in Progress, draft-thaler-appsawg-multi-transport-uris-01, July 2017.
[Multi-Transport URI]Thaler，D.，“使用具有多个传输堆栈的URI”，正在进行的工作，draft-Thaler-appsawg-Multi-Transport-URI-012017年7月。
[OSCORE] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", Work in Progress, draft-ietf-core-object-security-08, January 2018.
[OSCORE]Selander，G.，Mattsson，J.，Palombini，F.，和L.Seitz，“受限RESTful环境的对象安全（OSCORE）”，正在进行的工作，草稿-ietf-core-Object-Security-082018年1月。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.
[RFC768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，DOI 10.17487/RFC0768，1980年8月<https://www.rfc-editor.org/info/rfc768>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>.
[RFC6335]Cotton，M.，Eggert，L.，Touch，J.，Westerlund，M.，和S.Cheshire，“互联网分配号码管理局（IANA）服务名称和传输协议端口号注册管理程序”，BCP 165，RFC 6335，DOI 10.17487/RFC6335，2011年8月<https://www.rfc-editor.org/info/rfc6335>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，DOI 10.17487/RFC6347，2012年1月<https://www.rfc-editor.org/info/rfc6347>.
[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, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<https://www.rfc-editor.org/info/rfc7230>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <https://www.rfc-editor.org/info/rfc7540>.
[RFC7540]Belshe，M.，Paon，R.，和M.Thomson，编辑，“超文本传输协议版本2（HTTP/2）”，RFC 7540，DOI 10.17487/RFC7540，2015年5月<https://www.rfc-editor.org/info/rfc7540>.
[SecurityChallenges] Polk, T. and S. Turner, "Security Challenges For the Internet Of Things", Interconnecting Smart Objects with the Internet / IAB Workshop, February 2011, <https://www.iab.org/wp-content/IAB-uploads/2011/03/ Turner.pdf>.
[SecurityChallenges]Polk，T.和S.Turner，“物联网的安全挑战”，智能对象与互联网互连/IAB研讨会，2011年2月<https://www.iab.org/wp-content/IAB-uploads/2011/03/ 特纳.pdf>。
[SW2016] Swett, I., "QUIC Deployment Experience @Google", IETF 96 Proceedings, Berlin, Germany, July 2016, <https://www.ietf.org/proceedings/96/slides/ slides-96-quic-3.pdf>.
[SW2016]Swett，I.，“QUIC部署体验@谷歌”，IETF 96会议记录，德国柏林，2016年7月<https://www.ietf.org/proceedings/96/slides/ 幻灯片-96-quic-3.pdf>。
[TCP-in-IoT] Gomez, C., Crowcroft, J., and M. Scharf, "TCP Usage Guidance in the Internet of Things (IoT)", Work in Progress, draft-ietf-lwig-tcp-constrained-node-networks-01, October 2017.
[物联网中的TCP]Gomez，C.，Crowcroft，J.，和M.Scharf，“物联网（IoT）中的TCP使用指南”，正在进行的工作，草稿-ietf-lwig-TCP-constrained-node-networks-012017年10月。
This appendix gives examples for the first two configurations discussed in Section 4.
本附录给出了第4节中讨论的前两种配置的示例。
An example of the process followed by a CoAP client to retrieve the representation of a resource identified by a "coap+ws" URI might be as follows. Figure 17 below illustrates the WebSocket and CoAP messages exchanged in detail.
CoAP客户端检索由“CoAP+ws”URI标识的资源表示的过程示例如下。下面的图17详细说明了交换的WebSocket和CoAP消息。
1. The CoAP client obtains the URI <coap+ws://example.org/sensors/temperature?u=Cel>, for example, from a resource representation that it retrieved previously.
1. 例如，CoAP客户端从之前检索到的资源表示中获取URI<CoAP+ws://example.org/sensors/temperature？u=Cel>。
2. The CoAP client establishes a WebSocket connection to the endpoint URI composed of the authority "example.org" and the well-known path "/.well-known/coap", <ws://example.org/.well-known/coap>.
2. CoAP客户端建立到端点URI的WebSocket连接，该端点URI由权限“example.org”和众所周知的路径“/.well-known/CoAP”<ws://example.org/.well-known/CoAP>组成。
3. CSMs (Section 5.3) are exchanged (not shown).
3. 交换CSM（第5.3节）（未显示）。
4. The CoAP client sends a single-frame, masked, binary message containing a CoAP request. The request indicates the target resource with the Uri-Path ("sensors", "temperature") and Uri-Query ("u=Cel") Options.
4. CoAP客户端发送包含CoAP请求的单帧屏蔽二进制消息。该请求使用Uri路径（“传感器”、“温度”）和Uri查询（“u=Cel”）选项指示目标资源。
5. The CoAP client waits for the server to return a response.
5. CoAP客户端等待服务器返回响应。
6. The CoAP client uses the connection for further requests, or the connection is closed.
6. CoAP客户端使用该连接进行进一步请求，或者该连接已关闭。
CoAP CoAP Client Server (WebSocket (WebSocket Client) Server)
CoAP CoAP客户端服务器（WebSocket（WebSocket客户端）服务器）
| |
| |
+=========>| GET /.well-known/coap HTTP/1.1
| | Host: example.org
| | Upgrade: websocket
| | Connection: Upgrade
| | Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
| | Sec-WebSocket-Protocol: coap
| | Sec-WebSocket-Version: 13
| |
|<=========+ HTTP/1.1 101 Switching Protocols
| | Upgrade: websocket
| | Connection: Upgrade
| | Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
| | Sec-WebSocket-Protocol: coap
: :
:<-------->: Exchange of CSMs (not shown)
| |
+--------->| Binary frame (opcode=%x2, FIN=1, MASK=1)
| | +-------------------------+
| | | GET |
| | | Token: 0x53 |
| | | Uri-Path: "sensors" |
| | | Uri-Path: "temperature" |
| | | Uri-Query: "u=Cel" |
| | +-------------------------+
| |
|<---------+ Binary frame (opcode=%x2, FIN=1, MASK=0)
| | +-------------------------+
| | | 2.05 Content |
| | | Token: 0x53 |
| | | Payload: "22.3 Cel" |
| | +-------------------------+
: :
: :
+--------->| Close frame (opcode=%x8, FIN=1, MASK=1)
| |
|<---------+ Close frame (opcode=%x8, FIN=1, MASK=0)
| |
| |
| |
+=========>| GET /.well-known/coap HTTP/1.1
| | Host: example.org
| | Upgrade: websocket
| | Connection: Upgrade
| | Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
| | Sec-WebSocket-Protocol: coap
| | Sec-WebSocket-Version: 13
| |
|<=========+ HTTP/1.1 101 Switching Protocols
| | Upgrade: websocket
| | Connection: Upgrade
| | Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
| | Sec-WebSocket-Protocol: coap
: :
:<-------->: Exchange of CSMs (not shown)
| |
+--------->| Binary frame (opcode=%x2, FIN=1, MASK=1)
| | +-------------------------+
| | | GET |
| | | Token: 0x53 |
| | | Uri-Path: "sensors" |
| | | Uri-Path: "temperature" |
| | | Uri-Query: "u=Cel" |
| | +-------------------------+
| |
|<---------+ Binary frame (opcode=%x2, FIN=1, MASK=0)
| | +-------------------------+
| | | 2.05 Content |
| | | Token: 0x53 |
| | | Payload: "22.3 Cel" |
| | +-------------------------+
: :
: :
+--------->| Close frame (opcode=%x8, FIN=1, MASK=1)
| |
|<---------+ Close frame (opcode=%x8, FIN=1, MASK=0)
| |
Figure 17: A CoAP Client Retrieves the Representation of a Resource Identified by a "coap+ws" URI
图17:CoAP客户端检索由“CoAP+ws”URI标识的资源的表示形式
Figure 18 shows how a CoAP client uses a CoAP forward proxy with a WebSocket endpoint to retrieve the representation of the resource "coap://[2001:db8::1]/". The use of the forward proxy and the address of the WebSocket endpoint are determined by the client from local configuration rules. The request URI is specified in the Proxy-Uri Option. Since the request URI uses the "coap" URI scheme, the proxy fulfills the request by issuing a Confirmable GET request over UDP to the CoAP server and returning the response over the WebSocket connection to the client.
图18显示了CoAP客户端如何使用带有WebSocket端点的CoAP转发代理来检索资源“CoAP://[2001:db8:：1]/”的表示形式。转发代理的使用和WebSocket端点的地址由客户端根据本地配置规则确定。请求URI在代理URI选项中指定。由于请求URI使用“coap”URI方案，因此代理通过UDP向coap服务器发出可确认的GET请求，并通过WebSocket连接将响应返回给客户端，从而完成请求。
CoAP CoAP CoAP Client Proxy Server (WebSocket (WebSocket (UDP Client) Server) Endpoint)
CoAP CoAP CoAP客户端代理服务器（WebSocket（WebSocket（UDP客户端）服务器）端点）
| | |
+--------->| | Binary frame (opcode=%x2, FIN=1, MASK=1)
| | | +------------------------------------+
| | | | GET |
| | | | Token: 0x7d |
| | | | Proxy-Uri: "coap://[2001:db8::1]/" |
| | | +------------------------------------+
| | |
| +--------->| CoAP message (Ver=1, T=Con, MID=0x8f54)
| | | +------------------------------------+
| | | | GET |
| | | | Token: 0x0a15 |
| | | +------------------------------------+
| | |
| |<---------+ CoAP message (Ver=1, T=Ack, MID=0x8f54)
| | | +------------------------------------+
| | | | 2.05 Content |
| | | | Token: 0x0a15 |
| | | | Payload: "ready" |
| | | +------------------------------------+
| | |
|<---------+ | Binary frame (opcode=%x2, FIN=1, MASK=0)
| | | +------------------------------------+
| | | | 2.05 Content |
| | | | Token: 0x7d |
| | | | Payload: "ready" |
| | | +------------------------------------+
| | |
| | |
+--------->| | Binary frame (opcode=%x2, FIN=1, MASK=1)
| | | +------------------------------------+
| | | | GET |
| | | | Token: 0x7d |
| | | | Proxy-Uri: "coap://[2001:db8::1]/" |
| | | +------------------------------------+
| | |
| +--------->| CoAP message (Ver=1, T=Con, MID=0x8f54)
| | | +------------------------------------+
| | | | GET |
| | | | Token: 0x0a15 |
| | | +------------------------------------+
| | |
| |<---------+ CoAP message (Ver=1, T=Ack, MID=0x8f54)
| | | +------------------------------------+
| | | | 2.05 Content |
| | | | Token: 0x0a15 |
| | | | Payload: "ready" |
| | | +------------------------------------+
| | |
|<---------+ | Binary frame (opcode=%x2, FIN=1, MASK=0)
| | | +------------------------------------+
| | | | 2.05 Content |
| | | | Token: 0x7d |
| | | | Payload: "ready" |
| | | +------------------------------------+
| | |
Figure 18: A CoAP Client Retrieves the Representation of a Resource Identified by a "coap" URI via a WebSocket-Enabled CoAP Proxy
图18:CoAP客户端通过启用WebSocket的CoAP代理检索由“CoAP”URI标识的资源表示
Acknowledgments
致谢
We would like to thank Stephen Berard, Geoffrey Cristallo, Olivier Delaby, Esko Dijk, Christian Groves, Nadir Javed, Michael Koster, Achim Kraus, David Navarro, Szymon Sasin, Goeran Selander, Zach Shelby, Andrew Summers, Julien Vermillard, and Gengyu Wei for their feedback.
我们要感谢斯蒂芬·伯拉德、杰弗里·克里斯塔洛、奥利维尔·德拉比、埃斯科·迪克、克里斯蒂安·格罗夫斯、纳迪尔·贾维德、迈克尔·科斯特、阿奇姆·克劳斯、大卫·纳瓦罗、西蒙·萨辛、戈兰·塞兰德、扎克·谢尔比、安德鲁·萨默斯、朱利安·维米拉德和魏根玉的反馈。
Last Call reviews from Yoshifumi Nishida, Mark Nottingham, and Meral Shirazipour as well as several IESG reviewers provided extensive comments; from the IESG, we would like to specifically call out Ben Campbell, Mirja Kuehlewind, Eric Rescorla, Adam Roach, and the responsible AD Alexey Melnikov.
西田佳文、马克·诺丁汉和梅拉尔·西拉齐普尔以及几位IESG评论员的最后一次电话评论提供了广泛的评论；在IESG中，我们要特别指出本·坎贝尔、米尔贾·库勒温德、埃里克·雷科拉、亚当·罗奇和负责的广告人阿列克谢·梅尔尼科夫。
Contributors
贡献者
Matthias Kovatsch Siemens AG Otto-Hahn-Ring 6 Munich D-81739 Germany
Matthias Kovatsch西门子公司奥托哈恩环6慕尼黑D-81739德国
Phone: +49-173-5288856
Email: matthias.kovatsch@siemens.com
Phone: +49-173-5288856
Email: matthias.kovatsch@siemens.com
Teemu Savolainen Nokia Technologies Hatanpaan valtatie 30 Tampere FI-33100 Finland
Teemu Savolainen诺基亚技术公司Hatanpaan valtatie 30 Tampere FI-33100芬兰
Email: teemu.savolainen@nokia.com
Email: teemu.savolainen@nokia.com
Valik Solorzano Barboza Zebra Technologies 820 W. Jackson Blvd. Suite 700 Chicago, IL 60607 United States of America
Valik Solorzano Barboza Zebra Technologies，杰克逊大道西820号。美国伊利诺伊州芝加哥700号套房60607
Phone: +1-847-634-6700
Email: vsolorzanobarboza@zebra.com
Phone: +1-847-634-6700
Email: vsolorzanobarboza@zebra.com
Authors' Addresses
作者地址
Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany
卡斯滕·鲍曼大学不来梅邮政学院330440不来梅D-28359德国
Phone: +49-421-218-63921
Email: cabo@tzi.org
Phone: +49-421-218-63921
Email: cabo@tzi.org
Simon Lemay Zebra Technologies 820 W. Jackson Blvd. Suite 700 Chicago, IL 60607 United States of America
西蒙·莱梅·斑马科技公司，杰克逊大道西820号。美国伊利诺伊州芝加哥700号套房60607
Phone: +1-847-634-6700
Email: slemay@zebra.com
Phone: +1-847-634-6700
Email: slemay@zebra.com
Hannes Tschofenig ARM Ltd. 110 Fulbourn Road Cambridge CB1 9NJ United Kingdom
Hannes Tschofenig ARM Ltd.英国剑桥CB1 9NJ富尔伯恩路110号
Email: Hannes.tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Email: Hannes.tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Klaus Hartke Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany
克劳斯·哈特克大学不来梅邮政学院330440不来梅D-28359德国
Phone: +49-421-218-63905
Email: hartke@tzi.org
Phone: +49-421-218-63905
Email: hartke@tzi.org
Bilhanan Silverajan Tampere University of Technology Korkeakoulunkatu 10 Tampere FI-33720 Finland
比哈南·西尔维拉贾坦佩雷理工大学Kokkououkkutu 10坦佩雷FI-36720芬兰
Email: bilhanan.silverajan@tut.fi
Email: bilhanan.silverajan@tut.fi
Brian Raymor (editor)
布莱恩·雷莫（编辑）
Email: brianraymor@hotmail.com
Email: brianraymor@hotmail.com