Internet Engineering Task Force (IETF) Z. Shelby
Request for Comments: 7252 ARM
Category: Standards Track K. Hartke
ISSN: 2070-1721 C. Bormann
Universitaet Bremen TZI
June 2014
Internet Engineering Task Force (IETF) Z. Shelby
Request for Comments: 7252 ARM
Category: Standards Track K. Hartke
ISSN: 2070-1721 C. Bormann
Universitaet Bremen TZI
June 2014
The Constrained Application Protocol (CoAP)
受约束应用程序协议（CoAP）
Abstract
摘要
The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation.
受限应用协议（CoAP）是一种专门的web传输协议，用于受限节点和受限（例如，低功耗、有损）网络。节点通常有8位微控制器，带有少量ROM和RAM，而受限网络，如低功率无线个人区域网络（6LoWPANs）上的IPv6，通常具有高分组错误率和10s kbit/s的典型吞吐量。该协议设计用于机器对机器（M2M）应用，如智能能源和楼宇自动化。
CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.
CoAP提供应用程序端点之间的请求/响应交互模型，支持内置的服务和资源发现，并包括Web的关键概念，如URI和Internet媒体类型。CoAP的设计目的是方便地与HTTP接口，以便与Web集成，同时满足特定的需求，如多播支持、非常低的开销以及受限环境的简单性。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7252.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7252.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Features . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Constrained Application Protocol . . . . . . . . . . . . . . 10
2.1. Messaging Model . . . . . . . . . . . . . . . . . . . . . 11
2.2. Request/Response Model . . . . . . . . . . . . . . . . . 12
2.3. Intermediaries and Caching . . . . . . . . . . . . . . . 15
2.4. Resource Discovery . . . . . . . . . . . . . . . . . . . 15
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Option Value Formats . . . . . . . . . . . . . . . . . . 19
4. Message Transmission . . . . . . . . . . . . . . . . . . . . 20
4.1. Messages and Endpoints . . . . . . . . . . . . . . . . . 20
4.2. Messages Transmitted Reliably . . . . . . . . . . . . . . 21
4.3. Messages Transmitted without Reliability . . . . . . . . 23
4.4. Message Correlation . . . . . . . . . . . . . . . . . . . 24
4.5. Message Deduplication . . . . . . . . . . . . . . . . . . 24
4.6. Message Size . . . . . . . . . . . . . . . . . . . . . . 25
4.7. Congestion Control . . . . . . . . . . . . . . . . . . . 26
4.8. Transmission Parameters . . . . . . . . . . . . . . . . . 27
4.8.1. Changing the Parameters . . . . . . . . . . . . . . . 27
4.8.2. Time Values Derived from Transmission Parameters . . 28
5. Request/Response Semantics . . . . . . . . . . . . . . . . . 31
5.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.1. Piggybacked . . . . . . . . . . . . . . . . . . . . . 33
5.2.2. Separate . . . . . . . . . . . . . . . . . . . . . . 33
5.2.3. Non-confirmable . . . . . . . . . . . . . . . . . . . 34
5.3. Request/Response Matching . . . . . . . . . . . . . . . . 34
5.3.1. Token . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3.2. Request/Response Matching Rules . . . . . . . . . . . 35
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Features . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Constrained Application Protocol . . . . . . . . . . . . . . 10
2.1. Messaging Model . . . . . . . . . . . . . . . . . . . . . 11
2.2. Request/Response Model . . . . . . . . . . . . . . . . . 12
2.3. Intermediaries and Caching . . . . . . . . . . . . . . . 15
2.4. Resource Discovery . . . . . . . . . . . . . . . . . . . 15
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Option Value Formats . . . . . . . . . . . . . . . . . . 19
4. Message Transmission . . . . . . . . . . . . . . . . . . . . 20
4.1. Messages and Endpoints . . . . . . . . . . . . . . . . . 20
4.2. Messages Transmitted Reliably . . . . . . . . . . . . . . 21
4.3. Messages Transmitted without Reliability . . . . . . . . 23
4.4. Message Correlation . . . . . . . . . . . . . . . . . . . 24
4.5. Message Deduplication . . . . . . . . . . . . . . . . . . 24
4.6. Message Size . . . . . . . . . . . . . . . . . . . . . . 25
4.7. Congestion Control . . . . . . . . . . . . . . . . . . . 26
4.8. Transmission Parameters . . . . . . . . . . . . . . . . . 27
4.8.1. Changing the Parameters . . . . . . . . . . . . . . . 27
4.8.2. Time Values Derived from Transmission Parameters . . 28
5. Request/Response Semantics . . . . . . . . . . . . . . . . . 31
5.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.1. Piggybacked . . . . . . . . . . . . . . . . . . . . . 33
5.2.2. Separate . . . . . . . . . . . . . . . . . . . . . . 33
5.2.3. Non-confirmable . . . . . . . . . . . . . . . . . . . 34
5.3. Request/Response Matching . . . . . . . . . . . . . . . . 34
5.3.1. Token . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3.2. Request/Response Matching Rules . . . . . . . . . . . 35
5.4. Options . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.4.1. Critical/Elective . . . . . . . . . . . . . . . . . . 37
5.4.2. Proxy Unsafe or Safe-to-Forward and NoCacheKey . . . 38
5.4.3. Length . . . . . . . . . . . . . . . . . . . . . . . 38
5.4.4. Default Values . . . . . . . . . . . . . . . . . . . 38
5.4.5. Repeatable Options . . . . . . . . . . . . . . . . . 39
5.4.6. Option Numbers . . . . . . . . . . . . . . . . . . . 39
5.5. Payloads and Representations . . . . . . . . . . . . . . 40
5.5.1. Representation . . . . . . . . . . . . . . . . . . . 40
5.5.2. Diagnostic Payload . . . . . . . . . . . . . . . . . 41
5.5.3. Selected Representation . . . . . . . . . . . . . . . 41
5.5.4. Content Negotiation . . . . . . . . . . . . . . . . . 41
5.6. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.6.1. Freshness Model . . . . . . . . . . . . . . . . . . . 43
5.6.2. Validation Model . . . . . . . . . . . . . . . . . . 43
5.7. Proxying . . . . . . . . . . . . . . . . . . . . . . . . 44
5.7.1. Proxy Operation . . . . . . . . . . . . . . . . . . . 44
5.7.2. Forward-Proxies . . . . . . . . . . . . . . . . . . . 46
5.7.3. Reverse-Proxies . . . . . . . . . . . . . . . . . . . 46
5.8. Method Definitions . . . . . . . . . . . . . . . . . . . 47
5.8.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.8.2. POST . . . . . . . . . . . . . . . . . . . . . . . . 47
5.8.3. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.8.4. DELETE . . . . . . . . . . . . . . . . . . . . . . . 48
5.9. Response Code Definitions . . . . . . . . . . . . . . . . 48
5.9.1. Success 2.xx . . . . . . . . . . . . . . . . . . . . 48
5.9.2. Client Error 4.xx . . . . . . . . . . . . . . . . . . 50
5.9.3. Server Error 5.xx . . . . . . . . . . . . . . . . . . 51
5.10. Option Definitions . . . . . . . . . . . . . . . . . . . 52
5.10.1. Uri-Host, Uri-Port, Uri-Path, and Uri-Query . . . . 53
5.10.2. Proxy-Uri and Proxy-Scheme . . . . . . . . . . . . . 54
5.10.3. Content-Format . . . . . . . . . . . . . . . . . . . 55
5.10.4. Accept . . . . . . . . . . . . . . . . . . . . . . . 55
5.10.5. Max-Age . . . . . . . . . . . . . . . . . . . . . . 55
5.10.6. ETag . . . . . . . . . . . . . . . . . . . . . . . . 56
5.10.7. Location-Path and Location-Query . . . . . . . . . . 57
5.10.8. Conditional Request Options . . . . . . . . . . . . 57
5.10.9. Size1 Option . . . . . . . . . . . . . . . . . . . . 59
6. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.1. coap URI Scheme . . . . . . . . . . . . . . . . . . . . . 59
6.2. coaps URI Scheme . . . . . . . . . . . . . . . . . . . . 60
6.3. Normalization and Comparison Rules . . . . . . . . . . . 61
6.4. Decomposing URIs into Options . . . . . . . . . . . . . . 61
6.5. Composing URIs from Options . . . . . . . . . . . . . . . 62
7. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 64
7.2. Resource Discovery . . . . . . . . . . . . . . . . . . . 64
7.2.1. 'ct' Attribute . . . . . . . . . . . . . . . . . . . 64
5.4. Options . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.4.1. Critical/Elective . . . . . . . . . . . . . . . . . . 37
5.4.2. Proxy Unsafe or Safe-to-Forward and NoCacheKey . . . 38
5.4.3. Length . . . . . . . . . . . . . . . . . . . . . . . 38
5.4.4. Default Values . . . . . . . . . . . . . . . . . . . 38
5.4.5. Repeatable Options . . . . . . . . . . . . . . . . . 39
5.4.6. Option Numbers . . . . . . . . . . . . . . . . . . . 39
5.5. Payloads and Representations . . . . . . . . . . . . . . 40
5.5.1. Representation . . . . . . . . . . . . . . . . . . . 40
5.5.2. Diagnostic Payload . . . . . . . . . . . . . . . . . 41
5.5.3. Selected Representation . . . . . . . . . . . . . . . 41
5.5.4. Content Negotiation . . . . . . . . . . . . . . . . . 41
5.6. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.6.1. Freshness Model . . . . . . . . . . . . . . . . . . . 43
5.6.2. Validation Model . . . . . . . . . . . . . . . . . . 43
5.7. Proxying . . . . . . . . . . . . . . . . . . . . . . . . 44
5.7.1. Proxy Operation . . . . . . . . . . . . . . . . . . . 44
5.7.2. Forward-Proxies . . . . . . . . . . . . . . . . . . . 46
5.7.3. Reverse-Proxies . . . . . . . . . . . . . . . . . . . 46
5.8. Method Definitions . . . . . . . . . . . . . . . . . . . 47
5.8.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.8.2. POST . . . . . . . . . . . . . . . . . . . . . . . . 47
5.8.3. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.8.4. DELETE . . . . . . . . . . . . . . . . . . . . . . . 48
5.9. Response Code Definitions . . . . . . . . . . . . . . . . 48
5.9.1. Success 2.xx . . . . . . . . . . . . . . . . . . . . 48
5.9.2. Client Error 4.xx . . . . . . . . . . . . . . . . . . 50
5.9.3. Server Error 5.xx . . . . . . . . . . . . . . . . . . 51
5.10. Option Definitions . . . . . . . . . . . . . . . . . . . 52
5.10.1. Uri-Host, Uri-Port, Uri-Path, and Uri-Query . . . . 53
5.10.2. Proxy-Uri and Proxy-Scheme . . . . . . . . . . . . . 54
5.10.3. Content-Format . . . . . . . . . . . . . . . . . . . 55
5.10.4. Accept . . . . . . . . . . . . . . . . . . . . . . . 55
5.10.5. Max-Age . . . . . . . . . . . . . . . . . . . . . . 55
5.10.6. ETag . . . . . . . . . . . . . . . . . . . . . . . . 56
5.10.7. Location-Path and Location-Query . . . . . . . . . . 57
5.10.8. Conditional Request Options . . . . . . . . . . . . 57
5.10.9. Size1 Option . . . . . . . . . . . . . . . . . . . . 59
6. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.1. coap URI Scheme . . . . . . . . . . . . . . . . . . . . . 59
6.2. coaps URI Scheme . . . . . . . . . . . . . . . . . . . . 60
6.3. Normalization and Comparison Rules . . . . . . . . . . . 61
6.4. Decomposing URIs into Options . . . . . . . . . . . . . . 61
6.5. Composing URIs from Options . . . . . . . . . . . . . . . 62
7. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 64
7.2. Resource Discovery . . . . . . . . . . . . . . . . . . . 64
7.2.1. 'ct' Attribute . . . . . . . . . . . . . . . . . . . 64
8. Multicast CoAP . . . . . . . . . . . . . . . . . . . . . . . 65
8.1. Messaging Layer . . . . . . . . . . . . . . . . . . . . . 65
8.2. Request/Response Layer . . . . . . . . . . . . . . . . . 66
8.2.1. Caching . . . . . . . . . . . . . . . . . . . . . . . 67
8.2.2. Proxying . . . . . . . . . . . . . . . . . . . . . . 67
9. Securing CoAP . . . . . . . . . . . . . . . . . . . . . . . . 68
9.1. DTLS-Secured CoAP . . . . . . . . . . . . . . . . . . . . 69
9.1.1. Messaging Layer . . . . . . . . . . . . . . . . . . . 70
9.1.2. Request/Response Layer . . . . . . . . . . . . . . . 71
9.1.3. Endpoint Identity . . . . . . . . . . . . . . . . . . 71
10. Cross-Protocol Proxying between CoAP and HTTP . . . . . . . . 74
10.1. CoAP-HTTP Proxying . . . . . . . . . . . . . . . . . . . 75
10.1.1. GET . . . . . . . . . . . . . . . . . . . . . . . . 76
10.1.2. PUT . . . . . . . . . . . . . . . . . . . . . . . . 77
10.1.3. DELETE . . . . . . . . . . . . . . . . . . . . . . . 77
10.1.4. POST . . . . . . . . . . . . . . . . . . . . . . . . 77
10.2. HTTP-CoAP Proxying . . . . . . . . . . . . . . . . . . . 77
10.2.1. OPTIONS and TRACE . . . . . . . . . . . . . . . . . 78
10.2.2. GET . . . . . . . . . . . . . . . . . . . . . . . . 78
10.2.3. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 79
10.2.4. POST . . . . . . . . . . . . . . . . . . . . . . . . 79
10.2.5. PUT . . . . . . . . . . . . . . . . . . . . . . . . 79
10.2.6. DELETE . . . . . . . . . . . . . . . . . . . . . . . 80
10.2.7. CONNECT . . . . . . . . . . . . . . . . . . . . . . 80
11. Security Considerations . . . . . . . . . . . . . . . . . . . 80
11.1. Parsing the Protocol and Processing URIs . . . . . . . . 80
11.2. Proxying and Caching . . . . . . . . . . . . . . . . . . 81
11.3. Risk of Amplification . . . . . . . . . . . . . . . . . 81
11.4. IP Address Spoofing Attacks . . . . . . . . . . . . . . 83
11.5. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 84
11.6. Constrained-Node Considerations . . . . . . . . . . . . 86
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86
12.1. CoAP Code Registries . . . . . . . . . . . . . . . . . . 86
12.1.1. Method Codes . . . . . . . . . . . . . . . . . . . . 87
12.1.2. Response Codes . . . . . . . . . . . . . . . . . . . 88
12.2. CoAP Option Numbers Registry . . . . . . . . . . . . . . 89
12.3. CoAP Content-Formats Registry . . . . . . . . . . . . . 91
12.4. URI Scheme Registration . . . . . . . . . . . . . . . . 93
12.5. Secure URI Scheme Registration . . . . . . . . . . . . . 94
12.6. Service Name and Port Number Registration . . . . . . . 95
12.7. Secure Service Name and Port Number Registration . . . . 96
12.8. Multicast Address Registration . . . . . . . . . . . . . 97
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 97
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 98
14.1. Normative References . . . . . . . . . . . . . . . . . . 98
14.2. Informative References . . . . . . . . . . . . . . . . . 100
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 104
Appendix B. URI Examples . . . . . . . . . . . . . . . . . . . . 110
8. Multicast CoAP . . . . . . . . . . . . . . . . . . . . . . . 65
8.1. Messaging Layer . . . . . . . . . . . . . . . . . . . . . 65
8.2. Request/Response Layer . . . . . . . . . . . . . . . . . 66
8.2.1. Caching . . . . . . . . . . . . . . . . . . . . . . . 67
8.2.2. Proxying . . . . . . . . . . . . . . . . . . . . . . 67
9. Securing CoAP . . . . . . . . . . . . . . . . . . . . . . . . 68
9.1. DTLS-Secured CoAP . . . . . . . . . . . . . . . . . . . . 69
9.1.1. Messaging Layer . . . . . . . . . . . . . . . . . . . 70
9.1.2. Request/Response Layer . . . . . . . . . . . . . . . 71
9.1.3. Endpoint Identity . . . . . . . . . . . . . . . . . . 71
10. Cross-Protocol Proxying between CoAP and HTTP . . . . . . . . 74
10.1. CoAP-HTTP Proxying . . . . . . . . . . . . . . . . . . . 75
10.1.1. GET . . . . . . . . . . . . . . . . . . . . . . . . 76
10.1.2. PUT . . . . . . . . . . . . . . . . . . . . . . . . 77
10.1.3. DELETE . . . . . . . . . . . . . . . . . . . . . . . 77
10.1.4. POST . . . . . . . . . . . . . . . . . . . . . . . . 77
10.2. HTTP-CoAP Proxying . . . . . . . . . . . . . . . . . . . 77
10.2.1. OPTIONS and TRACE . . . . . . . . . . . . . . . . . 78
10.2.2. GET . . . . . . . . . . . . . . . . . . . . . . . . 78
10.2.3. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 79
10.2.4. POST . . . . . . . . . . . . . . . . . . . . . . . . 79
10.2.5. PUT . . . . . . . . . . . . . . . . . . . . . . . . 79
10.2.6. DELETE . . . . . . . . . . . . . . . . . . . . . . . 80
10.2.7. CONNECT . . . . . . . . . . . . . . . . . . . . . . 80
11. Security Considerations . . . . . . . . . . . . . . . . . . . 80
11.1. Parsing the Protocol and Processing URIs . . . . . . . . 80
11.2. Proxying and Caching . . . . . . . . . . . . . . . . . . 81
11.3. Risk of Amplification . . . . . . . . . . . . . . . . . 81
11.4. IP Address Spoofing Attacks . . . . . . . . . . . . . . 83
11.5. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 84
11.6. Constrained-Node Considerations . . . . . . . . . . . . 86
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86
12.1. CoAP Code Registries . . . . . . . . . . . . . . . . . . 86
12.1.1. Method Codes . . . . . . . . . . . . . . . . . . . . 87
12.1.2. Response Codes . . . . . . . . . . . . . . . . . . . 88
12.2. CoAP Option Numbers Registry . . . . . . . . . . . . . . 89
12.3. CoAP Content-Formats Registry . . . . . . . . . . . . . 91
12.4. URI Scheme Registration . . . . . . . . . . . . . . . . 93
12.5. Secure URI Scheme Registration . . . . . . . . . . . . . 94
12.6. Service Name and Port Number Registration . . . . . . . 95
12.7. Secure Service Name and Port Number Registration . . . . 96
12.8. Multicast Address Registration . . . . . . . . . . . . . 97
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 97
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 98
14.1. Normative References . . . . . . . . . . . . . . . . . . 98
14.2. Informative References . . . . . . . . . . . . . . . . . 100
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 104
Appendix B. URI Examples . . . . . . . . . . . . . . . . . . . . 110
The use of web services (web APIs) on the Internet has become ubiquitous in most applications and depends on the fundamental Representational State Transfer [REST] architecture of the Web.
在Internet上使用web服务（web API）在大多数应用程序中已经变得无处不在，并且依赖于web的基本表示状态转移[REST]体系结构。
The work on Constrained RESTful Environments (CoRE) aims at realizing the REST architecture in a suitable form for the most constrained nodes (e.g., 8-bit microcontrollers with limited RAM and ROM) and networks (e.g., 6LoWPAN, [RFC4944]). Constrained networks such as 6LoWPAN support the fragmentation of IPv6 packets into small link-layer frames; however, this causes significant reduction in packet delivery probability. One design goal of CoAP has been to keep message overhead small, thus limiting the need for fragmentation.
受限RESTful环境（CoRE）的工作旨在以适当的形式实现REST体系结构，以适用于最受限的节点（例如，RAM和ROM有限的8位微控制器）和网络（例如，6LoWPAN，[RFC4944]）。6LoWPAN等受限网络支持将IPv6数据包分割成较小的链路层帧；然而，这导致了分组交付概率的显著降低。CoAP的一个设计目标是保持较小的消息开销，从而限制对分段的需求。
One of the main goals of CoAP is to design a generic web protocol for the special requirements of this constrained environment, especially considering energy, building automation, and other machine-to-machine (M2M) applications. The goal of CoAP is not to blindly compress HTTP [RFC2616], but rather to realize a subset of REST common with HTTP but optimized for M2M applications. Although CoAP could be used for refashioning simple HTTP interfaces into a more compact protocol, more importantly it also offers features for M2M such as built-in discovery, multicast support, and asynchronous message exchanges.
CoAP的主要目标之一是针对这种受限环境的特殊要求设计通用web协议，特别是考虑能源、楼宇自动化和其他机器对机器（M2M）应用。CoAP的目标不是盲目地压缩HTTP[RFC2616]，而是实现与HTTP通用但针对M2M应用程序优化的REST子集。尽管CoAP可以用于将简单的HTTP接口重构为更紧凑的协议，但更重要的是，它还为M2M提供了内置发现、多播支持和异步消息交换等功能。
This document specifies the Constrained Application Protocol (CoAP), which easily translates to HTTP for integration with the existing Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments and M2M applications.
本文档指定了受限应用程序协议（CoAP），该协议可轻松转换为HTTP，以便与现有Web集成，同时满足特殊要求，如多播支持、非常低的开销以及受限环境和M2M应用程序的简单性。
CoAP has the following main features:
CoAP具有以下主要特点：
o Web protocol fulfilling M2M requirements in constrained environments
o 在受限环境中满足M2M要求的Web协议
o UDP [RFC0768] binding with optional reliability supporting unicast and multicast requests.
o UDP[RFC0768]绑定，具有支持单播和多播请求的可选可靠性。
o Asynchronous message exchanges.
o 异步消息交换。
o Low header overhead and parsing complexity.
o 低头开销和解析复杂性。
o URI and Content-type support.
o URI和内容类型支持。
o Simple proxy and caching capabilities.
o 简单的代理和缓存功能。
o A stateless HTTP mapping, allowing proxies to be built providing access to CoAP resources via HTTP in a uniform way or for HTTP simple interfaces to be realized alternatively over CoAP.
o 一种无状态HTTP映射，允许构建代理，通过HTTP以统一的方式提供对CoAP资源的访问，或者通过CoAP实现HTTP简单接口。
o Security binding to Datagram Transport Layer Security (DTLS) [RFC6347].
o 数据报传输层安全性（DTLS）的安全绑定[RFC6347]。
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 [RFC2119] when they appear in ALL CAPS. These words may also appear in this document in lowercase, absent their normative meanings.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母中出现时，应按照[RFC2119]中的说明进行解释。这些词语也可能以小写形式出现在本文件中，没有其规范意义。
This specification requires readers to be familiar with all the terms and concepts that are discussed in [RFC2616], including "resource", "representation", "cache", and "fresh". (Having been completed before the updated set of HTTP RFCs, RFC 7230 to RFC 7235, became available, this specification specifically references the predecessor version -- RFC 2616.) In addition, this specification defines the following terminology:
本规范要求读者熟悉[RFC2616]中讨论的所有术语和概念，包括“资源”、“表示”、“缓存”和“刷新”。（在更新的HTTP RFC集RFC 7230至RFC 7235可用之前完成，本规范特别引用了先前版本RFC 2616。）此外，本规范定义了以下术语：
Endpoint An entity participating in the CoAP protocol. Colloquially, an endpoint lives on a "Node", although "Host" would be more consistent with Internet standards usage, and is further identified by transport-layer multiplexing information that can include a UDP port number and a security association (Section 4.1).
端点参与CoAP协议的实体。通俗地说，端点位于“节点”上，尽管“主机”更符合互联网标准的使用，并且通过传输层多路复用信息进一步识别，该信息可以包括UDP端口号和安全关联（第4.1节）。
Sender The originating endpoint of a message. When the aspect of identification of the specific sender is in focus, also "source endpoint".
发件人消息的原始端点。当特定发送方的标识方面处于焦点时，也可以使用“源端点”。
Recipient The destination endpoint of a message. When the aspect of identification of the specific recipient is in focus, also "destination endpoint".
收件人消息的目标端点。当特定接收者的标识方面处于焦点时，也可以称为“目的地端点”。
Client The originating endpoint of a request; the destination endpoint of a response.
客户端：请求的发起端点；响应的目标端点。
Server The destination endpoint of a request; the originating endpoint of a response.
服务器请求的目标端点；响应的起始端点。
Origin Server The server on which a given resource resides or is to be created.
源服务器给定资源所在或将要创建的服务器。
Intermediary A CoAP endpoint that acts both as a server and as a client towards an origin server (possibly via further intermediaries). A common form of an intermediary is a proxy; several classes of such proxies are discussed in this specification.
中间层作为服务器和客户端（可能通过其他中间层）作用于源服务器的CoAP端点。中介的一种常见形式是代理；本规范中讨论了几种此类代理。
Proxy An intermediary that mainly is concerned with forwarding requests and relaying back responses, possibly performing caching, namespace translation, or protocol translation in the process. As opposed to intermediaries in the general sense, proxies generally do not implement specific application semantics. Based on the position in the overall structure of the request forwarding, there are two common forms of proxy: forward-proxy and reverse-proxy. In some cases, a single endpoint might act as an origin server, forward-proxy, or reverse-proxy, switching behavior based on the nature of each request.
代理主要负责转发请求和中继回响应的中介，可能在过程中执行缓存、名称空间转换或协议转换。与一般意义上的中介不同，代理通常不实现特定的应用程序语义。根据请求转发在整体结构中的位置，有两种常见的代理形式：正向代理和反向代理。在某些情况下，单个端点可能充当源服务器、转发代理或反向代理，根据每个请求的性质切换行为。
Forward-Proxy An endpoint selected by a client, usually via local configuration rules, to perform requests on behalf of the client, doing any necessary translations. Some translations are minimal, such as for proxy requests for "coap" URIs, whereas other requests might require translation to and from entirely different application-layer protocols.
转发代理客户端选择的端点，通常通过本地配置规则，代表客户端执行请求，执行任何必要的转换。有些转换是最小的，例如对于“coap”uri的代理请求，而其他请求可能需要转换到完全不同的应用层协议或从完全不同的应用层协议转换过来。
Reverse-Proxy An endpoint that stands in for one or more other server(s) and satisfies requests on behalf of these, doing any necessary translations. Unlike a forward-proxy, the client may not be aware that it is communicating with a reverse-proxy; a reverse-proxy receives requests as if it were the origin server for the target resource.
反向代理一个端点，它代表一个或多个其他服务器，并代表这些服务器满足请求，执行任何必要的转换。与正向代理不同，客户端可能不知道它正在与反向代理通信；反向代理接收请求，就像它是目标资源的源服务器一样。
CoAP-to-CoAP Proxy A proxy that maps from a CoAP request to a CoAP request, i.e., uses the CoAP protocol both on the server and the client side. Contrast to cross-proxy.
CoAP到CoAP代理从CoAP请求映射到CoAP请求的代理，即在服务器端和客户端使用CoAP协议。与交叉代理相反。
Cross-Proxy A cross-protocol proxy, or "cross-proxy" for short, is a proxy that translates between different protocols, such as a CoAP-to-HTTP proxy or an HTTP-to-CoAP proxy. While this specification makes very specific demands of CoAP-to-CoAP proxies, there is more variation possible in cross-proxies.
交叉代理跨协议代理，简称“交叉代理”，是在不同协议之间转换的代理，例如CoAP到HTTP代理或HTTP到CoAP代理。虽然本规范对CoAP到CoAP代理提出了非常具体的要求，但在交叉代理中可能存在更多的变化。
Confirmable Message Some messages require an acknowledgement. These messages are called "Confirmable". When no packets are lost, each Confirmable message elicits exactly one return message of type Acknowledgement or type Reset.
可确认消息某些消息需要确认。这些消息称为“可确认”。当没有数据包丢失时，每个可确认消息只会引发一条确认或重置类型的返回消息。
Non-confirmable Message Some other messages do not require an acknowledgement. This is particularly true for messages that are repeated regularly for application requirements, such as repeated readings from a sensor.
不可确认消息其他一些消息不需要确认。对于根据应用要求定期重复的消息，如传感器的重复读数，尤其如此。
Acknowledgement Message An Acknowledgement message acknowledges that a specific Confirmable message arrived. By itself, an Acknowledgement message does not indicate success or failure of any request encapsulated in the Confirmable message, but the Acknowledgement message may also carry a Piggybacked Response (see below).
确认消息确认消息确认特定的可确认消息已到达。就其本身而言，确认消息并不表示封装在可确认消息中的任何请求的成功或失败，但确认消息也可能携带一个附带的响应（见下文）。
Reset Message A Reset message indicates that a specific message (Confirmable or Non-confirmable) was received, but some context is missing to properly process it. This condition is usually caused when the receiving node has rebooted and has forgotten some state that would be required to interpret the message. Provoking a Reset message (e.g., by sending an Empty Confirmable message) is also useful as an inexpensive check of the liveness of an endpoint ("CoAP ping").
重置消息重置消息表示接收到特定消息（可确认或不可确认），但缺少适当处理该消息的上下文。这种情况通常是在接收节点重新启动并且忘记了解释消息所需的某些状态时造成的。激发重置消息（例如，通过发送空的可确认消息）也可用作端点活动性的廉价检查（“CoAP ping”）。
Piggybacked Response A piggybacked Response is included right in a CoAP Acknowledgement (ACK) message that is sent to acknowledge receipt of the Request for this Response (Section 5.2.1).
背驮式响应背驮式响应包含在CoAP确认（ACK）消息中，该消息用于确认收到该响应的请求（第5.2.1节）。
Separate Response When a Confirmable message carrying a request is acknowledged with an Empty message (e.g., because the server doesn't have the answer right away), a Separate Response is sent in a separate message exchange (Section 5.2.2).
单独响应当携带请求的可确认消息被空消息确认时（例如，因为服务器没有立即得到答案），单独的响应在单独的消息交换中发送（第5.2.2节）。
Empty Message A message with a Code of 0.00; neither a request nor a response. An Empty message only contains the 4-byte header.
空消息代码为0.00的消息；既不是请求也不是响应。空消息仅包含4字节头。
Critical Option An option that would need to be understood by the endpoint ultimately receiving the message in order to properly process the message (Section 5.4.1). Note that the implementation of critical options is, as the name "Option" implies, generally optional: unsupported critical options lead to an error response or summary rejection of the message.
关键选项最终接收消息的端点需要理解的选项，以便正确处理消息（第5.4.1节）。请注意，正如“选项”的名称所暗示的，关键选项的实现通常是可选的：不受支持的关键选项会导致错误响应或消息的摘要拒绝。
Elective Option An option that is intended to be ignored by an endpoint that does not understand it. Processing the message even without understanding the option is acceptable (Section 5.4.1).
可选选项不理解它的端点将忽略的选项。即使不了解选项，也可以处理消息（第5.4.1节）。
Unsafe Option An option that would need to be understood by a proxy receiving the message in order to safely forward the message (Section 5.4.2). Not every critical option is an unsafe option.
不安全选项接收消息的代理需要理解的选项，以便安全转发消息（第5.4.2节）。并非每个关键选项都是不安全的选项。
Safe-to-Forward Option An option that is intended to be safe for forwarding by a proxy that does not understand it. Forwarding the message even without understanding the option is acceptable (Section 5.4.2).
安全转发选项一种旨在通过不理解它的代理安全转发的选项。即使不了解选项，也可以转发消息（第5.4.2节）。
Resource Discovery The process where a CoAP client queries a server for its list of hosted resources (i.e., links as defined in Section 7).
资源发现CoAP客户端向服务器查询其托管资源列表（即第7节中定义的链接）的过程。
Content-Format The combination of an Internet media type, potentially with specific parameters given, and a content-coding (which is often the identity content-coding), identified by a numeric identifier defined by the "CoAP Content-Formats" registry. When the focus is less on the numeric identifier than on the combination of these characteristics of a resource representation, this is also called "representation format".
内容格式-互联网媒体类型（可能具有给定的特定参数）和内容编码（通常为标识内容编码）的组合，由“CoAP内容格式”注册表定义的数字标识符标识。当关注的焦点不是数字标识符而是资源表示的这些特征的组合时，这也称为“表示格式”。
Additional terminology for constrained nodes and constrained-node networks can be found in [RFC7228].
受约束节点和受约束节点网络的其他术语见[RFC7228]。
In this specification, the term "byte" is used in its now customary sense as a synonym for "octet".
在本规范中，术语“字节”在其现在的习惯意义上用作“八位字节”的同义词。
All multi-byte integers in this protocol are interpreted in network byte order.
此协议中的所有多字节整数均按网络字节顺序解释。
Where arithmetic is used, this specification uses the notation familiar from the programming language C, except that the operator "**" stands for exponentiation.
在使用算术的情况下，本规范使用编程语言C中熟悉的符号，但运算符“**”表示求幂。
The interaction model of CoAP is similar to the client/server model of HTTP. However, machine-to-machine interactions typically result in a CoAP implementation acting in both client and server roles. A CoAP request is equivalent to that of HTTP and is sent by a client to request an action (using a Method Code) on a resource (identified by a URI) on a server. The server then sends a response with a Response Code; this response may include a resource representation.
CoAP的交互模型类似于HTTP的客户机/服务器模型。但是，机器对机器的交互通常会导致CoAP实现同时扮演客户端和服务器角色。CoAP请求相当于HTTP请求，由客户端发送，以请求对服务器上的资源（由URI标识）执行操作（使用方法代码）。然后，服务器发送带有响应代码的响应；该响应可以包括资源表示。
Unlike HTTP, CoAP deals with these interchanges asynchronously over a datagram-oriented transport such as UDP. This is done logically using a layer of messages that supports optional reliability (with exponential back-off). CoAP defines four types of messages: Confirmable, Non-confirmable, Acknowledgement, Reset. Method Codes and Response Codes included in some of these messages make them carry requests or responses. The basic exchanges of the four types of messages are somewhat orthogonal to the request/response interactions; requests can be carried in Confirmable and Non-confirmable messages, and responses can be carried in these as well as piggybacked in Acknowledgement messages.
与HTTP不同，CoAP通过面向数据报的传输（如UDP）异步处理这些交换。这是通过使用支持可选可靠性（指数退避）的消息层在逻辑上实现的。CoAP定义了四种类型的消息：可确认、不可确认、确认、重置。其中一些消息中包含的方法代码和响应代码使它们携带请求或响应。这四种消息类型的基本交换在某种程度上与请求/响应交互正交；请求可以在可确认和不可确认的消息中进行，响应可以在这些消息中进行，也可以在确认消息中进行。
One could think of CoAP logically as using a two-layer approach, a CoAP messaging layer used to deal with UDP and the asynchronous nature of the interactions, and the request/response interactions using Method and Response Codes (see Figure 1). CoAP is however a single protocol, with messaging and request/response as just features of the CoAP header.
可以将CoAP逻辑上看作是使用两层方法，一个用于处理UDP和交互异步性质的CoAP消息传递层，以及使用方法和响应代码的请求/响应交互（见图1）。然而，CoAP是一个单一的协议，消息传递和请求/响应只是CoAP头的特征。
+----------------------+
| Application |
+----------------------+
+----------------------+ \
| Requests/Responses | |
|----------------------| | CoAP
| Messages | |
+----------------------+ /
+----------------------+
| UDP |
+----------------------+
+----------------------+
| Application |
+----------------------+
+----------------------+ \
| Requests/Responses | |
|----------------------| | CoAP
| Messages | |
+----------------------+ /
+----------------------+
| UDP |
+----------------------+
Figure 1: Abstract Layering of CoAP
图1:CoAP的抽象分层
The CoAP messaging model is based on the exchange of messages over UDP between endpoints.
CoAP消息传递模型基于端点之间通过UDP的消息交换。
CoAP uses a short fixed-length binary header (4 bytes) that may be followed by compact binary options and a payload. This message format is shared by requests and responses. The CoAP message format is specified in Section 3. Each message contains a Message ID used to detect duplicates and for optional reliability. (The Message ID is compact; its 16-bit size enables up to about 250 messages per second from one endpoint to another with default protocol parameters.)
CoAP使用一个短的固定长度二进制报头（4字节），后面可能跟有压缩二进制选项和有效负载。此消息格式由请求和响应共享。第3节规定了CoAP消息格式。每条消息都包含一个用于检测重复项和可选可靠性的消息ID。（消息ID非常紧凑；它的16位大小允许使用默认协议参数每秒从一个端点到另一个端点发送大约250条消息。）
Reliability is provided by marking a message as Confirmable (CON). A Confirmable message is retransmitted using a default timeout and exponential back-off between retransmissions, until the recipient sends an Acknowledgement message (ACK) with the same Message ID (in this example, 0x7d34) from the corresponding endpoint; see Figure 2. When a recipient is not at all able to process a Confirmable message (i.e., not even able to provide a suitable error response), it replies with a Reset message (RST) instead of an Acknowledgement (ACK).
通过将消息标记为可确认（CON）来提供可靠性。使用默认超时和重传之间的指数回退重新传输可确认消息，直到接收方从相应端点发送具有相同消息ID（在本例中为0x7d34）的确认消息（ACK）；参见图2。当收件人根本无法处理可确认的消息（即，甚至无法提供适当的错误响应）时，它会使用重置消息（RST）而不是确认（ACK）进行回复。
Client Server
| |
| CON [0x7d34] |
+----------------->|
| |
| ACK [0x7d34] |
|<-----------------+
| |
Client Server
| |
| CON [0x7d34] |
+----------------->|
| |
| ACK [0x7d34] |
|<-----------------+
| |
Figure 2: Reliable Message Transmission
图2：可靠的消息传输
A message that does not require reliable transmission (for example, each single measurement out of a stream of sensor data) can be sent as a Non-confirmable message (NON). These are not acknowledged, but still have a Message ID for duplicate detection (in this example, 0x01a0); see Figure 3. When a recipient is not able to process a Non-confirmable message, it may reply with a Reset message (RST).
不需要可靠传输的消息（例如，传感器数据流中的每个单独测量值）可以作为不可确认消息（Non）发送。这些未被确认，但仍有用于重复检测的消息ID（在本例中为0x01a0）；参见图3。当收件人无法处理不可确认的邮件时，可以使用重置邮件（RST）进行回复。
Client Server
| |
| NON [0x01a0] |
+----------------->|
| |
Client Server
| |
| NON [0x01a0] |
+----------------->|
| |
Figure 3: Unreliable Message Transmission
图3：不可靠的消息传输
See Section 4 for details of CoAP messages.
有关CoAP消息的详细信息，请参见第4节。
As CoAP runs over UDP, it also supports the use of multicast IP destination addresses, enabling multicast CoAP requests. Section 8 discusses the proper use of CoAP messages with multicast addresses and precautions for avoiding response congestion.
由于CoAP通过UDP运行，它还支持使用多播IP目标地址，从而支持多播CoAP请求。第8节讨论了正确使用具有多播地址的CoAP消息以及避免响应拥塞的预防措施。
Several security modes are defined for CoAP in Section 9 ranging from no security to certificate-based security. This document specifies a binding to DTLS for securing the protocol; the use of IPsec with CoAP is discussed in [IPsec-CoAP].
第9节为CoAP定义了几种安全模式，从无安全到基于证书的安全。本文件规定了与DTLS的绑定，用于保护协议；[IPsec-CoAP]中讨论了IPsec与CoAP的使用。
CoAP request and response semantics are carried in CoAP messages, which include either a Method Code or Response Code, respectively. Optional (or default) request and response information, such as the URI and payload media type are carried as CoAP options. A Token is used to match responses to requests independently from the underlying messages (Section 5.3). (Note that the Token is a concept separate from the Message ID.)
CoAP请求和响应语义包含在CoAP消息中，分别包括方法代码或响应代码。可选（或默认）请求和响应信息（如URI和有效负载媒体类型）作为CoAP选项携带。令牌用于独立于底层消息匹配请求响应（第5.3节）。（请注意，令牌是一个独立于消息ID的概念。）
A request is carried in a Confirmable (CON) or Non-confirmable (NON) message, and, if immediately available, the response to a request carried in a Confirmable message is carried in the resulting Acknowledgement (ACK) message. This is called a piggybacked response, detailed in Section 5.2.1. (There is no need for separately acknowledging a piggybacked response, as the client will retransmit the request if the Acknowledgement message carrying the piggybacked response is lost.) Two examples for a basic GET request with piggybacked response are shown in Figure 4, one successful, one resulting in a 4.04 (Not Found) response.
请求在可确认（CON）或不可确认（Non）消息中进行，如果立即可用，对可确认消息中进行的请求的响应将在生成的确认（ACK）消息中进行。这称为“背负式响应”，详见第5.2.1节。（不需要单独确认搭载响应，因为如果承载搭载响应的确认消息丢失，客户端将重新传输请求。）图4显示了带有搭载响应的基本GET请求的两个示例，一个成功，一个导致4.04（未找到）响应。
Client Server Client Server
| | | |
| CON [0xbc90] | | CON [0xbc91] |
| GET /temperature | | GET /temperature |
| (Token 0x71) | | (Token 0x72) |
+----------------->| +----------------->|
| | | |
| ACK [0xbc90] | | ACK [0xbc91] |
| 2.05 Content | | 4.04 Not Found |
| (Token 0x71) | | (Token 0x72) |
| "22.5 C" | | "Not found" |
|<-----------------+ |<-----------------+
| | | |
Client Server Client Server
| | | |
| CON [0xbc90] | | CON [0xbc91] |
| GET /temperature | | GET /temperature |
| (Token 0x71) | | (Token 0x72) |
+----------------->| +----------------->|
| | | |
| ACK [0xbc90] | | ACK [0xbc91] |
| 2.05 Content | | 4.04 Not Found |
| (Token 0x71) | | (Token 0x72) |
| "22.5 C" | | "Not found" |
|<-----------------+ |<-----------------+
| | | |
Figure 4: Two GET Requests with Piggybacked Responses
图4：两个带有附带响应的GET请求
If the server is not able to respond immediately to a request carried in a Confirmable message, it simply responds with an Empty Acknowledgement message so that the client can stop retransmitting the request. When the response is ready, the server sends it in a new Confirmable message (which then in turn needs to be acknowledged by the client). This is called a "separate response", as illustrated in Figure 5 and described in more detail in Section 5.2.2.
如果服务器无法立即响应可确认消息中包含的请求，它只会响应一条空的确认消息，以便客户端停止重新传输该请求。当响应准备就绪时，服务器将以新的可确认消息的形式发送响应（然后客户端需要确认该消息）。这称为“单独响应”，如图5所示，并在第5.2.2节中详细描述。
Client Server
| |
| CON [0x7a10] |
| GET /temperature |
| (Token 0x73) |
+----------------->|
| |
| ACK [0x7a10] |
|<-----------------+
| |
... Time Passes ...
| |
| CON [0x23bb] |
| 2.05 Content |
| (Token 0x73) |
| "22.5 C" |
|<-----------------+
| |
| ACK [0x23bb] |
+----------------->|
| |
Client Server
| |
| CON [0x7a10] |
| GET /temperature |
| (Token 0x73) |
+----------------->|
| |
| ACK [0x7a10] |
|<-----------------+
| |
... Time Passes ...
| |
| CON [0x23bb] |
| 2.05 Content |
| (Token 0x73) |
| "22.5 C" |
|<-----------------+
| |
| ACK [0x23bb] |
+----------------->|
| |
Figure 5: A GET Request with a Separate Response
图5：带有单独响应的GET请求
If a request is sent in a Non-confirmable message, then the response is sent using a new Non-confirmable message, although the server may instead send a Confirmable message. This type of exchange is illustrated in Figure 6.
如果请求是在不可确认的消息中发送的，则使用新的不可确认消息发送响应，尽管服务器可能会改为发送可确认的消息。这种类型的交换如图6所示。
Client Server
| |
| NON [0x7a11] |
| GET /temperature |
| (Token 0x74) |
+----------------->|
| |
| NON [0x23bc] |
| 2.05 Content |
| (Token 0x74) |
| "22.5 C" |
|<-----------------+
| |
Client Server
| |
| NON [0x7a11] |
| GET /temperature |
| (Token 0x74) |
+----------------->|
| |
| NON [0x23bc] |
| 2.05 Content |
| (Token 0x74) |
| "22.5 C" |
|<-----------------+
| |
Figure 6: A Request and a Response Carried in Non-confirmable Messages
图6：不可确认消息中包含的请求和响应
CoAP makes use of GET, PUT, POST, and DELETE methods in a similar manner to HTTP, with the semantics specified in Section 5.8. (Note that the detailed semantics of CoAP methods are "almost, but not entirely unlike" [HHGTTG] those of HTTP methods: intuition taken from HTTP experience generally does apply well, but there are enough differences that make it worthwhile to actually read the present specification.)
CoAP以类似于HTTP的方式使用GET、PUT、POST和DELETE方法，其语义在第5.8节中指定。（请注意，CoAP方法的详细语义“几乎，但并非完全不同于”[HHGTTG]HTTP方法的语义：从HTTP经验中获得的直觉通常应用得很好，但存在足够多的差异，值得实际阅读本规范。）
Methods beyond the basic four can be added to CoAP in separate specifications. New methods do not necessarily have to use requests and responses in pairs. Even for existing methods, a single request may yield multiple responses, e.g., for a multicast request (Section 8) or with the Observe option [OBSERVE].
基本四种方法之外的方法可以在单独的规范中添加到CoAP中。新方法不一定要成对使用请求和响应。即使对于现有方法，单个请求也可能产生多个响应，例如，对于多播请求（第8节）或使用观察选项[观察]。
URI support in a server is simplified as the client already parses the URI and splits it into host, port, path, and query components, making use of default values for efficiency. Response Codes relate to a small subset of HTTP status codes with a few CoAP-specific codes added, as defined in Section 5.9.
服务器中的URI支持被简化，因为客户端已经解析URI并将其拆分为主机、端口、路径和查询组件，使用默认值提高效率。响应代码与HTTP状态代码的一小部分相关，并添加了一些CoAP特定代码，如第5.9节所定义。
The protocol supports the caching of responses in order to efficiently fulfill requests. Simple caching is enabled using freshness and validity information carried with CoAP responses. A cache could be located in an endpoint or an intermediary. Caching functionality is specified in Section 5.6.
该协议支持缓存响应，以便高效地完成请求。使用CoAP响应附带的新鲜度和有效性信息启用简单缓存。缓存可以位于端点或中介中。第5.6节规定了缓存功能。
Proxying is useful in constrained networks for several reasons, including to limit network traffic, to improve performance, to access resources of sleeping devices, and for security reasons. The proxying of requests on behalf of another CoAP endpoint is supported in the protocol. When using a proxy, the URI of the resource to request is included in the request, while the destination IP address is set to the address of the proxy. See Section 5.7 for more information on proxy functionality.
代理在受限网络中很有用，原因有几个，包括限制网络流量、提高性能、访问休眠设备的资源以及出于安全原因。协议支持代表另一CoAP端点代理请求。使用代理时，请求中包含要请求的资源的URI，而目标IP地址设置为代理的地址。有关代理功能的更多信息，请参见第5.7节。
As CoAP was designed according to the REST architecture [REST], and thus exhibits functionality similar to that of the HTTP protocol, it is quite straightforward to map from CoAP to HTTP and from HTTP to CoAP. Such a mapping may be used to realize an HTTP REST interface using CoAP or to convert between HTTP and CoAP. This conversion can be carried out by a cross-protocol proxy ("cross-proxy"), which converts the Method or Response Code, media type, and options to the corresponding HTTP feature. Section 10 provides more detail about HTTP mapping.
由于CoAP是根据REST体系结构[REST]设计的，因此显示出与HTTP协议类似的功能，因此从CoAP映射到HTTP以及从HTTP映射到CoAP非常简单。这种映射可用于使用CoAP实现HTTP REST接口或在HTTP和CoAP之间转换。此转换可由跨协议代理（“跨代理”）执行，该代理将方法或响应代码、媒体类型和选项转换为相应的HTTP功能。第10节提供了有关HTTP映射的更多详细信息。
Resource discovery is important for machine-to-machine interactions and is supported using the CoRE Link Format [RFC6690] as discussed in Section 7.
资源发现对于机器到机器的交互非常重要，并且如第7节所述，使用核心链接格式[RFC6690]支持资源发现。
CoAP is based on the exchange of compact messages that, by default, are transported over UDP (i.e., each CoAP message occupies the data section of one UDP datagram). CoAP may also be used over Datagram Transport Layer Security (DTLS) (see Section 9.1). It could also be used over other transports such as SMS, TCP, or SCTP, the specification of which is out of this document's scope. (UDP-lite [RFC3828] and UDP zero checksum [RFC6936] are not supported by CoAP.)
CoAP基于默认情况下通过UDP传输的压缩消息交换（即，每个CoAP消息占用一个UDP数据报的数据部分）。CoAP也可用于数据报传输层安全（DTLS）（见第9.1节）。它也可以用于其他传输，如SMS、TCP或SCTP，其规范不在本文档范围内。（CoAP不支持UDP lite[RFC3828]和UDP零校验和[RFC6936]。）
CoAP messages are encoded in a simple binary format. The message format starts with a fixed-size 4-byte header. This is followed by a variable-length Token value, which can be between 0 and 8 bytes long.
CoAP消息以简单的二进制格式编码。消息格式以固定大小的4字节头开始。后面是一个可变长度的标记值，长度可以在0到8字节之间。
Following the Token value comes a sequence of zero or more CoAP Options in Type-Length-Value (TLV) format, optionally followed by a payload that takes up the rest of the datagram.
令牌值之后是一系列零或多个类型长度值（TLV）格式的CoAP选项，可选地后跟占用其余数据报的有效负载。
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 7: Message Format
图7：消息格式
The fields in the header are defined as follows:
标题中的字段定义如下：
Version (Ver): 2-bit unsigned integer. Indicates the CoAP version number. Implementations of this specification MUST set this field to 1 (01 binary). Other values are reserved for future versions. Messages with unknown version numbers MUST be silently ignored.
版本（Ver）：2位无符号整数。指示CoAP版本号。本规范的实现必须将此字段设置为1（01二进制）。其他值保留给将来的版本。具有未知版本号的消息必须以静默方式忽略。
Type (T): 2-bit unsigned integer. Indicates if this message is of type Confirmable (0), Non-confirmable (1), Acknowledgement (2), or Reset (3). The semantics of these message types are defined in Section 4.
类型（T）：2位无符号整数。指示此消息的类型是可确认（0）、不可确认（1）、确认（2）还是重置（3）。第4节定义了这些消息类型的语义。
Token Length (TKL): 4-bit unsigned integer. Indicates the length of the variable-length Token field (0-8 bytes). Lengths 9-15 are reserved, MUST NOT be sent, and MUST be processed as a message format error.
令牌长度（TKL）：4位无符号整数。指示可变长度令牌字段的长度（0-8字节）。长度9-15是保留的，不能发送，必须作为消息格式错误处理。
Code: 8-bit unsigned integer, split into a 3-bit class (most significant bits) and a 5-bit detail (least significant bits), documented as "c.dd" where "c" is a digit from 0 to 7 for the 3-bit subfield and "dd" are two digits from 00 to 31 for the 5-bit subfield. The class can indicate a request (0), a success response (2), a client error response (4), or a server error response (5). (All other class values are reserved.) As a special case, Code 0.00 indicates an Empty message. In case of a request, the Code field indicates the Request Method; in case of a response, a Response Code. Possible values are maintained in the CoAP Code Registries (Section 12.1). The semantics of requests and responses are defined in Section 5.
代码：8位无符号整数，分为3位类（最高有效位）和5位细节（最低有效位），记录为“c.dd”，其中“c”是3位子字段0到7之间的数字，“dd”是5位子字段00到31之间的两位数字。该类可以指示请求（0）、成功响应（2）、客户端错误响应（4）或服务器错误响应（5）。（保留所有其他类值。）作为特殊情况，代码0.00表示空消息。如果是请求，代码字段指示请求方法；如果是响应，则为响应代码。可能的值保存在CoAP代码注册表中（第12.1节）。第5节定义了请求和响应的语义。
Message ID: 16-bit unsigned integer in network byte order. Used to detect message duplication and to match messages of type Acknowledgement/Reset to messages of type Confirmable/Non-confirmable. The rules for generating a Message ID and matching messages are defined in Section 4.
消息ID：网络字节顺序的16位无符号整数。用于检测消息重复，并将确认/重置类型的消息与可确认/不可确认类型的消息相匹配。第4节定义了生成消息ID和匹配消息的规则。
The header is followed by the Token value, which may be 0 to 8 bytes, as given by the Token Length field. The Token value is used to correlate requests and responses. The rules for generating a Token and correlating requests and responses are defined in Section 5.3.1.
标头后面是令牌值，该值可能为0到8字节，如令牌长度字段所示。令牌值用于关联请求和响应。第5.3.1节定义了生成令牌和关联请求与响应的规则。
Header and Token are followed by zero or more Options (Section 3.1). An Option can be followed by the end of the message, by another Option, or by the Payload Marker and the payload.
标头和令牌后面跟着零个或多个选项（第3.1节）。一个选项后面可以是消息的结尾、另一个选项或有效负载标记和有效负载。
Following the header, token, and options, if any, comes the optional payload. If present and of non-zero length, it is prefixed by a fixed, one-byte Payload Marker (0xFF), which indicates the end of options and the start of the payload. The payload data extends from after the marker to the end of the UDP datagram, i.e., the Payload Length is calculated from the datagram size. The absence of the Payload Marker denotes a zero-length payload. The presence of a marker followed by a zero-length payload MUST be processed as a message format error.
在头、令牌和选项（如果有）之后是可选的负载。如果存在且长度非零，则以固定的单字节有效负载标记（0xFF）作为前缀，该标记指示选项的结束和有效负载的开始。有效负载数据从标记后延伸到UDP数据报的末尾，即，有效负载长度根据数据报大小计算。没有有效载荷标记表示零长度有效载荷。标记后跟零长度有效负载的存在必须作为消息格式错误处理。
Implementation Note: The byte value 0xFF may also occur within an option length or value, so simple byte-wise scanning for 0xFF is not a viable technique for finding the payload marker. The byte 0xFF has the meaning of a payload marker only where the beginning of another option could occur.
实现说明：字节值0xFF也可能出现在选项长度或值内，因此简单的按字节扫描0xFF不是查找有效负载标记的可行技术。字节0xFF仅在另一个选项开始时才具有有效负载标记的含义。
CoAP defines a number of options that can be included in a message. Each option instance in a message specifies the Option Number of the defined CoAP option, the length of the Option Value, and the Option Value itself.
CoAP定义了一系列可包含在消息中的选项。消息中的每个选项实例指定定义的CoAP选项的选项编号、选项值的长度以及选项值本身。
Instead of specifying the Option Number directly, the instances MUST appear in order of their Option Numbers and a delta encoding is used between them: the Option Number for each instance is calculated as the sum of its delta and the Option Number of the preceding instance in the message. For the first instance in a message, a preceding option instance with Option Number zero is assumed. Multiple instances of the same option can be included by using a delta of zero.
与直接指定选项号不同，实例必须按其选项号的顺序出现，并在它们之间使用增量编码：每个实例的选项号计算为其增量与消息中前一个实例的选项号之和。对于消息中的第一个实例，假定前面的选项实例的选项号为零。通过使用0的增量，可以包括同一选项的多个实例。
Option Numbers are maintained in the "CoAP Option Numbers" registry (Section 12.2). See Section 5.4 for the semantics of the options defined in this document.
选项编号保存在“CoAP选项编号”注册表中（第12.2节）。有关本文件中定义的选项的语义，请参见第5.4节。
0 1 2 3 4 5 6 7
+---------------+---------------+
| | |
| Option Delta | Option Length | 1 byte
| | |
+---------------+---------------+
\ \
/ Option Delta / 0-2 bytes
\ (extended) \
+-------------------------------+
\ \
/ Option Length / 0-2 bytes
\ (extended) \
+-------------------------------+
\ \
/ /
\ \
/ Option Value / 0 or more bytes
\ \
/ /
\ \
+-------------------------------+
0 1 2 3 4 5 6 7
+---------------+---------------+
| | |
| Option Delta | Option Length | 1 byte
| | |
+---------------+---------------+
\ \
/ Option Delta / 0-2 bytes
\ (extended) \
+-------------------------------+
\ \
/ Option Length / 0-2 bytes
\ (extended) \
+-------------------------------+
\ \
/ /
\ \
/ Option Value / 0 or more bytes
\ \
/ /
\ \
+-------------------------------+
Figure 8: Option Format
图8：选项格式
The fields in an option are defined as follows:
选项中的字段定义如下：
Option Delta: 4-bit unsigned integer. A value between 0 and 12 indicates the Option Delta. Three values are reserved for special constructs:
选项增量：4位无符号整数。介于0和12之间的值表示选项Delta。为特殊构造保留三个值：
13: An 8-bit unsigned integer follows the initial byte and indicates the Option Delta minus 13.
13：初始字节后是一个8位无符号整数，表示Delta减13选项。
14: A 16-bit unsigned integer in network byte order follows the initial byte and indicates the Option Delta minus 269.
14：网络字节顺序的16位无符号整数紧跟在初始字节之后，表示选项Delta减269。
15: Reserved for the Payload Marker. If the field is set to this value but the entire byte is not the payload marker, this MUST be processed as a message format error.
15：为有效负载标记保留。如果该字段设置为该值，但整个字节不是有效负载标记，则必须将其作为消息格式错误处理。
The resulting Option Delta is used as the difference between the Option Number of this option and that of the previous option (or zero for the first option). In other words, the Option Number is calculated by simply summing the Option Delta values of this and all previous options before it.
生成的选项增量用作此选项的选项编号与上一个选项的选项编号之间的差值（或第一个选项为零）。换言之，通过简单地将此选项和之前所有选项的选项增量值相加来计算选项编号。
Option Length: 4-bit unsigned integer. A value between 0 and 12 indicates the length of the Option Value, in bytes. Three values are reserved for special constructs:
选项长度：4位无符号整数。0到12之间的值表示选项值的长度（以字节为单位）。为特殊构造保留三个值：
13: An 8-bit unsigned integer precedes the Option Value and indicates the Option Length minus 13.
13：选项值前有一个8位无符号整数，表示选项长度减13。
14: A 16-bit unsigned integer in network byte order precedes the Option Value and indicates the Option Length minus 269.
14：选项值前有一个网络字节顺序的16位无符号整数，表示选项长度减269。
15: Reserved for future use. If the field is set to this value, it MUST be processed as a message format error.
15：保留供将来使用。如果该字段设置为该值，则必须将其作为消息格式错误处理。
Value: A sequence of exactly Option Length bytes. The length and format of the Option Value depend on the respective option, which MAY define variable-length values. See Section 3.2 for the formats used in this document; options defined in other documents MAY make use of other option value formats.
值：完全由选项长度字节组成的序列。选项值的长度和格式取决于相应的选项，该选项可以定义可变长度值。本文件中使用的格式见第3.2节；其他文档中定义的选项可能使用其他选项值格式。
The options defined in this document make use of the following option value formats.
本文档中定义的选项使用以下选项值格式。
empty: A zero-length sequence of bytes.
空：长度为零的字节序列。
opaque: An opaque sequence of bytes.
不透明的：一个不透明的字节序列。
uint: A non-negative integer that is represented in network byte order using the number of bytes given by the Option Length field.
uint：一个非负整数，使用Option Length字段给定的字节数以网络字节顺序表示。
An option definition may specify a range of permissible numbers of bytes; if it has a choice, a sender SHOULD represent the integer with as few bytes as possible, i.e., without leading zero bytes. For example, the number 0 is represented with an empty option value (a zero-length sequence of bytes) and the number 1 by a single byte with the numerical value of 1 (bit combination 00000001 in most significant bit first notation). A recipient MUST be prepared to process values with leading zero bytes.
选项定义可以指定允许的字节数范围；如果可以选择，发送方应该用尽可能少的字节表示整数，即不前导零字节。例如，数字0用一个空选项值（字节的零长度序列）表示，数字1用一个数字值为1的字节表示（最高有效位优先表示法中的位组合00000001）。收件人必须准备好处理前导为零字节的值。
Implementation Note: The exceptional behavior permitted for the sender is intended for highly constrained, templated implementations (e.g., hardware implementations) that use fixed-size options in the templates.
实现说明：发送方允许的异常行为适用于在模板中使用固定大小选项的高度受限的模板化实现（例如，硬件实现）。
string: A Unicode string that is encoded using UTF-8 [RFC3629] in Net-Unicode form [RFC5198].
字符串：使用UTF-8[RFC3629]以净Unicode格式[RFC5198]编码的Unicode字符串。
Note that here, and in all other places where UTF-8 encoding is used in the CoAP protocol, the intention is that the encoded strings can be directly used and compared as opaque byte strings by CoAP protocol implementations. There is no expectation and no need to perform normalization within a CoAP implementation (except where Unicode strings that are not known to be normalized are imported from sources outside the CoAP protocol). Note also that ASCII strings (that do not make use of special control characters) are always valid UTF-8 Net-Unicode strings.
注意，在这里，以及在CoAP协议中使用UTF-8编码的所有其他地方，目的是编码字符串可以直接使用，并通过CoAP协议实现作为不透明字节字符串进行比较。在CoAP实现中不需要也不需要执行规范化（除非从CoAP协议之外的源导入未被规范化的Unicode字符串）。还要注意，ASCII字符串（不使用特殊控制字符）始终是有效的UTF-8 Net Unicode字符串。
CoAP messages are exchanged asynchronously between CoAP endpoints. They are used to transport CoAP requests and responses, the semantics of which are defined in Section 5.
CoAP消息在CoAP端点之间异步交换。它们用于传输CoAP请求和响应，其语义在第5节中定义。
As CoAP is bound to unreliable transports such as UDP, CoAP messages may arrive out of order, appear duplicated, or go missing without notice. For this reason, CoAP implements a lightweight reliability mechanism, without trying to re-create the full feature set of a transport like TCP. It has the following features:
由于CoAP绑定到不可靠的传输（如UDP），CoAP消息可能会无序到达、出现重复或在未通知的情况下丢失。因此，CoAP实现了一种轻量级的可靠性机制，而无需重新创建TCP等传输的完整功能集。它具有以下特点：
o Simple stop-and-wait retransmission reliability with exponential back-off for Confirmable messages.
o 简单的停止等待重传可靠性，可确认消息具有指数回退功能。
o Duplicate detection for both Confirmable and Non-confirmable messages.
o 可确认和不可确认消息的重复检测。
A CoAP endpoint is the source or destination of a CoAP message. The specific definition of an endpoint depends on the transport being used for CoAP. For the transports defined in this specification, the endpoint is identified depending on the security mode used (see Section 9): With no security, the endpoint is solely identified by an IP address and a UDP port number. With other security modes, the endpoint is identified as defined by the security mode.
CoAP端点是CoAP消息的源或目标。端点的具体定义取决于用于CoAP的传输。对于本规范中定义的传输，端点的标识取决于所使用的安全模式（参见第9节）：在没有安全性的情况下，端点仅由IP地址和UDP端口号标识。对于其他安全模式，端点由安全模式定义。
There are different types of messages. The type of a message is specified by the Type field of the CoAP Header.
有不同类型的消息。消息的类型由CoAP标头的类型字段指定。
Separate from the message type, a message may carry a request, a response, or be Empty. This is signaled by the Request/Response Code field in the CoAP Header and is relevant to the request/response model. Possible values for the field are maintained in the CoAP Code Registries (Section 12.1).
与消息类型不同，消息可以包含请求、响应或空。这由CoAP报头中的请求/响应代码字段发出信号，并与请求/响应模型相关。该字段的可能值保存在CoAP代码注册表中（第12.1节）。
An Empty message has the Code field set to 0.00. The Token Length field MUST be set to 0 and bytes of data MUST NOT be present after the Message ID field. If there are any bytes, they MUST be processed as a message format error.
空消息的代码字段设置为0.00。令牌长度字段必须设置为0，并且消息ID字段后面不能有字节的数据。如果存在任何字节，则必须将其作为消息格式错误处理。
The reliable transmission of a message is initiated by marking the message as Confirmable in the CoAP header. A Confirmable message always carries either a request or response, unless it is used only to elicit a Reset message, in which case it is Empty. A recipient MUST either (a) acknowledge a Confirmable message with an Acknowledgement message or (b) reject the message if the recipient lacks context to process the message properly, including situations where the message is Empty, uses a code with a reserved class (1, 6, or 7), or has a message format error. Rejecting a Confirmable message is effected by sending a matching Reset message and otherwise ignoring it. The Acknowledgement message MUST echo the Message ID of the Confirmable message and MUST carry a response or be Empty (see Sections 5.2.1 and 5.2.2). The Reset message MUST echo the Message ID of the Confirmable message and MUST be Empty. Rejecting an Acknowledgement or Reset message (including the case where the Acknowledgement carries a request or a code with a reserved class, or the Reset message is not Empty) is effected by silently ignoring it. More generally, recipients of Acknowledgement and Reset messages MUST NOT respond with either Acknowledgement or Reset messages.
消息的可靠传输是通过在CoAP报头中将消息标记为可确认来启动的。可确认消息始终携带请求或响应，除非它仅用于引发重置消息，在这种情况下，重置消息为空。收件人必须（A）使用确认消息确认可确认的消息，或（b）如果收件人缺乏正确处理消息的上下文，包括消息为空、使用保留类（1、6或7）的代码或存在消息格式错误，则必须拒绝该消息。拒绝可确认消息是通过发送匹配的重置消息并忽略它来实现的。确认消息必须回显可确认消息的消息ID，并且必须带有响应或为空（见第5.2.1和5.2.2节）。重置消息必须回显可确认消息的消息ID，并且必须为空。拒绝确认或重置消息（包括确认包含保留类的请求或代码，或者重置消息不是空的情况）是通过静默忽略它来实现的。更一般地说，确认和重置消息的接收者不得响应确认或重置消息。
The sender retransmits the Confirmable message at exponentially increasing intervals, until it receives an acknowledgement (or Reset message) or runs out of attempts.
发送方以指数递增的间隔重新传输可确认消息，直到收到确认（或重置消息）或尝试次数不足为止。
Retransmission is controlled by two things that a CoAP endpoint MUST keep track of for each Confirmable message it sends while waiting for an acknowledgement (or reset): a timeout and a retransmission counter. For a new Confirmable message, the initial timeout is set to a random duration (often not an integral number of seconds) between ACK_TIMEOUT and (ACK_TIMEOUT * ACK_RANDOM_FACTOR) (see Section 4.8), and the retransmission counter is set to 0. When the timeout is triggered and the retransmission counter is less than
在等待确认（或重置）时，CoAP端点必须跟踪其发送的每个可确认消息的两项内容来控制重传：超时和重传计数器。对于新的可确认消息，初始超时设置为ACK_timeout和（ACK_timeout*ACK_random_FACTOR）之间的随机持续时间（通常不是整数秒）（参见第4.8节），重传计数器设置为0。当触发超时且重传计数器小于
MAX_RETRANSMIT, the message is retransmitted, the retransmission counter is incremented, and the timeout is doubled. If the retransmission counter reaches MAX_RETRANSMIT on a timeout, or if the endpoint receives a Reset message, then the attempt to transmit the message is canceled and the application process informed of failure. On the other hand, if the endpoint receives an acknowledgement in time, transmission is considered successful.
MAX_RETRANSMIT，消息被重新传输，重新传输计数器递增，超时加倍。如果重新传输计数器在超时时达到MAX_RETRANSMIT，或者如果端点接收到重置消息，则取消发送消息的尝试，并通知应用程序进程失败。另一方面，如果端点及时接收到确认，则认为传输成功。
This specification makes no strong requirements on the accuracy of the clocks used to implement the above binary exponential back-off algorithm. In particular, an endpoint may be late for a specific retransmission due to its sleep schedule and may catch up on the next one. However, the minimum spacing before another retransmission is ACK_TIMEOUT, and the entire sequence of (re-)transmissions MUST stay in the envelope of MAX_TRANSMIT_SPAN (see Section 4.8.2), even if that means a sender may miss an opportunity to transmit.
本规范对用于实现上述二进制指数退避算法的时钟精度没有严格要求。特别是，由于其睡眠时间表，端点可能会延迟进行特定的重新传输，并且可能会赶上下一次。然而，在另一次重传之前的最小间隔是ACK_超时，并且（重新）传输的整个序列必须保持在最大传输跨度的包络内（参见第4.8.2节），即使这意味着发送方可能会错过传输的机会。
A CoAP endpoint that sent a Confirmable message MAY give up in attempting to obtain an ACK even before the MAX_RETRANSMIT counter value is reached. For example, the application has canceled the request as it no longer needs a response, or there is some other indication that the CON message did arrive. In particular, a CoAP request message may have elicited a separate response, in which case it is clear to the requester that only the ACK was lost and a retransmission of the request would serve no purpose. However, a responder MUST NOT in turn rely on this cross-layer behavior from a requester, i.e., it MUST retain the state to create the ACK for the request, if needed, even if a Confirmable response was already acknowledged by the requester.
发送可确认消息的CoAP端点可能会在到达MAX_RETRANSMIT计数器值之前放弃尝试获取ACK。例如，应用程序已取消请求，因为它不再需要响应，或者有其他一些指示表明CON消息确实到达。特别地，CoAP请求消息可能已经引发了单独的响应，在这种情况下，请求者清楚地知道，只有ACK丢失，请求的重新传输没有任何用途。然而，响应者不能反过来依赖请求者的这种跨层行为，也就是说，如果需要，即使请求者已经确认了可确认的响应，响应者也必须保留为请求创建ACK的状态。
Another reason for giving up retransmission MAY be the receipt of ICMP errors. If it is desired to take account of ICMP errors, to mitigate potential spoofing attacks, implementations SHOULD take care to check the information about the original datagram in the ICMP message, including port numbers and CoAP header information such as message type and code, Message ID, and Token; if this is not possible due to limitations of the UDP service API, ICMP errors SHOULD be ignored. Packet Too Big errors [RFC4443] ("fragmentation needed and DF set" for IPv4 [RFC0792]) cannot properly occur and SHOULD be ignored if the implementation note in Section 4.6 is followed; otherwise, they SHOULD feed into a path MTU discovery algorithm [RFC4821]. Source Quench and Time Exceeded ICMP messages SHOULD be ignored. Host, network, port, or protocol unreachable errors or parameter problem errors MAY, after appropriate vetting, be used to inform the application of a failure in sending.
放弃重新传输的另一个原因可能是收到ICMP错误。如果希望考虑ICMP错误，以减轻潜在的欺骗攻击，则实现应注意检查ICMP消息中有关原始数据报的信息，包括端口号和CoAP头信息，如消息类型和代码、消息ID和令牌；如果由于UDP服务API的限制而无法执行此操作，则应忽略ICMP错误。数据包过大错误[RFC4443]（“IPv4[RFC0792]需要碎片和DF设置”）无法正确发生，如果遵循第4.6节中的实施说明，则应忽略该错误；否则，它们应该提供给路径MTU发现算法[RFC4821]。应忽略源猝灭和超出时间的ICMP消息。主机、网络、端口或协议无法访问的错误或参数问题错误在经过适当的检查后，可用于通知应用程序发送失败。
Some messages do not require an acknowledgement. This is particularly true for messages that are repeated regularly for application requirements, such as repeated readings from a sensor where eventual success is sufficient.
有些消息不需要确认。对于根据应用要求定期重复的消息尤其如此，例如从传感器重复读取的信息，如果最终成功就足够了。
As a more lightweight alternative, a message can be transmitted less reliably by marking the message as Non-confirmable. A Non-confirmable message always carries either a request or response and MUST NOT be Empty. A Non-confirmable message MUST NOT be acknowledged by the recipient. A recipient MUST reject the message if it lacks context to process the message properly, including the case where the message is Empty, uses a code with a reserved class (1, 6, or 7), or has a message format error. Rejecting a Non-confirmable message MAY involve sending a matching Reset message, and apart from the Reset message the rejected message MUST be silently ignored.
作为一种更轻量级的替代方案，通过将消息标记为不可确认消息，消息传输的可靠性会降低。不可确认消息始终包含请求或响应，并且不能为空。收件人不得确认不可确认的邮件。如果收件人缺少正确处理邮件的上下文（包括邮件为空、使用带有保留类（1、6或7）的代码或邮件格式错误），则必须拒绝邮件。拒绝不可确认的消息可能涉及发送匹配的重置消息，并且除了重置消息外，必须默默地忽略被拒绝的消息。
At the CoAP level, there is no way for the sender to detect if a Non-confirmable message was received or not. A sender MAY choose to transmit multiple copies of a Non-confirmable message within MAX_TRANSMIT_SPAN (limited by the provisions of Section 4.7, in particular, by PROBING_RATE if no response is received), or the network may duplicate the message in transit. To enable the receiver to act only once on the message, Non-confirmable messages specify a Message ID as well. (This Message ID is drawn from the same number space as the Message IDs for Confirmable messages.)
在CoAP级别，发送方无法检测是否收到了不可确认的消息。发送方可选择在最大传输范围内传输不可确认消息的多个副本（受第4.7节规定的限制，特别是在未收到响应的情况下，通过探测速率），或者网络可在传输过程中复制消息。为了使接收者只对消息执行一次操作，不可确认的消息还指定一个消息ID。（此消息ID与可确认消息的消息ID来自相同的数字空间。）
Summarizing Sections 4.2 and 4.3, the four message types can be used as in Table 1. "*" means that the combination is not used in normal operation but only to elicit a Reset message ("CoAP ping").
总结第4.2节和第4.3节，四种消息类型可如表1所示使用。“*”表示该组合不用于正常操作，而仅用于引发重置消息（“CoAP ping”）。
+----------+-----+-----+-----+-----+
| | CON | NON | ACK | RST |
+----------+-----+-----+-----+-----+
| Request | X | X | - | - |
| Response | X | X | X | - |
| Empty | * | - | X | X |
+----------+-----+-----+-----+-----+
+----------+-----+-----+-----+-----+
| | CON | NON | ACK | RST |
+----------+-----+-----+-----+-----+
| Request | X | X | - | - |
| Response | X | X | X | - |
| Empty | * | - | X | X |
+----------+-----+-----+-----+-----+
Table 1: Usage of Message Types
表1：消息类型的使用
An Acknowledgement or Reset message is related to a Confirmable message or Non-confirmable message by means of a Message ID along with additional address information of the corresponding endpoint. The Message ID is a 16-bit unsigned integer that is generated by the sender of a Confirmable or Non-confirmable message and included in the CoAP header. The Message ID MUST be echoed in the Acknowledgement or Reset message by the recipient.
确认或重置消息通过消息ID以及相应端点的附加地址信息与可确认消息或不可确认消息相关。消息ID是一个16位无符号整数，由可确认或不可确认消息的发送方生成，并包含在CoAP标头中。收件人必须在确认或重置消息中回显消息ID。
The same Message ID MUST NOT be reused (in communicating with the same endpoint) within the EXCHANGE_LIFETIME (Section 4.8.2).
在EXCHANGE_生命周期内（第4.8.2节），不得重复使用相同的消息ID（在与同一端点通信时）。
Implementation Note: Several implementation strategies can be employed for generating Message IDs. In the simplest case, a CoAP endpoint generates Message IDs by keeping a single Message ID variable, which is changed each time a new Confirmable or Non-confirmable message is sent, regardless of the destination address or port. Endpoints dealing with large numbers of transactions could keep multiple Message ID variables, for example, per prefix or destination address. (Note that some receiving endpoints may not be able to distinguish unicast and multicast packets addressed to it, so endpoints generating Message IDs need to make sure these do not overlap.) It is strongly recommended that the initial value of the variable (e.g., on startup) be randomized, in order to make successful off-path attacks on the protocol less likely.
实现说明：可以使用几种实现策略来生成消息ID。在最简单的情况下，CoAP端点通过保留单个消息ID变量来生成消息ID，该变量在每次发送新的可确认或不可确认消息时都会更改，而与目标地址或端口无关。处理大量事务的端点可以保留多个消息ID变量，例如，每个前缀或目标地址。（请注意，某些接收端点可能无法区分发送给它的单播和多播数据包，因此生成消息ID的端点需要确保这些数据包不会重叠。）强烈建议随机化变量的初始值（例如，启动时），以减少对协议进行成功的非路径攻击的可能性。
For an Acknowledgement or Reset message to match a Confirmable or Non-confirmable message, the Message ID and source endpoint of the Acknowledgement or Reset message MUST match the Message ID and destination endpoint of the Confirmable or Non-confirmable message.
要使确认或重置消息与可确认或不可确认消息匹配，确认或重置消息的消息ID和源端点必须与可确认或不可确认消息的消息ID和目标端点匹配。
A recipient might receive the same Confirmable message (as indicated by the Message ID and source endpoint) multiple times within the EXCHANGE_LIFETIME (Section 4.8.2), for example, when its Acknowledgement went missing or didn't reach the original sender before the first timeout. The recipient SHOULD acknowledge each duplicate copy of a Confirmable message using the same Acknowledgement or Reset message but SHOULD process any request or response in the message only once. This rule MAY be relaxed in case the Confirmable message transports a request that is idempotent (see Section 5.1) or can be handled in an idempotent fashion. Examples for relaxed message deduplication:
在EXCHANGE_生命周期内（第4.8.2节），收件人可能多次收到相同的可确认消息（由消息ID和源端点指示），例如，当其确认丢失或在第一次超时之前未到达原始发件人时。收件人应使用相同的确认或重置消息确认可确认消息的每个副本，但应仅处理消息中的任何请求或响应一次。如果可确认消息传输的请求是幂等的（参见第5.1节），或者可以以幂等方式处理，则可以放宽此规则。轻松邮件重复数据消除示例：
o A server might relax the requirement to answer all retransmissions of an idempotent request with the same response (Section 4.2), so that it does not have to maintain state for Message IDs. For example, an implementation might want to process duplicate transmissions of a GET, PUT, or DELETE request as separate requests if the effort incurred by duplicate processing is less expensive than keeping track of previous responses would be.
o 服务器可能会放宽以相同响应应答幂等请求的所有重传的要求（第4.2节），这样它就不必维护消息ID的状态。例如，如果重复处理所产生的成本低于跟踪以前的响应的成本，则实现可能希望将GET、PUT或DELETE请求的重复传输作为单独的请求进行处理。
o A constrained server might even want to relax this requirement for certain non-idempotent requests if the application semantics make this trade-off favorable. For example, if the result of a POST request is just the creation of some short-lived state at the server, it may be less expensive to incur this effort multiple times for a request than keeping track of whether a previous transmission of the same request already was processed.
o 受约束的服务器甚至可能希望放宽对某些非幂等请求的这一要求，如果应用程序语义使这一权衡有利的话。例如，如果POST请求的结果只是在服务器上创建一些短期状态，那么对于一个请求多次执行此操作可能比跟踪同一请求的前一次传输是否已被处理的成本更低。
A recipient might receive the same Non-confirmable message (as indicated by the Message ID and source endpoint) multiple times within NON_LIFETIME (Section 4.8.2). As a general rule that MAY be relaxed based on the specific semantics of a message, the recipient SHOULD silently ignore any duplicated Non-confirmable message and SHOULD process any request or response in the message only once.
收件人可能在非_生命周期内多次收到同一不可确认消息（由消息ID和源端点指示）（第4.8.2节）。根据消息的特定语义可以放宽的一般规则是，接收者应该默默地忽略任何重复的不可确认消息，并且应该只处理消息中的任何请求或响应一次。
While specific link layers make it beneficial to keep CoAP messages small enough to fit into their link-layer packets (see Section 1), this is a matter of implementation quality. The CoAP specification itself provides only an upper bound to the message size. Messages larger than an IP packet result in undesirable packet fragmentation. A CoAP message, appropriately encapsulated, SHOULD fit within a single IP packet (i.e., avoid IP fragmentation) and (by fitting into one UDP payload) obviously needs to fit within a single IP datagram. If the Path MTU is not known for a destination, an IP MTU of 1280 bytes SHOULD be assumed; if nothing is known about the size of the headers, good upper bounds are 1152 bytes for the message size and 1024 bytes for the payload size.
虽然特定的链路层有助于保持CoAP消息足够小，以适合其链路层数据包（参见第1节），但这是实现质量的问题。CoAP规范本身只提供消息大小的上限。大于IP数据包的消息会导致不需要的数据包碎片。适当封装的CoAP消息应适合于单个IP数据包（即，避免IP碎片），并且（通过适合于一个UDP有效负载）显然需要适合于单个IP数据报。如果目的地的路径MTU未知，则应假定1280字节的IP MTU；如果对报头的大小一无所知，那么消息大小的上限为1152字节，负载大小的上限为1024字节。
Implementation Note: CoAP's choice of message size parameters works well with IPv6 and with most of today's IPv4 paths. (However, with IPv4, it is harder to absolutely ensure that there is no IP fragmentation. If IPv4 support on unusual networks is a consideration, implementations may want to limit themselves to more conservative IPv4 datagram sizes such as 576 bytes; per [RFC0791], the absolute minimum value of the IP MTU for IPv4 is as low as 68 bytes, which would leave only 40 bytes minus security overhead for a UDP payload. Implementations extremely focused on this problem set might also set the IPv4 DF bit and perform some
实施说明：CoAP选择的消息大小参数适用于IPv6和当今大多数IPv4路径。（但是，对于IPv4，很难绝对确保不存在IP碎片。如果考虑在不寻常的网络上支持IPv4，则实施可能希望将自己限制为更保守的IPv4数据报大小，如576字节；per[RFC0791]，IPv4的IP MTU的绝对最小值低至68字节，这将只剩下40字节减去UDP有效负载的安全开销。非常关注此问题集的实现还可能设置IPv4 DF位并执行一些操作
form of path MTU discovery [RFC4821]; this should generally be unnecessary in realistic use cases for CoAP, however.) A more important kind of fragmentation in many constrained networks is that on the adaptation layer (e.g., 6LoWPAN L2 packets are limited to 127 bytes including various overheads); this may motivate implementations to be frugal in their packet sizes and to move to block-wise transfers [BLOCK] when approaching three-digit message sizes.
路径MTU发现的形式[RFC4821]；然而，在CoAP的实际用例中，这通常是不必要的。）许多受限网络中更重要的碎片类型是适配层上的碎片（例如，6LoWPAN L2数据包被限制为127字节，包括各种开销）；这可能会促使实现节省数据包大小，并在接近三位数消息大小时转向分块传输[block]。
Message sizes are also of considerable importance to implementations on constrained nodes. Many implementations will need to allocate a buffer for incoming messages. If an implementation is too constrained to allow for allocating the above-mentioned upper bound, it could apply the following implementation strategy for messages not using DTLS security: Implementations receiving a datagram into a buffer that is too small are usually able to determine if the trailing portion of a datagram was discarded and to retrieve the initial portion. So, at least the CoAP header and options, if not all of the payload, are likely to fit within the buffer. A server can thus fully interpret a request and return a 4.13 (Request Entity Too Large; see Section 5.9.2.9) Response Code if the payload was truncated. A client sending an idempotent request and receiving a response larger than would fit in the buffer can repeat the request with a suitable value for the Block Option [BLOCK].
消息大小对于受限节点上的实现也非常重要。许多实现需要为传入消息分配缓冲区。如果实现过于受限，无法分配上述上限，它可以对不使用DTLS安全性的消息应用以下实现策略：将数据报接收到太小的缓冲区中的实现通常能够确定是否丢弃了数据报的尾部，并检索初始部分。因此，至少CoAP头和选项（如果不是所有有效负载的话）可能适合缓冲区。因此，如果有效负载被截断，服务器可以完全解释请求并返回4.13（请求实体太大；请参阅第5.9.2.9节）响应代码。发送幂等请求并接收到大于缓冲区的响应的客户端可以使用Block选项[Block]的适当值重复请求。
Basic congestion control for CoAP is provided by the exponential back-off mechanism in Section 4.2.
CoAP的基本拥塞控制由第4.2节中的指数退避机制提供。
In order not to cause congestion, clients (including proxies) MUST strictly limit the number of simultaneous outstanding interactions that they maintain to a given server (including proxies) to NSTART. An outstanding interaction is either a CON for which an ACK has not yet been received but is still expected (message layer) or a request for which neither a response nor an Acknowledgment message has yet been received but is still expected (which may both occur at the same time, counting as one outstanding interaction). The default value of NSTART for this specification is 1.
为了不造成拥塞，客户端（包括代理）必须严格限制它们维护到给定服务器（包括代理）的并发未完成交互的数量，以使其不致于NSTART。未完成交互是尚未收到确认但仍在预期中的CON（消息层），或者是尚未收到响应或确认消息但仍在预期中的请求（两者可能同时发生，计为一个未完成交互）。此规范的NSTART默认值为1。
Further congestion control optimizations and considerations are expected in the future, may for example provide automatic initialization of the CoAP transmission parameters defined in Section 4.8, and thus may allow a value for NSTART greater than one.
预计将来会有进一步的拥塞控制优化和考虑，例如，可能会提供第4.8节中定义的CoAP传输参数的自动初始化，因此可能允许NSTART的值大于1。
After EXCHANGE_LIFETIME, a client stops expecting a response to a Confirmable request for which no acknowledgment message was received.
在EXCHANGE_生存期之后，客户端不再期望收到对未收到确认消息的可确认请求的响应。
The specific algorithm by which a client stops to "expect" a response to a Confirmable request that was acknowledged, or to a Non-confirmable request, is not defined. Unless this is modified by additional congestion control optimizations, it MUST be chosen in such a way that an endpoint does not exceed an average data rate of PROBING_RATE in sending to another endpoint that does not respond.
未定义客户端停止“期望”对已确认的可确认请求或不可确认请求的响应的特定算法。除非通过额外的拥塞控制优化对其进行修改，否则必须选择这样一种方式，即在发送到另一个没有响应的端点时，端点的平均数据速率不超过探测速率的平均数据速率。
Note: CoAP places the onus of congestion control mostly on the clients. However, clients may malfunction or actually be attackers, e.g., to perform amplification attacks (Section 11.3). To limit the damage (to the network and to its own energy resources), a server SHOULD implement some rate limiting for its response transmission based on reasonable assumptions about application requirements. This is most helpful if the rate limit can be made effective for the misbehaving endpoints, only.
注意：CoAP将拥塞控制的责任主要放在客户机上。然而，客户端可能会出现故障或实际上是攻击者，例如，执行放大攻击（第11.3节）。为了限制（对网络和自身能源的）损害，服务器应基于对应用程序需求的合理假设，对其响应传输实施一定的速率限制。如果速率限制仅对行为不端的端点有效，则这是最有用的。
Message transmission is controlled by the following parameters:
信息传输由以下参数控制：
+-------------------+---------------+
| name | default value |
+-------------------+---------------+
| ACK_TIMEOUT | 2 seconds |
| ACK_RANDOM_FACTOR | 1.5 |
| MAX_RETRANSMIT | 4 |
| NSTART | 1 |
| DEFAULT_LEISURE | 5 seconds |
| PROBING_RATE | 1 byte/second |
+-------------------+---------------+
+-------------------+---------------+
| name | default value |
+-------------------+---------------+
| ACK_TIMEOUT | 2 seconds |
| ACK_RANDOM_FACTOR | 1.5 |
| MAX_RETRANSMIT | 4 |
| NSTART | 1 |
| DEFAULT_LEISURE | 5 seconds |
| PROBING_RATE | 1 byte/second |
+-------------------+---------------+
Table 2: CoAP Protocol Parameters
表2:CoAP协议参数
The values for ACK_TIMEOUT, ACK_RANDOM_FACTOR, MAX_RETRANSMIT, NSTART, DEFAULT_LEISURE (Section 8.2), and PROBING_RATE may be configured to values specific to the application environment (including dynamically adjusted values); however, the configuration method is out of scope of this document. It is RECOMMENDED that an application environment use consistent values for these parameters; the specific effects of operating with inconsistent values in an application environment are outside the scope of the present specification.
确认超时、确认随机因子、最大重传、NSTART、默认空闲时间（第8.2节）和探测速率的值可配置为特定于应用程序环境的值（包括动态调整的值）；但是，配置方法超出了本文档的范围。建议应用程序环境对这些参数使用一致的值；在应用环境中使用不一致的值进行操作的具体影响不在本规范的范围内。
The transmission parameters have been chosen to achieve a behavior in the presence of congestion that is safe in the Internet. If a configuration desires to use different values, the onus is on the
选择传输参数是为了在出现拥塞的情况下实现在互联网上安全的行为。如果配置希望使用不同的值，则ONU位于
configuration to ensure these congestion control properties are not violated. In particular, a decrease of ACK_TIMEOUT below 1 second would violate the guidelines of [RFC5405]. ([RTO-CONSIDER] provides some additional background.) CoAP was designed to enable implementations that do not maintain round-trip-time (RTT) measurements. However, where it is desired to decrease the ACK_TIMEOUT significantly or increase NSTART, this can only be done safely when maintaining such measurements. Configurations MUST NOT decrease ACK_TIMEOUT or increase NSTART without using mechanisms that ensure congestion control safety, either defined in the configuration or in future standards documents.
配置以确保不违反这些拥塞控制属性。特别是，将ACK_超时减少到1秒以下将违反[RFC5405]的准则。（[RTO-THINK]提供了一些额外的背景。）CoAP设计用于支持不维护往返时间（RTT）测量的实现。但是，如果需要显著减少确认超时或增加NSTART，则只有在保持此类测量时才能安全地进行。在不使用确保拥塞控制安全的机制（无论是在配置中还是在未来的标准文档中定义的）的情况下，配置不得减少确认超时或增加NSTART。
ACK_RANDOM_FACTOR MUST NOT be decreased below 1.0, and it SHOULD have a value that is sufficiently different from 1.0 to provide some protection from synchronization effects.
ACK_RANDOM_FACTOR不得降低到1.0以下，且其值应与1.0相差足够大，以提供一些针对同步效应的保护。
MAX_RETRANSMIT can be freely adjusted, but a value that is too small will reduce the probability that a Confirmable message is actually received, while a larger value than given here will require further adjustments in the time values (see Section 4.8.2).
MAX_重新传输可以自由调整，但太小的值将降低实际接收可确认消息的概率，而大于此处给出的值将需要进一步调整时间值（见第4.8.2节）。
If the choice of transmission parameters leads to an increase of derived time values (see Section 4.8.2), the configuration mechanism MUST ensure the adjusted value is also available to all the endpoints with which these adjusted values are to be used to communicate.
如果传输参数的选择导致导出时间值的增加（见第4.8.2节），配置机制必须确保调整值也可用于所有端点，这些调整值将用于通信。
The combination of ACK_TIMEOUT, ACK_RANDOM_FACTOR, and MAX_RETRANSMIT influences the timing of retransmissions, which in turn influences how long certain information items need to be kept by an implementation. To be able to unambiguously reference these derived time values, we give them names as follows:
ACK_超时、ACK_随机_因子和MAX_重传的组合影响重传的定时，这反过来又影响实现需要保留某些信息项的时间。为了能够明确地引用这些派生的时间值，我们给它们命名如下：
o MAX_TRANSMIT_SPAN is the maximum time from the first transmission of a Confirmable message to its last retransmission. For the default transmission parameters, the value is (2+4+8+16)*1.5 = 45 seconds, or more generally:
o MAX_TRANSMIT_SPAN是从第一次传输可确认消息到最后一次重新传输的最长时间。对于默认传输参数，该值为（2+4+8+16）*1.5=45秒，或更一般地：
ACK_TIMEOUT * ((2 ** MAX_RETRANSMIT) - 1) * ACK_RANDOM_FACTOR
ACK_TIMEOUT * ((2 ** MAX_RETRANSMIT) - 1) * ACK_RANDOM_FACTOR
o MAX_TRANSMIT_WAIT is the maximum time from the first transmission of a Confirmable message to the time when the sender gives up on receiving an acknowledgement or reset. For the default transmission parameters, the value is (2+4+8+16+32)*1.5 = 93 seconds, or more generally:
o MAX_TRANSMIT_WAIT是从第一次传输可确认消息到发送方放弃接收确认或重置的最长时间。对于默认传输参数，该值为（2+4+8+16+32）*1.5=93秒，或更一般地：
ACK_TIMEOUT * ((2 ** (MAX_RETRANSMIT + 1)) - 1) *
ACK_RANDOM_FACTOR
ACK_TIMEOUT * ((2 ** (MAX_RETRANSMIT + 1)) - 1) *
ACK_RANDOM_FACTOR
In addition, some assumptions need to be made on the characteristics of the network and the nodes.
此外，需要对网络和节点的特性进行一些假设。
o MAX_LATENCY is the maximum time a datagram is expected to take from the start of its transmission to the completion of its reception. This constant is related to the MSL (Maximum Segment Lifetime) of [RFC0793], which is "arbitrarily defined to be 2 minutes" ([RFC0793] glossary, page 81). Note that this is not necessarily smaller than MAX_TRANSMIT_WAIT, as MAX_LATENCY is not intended to describe a situation when the protocol works well, but the worst-case situation against which the protocol has to guard. We, also arbitrarily, define MAX_LATENCY to be 100 seconds. Apart from being reasonably realistic for the bulk of configurations as well as close to the historic choice for TCP, this value also allows Message ID lifetime timers to be represented in 8 bits (when measured in seconds). In these calculations, there is no assumption that the direction of the transmission is irrelevant (i.e., that the network is symmetric); there is just the assumption that the same value can reasonably be used as a maximum value for both directions. If that is not the case, the following calculations become only slightly more complex.
o MAX_LATENCY是数据报从开始传输到完成接收所需的最长时间。该常数与[RFC0793]的MSL（最大段寿命）有关，MSL“任意定义为2分钟”（[RFC0793]术语表，第81页）。请注意，这不一定小于MAX_transmission_WAIT，因为MAX_LATENCY不是用来描述协议正常工作时的情况，而是协议必须防范的最坏情况。我们也任意将最大延迟定义为100秒。除了对大部分配置合理地切合实际以及接近TCP的历史选择外，该值还允许消息ID生存时间计时器以8位表示（以秒为单位）。在这些计算中，不存在传输方向无关的假设（即，网络是对称的）；只是假设相同的值可以合理地用作两个方向的最大值。如果情况并非如此，则以下计算只会稍微复杂一些。
o PROCESSING_DELAY is the time a node takes to turn around a Confirmable message into an acknowledgement. We assume the node will attempt to send an ACK before having the sender time out, so as a conservative assumption we set it equal to ACK_TIMEOUT.
o PROCESSING_DELAY是节点将可确认消息转换为确认所需的时间。我们假设节点将在发送方超时之前尝试发送ACK，因此保守地假设我们将其设置为ACK_TIMEOUT。
o MAX_RTT is the maximum round-trip time, or:
o MAX_RTT是最大往返时间，或：
(2 * MAX_LATENCY) + PROCESSING_DELAY
（2*最大延迟）+处理延迟
From these values, we can derive the following values relevant to the protocol operation:
根据这些值，我们可以得出与协议操作相关的以下值：
o EXCHANGE_LIFETIME is the time from starting to send a Confirmable message to the time when an acknowledgement is no longer expected, i.e., message-layer information about the message exchange can be purged. EXCHANGE_LIFETIME includes a MAX_TRANSMIT_SPAN, a MAX_LATENCY forward, PROCESSING_DELAY, and a MAX_LATENCY for the
o EXCHANGE_LIFETIME是从开始发送可确认消息到不再需要确认的时间，即，可以清除有关消息交换的消息层信息。EXCHANGE的生存期包括最大传输时间跨度、最大转发延迟、处理延迟和最大延迟
way back. Note that there is no need to consider MAX_TRANSMIT_WAIT if the configuration is chosen such that the last waiting period (ACK_TIMEOUT * (2 ** MAX_RETRANSMIT) or the difference between MAX_TRANSMIT_SPAN and MAX_TRANSMIT_WAIT) is less than MAX_LATENCY -- which is a likely choice, as MAX_LATENCY is a worst-case value unlikely to be met in the real world. In this case, EXCHANGE_LIFETIME simplifies to:
很久以前。注意，如果选择了这样的配置，则不必考虑Max发送消息，这样最后的等待周期（AcxTimeOut*（2×Max重发）或Max传输TrimeSpand和Max传输的区别）小于Max潜伏期——这是一个可能的选择，因为最大延迟是现实世界中不可能达到的最坏情况值。在这种情况下，EXCHANGE_生命周期简化为：
MAX_TRANSMIT_SPAN + (2 * MAX_LATENCY) + PROCESSING_DELAY
MAX_TRANSMIT_SPAN + (2 * MAX_LATENCY) + PROCESSING_DELAY
or 247 seconds with the default transmission parameters.
或247秒，使用默认传输参数。
o NON_LIFETIME is the time from sending a Non-confirmable message to the time its Message ID can be safely reused. If multiple transmission of a NON message is not used, its value is MAX_LATENCY, or 100 seconds. However, a CoAP sender might send a NON message multiple times, in particular for multicast applications. While the period of reuse is not bounded by the specification, an expectation of reliable detection of duplication at the receiver is on the timescales of MAX_TRANSMIT_SPAN. Therefore, for this purpose, it is safer to use the value:
o NON_LIFETIME是从发送不可确认消息到其消息ID可以安全重用的时间。如果未使用非消息的多次传输，则其值为最大延迟或100秒。但是，CoAP发送方可能多次发送非消息，特别是对于多播应用程序。虽然重用周期不受规范的限制，但在接收器处可靠检测重复的期望是在MAX_TRANSMIT_SPAN的时间尺度上。因此，出于此目的，使用以下值更安全：
MAX_TRANSMIT_SPAN + MAX_LATENCY
最大传输间隔+最大延迟
or 145 seconds with the default transmission parameters; however, an implementation that just wants to use a single timeout value for retiring Message IDs can safely use the larger value for EXCHANGE_LIFETIME.
或145秒，默认传输参数；但是，如果实现只想使用一个超时值使消息ID失效，则可以安全地将较大的值用于EXCHANGE\ U生存期。
Table 3 lists the derived parameters introduced in this subsection with their default values.
表3列出了本小节中引入的衍生参数及其默认值。
+-------------------+---------------+
| name | default value |
+-------------------+---------------+
| MAX_TRANSMIT_SPAN | 45 s |
| MAX_TRANSMIT_WAIT | 93 s |
| MAX_LATENCY | 100 s |
| PROCESSING_DELAY | 2 s |
| MAX_RTT | 202 s |
| EXCHANGE_LIFETIME | 247 s |
| NON_LIFETIME | 145 s |
+-------------------+---------------+
+-------------------+---------------+
| name | default value |
+-------------------+---------------+
| MAX_TRANSMIT_SPAN | 45 s |
| MAX_TRANSMIT_WAIT | 93 s |
| MAX_LATENCY | 100 s |
| PROCESSING_DELAY | 2 s |
| MAX_RTT | 202 s |
| EXCHANGE_LIFETIME | 247 s |
| NON_LIFETIME | 145 s |
+-------------------+---------------+
Table 3: Derived Protocol Parameters
表3：派生协议参数
CoAP operates under a similar request/response model as HTTP: a CoAP endpoint in the role of a "client" sends one or more CoAP requests to a "server", which services the requests by sending CoAP responses. Unlike HTTP, requests and responses are not sent over a previously established connection but are exchanged asynchronously over CoAP messages.
CoAP在与HTTP类似的请求/响应模型下运行：扮演“客户机”角色的CoAP端点向“服务器”发送一个或多个CoAP请求，服务器通过发送CoAP响应为请求提供服务。与HTTP不同，请求和响应不是通过先前建立的连接发送的，而是通过CoAP消息异步交换的。
A CoAP request consists of the method to be applied to the resource, the identifier of the resource, a payload and Internet media type (if any), and optional metadata about the request.
CoAP请求由应用于资源的方法、资源标识符、有效负载和Internet媒体类型（如果有）以及关于请求的可选元数据组成。
CoAP supports the basic methods of GET, POST, PUT, and DELETE, which are easily mapped to HTTP. They have the same properties of safe (only retrieval) and idempotent (you can invoke it multiple times with the same effects) as HTTP (see Section 9.1 of [RFC2616]). The GET method is safe; therefore, it MUST NOT take any other action on a resource other than retrieval. The GET, PUT, and DELETE methods MUST be performed in such a way that they are idempotent. POST is not idempotent, because its effect is determined by the origin server and dependent on the target resource; it usually results in a new resource being created or the target resource being updated.
CoAP支持GET、POST、PUT和DELETE等基本方法，这些方法很容易映射到HTTP。它们与HTTP（参见[RFC2616]第9.1节）具有相同的安全属性（仅检索）和幂等属性（您可以多次调用它并产生相同的效果）。GET方法是安全的；因此，它不能对资源执行除检索以外的任何其他操作。GET、PUT和DELETE方法必须以幂等的方式执行。POST不是幂等的，因为它的效果由源服务器决定，并且依赖于目标资源；它通常会导致创建新资源或更新目标资源。
A request is initiated by setting the Code field in the CoAP header of a Confirmable or a Non-confirmable message to a Method Code and including request information.
通过将可确认或不可确认消息的CoAP头中的代码字段设置为方法代码并包含请求信息，可以启动请求。
The methods used in requests are described in detail in Section 5.8.
第5.8节详细描述了请求中使用的方法。
After receiving and interpreting a request, a server responds with a CoAP response that is matched to the request by means of a client-generated token (Section 5.3); note that this is different from the Message ID that matches a Confirmable message to its Acknowledgement.
在接收和解释请求后，服务器响应CoAP响应，该响应通过客户端生成的令牌与请求匹配（第5.3节）；请注意，这与将可确认消息与其确认匹配的消息ID不同。
A response is identified by the Code field in the CoAP header being set to a Response Code. Similar to the HTTP Status Code, the CoAP Response Code indicates the result of the attempt to understand and satisfy the request. These codes are fully defined in Section 5.9. The Response Code numbers to be set in the Code field of the CoAP header are maintained in the CoAP Response Code Registry (Section 12.1.2).
响应由CoAP标头中设置为响应代码的代码字段标识。与HTTP状态代码类似，CoAP响应代码指示尝试理解和满足请求的结果。这些代码在第5.9节中有完整定义。在CoAP标题的代码字段中设置的响应代码编号保存在CoAP响应代码注册表中（第12.1.2节）。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|class| detail |
+-+-+-+-+-+-+-+-+
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|class| detail |
+-+-+-+-+-+-+-+-+
Figure 9: Structure of a Response Code
图9：响应代码的结构
The upper three bits of the 8-bit Response Code number define the class of response. The lower five bits do not have any categorization role; they give additional detail to the overall class (Figure 9).
8位响应代码的上三位定义了响应的类别。下五位不具有任何分类作用；它们为整个类提供了额外的细节（图9）。
As a human-readable notation for specifications and protocol diagnostics, CoAP code numbers including the Response Code are documented in the format "c.dd", where "c" is the class in decimal, and "dd" is the detail as a two-digit decimal. For example, "Forbidden" is written as 4.03 -- indicating an 8-bit code value of hexadecimal 0x83 (4*0x20+3) or decimal 131 (4*32+3).
作为规范和协议诊断的可读符号，包括响应代码在内的CoAP代码编号以“c.dd”格式记录，其中“c”是以十进制表示的类，“dd”是以两位十进制表示的细节。例如，“禁止”写为4.03——表示十六进制0x83（4*0x20+3）或十进制131（4*32+3）的8位代码值。
There are 3 classes of Response Codes:
有3类响应代码：
2 - Success: The request was successfully received, understood, and accepted.
2-成功：请求已成功接收、理解和接受。
4 - Client Error: The request contains bad syntax or cannot be fulfilled.
4-客户端错误：请求包含错误语法或无法实现。
5 - Server Error: The server failed to fulfill an apparently valid request.
5-服务器错误：服务器未能完成明显有效的请求。
The Response Codes are designed to be extensible: Response Codes in the Client Error or Server Error class that are unrecognized by an endpoint are treated as being equivalent to the generic Response Code of that class (4.00 and 5.00, respectively). However, there is no generic Response Code indicating success, so a Response Code in the Success class that is unrecognized by an endpoint can only be used to determine that the request was successful without any further details.
响应代码被设计为可扩展的：端点无法识别的客户端错误或服务器错误类中的响应代码被视为等同于该类的通用响应代码（分别为4.00和5.00）。但是，没有表示成功的通用响应代码，因此success类中端点无法识别的响应代码只能用于确定请求是否成功，而无需任何进一步的详细信息。
The possible Response Codes are described in detail in Section 5.9.
第5.9节详细描述了可能的响应代码。
Responses can be sent in multiple ways, which are defined in the following subsections.
响应可以以多种方式发送，这些方式在以下小节中定义。
In the most basic case, the response is carried directly in the Acknowledgement message that acknowledges the request (which requires that the request was carried in a Confirmable message). This is called a "Piggybacked Response".
在最基本的情况下，响应直接包含在确认请求的确认消息中（这要求请求包含在可确认的消息中）。这被称为“背负式响应”。
The response is returned in the Acknowledgement message, independent of whether the response indicates success or failure. In effect, the response is piggybacked on the Acknowledgement message, and no separate message is required to return the response.
响应在确认消息中返回，与响应是否表示成功或失败无关。实际上，响应是在确认消息上进行的，不需要单独的消息来返回响应。
Implementation Note: The protocol leaves the decision whether to piggyback a response or not (i.e., send a separate response) to the server. The client MUST be prepared to receive either. On the quality-of-implementation level, there is a strong expectation that servers will implement code to piggyback whenever possible -- saving resources in the network and both at the client and at the server.
实现说明：协议将决定是否将响应（即，发送单独的响应）携带到服务器。客户必须准备好接受任何一种情况。在实现的质量级别上，人们强烈期望服务器将实现代码，以便尽可能地实现代码，从而节省网络中以及客户端和服务器上的资源。
It may not be possible to return a piggybacked response in all cases. For example, a server might need longer to obtain the representation of the resource requested than it can wait to send back the Acknowledgement message, without risking the client repeatedly retransmitting the request message (see also the discussion of PROCESSING_DELAY in Section 4.8.2). The response to a request carried in a Non-confirmable message is always sent separately (as there is no Acknowledgement message).
可能不可能在所有情况下都返回一个附带的响应。例如，服务器可能需要更长的时间来获取所请求资源的表示，而不是等待发送回确认消息，而不会使客户端重复传输请求消息（另请参见第4.8.2节中关于处理延迟的讨论）。对不可确认消息中的请求的响应总是单独发送（因为没有确认消息）。
One way to implement this in a server is to initiate the attempt to obtain the resource representation and, while that is in progress, time out an acknowledgement timer. A server may also immediately send an acknowledgement if it knows in advance that there will be no piggybacked response. In both cases, the acknowledgement effectively is a promise that the request will be acted upon later.
在服务器中实现这一点的一种方法是启动获取资源表示的尝试，并在进行过程中超时确认计时器。如果服务器事先知道没有附带响应，那么它也可以立即发送确认。在这两种情况下，确认实际上是一种承诺，即以后将对请求采取行动。
When the server finally has obtained the resource representation, it sends the response. When it is desired that this message is not lost, it is sent as a Confirmable message from the server to the client and answered by the client with an Acknowledgement, echoing the new Message ID chosen by the server. (It may also be sent as a Non-confirmable message; see Section 5.2.3.)
当服务器最终获得资源表示时，它将发送响应。当希望此消息不会丢失时，它将作为可确认消息从服务器发送到客户端，并由客户端以确认的方式应答，并回显服务器选择的新消息ID。（也可作为不可确认的信息发送；见第5.2.3节。）
When the server chooses to use a separate response, it sends the Acknowledgement to the Confirmable request as an Empty message. Once the server sends back an Empty Acknowledgement, it MUST NOT send back
当服务器选择使用单独的响应时，它会将确认作为空消息发送给可确认请求。一旦服务器发回一个空的确认，它就不能发回
the response in another Acknowledgement, even if the client retransmits another identical request. If a retransmitted request is received (perhaps because the original Acknowledgement was delayed), another Empty Acknowledgement is sent, and any response MUST be sent as a separate response.
在另一个确认中的响应，即使客户端重新传输另一个相同的请求。如果收到重新传输的请求（可能是因为原始确认延迟），则会发送另一个空确认，并且任何响应都必须作为单独的响应发送。
If the server then sends a Confirmable response, the client's Acknowledgement to that response MUST also be an Empty message (one that carries neither a request nor a response). The server MUST stop retransmitting its response on any matching Acknowledgement (silently ignoring any Response Code or payload) or Reset message.
如果服务器随后发送可确认的响应，则客户端对该响应的确认也必须是空消息（既不包含请求也不包含响应的消息）。服务器必须停止在任何匹配的确认（静默忽略任何响应代码或负载）或重置消息上重新传输其响应。
Implementation Notes: Note that, as the underlying datagram transport may not be sequence-preserving, the Confirmable message carrying the response may actually arrive before or after the Acknowledgement message for the request; for the purposes of terminating the retransmission sequence, this also serves as an acknowledgement. Note also that, while the CoAP protocol itself does not make any specific demands here, there is an expectation that the response will come within a time frame that is reasonable from an application point of view. As there is no underlying transport protocol that could be instructed to run a keep-alive mechanism, the requester may want to set up a timeout that is unrelated to CoAP's retransmission timers in case the server is destroyed or otherwise unable to send the response.
实现说明：注意，由于底层数据报传输可能不保留序列，携带响应的可确认消息实际上可能在请求的确认消息之前或之后到达；为了终止重传序列，这也用作确认。还要注意的是，虽然CoAP协议本身在这里没有提出任何具体要求，但从应用的角度来看，预期响应将在合理的时间范围内。由于没有可指示运行保持活动机制的底层传输协议，请求者可能希望设置与CoAP的重传计时器无关的超时，以防服务器被破坏或无法发送响应。
If the request message is Non-confirmable, then the response SHOULD be returned in a Non-confirmable message as well. However, an endpoint MUST be prepared to receive a Non-confirmable response (preceded or followed by an Empty Acknowledgement message) in reply to a Confirmable request, or a Confirmable response in reply to a Non-confirmable request.
如果请求消息是不可确认的，那么响应也应该以不可确认消息的形式返回。但是，端点必须准备好接收不可确认响应（前面或后面是空的确认消息）以响应可确认请求，或者接收可确认响应以响应不可确认请求。
Regardless of how a response is sent, it is matched to the request by means of a token that is included by the client in the request, along with additional address information of the corresponding endpoint.
无论响应是如何发送的，它都通过客户端在请求中包含的令牌以及相应端点的附加地址信息与请求相匹配。
The Token is used to match a response with a request. The token value is a sequence of 0 to 8 bytes. (Note that every message carries a token, even if it is of zero length.) Every request carries a client-generated token that the server MUST echo (without modification) in any resulting response.
令牌用于将响应与请求相匹配。令牌值是一个0到8字节的序列。（请注意，每个消息都携带一个令牌，即使它的长度为零。）每个请求都携带一个客户端生成的令牌，服务器必须在任何结果响应中回显（无需修改）。
A token is intended for use as a client-local identifier for differentiating between concurrent requests (see Section 5.3); it could have been called a "request ID".
令牌用作区分并发请求的客户端本地标识符（见第5.3节）；它可以被称为“请求ID”。
The client SHOULD generate tokens in such a way that tokens currently in use for a given source/destination endpoint pair are unique. (Note that a client implementation can use the same token for any request if it uses a different endpoint each time, e.g., a different source port number.) An empty token value is appropriate e.g., when no other tokens are in use to a destination, or when requests are made serially per destination and receive piggybacked responses. There are, however, multiple possible implementation strategies to fulfill this.
客户端应该以这样的方式生成令牌，即当前用于给定源/目标端点对的令牌是唯一的。（请注意，如果客户机实现每次使用不同的端点（例如，不同的源端口号），则它可以对任何请求使用相同的令牌。）空令牌值是合适的，例如，当没有其他令牌用于某个目的地时，或者当每个目的地串行发出请求并接收附带响应时。然而，有多种可能的实施策略来实现这一点。
A client sending a request without using Transport Layer Security (Section 9) SHOULD use a nontrivial, randomized token to guard against spoofing of responses (Section 11.4). This protective use of tokens is the reason they are allowed to be up to 8 bytes in size. The actual size of the random component to be used for the Token depends on the security requirements of the client and the level of threat posed by spoofing of responses. A client that is connected to the general Internet SHOULD use at least 32 bits of randomness, keeping in mind that not being directly connected to the Internet is not necessarily sufficient protection against spoofing. (Note that the Message ID adds little in protection as it is usually sequentially assigned, i.e., guessable, and can be circumvented by spoofing a separate response.) Clients that want to optimize the Token length may further want to detect the level of ongoing attacks (e.g., by tallying recent Token mismatches in incoming messages) and adjust the Token length upwards appropriately. [RFC4086] discusses randomness requirements for security.
在不使用传输层安全性（第9节）的情况下发送请求的客户端应使用非平凡的随机令牌来防止响应的欺骗（第11.4节）。令牌的这种保护性使用是允许其最大为8字节的原因。用于令牌的随机组件的实际大小取决于客户端的安全要求和响应欺骗造成的威胁级别。连接到通用Internet的客户端应使用至少32位的随机性，记住，不直接连接到Internet不一定足以防止欺骗。（请注意，由于消息ID通常是按顺序分配的（即可猜测的），因此几乎不会增加保护功能，并且可以通过欺骗单独的响应来规避。）想要优化令牌长度的客户端可能还想要检测正在进行的攻击级别（例如，通过统计传入消息中最近的令牌不匹配情况）并适当向上调整令牌长度。[RFC4086]讨论了安全性的随机性要求。
An endpoint receiving a token it did not generate MUST treat the token as opaque and make no assumptions about its content or structure.
接收未生成的令牌的端点必须将该令牌视为不透明的，并且不对其内容或结构进行任何假设。
The exact rules for matching a response to a request are as follows:
将响应与请求匹配的确切规则如下：
1. The source endpoint of the response MUST be the same as the destination endpoint of the original request.
1. 响应的源端点必须与原始请求的目标端点相同。
2. In a piggybacked response, the Message ID of the Confirmable request and the Acknowledgement MUST match, and the tokens of the response and original request MUST match. In a separate response, just the tokens of the response and original request MUST match.
2. 在背驮式响应中，可确认请求和确认的消息ID必须匹配，响应和原始请求的令牌必须匹配。在单独的响应中，只有响应和原始请求的令牌必须匹配。
In case a message carrying a response is unexpected (the client is not waiting for a response from the identified endpoint, at the endpoint addressed, and/or with the given token), the response is rejected (Sections 4.2 and 4.3).
如果承载响应的消息是意外的（客户端没有等待来自已识别端点、在已寻址端点和/或使用给定令牌的响应），则拒绝响应（第4.2和4.3节）。
Implementation Note: A client that receives a response in a CON message may want to clean up the message state right after sending the ACK. If that ACK is lost and the server retransmits the CON, the client may no longer have any state to which to correlate this response, making the retransmission an unexpected message; the client will likely send a Reset message so it does not receive any more retransmissions. This behavior is normal and not an indication of an error. (Clients that are not aggressively optimized in their state memory usage will still have message state that will identify the second CON as a retransmission. Clients that actually expect more messages from the server [OBSERVE] will have to keep state in any case.)
实现说明：在CON消息中接收响应的客户端可能希望在发送ACK后立即清除消息状态。如果该ACK丢失并且服务器重新传输CON，则客户端可能不再具有与该响应相关联的任何状态，从而使重新传输成为意外消息；客户端可能会发送重置消息，因此不会再接收任何重传。这种行为是正常的，不是错误的迹象。（未积极优化其状态内存使用的客户端仍将具有消息状态，该状态将第二个CON标识为重新传输。实际期望从服务器[OBSERVE]发送更多消息的客户端在任何情况下都必须保持状态。）
Both requests and responses may include a list of one or more options. For example, the URI in a request is transported in several options, and metadata that would be carried in an HTTP header in HTTP is supplied as options as well.
请求和响应都可能包括一个或多个选项的列表。例如，请求中的URI通过几个选项传输，HTTP中HTTP头中携带的元数据也作为选项提供。
CoAP defines a single set of options that are used in both requests and responses:
CoAP定义了一组用于请求和响应的选项：
o Content-Format
o 内容格式
o ETag
o 埃塔格
o Location-Path
o 位置路径
o Location-Query
o 位置查询
o Max-Age
o 最大年龄
o Proxy-Uri
o 代理Uri
o Proxy-Scheme
o 代理方案
o Uri-Host
o Uri主机
o Uri-Path
o Uri路径
o Uri-Port
o Uri端口
o Uri-Query
o Uri查询
o Accept
o 接受
o If-Match
o 如果匹配
o If-None-Match
o 如果没有匹配
o Size1
o 尺码1
The semantics of these options along with their properties are defined in detail in Section 5.10.
第5.10节详细定义了这些选项的语义及其属性。
Not all options are defined for use with all methods and Response Codes. The possible options for methods and Response Codes are defined in Sections 5.8 and 5.9, respectively. In case an option is not defined for a Method or Response Code, it MUST NOT be included by a sender and MUST be treated like an unrecognized option by a recipient.
并非所有选项都定义用于所有方法和响应代码。方法和响应代码的可能选项分别在第5.8节和第5.9节中定义。如果未为方法或响应代码定义选项，则发送方不得包含该选项，并且接收方必须将其视为未识别的选项。
Options fall into one of two classes: "critical" or "elective". The difference between these is how an option unrecognized by an endpoint is handled:
选项分为两类：“关键”或“选修”。它们之间的区别在于如何处理端点无法识别的选项：
o Upon reception, unrecognized options of class "elective" MUST be silently ignored.
o 接收后，未识别的“选修”课程选项必须被默默忽略。
o Unrecognized options of class "critical" that occur in a Confirmable request MUST cause the return of a 4.02 (Bad Option) response. This response SHOULD include a diagnostic payload describing the unrecognized option(s) (see Section 5.5.2).
o 可确认请求中出现的“critical”类的未识别选项必须导致返回4.02（错误选项）响应。该响应应包括描述未识别选项的诊断有效载荷（见第5.5.2节）。
o Unrecognized options of class "critical" that occur in a Confirmable response, or piggybacked in an Acknowledgement, MUST cause the response to be rejected (Section 4.2).
o 在可确认响应中出现的或在确认中附带的“关键”类未识别选项必须导致响应被拒绝（第4.2节）。
o Unrecognized options of class "critical" that occur in a Non-confirmable message MUST cause the message to be rejected (Section 4.3).
o 不可确认消息中出现的“关键”类的未识别选项必须导致拒绝该消息（第4.3节）。
Note that, whether critical or elective, an option is never "mandatory" (it is always optional): these rules are defined in order to enable implementations to stop processing options they do not understand or implement.
请注意，无论是关键的还是可选的，选项都不是“强制的”（始终是可选的）：定义这些规则是为了使实现能够停止处理它们不理解或不实现的选项。
Critical/elective rules apply to non-proxying endpoints. A proxy processes options based on Unsafe/Safe-to-Forward classes as defined in Section 5.7.
关键/可选规则适用于非代理端点。代理处理基于第5.7节中定义的不安全/安全转发类的选项。
In addition to an option being marked as critical or elective, options are also classified based on how a proxy is to deal with the option if it does not recognize it. For this purpose, an option can either be considered Unsafe to forward (UnSafe is set) or Safe-to-Forward (UnSafe is clear).
除了被标记为关键或可选的期权外，期权还根据代理如何处理未识别的期权进行分类。为此，可将选项视为不安全转发（已设置不安全）或安全转发（清除不安全）。
In addition, for an option that is marked Safe-to-Forward, the option number indicates whether or not it is intended to be part of the Cache-Key (Section 5.6) in a request. If some of the NoCacheKey bits are 0, it is; if all NoCacheKey bits are 1, it is not (see Section 5.4.6).
此外，对于标记为“安全转发”的选项，选项编号指示该选项是否是请求中缓存密钥（第5.6节）的一部分。如果某些NoCacheKey位为0，则为；如果所有NoCacheKey位均为1，则不为1（见第5.4.6节）。
Note: The Cache-Key indication is relevant only for proxies that do not implement the given option as a request option and instead rely on the Unsafe/Safe-to-Forward indication only. For example, for ETag, actually using the request option as a part of the Cache-Key is grossly inefficient, but it is the best thing one can do if ETag is not implemented by a proxy, as the response is going to differ based on the presence of the request option. A more useful proxy that does implement the ETag request option is not using ETag as a part of the Cache-Key.
注意：缓存密钥指示仅适用于未将给定选项作为请求选项实现，而仅依赖不安全/安全转发指示的代理。例如，对于ETag，实际上使用请求选项作为缓存密钥的一部分是非常低效的，但是如果ETag不是由代理实现的，那么这是最好的方法，因为响应将根据请求选项的存在而有所不同。实现ETag请求选项的更有用的代理不使用ETag作为缓存密钥的一部分。
NoCacheKey is indicated in three bits so that only one out of eight codepoints is qualified as NoCacheKey, leaving seven out of eight codepoints for what appears to be the more likely case.
NoCacheKey以三位表示，因此八个代码点中只有一个符合NoCacheKey的条件，八个代码点中有七个符合更可能的情况。
Proxy behavior with regard to these classes is defined in Section 5.7.
第5.7节定义了这些类别的代理行为。
Option values are defined to have a specific length, often in the form of an upper and lower bound. If the length of an option value in a request is outside the defined range, that option MUST be treated like an unrecognized option (see Section 5.4.1).
选项值定义为具有特定长度，通常以上限和下限的形式。如果请求中选项值的长度超出定义的范围，则必须将该选项视为未识别的选项（参见第5.4.1节）。
Options may be defined to have a default value. If the value of an option is intended to be this default value, the option SHOULD NOT be included in the message. If the option is not present, the default value MUST be assumed.
选项可以定义为具有默认值。如果某个选项的值是此默认值，则该选项不应包含在消息中。如果该选项不存在，则必须假定默认值。
Where a critical option has a default value, this is chosen in such a way that the absence of the option in a message can be processed properly both by implementations unaware of the critical option and by implementations that interpret this absence as the presence of the default value for the option.
在关键选项具有默认值的情况下，选择该选项的方式应确保消息中缺少该选项的实现可以通过不知道该关键选项的实现以及将该缺少解释为该选项存在默认值的实现来正确处理。
The definition of some options specifies that those options are repeatable. An option that is repeatable MAY be included one or more times in a message. An option that is not repeatable MUST NOT be included more than once in a message.
某些选项的定义指定这些选项是可重复的。可重复的选项可以在消息中包含一次或多次。不可重复的选项不得在消息中包含多次。
If a message includes an option with more occurrences than the option is defined for, each supernumerary option occurrence that appears subsequently in the message MUST be treated like an unrecognized option (see Section 5.4.1).
如果消息包含的选项的出现次数超过了定义的选项，则随后出现在消息中的每个额外选项必须视为未识别的选项（见第5.4.1节）。
An Option is identified by an option number, which also provides some additional semantics information, e.g., odd numbers indicate a critical option, while even numbers indicate an elective option. Note that this is not just a convention, it is a feature of the protocol: Whether an option is elective or critical is entirely determined by whether its option number is even or odd.
选项由选项编号标识，选项编号还提供一些附加语义信息，例如，奇数表示关键选项，偶数表示可选选项。请注意，这不仅仅是一个惯例，它也是协议的一个特点：一个选项是可选的还是关键的，完全取决于它的选项号是偶数还是奇数。
More generally speaking, an Option number is constructed with a bit mask to indicate if an option is Critical or Elective, Unsafe or Safe-to-Forward, and, in the case of Safe-to-Forward, to provide a Cache-Key indication as shown by the following figure. In the following text, the bit mask is expressed as a single byte that is applied to the least significant byte of the option number in unsigned integer representation. When bit 7 (the least significant bit) is 1, an option is Critical (and likewise Elective when 0). When bit 6 is 1, an option is Unsafe (and likewise Safe-to-Forward when 0). When bit 6 is 0, i.e., the option is not Unsafe, it is not a Cache-Key (NoCacheKey) if and only if bits 3-5 are all set to 1; all other bit combinations mean that it indeed is a Cache-Key. These classes of options are explained in the next sections.
更一般地说，一个选项编号由一个位掩码构成，用于指示一个选项是关键的还是可选的、不安全的还是安全转发的，并且在安全转发的情况下，提供一个缓存键指示，如下图所示，位掩码表示为应用于无符号整数表示的选项号最低有效字节的单个字节。当第7位（最低有效位）为1时，选项是关键的（当为0时也是可选的）。当第6位为1时，选项不安全（当为0时，同样可以安全转发）。当位6为0时，即该选项不是不安全的，当且仅当位3-5全部设置为1时，该选项不是缓存密钥（NoCacheKey）；所有其他位组合都意味着它确实是一个缓存键。这些选项类别将在下一节中解释。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| | NoCacheKey| U | C |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| | NoCacheKey| U | C |
+---+---+---+---+---+---+---+---+
Figure 10: Option Number Mask (Least Significant Byte)
图10：选项编号掩码（最低有效字节）
An endpoint may use an equivalent of the C code in Figure 11 to derive the characteristics of an option number "onum".
端点可以使用图11中C代码的等价物来推导选项号“onum”的特征。
Critical = (onum & 1);
UnSafe = (onum & 2);
NoCacheKey = ((onum & 0x1e) == 0x1c);
Critical = (onum & 1);
UnSafe = (onum & 2);
NoCacheKey = ((onum & 0x1e) == 0x1c);
Figure 11: Determining Characteristics from an Option Number
图11：从选项编号确定特性
The option numbers for the options defined in this document are listed in the "CoAP Option Numbers" registry (Section 12.2).
本文件中定义的选项编号列在“CoAP选项编号”注册表中（第12.2节）。
Both requests and responses may include a payload, depending on the Method or Response Code, respectively. If a Method or Response Code is not defined to have a payload, then a sender MUST NOT include one, and a recipient MUST ignore it.
请求和响应都可以包括有效负载，这分别取决于方法或响应代码。如果方法或响应代码未定义为具有有效负载，则发送方不得包含有效负载，接收方必须忽略有效负载。
The payload of requests or of responses indicating success is typically a representation of a resource ("resource representation") or the result of the requested action ("action result"). Its format is specified by the Internet media type and content coding given by the Content-Format Option. In the absence of this option, no default value is assumed, and the format will need to be inferred by the application (e.g., from the application context). Payload "sniffing" SHOULD only be attempted if no content type is given.
指示成功的请求或响应的有效负载通常是资源的表示（“资源表示”）或请求操作的结果（“操作结果”）。其格式由“内容格式”选项提供的Internet媒体类型和内容编码指定。如果没有此选项，则不会假定默认值，并且应用程序需要推断格式（例如，从应用程序上下文）。只有在未给出内容类型的情况下才应尝试有效负载“嗅探”。
Implementation Note: On a quality-of-implementation level, there is a strong expectation that a Content-Format indication will be provided with resource representations whenever possible. This is not a "SHOULD" level requirement solely because it is not a protocol requirement, and it also would be difficult to outline exactly in what cases this expectation can be violated.
实施说明：在实施质量级别上，人们强烈期望在可能的情况下为内容格式指示提供资源表示。这不是一个“应该”级别的要求，仅仅因为它不是一个协议要求，而且也很难准确地概述在什么情况下会违反这一期望。
For responses indicating a client or server error, the payload is considered a representation of the result of the requested action only if a Content-Format Option is given. In the absence of this option, the payload is a Diagnostic Payload (Section 5.5.2).
对于指示客户端或服务器错误的响应，只有在给定内容格式选项的情况下，负载才被视为请求操作结果的表示。在没有该选项的情况下，有效载荷为诊断有效载荷（第5.5.2节）。
If no Content-Format option is given, the payload of responses indicating a client or server error is a brief human-readable diagnostic message, explaining the error situation. This diagnostic message MUST be encoded using UTF-8 [RFC3629], more specifically using Net-Unicode form [RFC5198].
如果未提供内容格式选项，则指示客户端或服务器错误的响应负载是一条简短的人类可读诊断消息，用于解释错误情况。此诊断消息必须使用UTF-8[RFC3629]编码，更具体地说，使用Net Unicode格式[RFC5198]。
The message is similar to the Reason-Phrase on an HTTP status line. It is not intended for end users but for software engineers that during debugging need to interpret it in the context of the present, English-language specification; therefore, no mechanism for language tagging is needed or provided. In contrast to what is usual in HTTP, the payload SHOULD be empty if there is no additional information beyond the Response Code.
该消息类似于HTTP状态行上的原因短语。本规范不适用于最终用户，但适用于调试期间需要在当前英语规范上下文中解释本规范的软件工程师；因此，不需要或不提供语言标记机制。与HTTP中常见的情况相反，如果响应代码之外没有其他信息，则有效负载应该为空。
Not all responses carry a payload that provides a representation of the resource addressed by the request. It is, however, sometimes useful to be able to refer to such a representation in relation to a response, independent of whether it actually was enclosed.
并非所有的响应都携带一个有效负载，该负载提供了请求所处理的资源的表示。然而，有时能够提及与答复有关的这种表述是有用的，这与答复是否实际包含无关。
We use the term "selected representation" to refer to the current representation of a target resource that would have been selected in a successful response if the corresponding request had used the method GET and excluded any conditional request options (Section 5.10.8).
我们使用术语“选定表示法”来指如果相应请求使用了GET方法并排除了任何条件请求选项（第5.10.8节），则在成功响应中会选择的目标资源的当前表示法。
Certain response options provide metadata about the selected representation, which might differ from the representation included in the message for responses to some state-changing methods. Of the response options defined in this specification, only the ETag response option (Section 5.10.6) is defined as metadata about the selected representation.
某些响应选项提供有关所选表示的元数据，这可能不同于消息中包含的用于响应某些状态更改方法的表示。在本规范中定义的响应选项中，只有ETag响应选项（第5.10.6节）被定义为关于所选表示的元数据。
A server may be able to supply a representation for a resource in one of multiple representation formats. Without further information from the client, it will provide the representation in the format it prefers.
服务器可以以多种表示格式之一为资源提供表示。在没有客户提供进一步信息的情况下，它将以它喜欢的格式提供表示。
By using the Accept Option (Section 5.10.4) in a request, the client can indicate which content-format it prefers to receive.
通过在请求中使用“接受”选项（第5.10.4节），客户机可以指示其希望接收的内容格式。
CoAP endpoints MAY cache responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests.
CoAP端点可以缓存响应，以减少未来等效请求的响应时间和网络带宽消耗。
The goal of caching in CoAP is to reuse a prior response message to satisfy a current request. In some cases, a stored response can be reused without the need for a network request, reducing latency and network round-trips; a "freshness" mechanism is used for this purpose (see Section 5.6.1). Even when a new request is required, it is often possible to reuse the payload of a prior response to satisfy the request, thereby reducing network bandwidth usage; a "validation" mechanism is used for this purpose (see Section 5.6.2).
CoAP中缓存的目标是重用先前的响应消息以满足当前请求。在某些情况下，存储的响应可以在不需要网络请求的情况下重用，从而减少延迟和网络往返；为此，采用“新鲜度”机制（见第5.6.1节）。即使在需要新的请求时，通常也可以重用先前响应的有效负载以满足请求，从而减少网络带宽使用；为此，使用“验证”机制（见第5.6.2节）。
Unlike HTTP, the cacheability of CoAP responses does not depend on the request method, but it depends on the Response Code. The cacheability of each Response Code is defined along the Response Code definitions in Section 5.9. Response Codes that indicate success and are unrecognized by an endpoint MUST NOT be cached.
与HTTP不同，CoAP响应的可缓存性并不取决于请求方法，而是取决于响应代码。每个响应代码的可缓存性是按照第5.9节中的响应代码定义定义的。不能缓存指示成功且端点无法识别的响应代码。
For a presented request, a CoAP endpoint MUST NOT use a stored response, unless:
对于提交的请求，CoAP端点不得使用存储的响应，除非：
o the presented request method and that used to obtain the stored response match,
o 提供的请求方法和用于获取存储响应匹配的方法，
o all options match between those in the presented request and those of the request used to obtain the stored response (which includes the request URI), except that there is no need for a match of any request options marked as NoCacheKey (Section 5.4) or recognized by the Cache and fully interpreted with respect to its specified cache behavior (such as the ETag request option described in Section 5.10.6; see also Section 5.4.2), and
o 除了不需要匹配标记为NoCacheKey（第5.4节）或由缓存识别并根据其指定缓存行为完全解释的任何请求选项外，所呈现请求中的选项与用于获取存储响应（包括请求URI）的请求中的选项都匹配（如第5.10.6节所述的ETag请求选项；另见第5.4.2节），以及
o the stored response is either fresh or successfully validated as defined below.
o 存储的响应是新的或已成功验证，定义如下。
The set of request options that is used for matching the cache entry is also collectively referred to as the "Cache-Key". For URI schemes other than coap and coaps, matching of those options that constitute the request URI may be performed under rules specific to the URI scheme.
用于匹配缓存项的请求选项集也统称为“缓存密钥”。对于coap和coap以外的URI方案，可以根据特定于URI方案的规则来执行构成请求URI的那些选项的匹配。
When a response is "fresh" in the cache, it can be used to satisfy subsequent requests without contacting the origin server, thereby improving efficiency.
当响应在缓存中是“新的”时，可以使用它来满足后续请求，而无需联系源服务器，从而提高效率。
The mechanism for determining freshness is for an origin server to provide an explicit expiration time in the future, using the Max-Age Option (see Section 5.10.5). The Max-Age Option indicates that the response is to be considered not fresh after its age is greater than the specified number of seconds.
确定新鲜度的机制是，源服务器使用“最大年龄”选项（见第5.10.5节）在将来提供明确的过期时间。Max Age选项表示在响应的时间超过指定的秒数后，该响应将被视为不新鲜。
The Max-Age Option defaults to a value of 60. Thus, if it is not present in a cacheable response, then the response is considered not fresh after its age is greater than 60 seconds. If an origin server wishes to prevent caching, it MUST explicitly include a Max-Age Option with a value of zero seconds.
“最大年限”选项的默认值为60。因此，如果它不存在于可缓存响应中，则响应在其期限大于60秒后被视为不新鲜。如果源服务器希望阻止缓存，则必须显式包含一个值为零秒的Max Age选项。
If a client has a fresh stored response and makes a new request matching the request for that stored response, the new response invalidates the old response.
如果客户机有一个新存储的响应，并发出与该存储响应的请求相匹配的新请求，则新响应将使旧响应无效。
When an endpoint has one or more stored responses for a GET request, but cannot use any of them (e.g., because they are not fresh), it can use the ETag Option (Section 5.10.6) in the GET request to give the origin server an opportunity both to select a stored response to be used, and to update its freshness. This process is known as "validating" or "revalidating" the stored response.
当端点有一个或多个GET请求的存储响应，但无法使用其中任何响应（例如，因为它们不是最新的），它可以在GET请求中使用ETag选项（第5.10.6节），以便为源服务器提供选择要使用的存储响应和更新其新鲜度的机会。此过程称为“验证”或“重新验证”存储的响应。
When sending such a request, the endpoint SHOULD add an ETag Option specifying the entity-tag of each stored response that is applicable.
当发送这样的请求时，端点应该添加一个ETag选项，指定每个存储响应的实体标记。
A 2.03 (Valid) response indicates the stored response identified by the entity-tag given in the response's ETag Option can be reused after updating it as described in Section 5.9.1.3.
2.03（有效）响应表示由响应的ETag选项中给出的实体标记标识的存储响应可以在按照第5.9.1.3节所述更新后重用。
Any other Response Code indicates that none of the stored responses nominated in the request is suitable. Instead, the response SHOULD be used to satisfy the request and MAY replace the stored response.
任何其他响应代码都表明请求中指定的存储响应都不合适。相反，应该使用响应来满足请求，并且可以替换存储的响应。
A proxy is a CoAP endpoint that can be tasked by CoAP clients to perform requests on their behalf. This may be useful, for example, when the request could otherwise not be made, or to service the response from a cache in order to reduce response time and network bandwidth or energy consumption.
代理是CoAP端点，可由CoAP客户端委托其代表其执行请求。例如，当请求不能以其他方式发出时，或者为了减少响应时间和网络带宽或能量消耗而服务于来自高速缓存的响应时，这可能是有用的。
In an overall architecture for a Constrained RESTful Environment, proxies can serve quite different purposes. Proxies can be explicitly selected by clients, a role that we term "forward-proxy". Proxies can also be inserted to stand in for origin servers, a role that we term "reverse-proxy". Orthogonal to this distinction, a proxy can map from a CoAP request to a CoAP request (CoAP-to-CoAP proxy) or translate from or to a different protocol ("cross-proxy"). Full definitions of these terms are provided in Section 1.2.
在受限RESTful环境的总体架构中，代理可以服务于完全不同的目的。客户端可以显式选择代理，我们称之为“转发代理”。还可以插入代理来代替源服务器，我们称之为“反向代理”。与此区别正交，代理可以从CoAP请求映射到CoAP请求（CoAP到CoAP代理），或者从不同的协议转换到不同的协议（“交叉代理”）。第1.2节提供了这些术语的完整定义。
Notes: The terminology in this specification has been selected to be culturally compatible with the terminology used in the wider web application environments, without necessarily matching it in every detail (which may not even be relevant to Constrained RESTful Environments). Not too much semantics should be ascribed to the components of the terms (such as "forward", "reverse", or "cross").
注意：本规范中的术语在文化上与更广泛的web应用程序环境中使用的术语兼容，而不必在每个细节上都匹配（这甚至可能与受限RESTful环境无关）。不应将太多语义归因于术语的组成部分（如“正向”、“反向”或“交叉”）。
HTTP proxies, besides acting as HTTP proxies, often offer a transport-protocol proxying function ("CONNECT") to enable end-to-end transport layer security through the proxy. No such function is defined for CoAP-to-CoAP proxies in this specification, as forwarding of UDP packets is unlikely to be of much value in Constrained RESTful Environments. See also Section 10.2.7 for the cross-proxy case.
HTTP代理除了充当HTTP代理外，通常还提供传输协议代理功能（“CONNECT”），以通过代理实现端到端传输层安全。本规范中没有为CoAP到CoAP代理定义此类功能，因为UDP数据包的转发在受限RESTful环境中不太可能有多大价值。交叉代理案件另见第10.2.7节。
When a client uses a proxy to make a request that will use a secure URI scheme (e.g., "coaps" or "https"), the request towards the proxy SHOULD be sent using DTLS except where equivalent lower-layer security is used for the leg between the client and the proxy.
当客户端使用代理发出将使用安全URI方案（例如，“CoAP”或“https”）的请求时，应使用DTL发送对代理的请求，除非客户端和代理之间的分支使用等效的低层安全性。
A proxy generally needs a way to determine potential request parameters for a request it places to a destination, based on the request it received from its client. This way is fully specified for a forward-proxy but may depend on the specific configuration for a reverse-proxy. In particular, the client of a reverse-proxy generally does not indicate a locator for the destination,
代理通常需要一种方法，根据从其客户端接收到的请求，确定其向目的地发出的请求的潜在请求参数。这种方式完全针对正向代理指定，但可能取决于反向代理的特定配置。具体而言，反向代理的客户端通常不指示目的地的定位器，
necessitating some form of namespace translation in the reverse-proxy. However, some aspects of the operation of proxies are common to all its forms.
在反向代理中需要某种形式的名称空间转换。然而，代理操作的某些方面对其所有形式都是通用的。
If a proxy does not employ a cache, then it simply forwards the translated request to the determined destination. Otherwise, if it does employ a cache but does not have a stored response that matches the translated request and is considered fresh, then it needs to refresh its cache according to Section 5.6. For options in the request that the proxy recognizes, it knows whether the option is intended to act as part of the key used in looking up the cached value or not. For example, since requests for different Uri-Path values address different resources, Uri-Path values are always part of the Cache-Key, while, e.g., Token values are never part of the Cache-Key. For options that the proxy does not recognize but that are marked Safe-to-Forward in the option number, the option also indicates whether it is to be included in the Cache-Key (NoCacheKey is not all set) or not (NoCacheKey is all set). (Options that are unrecognized and marked Unsafe lead to 4.02 Bad Option.)
如果代理不使用缓存，那么它只是将转换后的请求转发到确定的目的地。否则，如果它确实使用了缓存，但没有与转换请求匹配的存储响应，并且被认为是新的，则需要根据第5.6节刷新其缓存。对于代理识别的请求中的选项，它知道该选项是否作为用于查找缓存值的键的一部分。例如，由于对不同Uri路径值的请求寻址不同的资源，因此Uri路径值始终是缓存密钥的一部分，而例如，令牌值永远不是缓存密钥的一部分。对于代理无法识别但在选项编号中标记为“安全转发”的选项，该选项还指示是否将其包括在缓存密钥中（NoCacheKey未全部设置）或未包括在缓存密钥中（NoCacheKey已全部设置）。（未识别并标记为不安全的选项将导致4.02坏选项。）
If the request to the destination times out, then a 5.04 (Gateway Timeout) response MUST be returned. If the request to the destination returns a response that cannot be processed by the proxy (e.g, due to unrecognized critical options or message format errors), then a 5.02 (Bad Gateway) response MUST be returned. Otherwise, the proxy returns the response to the client.
如果对目标的请求超时，则必须返回5.04（网关超时）响应。如果对目标的请求返回代理无法处理的响应（例如，由于无法识别的关键选项或消息格式错误），则必须返回5.02（坏网关）响应。否则，代理将向客户端返回响应。
If a response is generated out of a cache, the generated (or implied) Max-Age Option MUST NOT extend the max-age originally set by the server, considering the time the resource representation spent in the cache. For example, the Max-Age Option could be adjusted by the proxy for each response using the formula:
如果响应是从缓存中生成的，则考虑到资源表示在缓存中花费的时间，生成的（或隐含的）最大年龄选项不得扩展服务器最初设置的最大年龄。例如，代理可以使用以下公式为每个响应调整“最大年龄”选项：
proxy-max-age = original-max-age - cache-age
proxy-max-age = original-max-age - cache-age
For example, if a request is made to a proxied resource that was refreshed 20 seconds ago and had an original Max-Age of 60 seconds, then that resource's proxied max-age is now 40 seconds. Considering potential network delays on the way from the origin server, a proxy should be conservative in the max-age values offered.
例如，如果向20秒前刷新且原始最大使用时间为60秒的代理资源发出请求，则该资源的代理最大使用时间现在为40秒。考虑到从源服务器出发途中的潜在网络延迟，代理服务器应在提供的最大使用年限值内保持保守。
All options present in a proxy request MUST be processed at the proxy. Unsafe options in a request that are not recognized by the proxy MUST lead to a 4.02 (Bad Option) response being returned by the proxy. A CoAP-to-CoAP proxy MUST forward to the origin server all Safe-to-Forward options that it does not recognize. Similarly,
必须在代理服务器上处理代理请求中存在的所有选项。代理无法识别请求中的不安全选项必须导致代理返回4.02（错误选项）响应。CoAP到CoAP代理必须将其无法识别的所有安全转发选项转发到源服务器。同样地，
Unsafe options in a response that are not recognized by the CoAP-to-CoAP proxy server MUST lead to a 5.02 (Bad Gateway) response. Again, Safe-to-Forward options that are not recognized MUST be forwarded.
CoAP-to-CoAP代理服务器无法识别响应中的不安全选项必须导致5.02（坏网关）响应。同样，必须转发未识别的安全转发选项。
Additional considerations for cross-protocol proxying between CoAP and HTTP are discussed in Section 10.
第10节讨论了CoAP和HTTP之间跨协议代理的其他注意事项。
CoAP distinguishes between requests made (as if) to an origin server and requests made through a forward-proxy. CoAP requests to a forward-proxy are made as normal Confirmable or Non-confirmable requests to the forward-proxy endpoint, but they specify the request URI in a different way: The request URI in a proxy request is specified as a string in the Proxy-Uri Option (see Section 5.10.2), while the request URI in a request to an origin server is split into the Uri-Host, Uri-Port, Uri-Path, and Uri-Query Options (see Section 5.10.1). Alternatively, the URI in a proxy request can be assembled from a Proxy-Scheme option and the split options mentioned.
CoAP区分向源服务器发出的请求（好像）和通过转发代理发出的请求。对转发代理的CoAP请求作为对转发代理端点的正常可确认或不可确认请求发出，但它们以不同的方式指定请求URI：代理请求中的请求URI在代理URI选项中指定为字符串（参见第5.10.2节），而对源服务器的请求中的请求URI被分为URI主机、URI端口、URI路径和URI查询选项（参见第5.10.1节）。或者，代理请求中的URI可以从代理方案选项和前面提到的拆分选项组合而成。
When a proxy request is made to an endpoint and the endpoint is unwilling or unable to act as proxy for the request URI, it MUST return a 5.05 (Proxying Not Supported) response. If the authority (host and port) is recognized as identifying the proxy endpoint itself (see Section 5.10.2), then the request MUST be treated as a local (non-proxied) request.
当向端点发出代理请求且该端点不愿意或无法充当请求URI的代理时，它必须返回5.05（不支持代理）响应。如果认证机构（主机和端口）被识别为识别代理端点本身（参见第5.10.2节），则该请求必须被视为本地（非代理）请求。
Unless a proxy is configured to forward the proxy request to another proxy, it MUST translate the request as follows: the scheme of the request URI defines the outgoing protocol and its details (e.g., CoAP is used over UDP for the "coap" scheme and over DTLS for the "coaps" scheme.) For a CoAP-to-CoAP proxy, the origin server's IP address and port are determined by the authority component of the request URI, and the request URI is decoded and split into the Uri-Host, Uri-Port, Uri-Path and Uri-Query Options. This consumes the Proxy-Uri or Proxy-Scheme option, which is therefore not forwarded to the origin server.
除非将代理配置为将代理请求转发给另一个代理，否则它必须按如下方式转换请求：请求URI的方案定义传出协议及其详细信息（例如，CoAP通过UDP用于“CoAP”方案，通过DTL用于“CoAP”方案）。对于CoAP到CoAP代理，源服务器的IP地址和端口由请求URI的授权组件确定，请求URI被解码并拆分为URI主机、URI端口、URI路径和URI查询选项。这将使用代理Uri或代理方案选项，因此不会将其转发到源服务器。
Reverse-proxies do not make use of the Proxy-Uri or Proxy-Scheme options but need to determine the destination (next hop) of a request from information in the request and information in their configuration. For example, a reverse-proxy might offer various resources as if they were its own resources, after having learned of their existence through resource discovery. The reverse-proxy is free to build a namespace for the URIs that identify these resources. A reverse-proxy may also build a namespace that gives the client more
反向代理不使用代理Uri或代理方案选项，但需要根据请求中的信息及其配置中的信息确定请求的目的地（下一跳）。例如，在通过资源发现了解到各种资源的存在后，反向代理可能会像提供自己的资源一样提供各种资源。反向代理可以自由地为标识这些资源的URI构建名称空间。反向代理还可以构建一个命名空间，为客户端提供更多
control over where the request goes, e.g., by embedding host identifiers and port numbers into the URI path of the resources offered.
控制请求的去向，例如，通过将主机标识符和端口号嵌入到所提供资源的URI路径中。
In processing the response, a reverse-proxy has to be careful that ETag option values from different sources are not mixed up on one resource offered to its clients. In many cases, the ETag can be forwarded unchanged. If the mapping from a resource offered by the reverse-proxy to resources offered by its various origin servers is not unique, the reverse-proxy may need to generate a new ETag, making sure the semantics of this option are properly preserved.
在处理响应时，反向代理必须小心，不同来源的ETag选项值不会在提供给其客户端的一个资源上混淆。在许多情况下，ETag可以不加更改地转发。如果从反向代理提供的资源到其各种源服务器提供的资源的映射不是唯一的，则反向代理可能需要生成一个新的ETag，以确保正确保留此选项的语义。
In this section, each method is defined along with its behavior. A request with an unrecognized or unsupported Method Code MUST generate a 4.05 (Method Not Allowed) piggybacked response.
在本节中，将定义每个方法及其行为。具有无法识别或不支持的方法代码的请求必须生成4.05（不允许使用方法）附带响应。
The GET method retrieves a representation for the information that currently corresponds to the resource identified by the request URI. If the request includes an Accept Option, that indicates the preferred content-format of a response. If the request includes an ETag Option, the GET method requests that ETag be validated and that the representation be transferred only if validation failed. Upon success, a 2.05 (Content) or 2.03 (Valid) Response Code SHOULD be present in the response.
GET方法检索当前与请求URI标识的资源相对应的信息的表示形式。如果请求包含接受选项，则表示响应的首选内容格式。如果请求包含ETag选项，GET方法将请求验证ETag，并且仅当验证失败时才传输表示。成功后，响应中应显示2.05（内容）或2.03（有效）响应代码。
The GET method is safe and idempotent.
GET方法安全且幂等。
The POST method requests that the representation enclosed in the request be processed. The actual function performed by the POST method is determined by the origin server and dependent on the target resource. It usually results in a new resource being created or the target resource being updated.
POST方法请求处理请求中包含的表示。POST方法执行的实际功能由源服务器确定，并取决于目标资源。它通常会导致创建新资源或更新目标资源。
If a resource has been created on the server, the response returned by the server SHOULD have a 2.01 (Created) Response Code and SHOULD include the URI of the new resource in a sequence of one or more Location-Path and/or Location-Query Options (Section 5.10.7). If the POST succeeds but does not result in a new resource being created on the server, the response SHOULD have a 2.04 (Changed) Response Code. If the POST succeeds and results in the target resource being deleted, the response SHOULD have a 2.02 (Deleted) Response Code. POST is neither safe nor idempotent.
如果已在服务器上创建资源，则服务器返回的响应应具有2.01（已创建）响应代码，并应在一个或多个位置路径和/或位置查询选项的序列中包含新资源的URI（第5.10.7节）。如果POST成功但未导致在服务器上创建新资源，则响应应具有2.04（已更改）响应代码。如果POST成功并导致目标资源被删除，则响应应具有2.02（已删除）响应代码。POST既不安全也不幂等。
The PUT method requests that the resource identified by the request URI be updated or created with the enclosed representation. The representation format is specified by the media type and content coding given in the Content-Format Option, if provided.
PUT方法请求更新或创建由请求URI标识的资源，并使用封闭的表示。表示格式由“内容格式”选项（如果提供）中给出的媒体类型和内容编码指定。
If a resource exists at the request URI, the enclosed representation SHOULD be considered a modified version of that resource, and a 2.04 (Changed) Response Code SHOULD be returned. If no resource exists, then the server MAY create a new resource with that URI, resulting in a 2.01 (Created) Response Code. If the resource could not be created or modified, then an appropriate error Response Code SHOULD be sent.
如果请求URI中存在资源，则应将附带的表示形式视为该资源的修改版本，并应返回2.04（更改的）响应代码。如果不存在任何资源，则服务器可能会使用该URI创建一个新资源，从而生成一个2.01（已创建）响应代码。如果无法创建或修改资源，则应发送适当的错误响应代码。
Further restrictions to a PUT can be made by including the If-Match (see Section 5.10.8.1) or If-None-Match (see Section 5.10.8.2) options in the request.
通过在请求中包含If匹配（见第5.10.8.1节）或If不匹配（见第5.10.8.2节）选项，可以对卖出进行进一步限制。
PUT is not safe but is idempotent.
PUT不安全，但它是幂等的。
The DELETE method requests that the resource identified by the request URI be deleted. A 2.02 (Deleted) Response Code SHOULD be used on success or in case the resource did not exist before the request.
DELETE方法请求删除由请求URI标识的资源。如果请求成功或请求之前资源不存在，则应使用2.02（已删除）响应代码。
DELETE is not safe but is idempotent.
DELETE不安全，但它是幂等的。
Each Response Code is described below, including any options required in the response. Where appropriate, some of the codes will be specified in regards to related Response Codes in HTTP [RFC2616]; this does not mean that any such relationship modifies the HTTP mapping specified in Section 10.
每个响应代码如下所述，包括响应中所需的任何选项。在适当的情况下，将针对HTTP[RFC2616]中的相关响应代码指定一些代码；这并不意味着任何此类关系都会修改第10节中指定的HTTP映射。
This class of Response Code indicates that the clients request was successfully received, understood, and accepted.
此类响应代码表示客户端请求已成功接收、理解和接受。
Like HTTP 201 "Created", but only used in response to POST and PUT requests. The payload returned with the response, if any, is a representation of the action result.
与HTTP 201类似，“已创建”，但仅用于响应POST和PUT请求。与响应一起返回的有效负载（如果有）表示操作结果。
If the response includes one or more Location-Path and/or Location-Query Options, the values of these options specify the location at which the resource was created. Otherwise, the resource was created at the request URI. A cache receiving this response MUST mark any stored response for the created resource as not fresh.
如果响应包含一个或多个位置路径和/或位置查询选项，则这些选项的值将指定创建资源的位置。否则，将在请求URI处创建资源。接收此响应的缓存必须将所创建资源的任何已存储响应标记为非新响应。
This response is not cacheable.
此响应不可缓存。
This Response Code is like HTTP 204 "No Content" but only used in response to requests that cause the resource to cease being available, such as DELETE and, in certain circumstances, POST. The payload returned with the response, if any, is a representation of the action result.
此响应代码类似于HTTP 204“无内容”，但仅用于响应导致资源停止可用的请求，例如删除，在某些情况下，还用于发布。与响应一起返回的有效负载（如果有）表示操作结果。
This response is not cacheable. However, a cache MUST mark any stored response for the deleted resource as not fresh.
此响应不可缓存。但是，缓存必须将已删除资源的任何已存储响应标记为不新鲜。
This Response Code is related to HTTP 304 "Not Modified" but only used to indicate that the response identified by the entity-tag identified by the included ETag Option is valid. Accordingly, the response MUST include an ETag Option and MUST NOT include a payload.
此响应代码与HTTP 304“未修改”相关，但仅用于指示由包含的ETag选项标识的实体标记标识的响应有效。因此，响应必须包括ETag选项，并且不得包括有效载荷。
When a cache that recognizes and processes the ETag response option receives a 2.03 (Valid) response, it MUST update the stored response with the value of the Max-Age Option included in the response (explicitly, or implicitly as a default value; see also Section 5.6.2). For each type of Safe-to-Forward option present in the response, the (possibly empty) set of options of this type that are present in the stored response MUST be replaced with the set of options of this type in the response received. (Unsafe options may trigger similar option-specific processing as defined by the option.)
当识别和处理ETag响应选项的缓存接收到2.03（有效）响应时，它必须使用响应中包含的Max Age选项的值（显式或隐式作为默认值；另请参见第5.6.2节）更新存储的响应。对于响应中存在的每种类型的安全转发选项，必须将存储响应中存在的该类型选项集（可能为空）替换为接收到的响应中的该类型选项集。（不安全选项可能触发选项定义的类似特定于选项的处理。）
This Response Code is like HTTP 204 "No Content" but only used in response to POST and PUT requests. The payload returned with the response, if any, is a representation of the action result.
此响应代码类似于HTTP 204“无内容”，但仅用于响应POST和PUT请求。与响应一起返回的有效负载（如果有）表示操作结果。
This response is not cacheable. However, a cache MUST mark any stored response for the changed resource as not fresh.
此响应不可缓存。但是，缓存必须将已更改资源的任何存储响应标记为非新响应。
This Response Code is like HTTP 200 "OK" but only used in response to GET requests.
此响应代码类似于HTTP 200“OK”，但仅用于响应GET请求。
The payload returned with the response is a representation of the target resource.
与响应一起返回的有效负载是目标资源的表示。
This response is cacheable: Caches can use the Max-Age Option to determine freshness (see Section 5.6.1) and (if present) the ETag Option for validation (see Section 5.6.2).
该响应是可缓存的：缓存可使用最大年龄选项确定新鲜度（见第5.6.1节）和（如果存在）ETag选项进行验证（见第5.6.2节）。
This class of Response Code is intended for cases in which the client seems to have erred. These Response Codes are applicable to any request method.
此类响应代码适用于客户端似乎出错的情况。这些响应代码适用于任何请求方法。
The server SHOULD include a diagnostic payload under the conditions detailed in Section 5.5.2.
在第5.5.2节详述的条件下，服务器应包括诊断有效负载。
Responses of this class are cacheable: Caches can use the Max-Age Option to determine freshness (see Section 5.6.1). They cannot be validated.
此类响应可缓存：缓存可使用最大年龄选项确定新鲜度（见第5.6.1节）。它们无法验证。
This Response Code is Like HTTP 400 "Bad Request".
此响应代码类似于HTTP 400“错误请求”。
The client is not authorized to perform the requested action. The client SHOULD NOT repeat the request without first improving its authentication status to the server. Which specific mechanism can be used for this is outside this document's scope; see also Section 9.
客户端无权执行请求的操作。客户机不应在不首先改善其对服务器的身份验证状态的情况下重复请求。在本文件的范围之外，可以使用哪种具体机制来实现这一点；另见第9节。
The request could not be understood by the server due to one or more unrecognized or malformed options. The client SHOULD NOT repeat the request without modification.
由于一个或多个无法识别或格式不正确的选项，服务器无法理解该请求。未经修改，客户端不应重复请求。
This Response Code is like HTTP 403 "Forbidden".
此响应代码类似于HTTP 403“禁止”。
This Response Code is like HTTP 404 "Not Found".
此响应代码类似于HTTP 404“未找到”。
This Response Code is like HTTP 405 "Method Not Allowed" but with no parallel to the "Allow" header field.
此响应代码类似于HTTP 405“Method Not Allowed”，但与“Allow”头字段不平行。
This Response Code is like HTTP 406 "Not Acceptable", but with no response entity.
此响应代码类似于HTTP 406“不可接受”，但没有响应实体。
This Response Code is like HTTP 412 "Precondition Failed".
此响应代码类似于HTTP 412“前置条件失败”。
This Response Code is like HTTP 413 "Request Entity Too Large".
此响应代码类似于HTTP 413“请求实体太大”。
The response SHOULD include a Size1 Option (Section 5.10.9) to indicate the maximum size of request entity the server is able and willing to handle, unless the server is not in a position to make this information available.
响应应包括Size1选项（第5.10.9节），以指示服务器能够并愿意处理的请求实体的最大大小，除非服务器无法提供此信息。
This Response Code is like HTTP 415 "Unsupported Media Type".
此响应代码类似于HTTP 415“不支持的媒体类型”。
This class of Response Code indicates cases in which the server is aware that it has erred or is incapable of performing the request. These Response Codes are applicable to any request method.
此类响应代码表示服务器意识到其出错或无法执行请求的情况。这些响应代码适用于任何请求方法。
The server SHOULD include a diagnostic payload under the conditions detailed in Section 5.5.2.
在第5.5.2节详述的条件下，服务器应包括诊断有效负载。
Responses of this class are cacheable: Caches can use the Max-Age Option to determine freshness (see Section 5.6.1). They cannot be validated.
此类响应可缓存：缓存可使用最大年龄选项确定新鲜度（见第5.6.1节）。它们无法验证。
This Response Code is like HTTP 500 "Internal Server Error".
此响应代码类似于HTTP 500“内部服务器错误”。
This Response Code is like HTTP 501 "Not Implemented".
此响应代码类似于HTTP 501“未实现”。
This Response Code is like HTTP 502 "Bad Gateway".
此响应代码类似于HTTP 502“坏网关”。
This Response Code is like HTTP 503 "Service Unavailable" but uses the Max-Age Option in place of the "Retry-After" header field to indicate the number of seconds after which to retry.
此响应代码类似于HTTP 503“Service Unavailable”（服务不可用），但使用Max Age选项代替“Retry After”（重试后）标头字段，以指示重试后的秒数。
This Response Code is like HTTP 504 "Gateway Timeout".
此响应代码类似于HTTP 504“网关超时”。
The server is unable or unwilling to act as a forward-proxy for the URI specified in the Proxy-Uri Option or using Proxy-Scheme (see Section 5.10.2).
服务器无法或不愿意充当代理URI选项中指定的URI的转发代理或使用代理方案（见第5.10.2节）。
The individual CoAP options are summarized in Table 4 and explained in the subsections of this section.
表4总结了各个CoAP选项，并在本节小节中进行了解释。
In this table, the C, U, and N columns indicate the properties Critical, UnSafe, and NoCacheKey, respectively. Since NoCacheKey only has a meaning for options that are Safe-to-Forward (not marked Unsafe), the column is filled with a dash for UnSafe options.
在该表中，C、U和N列分别表示临界、不安全和NoCacheKey属性。由于NoCacheKey仅对可安全转发（未标记为不安全）的选项具有含义，因此该列用破折号填充不安全选项。
+-----+---+---+---+---+----------------+--------+--------+----------+
| No. | C | U | N | R | Name | Format | Length | Default |
+-----+---+---+---+---+----------------+--------+--------+----------+
| 1 | x | | | x | If-Match | opaque | 0-8 | (none) |
| 3 | x | x | - | | Uri-Host | string | 1-255 | (see |
| | | | | | | | | below) |
| 4 | | | | x | ETag | opaque | 1-8 | (none) |
| 5 | x | | | | If-None-Match | empty | 0 | (none) |
| 7 | x | x | - | | Uri-Port | uint | 0-2 | (see |
| | | | | | | | | below) |
| 8 | | | | x | Location-Path | string | 0-255 | (none) |
| 11 | x | x | - | x | Uri-Path | string | 0-255 | (none) |
| 12 | | | | | Content-Format | uint | 0-2 | (none) |
| 14 | | x | - | | Max-Age | uint | 0-4 | 60 |
| 15 | x | x | - | x | Uri-Query | string | 0-255 | (none) |
| 17 | x | | | | Accept | uint | 0-2 | (none) |
| 20 | | | | x | Location-Query | string | 0-255 | (none) |
| 35 | x | x | - | | Proxy-Uri | string | 1-1034 | (none) |
| 39 | x | x | - | | Proxy-Scheme | string | 1-255 | (none) |
| 60 | | | x | | Size1 | uint | 0-4 | (none) |
+-----+---+---+---+---+----------------+--------+--------+----------+
+-----+---+---+---+---+----------------+--------+--------+----------+
| No. | C | U | N | R | Name | Format | Length | Default |
+-----+---+---+---+---+----------------+--------+--------+----------+
| 1 | x | | | x | If-Match | opaque | 0-8 | (none) |
| 3 | x | x | - | | Uri-Host | string | 1-255 | (see |
| | | | | | | | | below) |
| 4 | | | | x | ETag | opaque | 1-8 | (none) |
| 5 | x | | | | If-None-Match | empty | 0 | (none) |
| 7 | x | x | - | | Uri-Port | uint | 0-2 | (see |
| | | | | | | | | below) |
| 8 | | | | x | Location-Path | string | 0-255 | (none) |
| 11 | x | x | - | x | Uri-Path | string | 0-255 | (none) |
| 12 | | | | | Content-Format | uint | 0-2 | (none) |
| 14 | | x | - | | Max-Age | uint | 0-4 | 60 |
| 15 | x | x | - | x | Uri-Query | string | 0-255 | (none) |
| 17 | x | | | | Accept | uint | 0-2 | (none) |
| 20 | | | | x | Location-Query | string | 0-255 | (none) |
| 35 | x | x | - | | Proxy-Uri | string | 1-1034 | (none) |
| 39 | x | x | - | | Proxy-Scheme | string | 1-255 | (none) |
| 60 | | | x | | Size1 | uint | 0-4 | (none) |
+-----+---+---+---+---+----------------+--------+--------+----------+
C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable
C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable
Table 4: Options
表4：备选方案
The Uri-Host, Uri-Port, Uri-Path, and Uri-Query Options are used to specify the target resource of a request to a CoAP origin server. The options encode the different components of the request URI in a way that no percent-encoding is visible in the option values and that the full URI can be reconstructed at any involved endpoint. The syntax of CoAP URIs is defined in Section 6.
Uri主机、Uri端口、Uri路径和Uri查询选项用于指定对CoAP源服务器的请求的目标资源。这些选项对请求URI的不同组件进行编码，使得在选项值中看不到百分比编码，并且可以在任何涉及的端点重构完整URI。第6节定义了CoAP URI的语法。
The steps for parsing URIs into options is defined in Section 6.4. These steps result in zero or more Uri-Host, Uri-Port, Uri-Path, and Uri-Query Options being included in a request, where each option holds the following values:
第6.4节定义了将URI解析为选项的步骤。这些步骤导致请求中包含零个或多个Uri主机、Uri端口、Uri路径和Uri查询选项，其中每个选项都包含以下值：
o the Uri-Host Option specifies the Internet host of the resource being requested,
o Uri主机选项指定所请求资源的Internet主机，
o the Uri-Port Option specifies the transport-layer port number of the resource,
o Uri端口选项指定资源的传输层端口号，
o each Uri-Path Option specifies one segment of the absolute path to the resource, and
o 每个Uri路径选项指定一段到资源的绝对路径，以及
o each Uri-Query Option specifies one argument parameterizing the resource.
o 每个Uri查询选项指定一个参数化资源。
Note: Fragments ([RFC3986], Section 3.5) are not part of the request URI and thus will not be transmitted in a CoAP request.
注意：片段（[RFC3986]，第3.5节）不是请求URI的一部分，因此不会在CoAP请求中传输。
The default value of the Uri-Host Option is the IP literal representing the destination IP address of the request message. Likewise, the default value of the Uri-Port Option is the destination UDP port. The default values for the Uri-Host and Uri-Port Options are sufficient for requests to most servers. Explicit Uri-Host and Uri-Port Options are typically used when an endpoint hosts multiple virtual servers.
Uri主机选项的默认值是表示请求消息的目标IP地址的IP文本。同样，Uri端口选项的默认值是目标UDP端口。Uri主机和Uri端口选项的默认值足以满足大多数服务器的请求。当端点承载多个虚拟服务器时，通常使用显式Uri主机和Uri端口选项。
The Uri-Path and Uri-Query Option can contain any character sequence. No percent-encoding is performed. The value of a Uri-Path Option MUST NOT be "." or ".." (as the request URI must be resolved before parsing it into options).
Uri路径和Uri查询选项可以包含任何字符序列。不执行百分比编码。Uri路径选项的值不能为“.”或“.”（因为必须在将请求Uri解析为选项之前解析请求Uri）。
The steps for constructing the request URI from the options are defined in Section 6.5. Note that an implementation does not necessarily have to construct the URI; it can simply look up the target resource by examining the individual options.
第6.5节定义了从选项构造请求URI的步骤。注意，实现不一定要构造URI；它可以通过检查各个选项简单地查找目标资源。
Examples can be found in Appendix B.
示例见附录B。
The Proxy-Uri Option is used to make a request to a forward-proxy (see Section 5.7). The forward-proxy is requested to forward the request or service it from a valid cache and return the response.
Proxy Uri选项用于向转发代理发出请求（参见第5.7节）。请求转发代理从有效缓存转发请求或为其提供服务，并返回响应。
The option value is an absolute-URI ([RFC3986], Section 4.3).
选项值是一个绝对URI（[RFC3986]，第4.3节）。
Note that the forward-proxy MAY forward the request on to another proxy or directly to the server specified by the absolute-URI. In order to avoid request loops, a proxy MUST be able to recognize all of its server names, including any aliases, local variations, and the numeric IP addresses.
请注意，转发代理可以将请求转发到另一个代理，也可以直接转发到绝对URI指定的服务器。为了避免请求循环，代理必须能够识别其所有服务器名称，包括任何别名、本地变体和数字IP地址。
An endpoint receiving a request with a Proxy-Uri Option that is unable or unwilling to act as a forward-proxy for the request MUST cause the return of a 5.05 (Proxying Not Supported) response.
接收具有代理Uri选项的请求的端点不能或不愿意充当该请求的转发代理，必须导致返回5.05（不支持代理）响应。
The Proxy-Uri Option MUST take precedence over any of the Uri-Host, Uri-Port, Uri-Path or Uri-Query options (each of which MUST NOT be included in a request containing the Proxy-Uri Option).
代理Uri选项必须优先于任何Uri主机、Uri端口、Uri路径或Uri查询选项（每个选项不得包含在包含代理Uri选项的请求中）。
As a special case to simplify many proxy clients, the absolute-URI can be constructed from the Uri-* options. When a Proxy-Scheme Option is present, the absolute-URI is constructed as follows: a CoAP URI is constructed from the Uri-* options as defined in Section 6.5. In the resulting URI, the initial scheme up to, but not including, the following colon is then replaced by the content of the Proxy-Scheme Option. Note that this case is only applicable if the components of the desired URI other than the scheme component actually can be expressed using Uri-* options; for example, to represent a URI with a userinfo component in the authority, only Proxy-Uri can be used.
作为简化许多代理客户端的特例，绝对URI可以从URI-*选项构造。当存在代理方案选项时，绝对URI的构造如下：CoAP URI由第6.5节中定义的URI-*选项构造而成。在生成的URI中，以下冒号之前（但不包括）的初始方案将替换为代理方案选项的内容。注意，仅当除了scheme组件之外的所需URI的组件实际上可以使用URI-*选项表示时，这种情况才适用；例如，要用授权中的userinfo组件表示URI，只能使用代理URI。
The Content-Format Option indicates the representation format of the message payload. The representation format is given as a numeric Content-Format identifier that is defined in the "CoAP Content-Formats" registry (Section 12.3). In the absence of the option, no default value is assumed, i.e., the representation format of any representation message payload is indeterminate (Section 5.5).
内容格式选项指示消息有效负载的表示格式。表示格式作为“CoAP内容格式”注册表中定义的数字内容格式标识符给出（第12.3节）。在没有选项的情况下，不假设任何默认值，即任何表示消息有效负载的表示格式是不确定的（第5.5节）。
The CoAP Accept option can be used to indicate which Content-Format is acceptable to the client. The representation format is given as a numeric Content-Format identifier that is defined in the "CoAP Content-Formats" registry (Section 12.3). If no Accept option is given, the client does not express a preference (thus no default value is assumed). The client prefers the representation returned by the server to be in the Content-Format indicated. The server returns the preferred Content-Format if available. If the preferred Content-Format cannot be returned, then a 4.06 "Not Acceptable" MUST be sent as a response, unless another error code takes precedence for this response.
CoAP Accept选项可用于指示客户可接受的内容格式。表示格式作为“CoAP内容格式”注册表中定义的数字内容格式标识符给出（第12.3节）。如果未给出接受选项，则客户机不表示偏好（因此不假定默认值）。客户端希望服务器返回的表示形式采用指定的内容格式。服务器返回首选的内容格式（如果可用）。如果无法返回首选内容格式，则必须将4.06“不可接受”作为响应发送，除非此响应优先使用其他错误代码。
The Max-Age Option indicates the maximum time a response may be cached before it is considered not fresh (see Section 5.6.1).
Max Age选项表示响应被视为不新鲜之前可以缓存的最长时间（见第5.6.1节）。
The option value is an integer number of seconds between 0 and 2**32-1 inclusive (about 136.1 years). A default value of 60 seconds is assumed in the absence of the option in a response.
选项值是介于0和2**32-1（含）之间的整数秒数（约136.1年）。如果响应中没有选项，则假定默认值为60秒。
The value is intended to be current at the time of transmission. Servers that provide resources with strict tolerances on the value of Max-Age SHOULD update the value before each retransmission. (See also Section 5.7.1.)
该值为传输时的当前值。为资源提供严格允许最大使用年限值的服务器应在每次重新传输之前更新该值。（另见第5.7.1节。）
An entity-tag is intended for use as a resource-local identifier for differentiating between representations of the same resource that vary over time. It is generated by the server providing the resource, which may generate it in any number of ways including a version, checksum, hash, or time. An endpoint receiving an entity-tag MUST treat it as opaque and make no assumptions about its content or structure. (Endpoints that generate an entity-tag are encouraged to use the most compact representation possible, in particular in regards to clients and intermediaries that may want to store multiple ETag values.)
实体标记用作资源本地标识符，用于区分随时间变化的同一资源的表示形式。它是由提供资源的服务器生成的，该服务器可以通过多种方式生成它，包括版本、校验和、哈希或时间。接收实体标记的端点必须将其视为不透明的，并且不对其内容或结构进行任何假设。（鼓励生成实体标记的端点使用尽可能紧凑的表示形式，特别是对于可能要存储多个ETag值的客户端和中介。）
The ETag Option in a response provides the current value (i.e., after the request was processed) of the entity-tag for the "tagged representation". If no Location-* options are present, the tagged representation is the selected representation (Section 5.5.3) of the target resource. If one or more Location-* options are present and thus a location URI is indicated (Section 5.10.7), the tagged representation is the representation that would be retrieved by a GET request to the location URI.
响应中的ETag选项为“标记的表示”提供实体标记的当前值（即，在处理请求之后）。如果不存在位置-*选项，则标记的表示是目标资源的选定表示（第5.5.3节）。如果存在一个或多个Location-*选项，并因此指示位置URI（第5.10.7节），则标记的表示是将由对位置URI的GET请求检索的表示。
An ETag response option can be included with any response for which there is a tagged representation (e.g., it would not be meaningful in a 4.04 or 4.00 response). The ETag Option MUST NOT occur more than once in a response.
ETag响应选项可以包含在任何带有标记表示的响应中（例如，在4.04或4.00响应中它没有意义）。ETag选项在响应中不得出现多次。
There is no default value for the ETag Option; if it is not present in a response, the server makes no statement about the entity-tag for the tagged representation.
ETag选项没有默认值；如果响应中没有实体标记，则服务器不会对标记表示的实体标记进行任何声明。
In a GET request, an endpoint that has one or more representations previously obtained from the resource, and has obtained ETag response options with these, can specify an instance of the ETag Option for one or more of these stored responses.
在GET请求中，具有先前从资源获得的一个或多个表示并已使用这些表示获得ETag响应选项的端点可以为一个或多个存储响应指定ETag选项的实例。
A server can issue a 2.03 Valid response (Section 5.9.1.3) in place of a 2.05 Content response if one of the ETags given is the entity-tag for the current representation, i.e., is valid; the 2.03 Valid response then echoes this specific ETag in a response option.
如果给定的ETag之一是当前表示的实体标记（即有效），则服务器可以发出2.03有效响应（第5.9.1.3节）代替2.05内容响应；然后，2.03有效响应在响应选项中回显此特定ETag。
In effect, a client can determine if any of the stored representations is current (see Section 5.6.2) without needing to transfer them again.
实际上，客户可以确定任何存储的表示是否为当前表示（见第5.6.2节），而无需再次传输。
The ETag Option MAY occur zero, one, or multiple times in a request.
ETag选项可能在一个请求中出现零次、一次或多次。
The Location-Path and Location-Query Options together indicate a relative URI that consists either of an absolute path, a query string, or both. A combination of these options is included in a 2.01 (Created) response to indicate the location of the resource created as the result of a POST request (see Section 5.8.2). The location is resolved relative to the request URI.
位置路径和位置查询选项一起指示由绝对路径、查询字符串或两者组成的相对URI。这些选项的组合包含在2.01（已创建）响应中，以指示因POST请求而创建的资源的位置（参见第5.8.2节）。相对于请求URI解析位置。
If a response with one or more Location-Path and/or Location-Query Options passes through a cache that interprets these options and the implied URI identifies one or more currently stored responses, those entries MUST be marked as not fresh.
如果具有一个或多个位置路径和/或位置查询选项的响应通过解释这些选项的缓存，并且隐含的URI标识了一个或多个当前存储的响应，则必须将这些条目标记为不新鲜。
Each Location-Path Option specifies one segment of the absolute path to the resource, and each Location-Query Option specifies one argument parameterizing the resource. The Location-Path and Location-Query Option can contain any character sequence. No percent-encoding is performed. The value of a Location-Path Option MUST NOT be "." or "..".
每个位置路径选项指定资源绝对路径的一段，每个位置查询选项指定一个参数化资源。位置路径和位置查询选项可以包含任何字符序列。不执行百分比编码。位置路径选项的值不能为“.”或“.”。
The steps for constructing the location URI from the options are analogous to Section 6.5, except that the first five steps are skipped and the result is a relative URI-reference, which is then interpreted relative to the request URI. Note that the relative URI-reference constructed this way always includes an absolute path (e.g., leaving out Location-Path but supplying Location-Query means the path component in the URI is "/").
从选项构造位置URI的步骤类似于第6.5节，只是跳过了前五个步骤，结果是相对URI引用，然后相对于请求URI进行解释。注意，以这种方式构造的相对URI引用始终包括绝对路径（例如，省略位置路径，但提供位置查询意味着URI中的路径组件为“/”）。
The options that are used to compute the relative URI-reference are collectively called Location-* options. Beyond Location-Path and Location-Query, more Location-* options may be defined in the future and have been reserved option numbers 128, 132, 136, and 140. If any of these reserved option numbers occurs in addition to Location-Path and/or Location-Query and are not supported, then a 4.02 (Bad Option) error MUST be returned.
用于计算相对URI引用的选项统称为Location-*选项。除了位置路径和位置查询，将来可能会定义更多的位置-*选项，并保留选项编号128、132、136和140。如果在位置路径和/或位置查询之外出现任何保留选项号，并且不受支持，则必须返回4.02（坏选项）错误。
Conditional request options enable a client to ask the server to perform the request only if certain conditions specified by the option are fulfilled.
条件请求选项允许客户端仅在满足选项指定的某些条件时才请求服务器执行请求。
For each of these options, if the condition given is not fulfilled, then the server MUST NOT perform the requested method. Instead, the server MUST respond with the 4.12 (Precondition Failed) Response Code.
对于这些选项中的每一个，如果未满足给定的条件，则服务器不得执行请求的方法。相反，服务器必须使用4.12（前提条件失败）响应代码进行响应。
If the condition is fulfilled, the server performs the request method as if the conditional request options were not present.
如果条件满足，服务器将执行请求方法，就像条件请求选项不存在一样。
If the request would, without the conditional request options, result in anything other than a 2.xx or 4.12 Response Code, then any conditional request options MAY be ignored.
如果在没有条件请求选项的情况下，请求将导致除2.xx或4.12响应代码以外的任何结果，则可能会忽略任何条件请求选项。
The If-Match Option MAY be used to make a request conditional on the current existence or value of an ETag for one or more representations of the target resource. If-Match is generally useful for resource update requests, such as PUT requests, as a means for protecting against accidental overwrites when multiple clients are acting in parallel on the same resource (i.e., the "lost update" problem).
If Match选项可用于使请求以目标资源的一个或多个表示的ETag的当前存在或值为条件。如果匹配通常对资源更新请求（如PUT请求）有用，作为防止多个客户端在同一资源上并行操作时意外覆盖的一种方法（即“丢失更新”问题）。
The value of an If-Match option is either an ETag or the empty string. An If-Match option with an ETag matches a representation with that exact ETag. An If-Match option with an empty value matches any existing representation (i.e., it places the precondition on the existence of any current representation for the target resource).
If Match选项的值是ETag或空字符串。带有ETag的If Match选项将表示形式与该确切ETag匹配。具有空值的If Match选项匹配任何现有表示（即，它将前提条件放在目标资源的任何当前表示的存在上）。
The If-Match Option can occur multiple times. If any of the options match, then the condition is fulfilled.
“如果匹配”选项可以出现多次。如果任何选项匹配，则满足条件。
If there is one or more If-Match Options, but none of the options match, then the condition is not fulfilled.
如果存在一个或多个If匹配选项，但所有选项均不匹配，则该条件不满足。
The If-None-Match Option MAY be used to make a request conditional on the nonexistence of the target resource. If-None-Match is useful for resource creation requests, such as PUT requests, as a means for protecting against accidental overwrites when multiple clients are acting in parallel on the same resource. The If-None-Match Option carries no value.
If None Match选项可用于使请求以目标资源不存在为条件。如果不匹配对于资源创建请求（如PUT请求）很有用，那么当多个客户端在同一资源上并行操作时，它可以作为防止意外覆盖的一种手段。If None Match选项不带任何值。
If the target resource does exist, then the condition is not fulfilled.
如果目标资源确实存在，则该条件不满足。
(It is not very useful to combine If-Match and If-None-Match options in one request, because the condition will then never be fulfilled.)
（在一个请求中组合If-Match和If-None-Match选项不是很有用，因为这样就永远不会满足条件。）
The Size1 option provides size information about the resource representation in a request. The option value is an integer number of bytes. Its main use is with block-wise transfers [BLOCK]. In the present specification, it is used in 4.13 responses (Section 5.9.2.9) to indicate the maximum size of request entity that the server is able and willing to handle.
Size1选项提供有关请求中资源表示的大小信息。选项值为整数字节数。它的主要用途是分块传输[分块]。在本规范中，它在4.13响应（第5.9.2.9节）中用于指示服务器能够并愿意处理的请求实体的最大大小。
CoAP uses the "coap" and "coaps" URI schemes for identifying CoAP resources and providing a means of locating the resource. Resources are organized hierarchically and governed by a potential CoAP origin server listening for CoAP requests ("coap") or DTLS-secured CoAP requests ("coaps") on a given UDP port. The CoAP server is identified via the generic syntax's authority component, which includes a host component and optional UDP port number. The remainder of the URI is considered to be identifying a resource that can be operated on by the methods defined by the CoAP protocol. The "coap" and "coaps" URI schemes can thus be compared to the "http" and "https" URI schemes, respectively.
CoAP使用“CoAP”和“CoAP”URI方案来标识CoAP资源并提供定位资源的方法。资源按层次结构组织，并由潜在的CoAP源服务器管理，该服务器在给定的UDP端口上侦听CoAP请求（“CoAP”）或DTLS安全的CoAP请求（“CoAP”）。CoAP服务器通过通用语法的授权组件标识，该组件包括主机组件和可选的UDP端口号。URI的其余部分被认为是标识可由CoAP协议定义的方法操作的资源。因此，“coap”和“coap”URI方案可以分别与“http”和“https”URI方案进行比较。
The syntax of the "coap" and "coaps" URI schemes is specified in this section in Augmented Backus-Naur Form (ABNF) [RFC5234]. The definitions of "host", "port", "path-abempty", "query", "segment", "IP-literal", "IPv4address", and "reg-name" are adopted from [RFC3986].
“coap”和“coap”URI方案的语法在本节中以增广的Backus Naur形式（ABNF）[RFC5234]进行了指定。“主机”、“端口”、“路径空”、“查询”、“段”、“IP文字”、“IPv4address”和“注册名”的定义采用[RFC3986]中的定义。
Implementation Note: Unfortunately, over time, the URI format has acquired significant complexity. Implementers are encouraged to examine [RFC3986] closely. For example, the ABNF for IPv6 addresses is more complicated than maybe expected. Also, implementers should take care to perform the processing of percent-decoding or percent-encoding exactly once on the way from a URI to its decoded components or back. Percent-encoding is crucial for data transparency but may lead to unusual results such as a slash character in a path component.
实现说明：不幸的是，随着时间的推移，URI格式变得非常复杂。鼓励实施者仔细检查[RFC3986]。例如，IPv6地址的ABNF比预期的要复杂。此外，实现者应该注意在从URI到其解码组件或返回的过程中，只执行一次百分比解码或百分比编码的处理。百分比编码对于数据透明性至关重要，但可能会导致不寻常的结果，如路径组件中的斜杠字符。
coap-URI = "coap:" "//" host [ ":" port ] path-abempty [ "?" query ]
coap-URI = "coap:" "//" host [ ":" port ] path-abempty [ "?" query ]
If the host component is provided as an IP-literal or IPv4address, then the CoAP server can be reached at that IP address. If host is a registered name, then that name is considered an indirect identifier and the endpoint might use a name resolution service, such as DNS, to find the address of that host. The host MUST NOT be empty; if a URI
如果主机组件作为IP文本或IPv4address提供，则可以通过该IP地址访问CoAP服务器。如果主机是注册的名称，则该名称被视为间接标识符，端点可能使用名称解析服务（如DNS）来查找该主机的地址。主机不能为空；如果一个URI
is received with a missing authority or an empty host, then it MUST be considered invalid. The port subcomponent indicates the UDP port at which the CoAP server is located. If it is empty or not given, then the default port 5683 is assumed.
接收时缺少授权或主机为空，则必须将其视为无效。port子组件表示CoAP服务器所在的UDP端口。如果为空或未给定，则假定默认端口5683。
The path identifies a resource within the scope of the host and port. It consists of a sequence of path segments separated by a slash character (U+002F SOLIDUS "/").
路径标识主机和端口范围内的资源。它由一系列由斜杠字符（U+002F SOLIDUS“/）分隔的路径段组成。
The query serves to further parameterize the resource. It consists of a sequence of arguments separated by an ampersand character (U+0026 AMPERSAND "&"). An argument is often in the form of a "key=value" pair.
查询用于进一步参数化资源。它由一系列参数组成，由一个符号和字符（U+0026符号和“&”）分隔。参数通常是“key=value”对的形式。
The "coap" URI scheme supports the path prefix "/.well-known/" defined by [RFC5785] for "well-known locations" in the namespace of a host. This enables discovery of policy or other information about a host ("site-wide metadata"), such as hosted resources (see Section 7).
“coap”URI方案支持[RFC5785]为主机命名空间中的“已知位置”定义的路径前缀“/.well-known/”。这允许发现有关主机的策略或其他信息（“站点范围元数据”），例如托管资源（请参见第7节）。
Application designers are encouraged to make use of short but descriptive URIs. As the environments that CoAP is used in are usually constrained for bandwidth and energy, the trade-off between these two qualities should lean towards the shortness, without ignoring descriptiveness.
鼓励应用程序设计人员使用简短但描述性的URI。由于使用CoAP的环境通常受到带宽和能量的限制，这两种质量之间的权衡应该倾向于简短，而不忽略描述性。
coaps-URI = "coaps:" "//" host [ ":" port ] path-abempty
[ "?" query ]
coaps-URI = "coaps:" "//" host [ ":" port ] path-abempty
[ "?" query ]
All of the requirements listed above for the "coap" scheme are also requirements for the "coaps" scheme, except that a default UDP port of 5684 is assumed if the port subcomponent is empty or not given, and the UDP datagrams MUST be secured through the use of DTLS as described in Section 9.1.
上述“coap”方案的所有要求也是“coap”方案的要求，但如果端口子组件为空或未给定，则假定默认UDP端口为5684，并且UDP数据报必须通过使用第9.1节所述DTL进行保护。
Considerations for caching of responses to "coaps" identified requests are discussed in Section 11.2.
第11.2节讨论了缓存“CoAP”识别请求响应的注意事项。
Resources made available via the "coaps" scheme have no shared identity with the "coap" scheme even if their resource identifiers indicate the same authority (the same host listening to the same UDP port). They are distinct namespaces and are considered to be distinct origin servers.
通过“coap”方案提供的资源与“coap”方案没有共享标识，即使其资源标识符指示相同的权限（同一主机侦听相同的UDP端口）。它们是不同的名称空间，被认为是不同的源服务器。
Since the "coap" and "coaps" schemes conform to the URI generic syntax, such URIs are normalized and compared according to the algorithm defined in [RFC3986], Section 6, using the defaults described above for each scheme.
由于“coap”和“coap”方案符合URI通用语法，因此根据[RFC3986]第6节中定义的算法，使用上述每个方案的默认值对此类URI进行规范化和比较。
If the port is equal to the default port for a scheme, the normal form is to elide the port subcomponent. Likewise, an empty path component is equivalent to an absolute path of "/", so the normal form is to provide a path of "/" instead. The scheme and host are case insensitive and normally provided in lowercase; IP-literals are in recommended form [RFC5952]; all other components are compared in a case-sensitive manner. Characters other than those in the "reserved" set are equivalent to their percent-encoded bytes (see [RFC3986], Section 2.1): the normal form is to not encode them.
如果端口等于方案的默认端口，则标准形式是删除端口子组件。同样，空路径组件相当于绝对路径“/”，因此标准形式是提供路径“/”。scheme和host不区分大小写，通常以小写形式提供；IP文本采用推荐格式[RFC5952]；以区分大小写的方式比较所有其他组件。“保留”集中的字符以外的字符相当于其编码字节的百分比（参见[RFC3986]，第2.1节）：正常形式是不对其进行编码。
For example, the following three URIs are equivalent and cause the same options and option values to appear in the CoAP messages:
例如，以下三个URI是等效的，并导致相同的选项和选项值出现在CoAP消息中：
coap://example.com:5683/~sensors/temp.xml
coap://EXAMPLE.com/%7Esensors/temp.xml
coap://EXAMPLE.com:/%7esensors/temp.xml
coap://example.com:5683/~sensors/temp.xml
coap://EXAMPLE.com/%7Esensors/temp.xml
coap://EXAMPLE.com:/%7esensors/temp.xml
The steps to parse a request's options from a string |url| are as follows. These steps either result in zero or more of the Uri-Host, Uri-Port, Uri-Path, and Uri-Query Options being included in the request or they fail.
从字符串| url |解析请求选项的步骤如下。这些步骤要么导致请求中包含零个或多个Uri主机、Uri端口、Uri路径和Uri查询选项，要么失败。
1. If the |url| string is not an absolute URI ([RFC3986]), then fail this algorithm.
1. 如果| url |字符串不是绝对URI（[RFC3986]），则此算法失败。
2. Resolve the |url| string using the process of reference resolution defined by [RFC3986]. At this stage, the URL is in ASCII encoding [RFC0020], even though the decoded components will be interpreted in UTF-8 [RFC3629] after steps 5, 8, and 9.
2. 使用[RFC3986]定义的引用解析过程解析| url |字符串。在此阶段，URL采用ASCII编码[RFC0020]，即使在步骤5、8和9之后解码的组件将以UTF-8[RFC3629]进行解释。
NOTE: It doesn't matter what it is resolved relative to, since we already know it is an absolute URL at this point.
注意：它是相对于什么解析的并不重要，因为我们现在已经知道它是一个绝对URL。
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”，则此算法失败。
4. If |url| has a <fragment> component, then fail this algorithm.
4. 如果| url |有一个<fragment>组件，则此算法失败。
5. If the <host> component of |url| does not represent the request's destination IP address as an IP-literal or IPv4address, include a Uri-Host Option and let that option's value be the value of the <host> component of |url|, converted to ASCII lowercase, and then convert all percent-encodings ("%" followed by two hexadecimal digits) to the corresponding characters.
5. 如果| url |的<host>组件未将请求的目标IP地址表示为IP文本或IPv4address，请包含Uri主机选项，并将该选项的值设为| url |的<host>组件的值，转换为ASCII小写，然后转换所有百分比编码（“%”后跟两个十六进制数字）到相应的字符。
NOTE: In the usual case where the request's destination IP address is derived from the host part, this ensures that a Uri-Host Option is only used for a <host> component of the form reg-name.
注意：在通常情况下，请求的目标IP地址是从主机部分派生的，这确保Uri主机选项仅用于reg name格式的<host>组件。
6. If |url| has a <port> component, then let |port| be that component's value interpreted as a decimal integer; otherwise, let |port| be the default port for the scheme.
6. 如果| url |有一个<port>组件，那么让| port |作为该组件的值，解释为十进制整数；否则，让| port |作为方案的默认端口。
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 |。
8. If the value of the <path> component of |url| is empty or consists of a single slash character (U+002F SOLIDUS "/"), then move to the next step.
8. 如果| url |的<path>组件的值为空或由单个斜杠字符（U+002F SOLIDUS/）组成，则转到下一步。
Otherwise, for each segment in the <path> component, include a Uri-Path Option and let that option's value be the segment (not including the delimiting slash characters) after converting each percent-encoding ("%" followed by two hexadecimal digits) to the corresponding byte.
否则，对于<path>组件中的每个段，在将每个百分比编码（“%”后跟两个十六进制数字）转换为相应字节后，包括一个Uri path选项，并让该选项的值为段（不包括分隔斜杠字符）。
9. If |url| has a <query> component, then, for each argument in the <query> component, include a Uri-Query Option and let that option's value be the argument (not including the question mark and the delimiting ampersand characters) after converting each percent-encoding to the corresponding byte.
9. 如果| url |有一个<query>组件，那么对于<query>组件中的每个参数，在将每个百分比编码转换为相应字节后，包括一个Uri查询选项，并将该选项的值作为参数（不包括问号和定界符和字符）。
Note that these rules completely resolve any percent-encoding.
请注意，这些规则完全解析任何百分比编码。
The steps to construct a URI from a request's options are as follows. These steps either result in a URI or they fail. In these steps, percent-encoding a character means replacing each of its (UTF-8-encoded) bytes by a "%" character followed by two hexadecimal digits representing the byte, where the digits A-F are in uppercase (as defined in Section 2.1 of [RFC3986]; to reduce variability, the hexadecimal notation for percent-encoding in CoAP URIs MUST use uppercase letters). The definitions of "unreserved" and "sub-delims" are adopted from [RFC3986].
从请求的选项构造URI的步骤如下。这些步骤要么导致URI，要么失败。在这些步骤中，字符百分比编码意味着用“%”字符替换其每个（UTF-8编码）字节，后跟表示字节的两个十六进制数字，其中数字a-F为大写（如[RFC3986]第2.1节中的定义）；为了减少可变性，CoAP URI中百分比编码的十六进制表示法必须使用大写字母）。“无保留”和“子文件”的定义采用[RFC3986]中的定义。
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://”。
2. If the request includes a Uri-Host Option, let |host| be that option's value, where any non-ASCII characters are replaced by their corresponding percent-encoding. If |host| is not a valid reg-name or IP-literal or IPv4address, fail the algorithm. If the request does not include a Uri-Host Option, let |host| be the IP-literal (making use of the conventions of [RFC5952]) or IPv4address representing the request's destination IP address.
2. 如果请求包含一个Uri主机选项，则将| Host |作为该选项的值，其中任何非ASCII字符都将替换为相应的百分比编码。如果| host |不是有效的注册表名或IP文本或IPv4address，则使算法失败。如果请求不包括Uri主机选项，则将| Host |设为IP文本（使用[RFC5952]的约定）或表示请求目标IP地址的IPv4address。
3. Append |host| to |url|.
3. 将|主机|附加到| url |。
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端口。
5. If |port| is not the default port for the scheme, then append a single U+003A COLON character (:) followed by the decimal representation of |port| to |url|.
5. 如果| port |不是方案的默认端口，则在| url |后附加一个U+003A冒号字符（：），后跟| port |的十进制表示形式。
6. Let |resource name| be the empty string. For each Uri-Path Option in the request, append a single character U+002F SOLIDUS (/) followed by the option's value to |resource name|, after converting any character that is not either in the "unreserved" set, in the "sub-delims" set, a U+003A COLON (:) character, or a U+0040 COMMERCIAL AT (@) character to its percent-encoded form.
6. 设| resource name |为空字符串。对于请求中的每个Uri路径选项，在将任何不在“未保留”集中、“子delims”集中的字符、U+003A冒号（：）字符或U+0040商业AT（@）字符转换为其百分比编码形式后，将单个字符U+002F SOLIDUS（/）后跟选项值附加到| resource name |。
7. If |resource name| is the empty string, set it to a single character U+002F SOLIDUS (/).
7. 如果| resource name |是空字符串，则将其设置为单个字符U+002F SOLIDUS（/）。
8. For each Uri-Query Option in the request, append a single character U+003F QUESTION MARK (?) (first option) or U+0026 AMPERSAND (&) (subsequent options) followed by the option's value to |resource name|, after converting any character that is not either in the "unreserved" set, in the "sub-delims" set (except U+0026 AMPERSAND (&)), a U+003A COLON (:), a U+0040 COMMERCIAL AT (@), a U+002F SOLIDUS (/), or a U+003F QUESTION MARK (?) character to its percent-encoded form.
8. 对于请求中的每个Uri查询选项，在转换“unreserved”集中不存在的任何字符后，在“sub-delims”集中（U+0026和（&）除外）添加一个字符U+003F问号（？）（第一个选项）或U+0026和（&）（后续选项），然后将选项的值添加到| resource name |，即U+003A冒号（：）、U+0040商业AT（@）、U+002F索利多金币（/）或U+003F问号（？）字符的百分比编码形式。
9. Append |resource name| to |url|.
9. 将|资源名称|附加到| url |。
10. Return |url|.
10. 返回| url |。
Note that these steps have been designed to lead to a URI in normal form (see Section 6.3).
请注意，这些步骤旨在生成一个标准形式的URI（参见第6.3节）。
As a part of discovering the services offered by a CoAP server, a client has to learn about the endpoint used by a server.
作为发现CoAP服务器提供的服务的一部分，客户机必须了解服务器使用的端点。
A server is discovered by a client (knowing or) learning a URI that references a resource in the namespace of the server. Alternatively, clients can use multicast CoAP (see Section 8) and the "All CoAP Nodes" multicast address to find CoAP servers.
客户端（知道或）学习引用服务器命名空间中资源的URI时，会发现服务器。或者，客户端可以使用多播CoAP（参见第8节）和“所有CoAP节点”多播地址来查找CoAP服务器。
Unless the port subcomponent in a "coap" or "coaps" URI indicates the UDP port at which the CoAP server is located, the server is assumed to be reachable at the default port.
除非“coap”或“coaps”URI中的端口子组件指示coap服务器所在的UDP端口，否则假定服务器可以在默认端口访问。
The CoAP default port number 5683 MUST be supported by a server that offers resources for resource discovery (see Section 7.2 below) and SHOULD be supported for providing access to other resources. The default port number 5684 for DTLS-secured CoAP MAY be supported by a server for resource discovery and for providing access to other resources. In addition, other endpoints may be hosted at other ports, e.g., in the dynamic port space.
为资源发现提供资源的服务器必须支持CoAP默认端口号5683（请参见下面的第7.2节），并应支持该端口号以提供对其他资源的访问。DTLS安全CoAP的默认端口号5684可由服务器支持，用于资源发现和提供对其他资源的访问。此外，其他端点可以托管在其他端口上，例如，在动态端口空间中。
Implementation Note: When a CoAP server is hosted by a 6LoWPAN node, header compression efficiency is improved when it also supports a port number in the 61616-61631 compressed UDP port space defined in [RFC4944] and [RFC6282]. (Note that, as its UDP port differs from the default port, it is a different endpoint from the server at the default port.)
实施说明：当CoAP服务器由6LoWPAN节点托管时，如果它还支持[RFC4944]和[RFC6282]中定义的61616-61631压缩UDP端口空间中的端口号，则可以提高标头压缩效率。（请注意，由于其UDP端口与默认端口不同，因此它与默认端口处的服务器是不同的端点。）
The discovery of resources offered by a CoAP endpoint is extremely important in machine-to-machine applications where there are no humans in the loop and static interfaces result in fragility. To maximize interoperability in a CoRE environment, a CoAP endpoint SHOULD support the CoRE Link Format of discoverable resources as described in [RFC6690], except where fully manual configuration is desired. It is up to the server which resources are made discoverable (if any).
The discovery of resources offered by a CoAP endpoint is extremely important in machine-to-machine applications where there are no humans in the loop and static interfaces result in fragility. To maximize interoperability in a CoRE environment, a CoAP endpoint SHOULD support the CoRE Link Format of discoverable resources as described in [RFC6690], except where fully manual configuration is desired. It is up to the server which resources are made discoverable (if any).translate error, please retry
This section defines a new Web Linking [RFC5988] attribute for use with [RFC6690]. The Content-Format code "ct" attribute provides a hint about the Content-Formats this resource returns. Note that this is only a hint, and it does not override the Content-Format Option of
本节定义了与[RFC6690]一起使用的新Web链接[RFC5988]属性。内容格式代码“ct”属性提供了有关此资源返回的内容格式的提示。请注意，这只是一个提示，并不覆盖的内容格式选项
a CoAP response obtained by actually requesting the representation of the resource. The value is in the CoAP identifier code format as a decimal ASCII integer and MUST be in the range of 0-65535 (16-bit unsigned integer). For example, "application/xml" would be indicated as "ct=41". If no Content-Format code attribute is present, then nothing about the type can be assumed. The Content-Format code attribute MAY include a space-separated sequence of Content-Format codes, indicating that multiple content-formats are available. The syntax of the attribute value is summarized in the production "ct-value" in Figure 12, where "cardinal", "SP", and "DQUOTE" are defined as in [RFC6690].
通过实际请求资源的表示而获得的CoAP响应。该值采用CoAP标识符代码格式，为十进制ASCII整数，且必须在0-65535（16位无符号整数）范围内。例如，“application/xml”将表示为“ct=41”。如果不存在“内容格式代码”属性，则不能假定与类型有关的任何内容。内容格式代码属性可以包括以空格分隔的内容格式代码序列，指示多个内容格式可用。属性值的语法总结在图12中的产品“ct值”中，其中“基数”、“SP”和“DQUOTE”的定义如[RFC6690]所示。
ct-value = cardinal
/ DQUOTE cardinal *( 1*SP cardinal ) DQUOTE
ct-value = cardinal
/ DQUOTE cardinal *( 1*SP cardinal ) DQUOTE
Figure 12
图12
CoAP supports making requests to an IP multicast group. This is defined by a series of deltas to unicast CoAP. A more general discussion of group communication with CoAP is in [GROUPCOMM].
CoAP支持向IP多播组发出请求。这是由一系列到单播CoAP的增量定义的。[GROUPCOMM]中对与CoAP的团体沟通进行了更一般性的讨论。
CoAP endpoints that offer services that they want other endpoints to be able to find using multicast service discovery join one or more of the appropriate all-CoAP-node multicast addresses (Section 12.8) and listen on the default CoAP port. Note that an endpoint might receive multicast requests on other multicast addresses, including the all-nodes IPv6 address (or via broadcast on IPv4); an endpoint MUST therefore be prepared to receive such messages but MAY ignore them if multicast service discovery is not desired.
提供他们希望其他端点能够使用多播服务发现找到的服务的CoAP端点加入一个或多个适当的所有CoAP节点多播地址（第12.8节），并侦听默认CoAP端口。请注意，端点可能会在其他多播地址上接收多播请求，包括所有节点的IPv6地址（或通过IPv4上的广播）；因此，端点必须准备好接收此类消息，但如果不需要多播服务发现，则可以忽略这些消息。
A multicast request is characterized by being transported in a CoAP message that is addressed to an IP multicast address instead of a CoAP endpoint. Such multicast requests MUST be Non-confirmable.
多播请求的特征是在CoAP消息中传输，该消息被寻址到IP多播地址而不是CoAP端点。此类多播请求必须是不可确认的。
A server SHOULD be aware that a request arrived via multicast, e.g., by making use of modern APIs such as IPV6_RECVPKTINFO [RFC3542], if available.
服务器应该知道请求是通过多播到达的，例如，通过使用现代API，如IPV6_RECVPKTINFO[RFC3542]，如果可用。
To avoid an implosion of error responses, when a server is aware that a request arrived via multicast, it MUST NOT return a Reset message in reply to a Non-confirmable message. If it is not aware, it MAY return a Reset message in reply to a Non-confirmable message as usual. Because such a Reset message will look identical to one for a
为了避免错误响应的内爆，当服务器意识到通过多播到达的请求时，它不能返回重置消息来回复不可确认的消息。如果它不知道，它可能会像往常一样返回一条重置消息，作为对不可确认消息的回复。因为这样的重置消息看起来与
unicast message from the sender, the sender MUST avoid using a Message ID that is also still active from this endpoint with any unicast endpoint that might receive the multicast message.
从发送方发送的单播消息，发送方必须避免将此端点中仍处于活动状态的消息ID与可能接收多播消息的任何单播端点一起使用。
At the time of writing, multicast messages can only be carried in UDP not in DTLS. This means that the security modes defined for CoAP in this document are not applicable to multicast.
在编写本文时，多播消息只能在UDP中传输，而不能在DTL中传输。这意味着本文档中为CoAP定义的安全模式不适用于多播。
When a server is aware that a request arrived via multicast, the server MAY always ignore the request, in particular if it doesn't have anything useful to respond (e.g., if it only has an empty payload or an error response). The decision for this may depend on the application. (For example, in query filtering as described in [RFC6690], a server should not respond to a multicast request if the filter does not match. More examples are in [GROUPCOMM].)
当服务器意识到通过多播到达的请求时，服务器可能总是忽略该请求，特别是如果它没有任何有用的响应（例如，如果它只有空负载或错误响应）。对此的决定可能取决于应用程序。（例如，在[RFC6690]中描述的查询筛选中，如果筛选器不匹配，服务器不应响应多播请求。更多示例见[GROUPCOMM]。）
If a server does decide to respond to a multicast request, it should not respond immediately. Instead, it should pick a duration for the period of time during which it intends to respond. For the purposes of this exposition, we call the length of this period the Leisure. The specific value of this Leisure may depend on the application or MAY be derived as described below. The server SHOULD then pick a random point of time within the chosen leisure period to send back the unicast response to the multicast request. If further responses need to be sent based on the same multicast address membership, a new leisure period starts at the earliest after the previous one finishes.
如果服务器决定响应多播请求，则不应立即响应。相反，它应该为它打算做出响应的时间段选择一个持续时间。为了这一论述的目的，我们称这一时期的长度为休闲。此休闲的具体值可能取决于应用程序，也可能如下文所述得出。然后，服务器应在所选空闲时间内选择一个随机时间点，将单播响应发送回多播请求。如果需要基于相同的多播地址成员身份发送进一步的响应，则新的空闲时间最早在前一个空闲时间结束后开始。
To compute a value for Leisure, the server should have a group size estimate G, a target data transfer rate R (which both should be chosen conservatively), and an estimated response size S; a rough lower bound for Leisure can then be computed as
为了计算空闲值，服务器应当具有组大小估计值G、目标数据传输速率R（两者都应当保守地选择）和估计响应大小S；休闲的粗略下限可以计算为
lb_Leisure = S * G / R
lb_Leisure = S * G / R
For example, for a multicast request with link-local scope on a 2.4 GHz IEEE 802.15.4 (6LoWPAN) network, G could be (relatively conservatively) set to 100, S to 100 bytes, and the target rate to 8 kbit/s = 1 kB/s. The resulting lower bound for the Leisure is 10 seconds.
例如，对于2.4 GHz IEEE 802.15.4（6LoWPAN）网络上具有链路本地作用域的多播请求，G可以（相对保守地）设置为100，S到100字节，目标速率为8 kbit/S=1 kB/S。休闲的结果下限为10秒。
If a CoAP endpoint does not have suitable data to compute a value for Leisure, it MAY resort to DEFAULT_LEISURE.
如果CoAP端点没有合适的数据来计算休闲值，它可能会求助于默认的休闲。
When matching a response to a multicast request, only the token MUST match; the source endpoint of the response does not need to (and will not) be the same as the destination endpoint of the original request.
当匹配多播请求的响应时，只有令牌必须匹配；响应的源端点不需要（也不会）与原始请求的目标端点相同。
For the purposes of interpreting the Location-* options and any links embedded in the representation, the request URI (i.e., the base URI relative to which the response is interpreted) is formed by replacing the multicast address in the Host component of the original request URI by the literal IP address of the endpoint actually responding.
为了解释Location-*选项和嵌入在表示中的任何链接，请求URI（即，相对于响应被解释的基本URI）是通过将原始请求URI的主机组件中的多播地址替换为实际响应的端点的文本IP地址而形成的。
When a client makes a multicast request, it always makes a new request to the multicast group (since there may be new group members that joined meanwhile or ones that did not get the previous request). It MAY update a cache with the received responses. Then, it uses both cached-still-fresh and new responses as the result of the request.
当客户端发出多播请求时，它总是向多播组发出一个新请求（因为可能有新的组成员同时加入，或者有一些成员没有收到以前的请求）。它可以用接收到的响应更新缓存。然后，它使用缓存的仍然新鲜的响应和新响应作为请求的结果。
A response received in reply to a GET request to a multicast group MAY be used to satisfy a subsequent request on the related unicast request URI. The unicast request URI is obtained by replacing the authority part of the request URI with the transport-layer source address of the response message.
为响应对多播组的GET请求而接收的响应可用于满足相关单播请求URI上的后续请求。通过将请求URI的授权部分替换为响应消息的传输层源地址来获得单播请求URI。
A cache MAY revalidate a response by making a GET request on the related unicast request URI.
缓存可以通过对相关的单播请求URI发出GET请求来重新验证响应。
A GET request to a multicast group MUST NOT contain an ETag option. A mechanism to suppress responses the client already has is left for further study.
对多播组的GET请求不得包含ETag选项。抑制客户已有反应的机制有待进一步研究。
When a forward-proxy receives a request with a Proxy-Uri or URI constructed from Proxy-Scheme that indicates a multicast address, the proxy obtains a set of responses as described above and sends all responses (both cached-still-fresh and new) back to the original client.
当转发代理接收到具有代理Uri或根据代理方案构造的Uri（指示多播地址）的请求时，该代理获得如上所述的一组响应，并将所有响应（缓存的仍然是新的和新的）发送回原始客户机。
This specification does not provide a way to indicate the unicast-modified request URI (base URI) in responses thus forwarded. Proxying multicast requests is discussed in more detail in [GROUPCOMM]; one proposal to address the base URI issue can be found in Section 3 of [CoAP-MISC].
本规范不提供一种方法来指示这样转发的响应中的单播修改请求URI（基本URI）。代理多播请求在[GROUPCOMM]中有更详细的讨论；[CoAP MISC]第3节中提供了一个解决基本URI问题的建议。
This section defines the DTLS binding for CoAP.
本节定义了CoAP的DTLS绑定。
During the provisioning phase, a CoAP device is provided with the security information that it needs, including keying materials and access control lists. This specification defines provisioning for the RawPublicKey mode in Section 9.1.3.2.1. At the end of the provisioning phase, the device will be in one of four security modes with the following information for the given mode. The NoSec and RawPublicKey modes are mandatory to implement for this specification.
在供应阶段，CoAP设备将获得其所需的安全信息，包括密钥材料和访问控制列表。本规范在第9.1.3.2.1节中定义了RawPublicKey模式的设置。在供应阶段结束时，设备将处于四种安全模式之一，并具有给定模式的以下信息。NoSec和RawPublicKey模式对于本规范是强制性的。
NoSec: There is no protocol-level security (DTLS is disabled). Alternative techniques to provide lower-layer security SHOULD be used when appropriate. The use of IPsec is discussed in [IPsec-CoAP]. Certain link layers in use with constrained nodes also provide link-layer security, which may be appropriate with proper key management.
NOSC：没有协议级安全性（DTLS被禁用）。适当时，应使用提供低层安全性的替代技术。[IPsec CoAP]中讨论了IPsec的使用。与受约束节点一起使用的某些链路层还提供链路层安全性，这可能与适当的密钥管理相适应。
PreSharedKey: DTLS is enabled, there is a list of pre-shared keys [RFC4279], and each key includes a list of which nodes it can be used to communicate with as described in Section 9.1.3.1. At the extreme, there may be one key for each node this CoAP node needs to communicate with (1:1 node/key ratio). Conversely, if more than two entities share a specific pre-shared key, this key only enables the entities to authenticate as a member of that group and not as a specific peer.
预共享密钥：DTLS已启用，有一个预共享密钥列表[RFC4279]，每个密钥包括一个可用于与之通信的节点列表，如第9.1.3.1节所述。在极端情况下，该CoAP节点需要与之通信的每个节点可能有一个密钥（1:1节点/密钥比）。相反，如果两个以上的实体共享一个特定的预共享密钥，则该密钥仅允许实体作为该组的成员而不是特定的对等方进行身份验证。
RawPublicKey: DTLS is enabled and the device has an asymmetric key pair without a certificate (a raw public key) that is validated using an out-of-band mechanism [RFC7250] as described in Section 9.1.3.2. The device also has an identity calculated from the public key and a list of identities of the nodes it can communicate with.
RAWCPublicKey:DTLS已启用，并且设备具有一个非对称密钥对，没有证书（原始公钥），该证书使用带外机制[RFC7250]进行验证，如第9.1.3.2节所述。该设备还具有根据公钥计算出的标识以及可与其通信的节点的标识列表。
Certificate: DTLS is enabled and the device has an asymmetric key pair with an X.509 certificate [RFC5280] that binds it to its subject and is signed by some common trust root as described in Section 9.1.3.3. The device also has a list of root trust anchors that can be used for validating a certificate.
证书：DTLS已启用，并且设备具有一个非对称密钥对，该密钥对具有一个X.509证书[RFC5280]，该证书将其绑定到其主题，并由某个公共信任根签名，如第9.1.3.3节所述。该设备还具有可用于验证证书的根信任锚的列表。
In the "NoSec" mode, the system simply sends the packets over normal UDP over IP and is indicated by the "coap" scheme and the 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; see Section 11.5 for an additional complication with this approach.
在“NOSC”模式下，系统仅通过IP上的普通UDP发送数据包，并由“coap”方案和coap默认端口指示。只有通过阻止攻击者通过CoAP节点从网络发送或接收数据包，系统才能得到安全保护；参见第11.5节，了解该方法的额外复杂性。
The other three security modes are achieved using DTLS and are indicated by the "coaps" scheme and DTLS-secured CoAP default port. The result is a security association that can be used to authenticate (within the limits of the security model) and, based on this authentication, authorize the communication partner. CoAP itself does not provide protocol primitives for authentication or authorization; where this is required, it can either be provided by communication security (i.e., IPsec or DTLS) or by object security (within the payload). Devices that require authorization for certain operations are expected to require one of these two forms of security. Necessarily, where an intermediary is involved, communication security only works when that intermediary is part of the trust relationships. CoAP does not provide a way to forward different levels of authorization that clients may have with an intermediary to further intermediaries or origin servers -- it therefore may be required to perform all authorization at the first intermediary.
其他三种安全模式使用DTLS实现，并由“CoAP”方案和DTLS安全CoAP默认端口指示。结果是一个安全关联，可用于身份验证（在安全模型的限制范围内），并基于此身份验证对通信伙伴进行授权。CoAP本身不提供用于认证或授权的协议原语；如果需要，可以通过通信安全性（即IPsec或DTLS）或对象安全性（在有效负载内）提供。某些操作需要授权的设备预计需要这两种安全形式之一。必要的是，在涉及中介的情况下，只有当该中介是信任关系的一部分时，通信安全才起作用。CoAP并没有提供一种方式，将客户端可能与中介之间具有的不同级别的授权转发给其他中介或源服务器——因此可能需要在第一个中介执行所有授权。
Just as HTTP is secured using Transport Layer Security (TLS) over TCP, CoAP is secured using Datagram TLS (DTLS) [RFC6347] over UDP (see Figure 13). This section defines the CoAP binding to DTLS, along with the minimal mandatory-to-implement configurations appropriate for constrained environments. The binding is defined by a series of deltas to unicast CoAP. In practice, DTLS is TLS with added features to deal with the unreliable nature of the UDP transport.
正如HTTP使用TCP上的传输层安全性（TLS）进行安全保护一样，CoAP也使用UDP上的数据报TLS（DTLS）[RFC6347]进行安全保护（见图13）。本节定义了与DTL的CoAP绑定，以及实现适用于受限环境的配置的最低强制要求。绑定由一系列到单播CoAP的增量定义。实际上，DTLS是TLS，它增加了一些特性来处理UDP传输的不可靠特性。
+----------------------+
| Application |
+----------------------+
+----------------------+
| Requests/Responses |
|----------------------| CoAP
| Messages |
+----------------------+
+----------------------+
| DTLS |
+----------------------+
+----------------------+
| UDP |
+----------------------+
+----------------------+
| Application |
+----------------------+
+----------------------+
| Requests/Responses |
|----------------------| CoAP
| Messages |
+----------------------+
+----------------------+
| DTLS |
+----------------------+
+----------------------+
| UDP |
+----------------------+
Figure 13: Abstract Layering of DTLS-Secured CoAP
图13：DTLS安全CoAP的抽象分层
In some constrained nodes (limited flash and/or RAM) and networks (limited bandwidth or high scalability requirements), and depending on the specific cipher suites in use, all modes of DTLS may not be applicable. Some DTLS cipher suites can add significant implementation complexity as well as some initial handshake overhead needed when setting up the security association. Once the initial handshake is completed, DTLS adds a limited per-datagram overhead of approximately 13 bytes, not including any initialization vectors/ nonces (e.g., 8 bytes with TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]), integrity check values (e.g., 8 bytes with TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]), and padding required by the cipher suite. Whether the use of a given mode of DTLS is applicable for a CoAP-based application should be carefully weighed considering the specific cipher suites that may be applicable, whether the session maintenance makes it compatible with application flows, and whether sufficient resources are available on the constrained nodes and for the added network overhead. (For some modes of using DTLS, this specification identifies a mandatory-to-implement cipher suite. This is an implementation requirement to maximize interoperability in those cases where these cipher suites are indeed appropriate. The specific security policies of an application may determine the actual set of cipher suites that can be used.) DTLS is not applicable to group keying (multicast communication); however, it may be a component in a future group key management protocol.
在某些受限制的节点（有限的闪存和/或RAM）和网络（有限的带宽或高可扩展性要求）中，根据使用的特定密码套件，DTL的所有模式可能都不适用。一些DTLS密码套件可能会增加显著的实现复杂性，以及在设置安全关联时所需的一些初始握手开销。一旦初始握手完成，DTLS将增加约13字节的有限的每数据报开销，不包括任何初始化向量/时值（例如，8字节的TLS_PSK_与_AES_128_CCM_8[RFC6655]）、完整性检查值（例如，8字节的TLS_PSK_与_AES_128_CCM_8[RFC6655]），以及密码套件所需的填充。考虑到可能适用的特定密码套件，会话维护是否使其与应用程序流兼容，应仔细权衡DTL的给定模式是否适用于基于CoAP的应用程序，以及在受约束的节点上是否有足够的可用资源以及增加的网络开销。（对于某些使用DTL的模式，本规范确定了实现密码套件的强制要求。这是在这些密码套件确实适用的情况下最大限度地提高互操作性的实现要求。应用程序的特定安全策略可能决定可使用的实际密码套件集。）DTLS不适用于组键控（多播通信）；但是，它可能是未来组密钥管理协议中的一个组件。
The endpoint acting as the CoAP client should also act as the DTLS client. It should initiate a session to the server on the appropriate port. When the DTLS handshake has finished, the client may initiate the first CoAP request. All CoAP messages MUST be sent as DTLS "application data".
充当CoAP客户端的端点也应充当DTLS客户端。它应该在适当的端口上启动到服务器的会话。当DTLS握手完成时，客户端可以启动第一个CoAP请求。所有CoAP消息必须作为DTL“应用程序数据”发送。
The following rules are added for matching an Acknowledgement message or Reset message to a Confirmable message, or a Reset message to a Non-confirmable message: The DTLS session MUST be the same, and the epoch MUST be the same.
为将确认消息或重置消息与可确认消息匹配，或将重置消息与不可确认消息匹配，添加了以下规则：DTLS会话必须相同，历元必须相同。
A message is the same when it is sent within the same DTLS session and same epoch and has the same Message ID.
在同一DTLS会话和同一历元内发送的消息是相同的，并且具有相同的消息ID。
Note: When a Confirmable message is retransmitted, a new DTLS sequence_number is used for each attempt, even though the CoAP Message ID stays the same. So a recipient still has to perform deduplication as described in Section 4.5. Retransmissions MUST NOT be performed across epochs.
注意：当重新传输可确认消息时，每次尝试都会使用新的DTLS序列号，即使CoAP消息ID保持不变。因此，收件人仍然必须执行第4.5节所述的重复数据消除。不得跨时代执行重传。
DTLS connections in RawPublicKey and Certificate mode are set up using mutual authentication so they can remain up and be reused for future message exchanges in either direction. Devices can close a DTLS connection when they need to recover resources, but in general they should keep the connection up for as long as possible. Closing the DTLS connection after every CoAP message exchange is very inefficient.
RawPublicKey和Certificate模式下的DTLS连接是使用相互身份验证建立的，因此它们可以保持不动，并可在将来的消息交换中在任意方向重复使用。当设备需要恢复资源时，可以关闭DTLS连接，但通常应尽可能长时间保持连接。在每次CoAP消息交换之后关闭DTLS连接是非常低效的。
The following rules are added for matching a response to a request: The DTLS session MUST be the same, and the epoch MUST be the same.
为将响应与请求匹配，添加了以下规则：DTLS会话必须相同，历元必须相同。
This means the response to a DTLS secured request MUST always be DTLS secured using the same security session and epoch. Any attempt to supply a NoSec response to a DTLS request simply does not match the request and therefore MUST be rejected (unless it does match an unrelated NoSec request).
这意味着对DTLS安全请求的响应必须始终使用相同的安全会话和epoch进行DTLS安全。任何向DTLS请求提供NOSC响应的尝试都与请求不匹配，因此必须被拒绝（除非它与不相关的NOSC请求匹配）。
Devices SHOULD support the Server Name Indication (SNI) to indicate their authority in the SNI HostName field as defined in Section 3 of [RFC6066]. This is needed so that when a host that acts as a virtual server for multiple Authorities receives a new DTLS connection, it knows which keys to use for the DTLS session.
设备应支持服务器名称指示（SNI），以在[RFC6066]第3节中定义的SNI主机名字段中指示其权限。这是必需的，以便当充当多个权限的虚拟服务器的主机接收到新的DTLS连接时，它知道DTLS会话要使用哪些密钥。
When forming a connection to a new node, the system selects an appropriate key based on which nodes it is trying to reach and then forms a DTLS session using a PSK (Pre-Shared Key) mode of DTLS. Implementations in these modes MUST support the mandatory-to-implement cipher suite TLS_PSK_WITH_AES_128_CCM_8 as specified in [RFC6655].
当形成与新节点的连接时，系统根据其试图到达的节点选择适当的密钥，然后使用DTLS的PSK（预共享密钥）模式形成DTLS会话。按照[RFC6655]中的规定，这些模式下的实现必须支持强制实现密码套件TLS_PSK_和_AES_128_CCM_8。
Depending on the commissioning model, applications may need to define an application profile for identity hints (as required and detailed in Section 5.2 of [RFC4279]) to enable the use of PSK identity hints.
根据调试模型，应用程序可能需要定义身份提示的应用程序配置文件（如[RFC4279]第5.2节所要求和详细说明），以便能够使用PSK身份提示。
The security considerations of Section 7 of [RFC4279] apply. In particular, applications should carefully weigh whether or not they need Perfect Forward Secrecy (PFS) and select an appropriate cipher suite (Section 7.1 of [RFC4279]). The entropy of the PSK must be sufficient to mitigate against brute-force and (where the PSK is not chosen randomly but by a human) dictionary attacks (Section 7.2 of [RFC4279]). The cleartext communication of client identities may leak data or compromise privacy (Section 7.3 of [RFC4279]).
[RFC4279]第7节的安全注意事项适用。特别是，应用程序应仔细权衡是否需要完全前向保密（PFS），并选择适当的密码套件（RFC4279第7.1节）。PSK的熵必须足以抵御暴力和（PSK不是随机选择的，而是由人选择的）字典攻击（RFC4279第7.2节）。客户身份的明文通信可能泄漏数据或损害隐私（RFC4279第7.3节）。
In this mode, the device has an asymmetric key pair but without an X.509 certificate (called a raw public key); for example, the asymmetric key pair is generated by the manufacturer and installed on the device (see also Section 11.6). A device MAY be configured with multiple raw public keys. The type and length of the raw public key depends on the cipher suite used. Implementations in RawPublicKey mode MUST support the mandatory-to-implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as specified in [RFC7251], [RFC5246], and [RFC4492]. The key used MUST be ECDSA capable. The curve secp256r1 MUST be supported [RFC4492]; this curve is equivalent to the NIST P-256 curve. The hash algorithm is SHA-256. Implementations MUST use the Supported Elliptic Curves and Supported Point Formats Extensions [RFC4492]; the uncompressed point format MUST be supported; [RFC6090] can be used as an implementation method. Some guidance relevant to the implementation of this cipher suite can be found in [W3CXMLSEC]. The mechanism for using raw public keys with TLS is specified in [RFC7250].
在此模式下，设备具有非对称密钥对，但没有X.509证书（称为原始公钥）；例如，非对称密钥对由制造商生成并安装在设备上（另见第11.6节）。设备可以配置有多个原始公钥。原始公钥的类型和长度取决于使用的密码套件。按照[RFC7251]、[RFC5246]和[RFC4492]中的规定，RawPublicKey模式下的实现必须支持强制实现密码套件TLS_ECDHE_ECDSA_和_AES_128_CCM_8。使用的密钥必须支持ECDSA。必须支持曲线secp256r1[RFC4492]；该曲线相当于NIST P-256曲线。哈希算法是SHA-256。实现必须使用支持的椭圆曲线和支持的点格式扩展[RFC4492]；必须支持未压缩的点格式；[RFC6090]可用作实现方法。[W3CXMLSEC]中提供了一些与此密码套件的实现相关的指导。[RFC7250]中规定了将原始公钥用于TLS的机制。
Implementation Note: Specifically, this means the extensions listed in Figure 14 with at least the values listed will be present in the DTLS handshake.
实现说明：具体来说，这意味着图14中列出的扩展（至少包含列出的值）将出现在DTLS握手中。
Extension: elliptic_curves Type: elliptic_curves (0x000a) Length: 4 Elliptic Curves Length: 2 Elliptic curves (1 curve) Elliptic curve: secp256r1 (0x0017)
扩展名：椭圆曲线类型：椭圆曲线（0x000a）长度：4条椭圆曲线长度：2条椭圆曲线（1条曲线）椭圆曲线：secp256r1（0x0017）
Extension: ec_point_formats Type: ec_point_formats (0x000b) Length: 2 EC point formats Length: 1 Elliptic curves point formats (1) EC point format: uncompressed (0)
扩展名：ec_点_格式类型：ec_点_格式（0x000b）长度：2 ec点格式长度：1椭圆曲线点格式（1）ec点格式：未压缩（0）
Extension: signature_algorithms Type: signature_algorithms (0x000d) Length: 4 Data (4 bytes): 00 02 04 03 HashAlgorithm: sha256 (4) SignatureAlgorithm: ecdsa (3)
扩展名：签名算法类型：签名算法（0x000d）长度：4个数据（4字节）：00 02 04 03哈希算法：sha256（4）签名算法：ecdsa（3）
Figure 14: DTLS Extensions Present for TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
图14:TLS_ECDHE_ECDSA_与_AES_128_CCM_8的DTLS扩展
The RawPublicKey mode was designed to be easily provisioned in M2M deployments. It is assumed that each device has an appropriate asymmetric public key pair installed. An identifier is calculated by the endpoint from the public key as described in Section 2 of [RFC6920]. All implementations that support checking RawPublicKey identities MUST support at least the sha-256-120 mode (SHA-256 truncated to 120 bits). Implementations SHOULD also support longer length identifiers and MAY support shorter lengths. Note that the shorter lengths provide less security against attacks, and their use is NOT RECOMMENDED.
RawPublicKey模式被设计为可以在M2M部署中轻松配置。假设每个设备都安装了适当的非对称公钥对。如[RFC6920]第2节所述，端点根据公钥计算标识符。所有支持检查公钥标识的实现必须至少支持sha-256-120模式（sha-256被截断为120位）。实现还应该支持较长的标识符，并且可能支持较短的长度。请注意，较短的长度对攻击的安全性较差，因此不建议使用它们。
Depending on how identifiers are given to the system that verifies them, support for URI, binary, and/or human-speakable format [RFC6920] needs to be implemented. All implementations SHOULD support the binary mode, and implementations that have a user interface SHOULD also support the human-speakable format.
根据向验证标识符的系统提供标识符的方式，需要实现对URI、二进制和/或人类可说出格式[RFC6920]的支持。所有的实现都应该支持二进制模式，具有用户界面的实现也应该支持人类可说出的格式。
During provisioning, the identifier of each node is collected, for example, by reading a barcode on the outside of the device or by obtaining a pre-compiled list of the identifiers. These identifiers are then installed in the corresponding endpoint, for example, an M2M data collection server. The identifier is used for two purposes, to associate the endpoint with further device information and to perform access control. During (initial and ongoing) provisioning, an access control list of identifiers with which the device may start DTLS sessions SHOULD also be installed and maintained.
在供应期间，例如通过读取设备外部的条形码或通过获得标识符的预编译列表来收集每个节点的标识符。然后将这些标识符安装在相应的端点中，例如M2M数据采集服务器。标识符用于两个目的，将端点与进一步的设备信息关联，以及执行访问控制。在（初始和正在进行的）配置期间，还应安装和维护设备可用于启动DTLS会话的标识符的访问控制列表。
Implementations in Certificate Mode MUST support the mandatory-to-implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as specified in [RFC7251], [RFC5246], and [RFC4492]. Namely, the certificate includes a SubjectPublicKeyInfo that indicates an algorithm of id-ecPublicKey with namedCurves secp256r1 [RFC5480]; the public key format is uncompressed [RFC5480]; the hash algorithm is SHA-256; if included, the key usage extension indicates digitalSignature. Certificates MUST be signed with ECDSA using secp256r1, and the signature MUST use SHA-256. The key used MUST be ECDSA capable. The curve secp256r1 MUST be supported [RFC4492]; this curve is equivalent to the NIST P-256 curve. The hash algorithm is SHA-256. Implementations MUST use the Supported Elliptic Curves and Supported Point Formats Extensions [RFC4492]; the uncompressed point format MUST be supported; [RFC6090] can be used as an implementation method.
证书模式下的实现必须支持强制使用[RFC7251]、[RFC5246]和[RFC4492]中指定的\U AES\U 128\U CCM\U 8实现密码套件TLS\U ECDHE\U ECDSA\U。即，证书包括SubjectPublicKeyInfo，该SubjectPublicKeyInfo指示名为Curves secp256r1[RFC5480]的id ecPublicKey算法；公钥格式为未压缩[RFC5480]；哈希算法为SHA-256；如果包含，则密钥使用扩展名表示数字签名。必须使用secp256r1使用ECDSA对证书进行签名，并且签名必须使用SHA-256。使用的密钥必须支持ECDSA。必须支持曲线secp256r1[RFC4492]；该曲线相当于NIST P-256曲线。哈希算法是SHA-256。实现必须使用支持的椭圆曲线和支持的点格式扩展[RFC4492]；必须支持未压缩的点格式；[RFC6090]可用作实现方法。
The subject in the certificate would be built out of a long-term unique identifier for the device such as the EUI-64 [EUI64]. The subject could also be based on the Fully Qualified Domain Name (FQDN) that was used as the Host part of the CoAP URI. However, the device's IP address should not typically be used as the subject, as it would change over time. The discovery process used in the system would build up the mapping between IP addresses of the given devices and the subject for each device. Some devices could have more than one subject and would need more than a single certificate.
证书中的主题将由设备的长期唯一标识符（如EUI-64[EUI64]）构建。主题还可以基于用作CoAP URI主机部分的完全限定域名（FQDN）。但是，设备的IP地址通常不应用作主题，因为它会随着时间的推移而改变。系统中使用的发现过程将在给定设备的IP地址和每个设备的主题之间建立映射。某些设备可能有多个主题，并且需要多个证书。
When a new connection is formed, the certificate from the remote device needs to be verified. If the CoAP node has a source of absolute time, then the node SHOULD check that the validity dates of the certificate are within range. The certificate MUST be validated as appropriate for the security requirements, using functionality equivalent to the algorithm specified in Section 6 of [RFC5280]. If the certificate contains a SubjectAltName, then the authority of the request URI MUST match at least one of the authorities of any CoAP URI found in a field of URI type in the SubjectAltName set. If there is no SubjectAltName in the certificate, then the authority of the request URI MUST match the Common Name (CN) found in the certificate using the matching rules defined in [RFC3280] with the exception that certificates with wildcards are not allowed.
形成新连接时，需要验证来自远程设备的证书。如果CoAP节点具有绝对时间源，则该节点应检查证书的有效日期是否在范围内。必须使用与[RFC5280]第6节中规定的算法等效的功能，根据安全要求对证书进行验证。如果证书包含SubjectAltName，则请求URI的权限必须与SubjectAltName集中URI类型字段中找到的任何CoAP URI的至少一个权限相匹配。如果证书中没有SubjectAltName，则请求URI的权限必须使用[RFC3280]中定义的匹配规则匹配证书中的公共名称（CN），但不允许使用通配符的证书除外。
CoRE support for certificate status checking requires further study. As a mapping of the Online Certificate Status Protocol (OCSP) [RFC6960] onto CoAP is not currently defined and OCSP may also not be easily applicable in all environments, an alternative approach may be using the TLS Certificate Status Request extension (Section 8 of [RFC6066]; also known as "OCSP stapling") or preferably the Multiple Certificate Status Extension ([RFC6961]), if available.
对证书状态检查的核心支持需要进一步研究。由于目前尚未定义在线证书状态协议（OCSP）[RFC6960]到CoAP的映射，并且OCSP可能也不容易在所有环境中都适用，因此另一种方法可能是使用TLS证书状态请求扩展（RFC6066]第8节；也称为“OCSP装订”）或者最好是多证书状态扩展（[RFC6961]），如果可用。
If the system has a shared key in addition to the certificate, then a cipher suite that includes the shared key such as TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA [RFC5489] SHOULD be used.
如果系统除证书外还有共享密钥，则应使用包含共享密钥的密码套件，如TLS_ECDHE_PSK_和_AES_128_CBC_SHA[RFC5489]。
CoAP supports a limited subset of HTTP functionality, and thus cross-protocol proxying to HTTP is straightforward. There might be several reasons for proxying between CoAP and HTTP, for example, when designing a web interface for use over either protocol or when realizing a CoAP-HTTP proxy. Likewise, CoAP could equally be proxied to other protocols such as XMPP [RFC6120] or SIP [RFC3264]; the definition of these mechanisms is out of scope for this specification.
CoAP支持有限的HTTP功能子集，因此跨协议代理HTTP非常简单。在CoAP和HTTP之间代理可能有几个原因，例如，在设计通过任一协议使用的web接口时，或者在实现CoAP HTTP代理时。类似地，CoAP同样可以代理其他协议，如XMPP[RFC6120]或SIP[RFC3264]；这些机制的定义超出了本规范的范围。
There are two possible directions to access a resource via a forward-proxy:
通过转发代理访问资源有两个可能的方向：
CoAP-HTTP Proxying: Enables CoAP clients to access resources on HTTP servers through an intermediary. This is initiated by including the Proxy-Uri or Proxy-Scheme Option with an "http" or "https" URI in a CoAP request to a CoAP-HTTP proxy.
CoAP HTTP代理：使CoAP客户端能够通过中介访问HTTP服务器上的资源。这是通过在对CoAP http代理的CoAP请求中包含带有“http”或“https”Uri的代理Uri或代理方案选项来启动的。
HTTP-CoAP Proxying: Enables HTTP clients to access resources on CoAP servers through an intermediary. This is initiated by specifying a "coap" or "coaps" URI in the Request-Line of an HTTP request to an HTTP-CoAP proxy.
HTTP CoAP代理：使HTTP客户端能够通过中介访问CoAP服务器上的资源。这是通过在HTTP coap代理的HTTP请求的请求行中指定“coap”或“coap”URI来启动的。
Either way, only the request/response model of CoAP is mapped to HTTP. The underlying model of Confirmable or Non-confirmable messages, etc., is invisible and MUST have no effect on a proxy function. The following sections describe the handling of requests to a forward-proxy. Reverse-proxies are not specified, as the proxy function is transparent to the client with the proxy acting as if it were the origin server. However, similar considerations apply to reverse-proxies as to forward-proxies, and there generally will be an expectation that reverse-proxies operate in a similar way forward-proxies would. As an implementation note, HTTP client libraries may make it hard to operate an HTTP-CoAP forward-proxy by not providing a way to put a CoAP URI on the HTTP Request-Line; reverse-proxying may therefore lead to wider applicability of a proxy. A separate specification may define a convention for URIs operating such an HTTP-CoAP reverse-proxy [MAPPING].
无论哪种方式，只有CoAP的请求/响应模型映射到HTTP。可确认或不可确认消息等的基础模型是不可见的，并且必须对代理函数没有影响。以下各节描述对转发代理的请求的处理。不指定反向代理，因为代理功能对客户端是透明的，代理的作用就像原始服务器一样。然而，对于反向代理和正向代理，同样的考虑也适用于反向代理，并且通常期望反向代理以与正向代理类似的方式运行。作为实现注意事项，HTTP客户端库可能会因为没有提供将CoAP URI放在HTTP请求行上的方法而使操作HTTP CoAP转发代理变得困难；因此，反向代理可能导致代理更广泛的适用性。一个单独的规范可以为操作这种HTTP CoAP反向代理[映射]的URI定义一个约定。
If a request contains a Proxy-Uri or Proxy-Scheme Option with an 'http' or 'https' URI [RFC2616], then the receiving CoAP endpoint (called "the proxy" henceforth) is requested to perform the operation specified by the request method on the indicated HTTP resource and return the result to the client. (See also Section 5.7 for how the request to the proxy is formulated, including security requirements.)
如果请求包含具有“http”或“https”Uri[RFC2616]的代理Uri或代理方案选项，则请求接收CoAP端点（此后称为“代理”）在指示的http资源上执行请求方法指定的操作，并将结果返回给客户端。（另请参见第5.7节，了解如何制定对代理的请求，包括安全要求。）
This section specifies for any CoAP request the CoAP response that the proxy should return to the client. How the proxy actually satisfies the request is an implementation detail, although the typical case is expected to be that the proxy translates and forwards the request to an HTTP origin server.
本节为任何CoAP请求指定代理应返回给客户端的CoAP响应。代理如何实际满足请求是一个实现细节，尽管典型的情况是代理转换请求并将其转发到HTTP源服务器。
Since HTTP and CoAP share the basic set of request methods, performing a CoAP request on an HTTP resource is not so different from performing it on a CoAP resource. The meanings of the individual CoAP methods when performed on HTTP resources are explained in the subsections of this section.
由于HTTP和CoAP共享一组基本的请求方法，因此在HTTP资源上执行CoAP请求与在CoAP资源上执行CoAP请求没有太大区别。在HTTP资源上执行的各个CoAP方法的含义将在本节的小节中解释。
If the proxy is unable or unwilling to service a request with an HTTP URI, a 5.05 (Proxying Not Supported) response is returned to the client. If the proxy services the request by interacting with a third party (such as the HTTP origin server) and is unable to obtain a result within a reasonable time frame, a 5.04 (Gateway Timeout) response is returned; if a result can be obtained but is not understood, a 5.02 (Bad Gateway) response is returned.
如果代理无法或不愿意使用HTTP URI为请求提供服务，则会向客户端返回5.05（不支持代理）响应。如果代理通过与第三方（如HTTP源服务器）交互为请求提供服务，并且无法在合理的时间范围内获得结果，则返回5.04（网关超时）响应；如果可以获得结果但无法理解，则返回5.02（坏网关）响应。
The GET method requests the proxy to return a representation of the HTTP resource identified by the request URI.
GET方法请求代理返回由请求URI标识的HTTP资源的表示形式。
Upon success, a 2.05 (Content) Response Code SHOULD be returned. The payload of the response MUST be a representation of the target HTTP resource, and the Content-Format Option MUST be set accordingly. The response MUST indicate a Max-Age value that is no greater than the remaining time the representation can be considered fresh. If the HTTP entity has an entity-tag, the proxy SHOULD include an ETag Option in the response and process ETag Options in requests as described below.
成功后，应返回2.05（内容）响应代码。响应的有效负载必须是目标HTTP资源的表示，并且必须相应地设置内容格式选项。响应必须指示一个最大年龄值，该值不得大于表示被视为新的剩余时间。如果HTTP实体具有实体标记，则代理应在响应中包含ETag选项，并在请求中包含process ETag选项，如下所述。
A client can influence the processing of a GET request by including the following option:
客户端可以通过包括以下选项来影响GET请求的处理：
Accept: The request MAY include an Accept Option, identifying the preferred response content-format.
接受：请求可能包括一个接受选项，用于标识首选响应内容格式。
ETag: The request MAY include one or more ETag Options, identifying responses that the client has stored. This requests the proxy to send a 2.03 (Valid) response whenever it would send a 2.05 (Content) response with an entity-tag in the requested set otherwise. Note that CoAP ETags are always strong ETags in the HTTP sense; CoAP does not have the equivalent of HTTP weak ETags, and there is no good way to make use of these in a cross-proxy.
ETag：请求可能包括一个或多个ETag选项，用于标识客户端存储的响应。这会请求代理在发送2.05（内容）响应时发送2.03（有效）响应，而在其他情况下，则在请求集中发送实体标记。注意，CoAP ETag在HTTP意义上始终是强ETag；CoAP没有HTTP弱ETag的等价物，在交叉代理中也没有很好的方法来使用它们。
The PUT method requests the proxy to update or create the HTTP resource identified by the request URI with the enclosed representation.
PUT方法请求代理更新或创建由请求URI标识的HTTP资源，并使用封闭的表示形式。
If a new resource is created at the request URI, a 2.01 (Created) response MUST be returned to the client. If an existing resource is modified, a 2.04 (Changed) response MUST be returned to indicate successful completion of the request.
如果在请求URI处创建了新资源，则必须向客户端返回2.01（已创建）响应。如果修改了现有资源，则必须返回2.04（已更改）响应以指示请求成功完成。
The DELETE method requests the proxy to delete the HTTP resource identified by the request URI at the HTTP origin server.
DELETE方法请求代理删除由HTTP源服务器上的请求URI标识的HTTP资源。
A 2.02 (Deleted) response MUST be returned to the client upon success or if the resource does not exist at the time of the request.
如果请求成功或请求时资源不存在，则必须将2.02（已删除）响应返回给客户端。
The POST method requests the proxy to have the representation enclosed in the request be processed by the HTTP origin server. The actual function performed by the POST method is determined by the origin server and dependent on the resource identified by the request URI.
POST方法请求代理将请求中包含的表示形式由HTTP源服务器处理。POST方法执行的实际功能由源服务器确定，并取决于请求URI标识的资源。
If the action performed by the POST method does not result in a resource that can be identified by a URI, a 2.04 (Changed) response MUST be returned to the client. If a resource has been created on the origin server, a 2.01 (Created) response MUST be returned.
如果POST方法执行的操作没有产生可由URI标识的资源，则必须向客户端返回2.04（已更改）响应。如果已在源服务器上创建资源，则必须返回2.01（已创建）响应。
If an HTTP request contains a Request-URI with a "coap" or "coaps" URI, then the receiving HTTP endpoint (called "the proxy" henceforth) is requested to perform the operation specified by the request method on the indicated CoAP resource and return the result to the client.
如果HTTP请求包含具有“coap”或“coaps”URI的请求URI，则请求接收HTTP端点（此后称为“代理”）对指示的coap资源执行请求方法指定的操作，并将结果返回给客户端。
This section specifies for any HTTP request the HTTP response that the proxy should return to the client. Unless otherwise specified, all the statements made are RECOMMENDED behavior; some highly constrained implementations may need to resort to shortcuts. How the proxy actually satisfies the request is an implementation detail, although the typical case is expected to be that the proxy translates and forwards the request to a CoAP origin server. The meanings of the individual HTTP methods when performed on CoAP resources are explained in the subsections of this section.
本节为任何HTTP请求指定代理应返回给客户端的HTTP响应。除非另有规定，否则所有声明均为推荐行为；一些高度受限的实现可能需要使用快捷方式。代理如何实际满足请求是一个实现细节，尽管典型的情况是代理转换请求并将其转发给CoAP源服务器。在CoAP资源上执行的各个HTTP方法的含义将在本节的小节中解释。
If the proxy is unable or unwilling to service a request with a CoAP URI, a 501 (Not Implemented) response is returned to the client. If the proxy services the request by interacting with a third party (such as the CoAP origin server) and is unable to obtain a result within a reasonable time frame, a 504 (Gateway Timeout) response is returned; if a result can be obtained but is not understood, a 502 (Bad Gateway) response is returned.
如果代理无法或不愿意使用CoAP URI为请求提供服务，则会向客户端返回501（未实现）响应。如果代理通过与第三方（例如CoAP源服务器）交互来服务请求，并且无法在合理的时间范围内获得结果，则返回504（网关超时）响应；如果可以获得结果但无法理解，则返回502（坏网关）响应。
As the OPTIONS and TRACE methods are not supported in CoAP, a 501 (Not Implemented) error MUST be returned to the client.
由于CoAP中不支持选项和跟踪方法，因此必须向客户端返回501（未实现）错误。
The GET method requests the proxy to return a representation of the CoAP resource identified by the Request-URI.
GET方法请求代理返回由请求URI标识的CoAP资源的表示形式。
Upon success, a 200 (OK) response is returned. The payload of the response MUST be a representation of the target CoAP resource, and the Content-Type and Content-Encoding header fields MUST be set accordingly. The response MUST indicate a max-age directive that indicates a value no greater than the remaining time the representation can be considered fresh. If the CoAP response has an ETag option, the proxy should include an ETag header field in the response.
成功后，返回200（OK）响应。响应的有效负载必须是目标CoAP资源的表示，并且必须相应地设置内容类型和内容编码头字段。响应必须指示一个max age指令，该指令指示的值不大于表示可以视为新的剩余时间。如果CoAP响应具有ETag选项，则代理应在响应中包含ETag头字段。
A client can influence the processing of a GET request by including the following options:
客户端可以通过包括以下选项来影响GET请求的处理：
Accept: The most-preferred media type of the HTTP Accept header field in a request is mapped to a CoAP Accept option. HTTP Accept media-type ranges, parameters, and extensions are not supported by the CoAP Accept option. If the proxy cannot send a response that is acceptable according to the combined Accept field value, then the proxy sends a 406 (Not Acceptable) response. The proxy MAY then retry the request with further media types from the HTTP Accept header field.
Accept：请求中HTTP Accept标头字段的最首选媒体类型映射到CoAP Accept选项。CoAP Accept选项不支持HTTP Accept媒体类型范围、参数和扩展。如果代理无法发送根据组合接受字段值可接受的响应，则代理将发送406（不可接受）响应。然后，代理可以使用HTTP Accept标头字段中的其他媒体类型重试该请求。
Conditional GETs: Conditional HTTP GET requests that include an "If-Match" or "If-None-Match" request-header field can be mapped to a corresponding CoAP request. The "If-Modified-Since" and "If-Unmodified-Since" request-header fields are not directly supported by CoAP but are implemented locally by a caching proxy.
条件GET：包含“如果匹配”或“如果不匹配”请求头字段的条件HTTP GET请求可以映射到相应的CoAP请求。CoAP不直接支持“If Modified Since”和“If Unmodified Since”请求头字段，而是通过缓存代理在本地实现。
The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response.
HEAD方法与GET相同，只是服务器不能在响应中返回消息体。
Although there is no direct equivalent of HTTP's HEAD method in CoAP, an HTTP-CoAP proxy responds to HEAD requests for CoAP resources, and the HTTP headers are returned without a message-body.
虽然在CoAP中没有HTTP的HEAD方法的直接等价物，但HTTP CoAP代理会响应HEAD对CoAP资源的请求，并且返回的HTTP头没有消息体。
Implementation Note: An HTTP-CoAP proxy may want to try using a block-wise transfer option [BLOCK] to minimize the amount of data actually transferred, but it needs to be prepared for the case that the origin server does not support block-wise transfers.
实施说明：HTTP CoAP代理可能希望尝试使用分块传输选项[block]来最小化实际传输的数据量，但需要为源服务器不支持分块传输的情况做好准备。
The POST method requests the proxy to have the representation enclosed in the request be processed by the CoAP origin server. The actual function performed by the POST method is determined by the origin server and dependent on the resource identified by the request URI.
POST方法请求代理将请求中包含的表示形式由CoAP源服务器处理。POST方法执行的实际功能由源服务器确定，并取决于请求URI标识的资源。
If the action performed by the POST method does not result in a resource that can be identified by a URI, a 200 (OK) or 204 (No Content) response MUST be returned to the client. If a resource has been created on the origin server, a 201 (Created) response MUST be returned.
如果POST方法执行的操作没有产生可由URI标识的资源，则必须向客户端返回200（确定）或204（无内容）响应。如果已在源服务器上创建资源，则必须返回201（已创建）响应。
If any of the Location-* Options are present in the CoAP response, a Location header field constructed from the values of these options is returned.
如果CoAP响应中存在任何Location-*选项，则返回由这些选项的值构造的Location header字段。
The PUT method requests the proxy to update or create the CoAP resource identified by the Request-URI with the enclosed representation.
PUT方法请求代理更新或创建由请求URI标识的CoAP资源，并使用附带的表示。
If a new resource is created at the Request-URI, a 201 (Created) response is returned to the client. If an existing resource is modified, either the 200 (OK) or 204 (No Content) Response Codes is sent to indicate successful completion of the request.
如果在请求URI处创建了新资源，则会向客户端返回201（已创建）响应。如果修改了现有资源，则发送200（确定）或204（无内容）响应代码以指示请求成功完成。
The DELETE method requests the proxy to delete the CoAP resource identified by the Request-URI at the CoAP origin server.
DELETE方法请求代理删除CoAP源服务器上由请求URI标识的CoAP资源。
A successful response is 200 (OK) if the response includes an entity describing the status or 204 (No Content) if the action has been enacted but the response does not include an entity.
如果响应包含描述状态的实体，则成功响应为200（正常）；如果已实施操作，但响应不包含实体，则成功响应为204（无内容）。
This method cannot currently be satisfied by an HTTP-CoAP proxy function, as TLS to DTLS tunneling has not yet been specified. For now, a 501 (Not Implemented) error is returned to the client.
HTTP CoAP代理函数目前无法满足此方法，因为尚未指定TLS到DTLS的隧道。目前，一个501（未实现）错误返回给客户端。
This section analyzes the possible threats to the protocol. It is meant to inform protocol and application developers about the security limitations of CoAP as described in this document. As CoAP realizes a subset of the features in HTTP/1.1, the security considerations in Section 15 of [RFC2616] are also pertinent to CoAP. This section concentrates on describing limitations specific to CoAP.
本节分析协议可能面临的威胁。其目的是告知协议和应用程序开发人员本文档中描述的CoAP的安全限制。由于CoAP实现了HTTP/1.1中的一部分功能，因此[RFC2616]第15节中的安全注意事项也与CoAP相关。本节重点描述CoAP的特定限制。
A network-facing application can exhibit vulnerabilities in its processing logic for incoming packets. Complex parsers are well-known as a likely source of such vulnerabilities, such as the ability to remotely crash a node, or even remotely execute arbitrary code on it. CoAP attempts to narrow the opportunities for introducing such vulnerabilities by reducing parser complexity, by giving the entire range of encodable values a meaning where possible, and by aggressively reducing complexity that is often caused by unnecessary choice between multiple representations that mean the same thing. Much of the URI processing has been moved to the clients, further reducing the opportunities for introducing vulnerabilities into the servers. Even so, the URI processing code in CoAP implementations is likely to be a large source of remaining vulnerabilities and should be implemented with special care. CoAP access control implementations need to ensure they don't introduce vulnerabilities through discrepancies between the code deriving access control decisions from a URI and the code finally serving up the resource addressed by the URI. The most complex parser remaining could be the one for the CoRE Link Format, although this also has been designed with a goal of reduced implementation complexity [RFC6690]. (See also Section 15.2 of [RFC2616].)
面向网络的应用程序在其传入数据包的处理逻辑中可能存在漏洞。众所周知，复杂的解析器可能是此类漏洞的来源，例如远程使节点崩溃，甚至远程在其上执行任意代码的能力。CoAP试图通过降低解析器复杂性、尽可能赋予整个可编码值范围以含义，以及通过积极降低复杂性来缩小引入此类漏洞的机会，这种复杂性通常是由于在表示相同内容的多个表示之间进行不必要的选择而导致的。大部分URI处理已经转移到客户端，进一步减少了将漏洞引入服务器的机会。即便如此，CoAP实现中的URI处理代码很可能是剩余漏洞的一大来源，应特别小心地实施。CoAP访问控制实现需要确保它们不会由于从URI派生访问控制决策的代码与最终提供URI所寻址资源的代码之间的差异而引入漏洞。剩下的最复杂的解析器可能是核心链接格式的解析器，尽管其设计目标也是降低实现复杂性[RFC6690]。（另见[RFC2616]第15.2节）
As mentioned in Section 15.7 of [RFC2616], proxies are by their very nature men-in-the-middle, breaking any IPsec or DTLS protection that a direct CoAP message exchange might have. They are therefore interesting targets for breaking confidentiality or integrity of CoAP message exchanges. As noted in [RFC2616], they are also interesting targets for breaking availability.
如[RFC2616]第15.7节所述，代理本质上是中间人，破坏了直接CoAP消息交换可能具有的任何IPsec或DTLS保护。因此，它们是破坏CoAP消息交换的机密性或完整性的有趣目标。如[RFC2616]所述，它们也是打破可用性的有趣目标。
The threat to confidentiality and integrity of request/response data is amplified where proxies also cache. Note that CoAP does not define any of the cache-suppressing Cache-Control options that HTTP/1.1 provides to better protect sensitive data.
在代理也缓存的情况下，对请求/响应数据的机密性和完整性的威胁会加剧。请注意，CoAP没有定义HTTP/1.1为更好地保护敏感数据而提供的任何缓存抑制缓存控制选项。
For a caching implementation, any access control considerations that would apply to making the request that generated the cache entry also need to be applied to the value in the cache. This is relevant for clients that implement multiple security domains, as well as for proxies that may serve multiple clients. Also, a caching proxy MUST NOT make cached values available to requests that have lesser transport-security properties than those the proxy would require to perform request forwarding in the first place.
对于缓存实现，任何适用于生成缓存项的请求的访问控制注意事项也需要应用于缓存中的值。这与实现多个安全域的客户端以及可能服务于多个客户端的代理相关。此外，缓存代理不得使缓存值可用于传输安全属性低于代理首先执行请求转发所需的传输安全属性的请求。
Unlike the "coap" scheme, responses to "coaps" identified requests are never "public" and thus MUST NOT be reused for shared caching, unless the cache is able to make equivalent access control decisions to the ones that led to the cached entry. They can, however, be reused in a private cache if the message is cacheable by default in CoAP.
与“coap”方案不同，对“coap”标识的请求的响应从来都不是“公共”的，因此不能再用于共享缓存，除非缓存能够做出与导致缓存项的响应相同的访问控制决策。但是，如果消息在CoAP中默认可缓存，则它们可以在专用缓存中重用。
Finally, a proxy that fans out Separate Responses (as opposed to piggybacked Responses) to multiple original requesters may provide additional amplification (see Section 11.3).
最后，向多个原始请求者扇出单独响应（而不是附带响应）的代理可以提供额外的放大（参见第11.3节）。
CoAP servers generally reply to a request packet with a response packet. This response packet may be significantly larger than the request packet. An attacker might use CoAP nodes to turn a small attack packet into a larger attack packet, an approach known as amplification. There is therefore a danger that CoAP nodes could become implicated in denial-of-service (DoS) attacks by using the amplifying properties of the protocol: an attacker that is attempting to overload a victim but is limited in the amount of traffic it can generate can use amplification to generate a larger amount of traffic.
CoAP服务器通常使用响应数据包回复请求数据包。该响应包可能比请求包大得多。攻击者可能会使用CoAP节点将一个较小的攻击数据包转化为一个较大的攻击数据包，这种方法称为放大。因此，CoAP节点有可能通过使用协议的放大属性而卷入拒绝服务（DoS）攻击的危险：试图使受害者过载但其可生成的通信量有限的攻击者可以使用放大来生成更大的通信量。
This is particularly a problem in nodes that enable NoSec access, are accessible from an attacker, and can access potential victims (e.g., on the general Internet), as the UDP protocol provides no way to verify the source address given in the request packet. An attacker need only place the IP address of the victim in the source address of a suitable request packet to generate a larger packet directed at the victim.
这在启用NOSC访问、可由攻击者访问并可访问潜在受害者（例如，在通用Internet上）的节点中尤其存在问题，因为UDP协议无法验证请求数据包中给出的源地址。攻击者只需将受害者的IP地址放在适当请求数据包的源地址中，即可生成指向受害者的较大数据包。
As a mitigating factor, many constrained networks will only be able to generate a small amount of traffic, which may make CoAP nodes less attractive for this attack. However, the limited capacity of the constrained network makes the network itself a likely victim of an amplification attack.
作为缓解因素，许多受约束的网络只能产生少量流量，这可能会降低CoAP节点对这种攻击的吸引力。然而，受限网络的有限容量使得网络本身很可能成为放大攻击的受害者。
Therefore, large amplification factors SHOULD NOT be provided in the response if the request is not authenticated. A CoAP server can reduce the amount of amplification it provides to an attacker by using slicing/blocking modes of CoAP [BLOCK] and offering large resource representations only in relatively small slices. For example, for a 1000-byte resource, a 10-byte request might result in an 80-byte response (with a 64-byte block) instead of a 1016-byte response, considerably reducing the amplification provided.
因此，如果请求未经身份验证，则响应中不应提供较大的放大系数。CoAP服务器可以通过使用CoAP[BLOCK]的切片/阻塞模式，并仅在相对较小的切片中提供大资源表示，从而减少向攻击者提供的放大量。例如，对于1000字节的资源，10字节的请求可能会导致80字节的响应（带有64字节的块）而不是1016字节的响应，从而大大减少了提供的放大。
CoAP also supports the use of multicast IP addresses in requests, an important requirement for M2M. Multicast CoAP requests may be the source of accidental or deliberate DoS attacks, especially over constrained networks. This specification attempts to reduce the amplification effects of multicast requests by limiting when a response is returned. To limit the possibility of malicious use, CoAP servers SHOULD NOT accept multicast requests that can not be authenticated in some way, cryptographically or by some multicast boundary limiting the potential sources. If possible, a CoAP server SHOULD limit the support for multicast requests to the specific resources where the feature is required.
CoAP还支持在请求中使用多播IP地址，这是M2M的一个重要要求。多播CoAP请求可能是意外或蓄意DoS攻击的来源，尤其是在受限网络上。本规范试图通过限制何时返回响应来减少多播请求的放大效应。为了限制恶意使用的可能性，CoAP服务器不应接受无法通过某种方式、加密方式或限制潜在源的某个多播边界进行身份验证的多播请求。如果可能，CoAP服务器应将对多播请求的支持限制在需要该功能的特定资源上。
On some general-purpose operating systems providing a POSIX-style API [IEEE1003.1], it is not straightforward to find out whether a packet received was addressed to a multicast address. While many implementations will know whether they have joined a multicast group, this creates a problem for packets addressed to multicast addresses of the form FF0x::1, which are received by every IPv6 node. Implementations SHOULD make use of modern APIs such as IPV6_RECVPKTINFO [RFC3542], if available, to make this determination.
在一些提供POSIX风格API[IEEE1003.1]的通用操作系统上，很难确定接收到的数据包是否被寻址到多播地址。虽然许多实现会知道它们是否加入了多播组，但这会给寻址到FF0x:：1格式的多播地址的数据包带来问题，每个IPv6节点都会收到这些数据包。实现应该使用现代API，如IPV6_RECVPKTINFO[RFC3542]，如果可用，来进行此确定。
Due to the lack of a handshake in UDP, a rogue endpoint that is free to read and write messages carried by the constrained network (i.e., NoSec or PreSharedKey deployments with a nodes/key ratio > 1:1), may easily attack a single endpoint, a group of endpoints, as well as the whole network, e.g., by:
由于UDP中缺少握手，可以自由读写受约束网络（即节点/密钥比>1:1的NOSC或预共享密钥部署）携带的消息的恶意端点可能很容易攻击单个端点、一组端点以及整个网络，例如：
1. spoofing a Reset message in response to a Confirmable message or Non-confirmable message, thus making an endpoint "deaf"; or
1. 欺骗重置消息以响应可确认消息或不可确认消息，从而使端点“聋”；或
2. spoofing an ACK in response to a CON message, thus potentially preventing the sender of the CON message from retransmitting, and drowning out the actual response; or
2. 欺骗应答CON消息的ACK，从而潜在地防止CON消息的发送者重新传输，并淹没实际响应；或
3. spoofing the entire response with forged payload/options (this has different levels of impact: from single-response disruption, to much bolder attacks on the supporting infrastructure, e.g., poisoning proxy caches, or tricking validation/lookup interfaces in resource directories and, more generally, any component that stores global network state and uses CoAP as the messaging facility to handle setting or updating state is a potential target.); or
3. 使用伪造的有效负载/选项欺骗整个响应（这会产生不同程度的影响：从单一响应中断到对支持基础设施更大胆的攻击，例如，毒害代理缓存，或欺骗资源目录中的验证/查找接口，更一般地说，是存储全局网络状态并使用CoAP作为消息传递工具来处理设置的任何组件或更新状态是潜在目标。）；或
4. spoofing a multicast request for a target node; this may result in network congestion/collapse, a DoS attack on the victim, or forced wake-up from sleeping; or
4. 欺骗针对目标节点的多播请求；这可能会导致网络拥塞/崩溃、对受害者的DoS攻击或强制从睡眠中唤醒；或
5. spoofing observe messages, etc.
5. 欺骗、监视消息等。
Response spoofing by off-path attackers can be detected and mitigated even without transport layer security by choosing a nontrivial, randomized token in the request (Section 5.3.1). [RFC4086] discusses randomness requirements for security.
即使在没有传输层安全的情况下，也可以通过在请求中选择非平凡的随机令牌来检测和缓解非路径攻击者的响应欺骗（第5.3.1节）。[RFC4086]讨论了安全性的随机性要求。
In principle, other kinds of spoofing can be detected by CoAP only in case Confirmable message semantics is used, because of unexpected Acknowledgement or Reset messages coming from the deceived endpoint. But this imposes keeping track of the used Message IDs, which is not always possible, and moreover detection becomes available usually after the damage is already done. This kind of attack can be prevented using security modes other than NoSec.
原则上，由于来自被欺骗端点的意外确认或重置消息，只有在使用可确认消息语义的情况下，CoAP才能检测到其他类型的欺骗。但这就要求跟踪所使用的消息ID，这并不总是可能的，而且通常在损坏已经发生之后，检测才可用。可以使用非NOSC的安全模式来防止此类攻击。
With or without source address spoofing, a client can attempt to overload a server by sending requests, preferably complex ones, to a server; address spoofing makes tracing back, and blocking, this attack harder. Given that the cost of a CON request is small, this attack can easily be executed. Under this attack, a constrained node
无论是否存在源地址欺骗，客户端都可以通过向服务器发送请求（最好是复杂的请求）来尝试过载服务器；地址欺骗使得追踪和阻止这种攻击更加困难。考虑到CON请求的成本很小，这种攻击很容易执行。在这种攻击下，一个受约束的节点
with limited total energy available may exhaust that energy much more quickly than planned (battery depletion attack). Also, if the client uses a Confirmable message and the server responds with a Confirmable separate response to a (possibly spoofed) address that does not respond, the server will have to allocate buffer and retransmission logic for each response up to the exhaustion of MAX_TRANSMIT_SPAN, making it more likely that it runs out of resources for processing legitimate traffic. The latter problem can be mitigated somewhat by limiting the rate of responses as discussed in Section 4.7. An attacker could also spoof the address of a legitimate client; this might cause the server, if it uses separate responses, to block legitimate responses to that client because of NSTART=1. All these attacks can be prevented using a security mode other than NoSec, thus leaving only attacks on the security protocol.
由于可用总能量有限，可能会比计划中更快地消耗能量（电池耗尽攻击）。此外，如果客户端使用可确认的消息，而服务器对没有响应的（可能是伪造的）地址做出可确认的单独响应，则服务器必须为每个响应分配缓冲区和重传逻辑，直到最大传输跨度耗尽，使其更有可能耗尽用于处理合法流量的资源。后一个问题可以通过限制第4.7节中讨论的响应速度来有所缓解。攻击者还可以伪造合法客户端的地址；如果服务器使用单独的响应，这可能会导致服务器由于NSTART=1而阻止对该客户端的合法响应。所有这些攻击都可以使用非NOSC的安全模式来防止，因此只留下对安全协议的攻击。
The ability to incite a CoAP endpoint to send packets to a fake source address can be used not only for amplification, but also for cross-protocol attacks against a victim listening to UDP packets at a given address (IP address and port). This would occur as follows:
煽动CoAP端点向假源地址发送数据包的能力不仅可用于放大，还可用于针对在给定地址（IP地址和端口）侦听UDP数据包的受害者的跨协议攻击。这将发生如下情况：
o The attacker sends a message to a CoAP endpoint with the given address as the fake source address.
o 攻击者向CoAP端点发送消息，将给定地址作为假源地址。
o The CoAP endpoint replies with a message to the given source address.
o CoAP端点会向给定的源地址回复一条消息。
o The victim at the given address receives a UDP packet that it interprets according to the rules of a different protocol.
o 给定地址的受害者接收一个UDP数据包，该数据包根据不同协议的规则进行解释。
This may be used to circumvent firewall rules that prevent direct communication from the attacker to the victim but happen to allow communication from the CoAP endpoint (which may also host a valid role in the other protocol) to the victim.
这可用于规避防火墙规则，防火墙规则阻止攻击者直接与受害者进行通信，但恰好允许从CoAP端点（也可能在其他协议中承载有效角色）与受害者进行通信。
Also, CoAP endpoints may be the victim of a cross-protocol attack generated through an endpoint of another UDP-based protocol such as DNS. In both cases, attacks are possible if the security properties of the endpoints rely on checking IP addresses (and firewalling off direct attacks sent from outside using fake IP addresses). In general, because of their lack of context, UDP-based protocols are relatively easy targets for cross-protocol attacks.
此外，CoAP端点可能是通过另一个基于UDP的协议（如DNS）的端点生成的跨协议攻击的受害者。在这两种情况下，如果端点的安全属性依赖于检查IP地址（以及使用假IP地址阻止从外部发送的直接攻击），则可能发生攻击。通常，由于缺乏上下文，基于UDP的协议相对容易成为跨协议攻击的目标。
Finally, CoAP URIs transported by other means could be used to incite clients to send messages to endpoints of other protocols.
最后，通过其他方式传输的CoAP URI可用于激励客户端向其他协议的端点发送消息。
One mitigation against cross-protocol attacks is strict checking of the syntax of packets received, combined with sufficient difference in syntax. As an example, it might help if it were difficult to incite a DNS server to send a DNS response that would pass the checks of a CoAP endpoint. Unfortunately, the first two bytes of a DNS reply are an ID that can be chosen by the attacker and that map into the interesting part of the CoAP header, and the next two bytes are then interpreted as CoAP's Message ID (i.e., any value is acceptable). The DNS count words may be interpreted as multiple instances of a (nonexistent but elective) CoAP option 0, or possibly as a Token. The echoed query finally may be manufactured by the attacker to achieve a desired effect on the CoAP endpoint; the response added by the server (if any) might then just be interpreted as added payload.
针对跨协议攻击的一种缓解措施是严格检查所接收数据包的语法，并结合语法上的充分差异。例如，如果很难激励DNS服务器发送通过CoAP端点检查的DNS响应，则可能会有所帮助。不幸的是，DNS应答的前两个字节是攻击者可以选择的ID，并映射到CoAP头的感兴趣部分，接下来的两个字节则被解释为CoAP的消息ID（即，任何值都是可接受的）。DNS计数字可解释为（不存在但可选）CoAP选项0的多个实例，或可能解释为令牌。攻击者最终可能会制造回显查询，以在CoAP端点上实现所需的效果；服务器添加的响应（如果有）可能被解释为添加的负载。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID | T, TKL, code
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z | RCODE | Message ID
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID | T, TKL, code
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z | RCODE | Message ID
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 15: DNS Header ([RFC1035], Section 4.1.1) vs. CoAP Message
图15:DNS头（[RFC1035]，第4.1.1节）与CoAP消息
In general, for any pair of protocols, one of the protocols can very well have been designed in a way that enables an attacker to cause the generation of replies that look like messages of the other protocol. It is often much harder to ensure or prove the absence of viable attacks than to generate examples that may not yet completely enable an attack but might be further developed by more creative minds. Cross-protocol attacks can therefore only be completely mitigated if endpoints don't authorize actions desired by an attacker just based on trusting the source IP address of a packet. Conversely, a NoSec environment that completely relies on a firewall for CoAP security not only needs to firewall off the CoAP endpoints but also all other endpoints that might be incited to send UDP messages to CoAP endpoints using some other UDP-based protocol.
通常，对于任何一对协议，其中一个协议的设计方式都可以使攻击者能够生成类似于另一个协议的消息的回复。确保或证明不存在可行的攻击通常比生成可能尚未完全启用攻击但可能由更具创造性的头脑进一步开发的示例要困难得多。因此，只有当端点仅基于对数据包源IP地址的信任而不授权攻击者所需的操作时，跨协议攻击才能得到完全缓解。相反，完全依赖防火墙实现CoAP安全的NOSC环境不仅需要对CoAP端点进行防火墙隔离，还需要对所有可能被煽动使用其他基于UDP的协议向CoAP端点发送UDP消息的其他端点进行防火墙隔离。
In addition to the considerations above, the security considerations for DTLS with respect to cross-protocol attacks apply. For example, if the same DTLS security association ("connection") is used to carry data of multiple protocols, DTLS no longer provides protection against cross-protocol attacks between these protocols.
除上述注意事项外，DTL在跨协议攻击方面的安全注意事项也适用。例如，如果使用相同的DTLS安全关联（“连接”）来承载多个协议的数据，则DTLS不再提供针对这些协议之间的跨协议攻击的保护。
Implementers on constrained nodes often find themselves without a good source of entropy [RFC4086]. If that is the case, the node MUST NOT be used for processes that require good entropy, such as key generation. Instead, keys should be generated externally and added to the device during manufacturing or commissioning.
受约束节点上的实现者经常发现自己没有一个好的熵源[RFC4086]。如果是这种情况，则该节点不得用于需要良好熵的过程，例如密钥生成。相反，应在外部生成密钥，并在制造或调试期间将其添加到设备中。
Due to their low processing power, constrained nodes are particularly susceptible to timing attacks. Special care must be taken in implementation of cryptographic primitives.
由于处理能力低，受约束节点特别容易受到定时攻击。在实现加密原语时必须特别小心。
Large numbers of constrained nodes will be installed in exposed environments and will have little resistance to tampering, including recovery of keying materials. This needs to be considered when defining the scope of credentials assigned to them. In particular, assigning a shared key to a group of nodes may make any single constrained node a target for subverting the entire group.
大量受约束节点将安装在暴露的环境中，对篡改（包括恢复密钥材料）几乎没有抵抗力。在定义分配给他们的凭据的范围时，需要考虑这一点。特别是，将共享密钥分配给一组节点可能会使任何单个受约束节点成为颠覆整个组的目标。
This document defines two sub-registries for the values of the Code field in the CoAP header within the "Constrained RESTful Environments (CoRE) Parameters" registry, hereafter referred to as the "CoRE Parameters" registry.
本文档为“受限RESTful环境（核心）参数”注册表（以下简称“核心参数”注册表）中CoAP头中的代码字段值定义了两个子注册表。
Values in the two sub-registries are eight-bit values notated as three decimal digits c.dd separated by a period between the first and the second digit; the first digit c is between 0 and 7 and denotes the code class; the second and third digits dd denote a decimal number between 00 and 31 for the detail.
两个子注册表中的值为八位值，表示为三位十进制数字c.dd，由第一位和第二位数字之间的一个句点分隔；第一个数字c介于0和7之间，表示代码类；第二位和第三位数字dd表示细节的十进制数，介于00和31之间。
All Code values are assigned by sub-registries according to the following ranges:
所有代码值由子注册表按照以下范围分配：
0.00 Indicates an Empty message (see Section 4.1).
0.00 表示一条空消息（见第4.1节）。
0.01-0.31 Indicates a request. Values in this range are assigned by the "CoAP Method Codes" sub-registry (see Section 12.1.1).
0.01-0.31表示请求。该范围内的值由“CoAP方法代码”子注册表分配（见第12.1.1节）。
1.00-1.31 Reserved
1.00-1.31保留
2.00-5.31 Indicates a response. Values in this range are assigned by the "CoAP Response Codes" sub-registry (see Section 12.1.2).
2.00-5.31表示响应。该范围内的值由“CoAP响应代码”子注册表分配（见第12.1.2节）。
6.00-7.31 Reserved
6.00-7.31预留
The name of the sub-registry is "CoAP Method Codes".
子注册表的名称为“CoAP方法代码”。
Each entry in the sub-registry must include the Method Code in the range 0.01-0.31, the name of the method, and a reference to the method's documentation.
子注册表中的每个条目必须包括0.01-0.31范围内的方法代码、方法名称以及对方法文档的引用。
Initial entries in this sub-registry are as follows:
此子注册表中的初始条目如下：
+------+--------+-----------+
| Code | Name | Reference |
+------+--------+-----------+
| 0.01 | GET | [RFC7252] |
| 0.02 | POST | [RFC7252] |
| 0.03 | PUT | [RFC7252] |
| 0.04 | DELETE | [RFC7252] |
+------+--------+-----------+
+------+--------+-----------+
| Code | Name | Reference |
+------+--------+-----------+
| 0.01 | GET | [RFC7252] |
| 0.02 | POST | [RFC7252] |
| 0.03 | PUT | [RFC7252] |
| 0.04 | DELETE | [RFC7252] |
+------+--------+-----------+
Table 5: CoAP Method Codes
表5:CoAP方法代码
All other Method Codes are Unassigned.
所有其他方法代码均未分配。
The IANA policy for future additions to this sub-registry is "IETF Review or IESG Approval" as described in [RFC5226].
如[RFC5226]所述，本子注册中心未来新增的IANA政策为“IETF审查或IESG批准”。
The documentation of a Method Code should specify the semantics of a request with that code, including the following properties:
方法代码的文档应使用该代码指定请求的语义，包括以下属性：
o The Response Codes the method returns in the success case.
o 方法在成功案例中返回的响应代码。
o Whether the method is idempotent, safe, or both.
o 方法是幂等的、安全的还是两者都是。
The name of the sub-registry is "CoAP Response Codes".
子注册表的名称为“CoAP响应代码”。
Each entry in the sub-registry must include the Response Code in the range 2.00-5.31, a description of the Response Code, and a reference to the Response Code's documentation.
子注册表中的每个条目必须包括范围为2.00-5.31的响应代码、响应代码的说明以及响应代码文档的参考。
Initial entries in this sub-registry are as follows:
此子注册表中的初始条目如下：
+------+------------------------------+-----------+
| Code | Description | Reference |
+------+------------------------------+-----------+
| 2.01 | Created | [RFC7252] |
| 2.02 | Deleted | [RFC7252] |
| 2.03 | Valid | [RFC7252] |
| 2.04 | Changed | [RFC7252] |
| 2.05 | Content | [RFC7252] |
| 4.00 | Bad Request | [RFC7252] |
| 4.01 | Unauthorized | [RFC7252] |
| 4.02 | Bad Option | [RFC7252] |
| 4.03 | Forbidden | [RFC7252] |
| 4.04 | Not Found | [RFC7252] |
| 4.05 | Method Not Allowed | [RFC7252] |
| 4.06 | Not Acceptable | [RFC7252] |
| 4.12 | Precondition Failed | [RFC7252] |
| 4.13 | Request Entity Too Large | [RFC7252] |
| 4.15 | Unsupported Content-Format | [RFC7252] |
| 5.00 | Internal Server Error | [RFC7252] |
| 5.01 | Not Implemented | [RFC7252] |
| 5.02 | Bad Gateway | [RFC7252] |
| 5.03 | Service Unavailable | [RFC7252] |
| 5.04 | Gateway Timeout | [RFC7252] |
| 5.05 | Proxying Not Supported | [RFC7252] |
+------+------------------------------+-----------+
+------+------------------------------+-----------+
| Code | Description | Reference |
+------+------------------------------+-----------+
| 2.01 | Created | [RFC7252] |
| 2.02 | Deleted | [RFC7252] |
| 2.03 | Valid | [RFC7252] |
| 2.04 | Changed | [RFC7252] |
| 2.05 | Content | [RFC7252] |
| 4.00 | Bad Request | [RFC7252] |
| 4.01 | Unauthorized | [RFC7252] |
| 4.02 | Bad Option | [RFC7252] |
| 4.03 | Forbidden | [RFC7252] |
| 4.04 | Not Found | [RFC7252] |
| 4.05 | Method Not Allowed | [RFC7252] |
| 4.06 | Not Acceptable | [RFC7252] |
| 4.12 | Precondition Failed | [RFC7252] |
| 4.13 | Request Entity Too Large | [RFC7252] |
| 4.15 | Unsupported Content-Format | [RFC7252] |
| 5.00 | Internal Server Error | [RFC7252] |
| 5.01 | Not Implemented | [RFC7252] |
| 5.02 | Bad Gateway | [RFC7252] |
| 5.03 | Service Unavailable | [RFC7252] |
| 5.04 | Gateway Timeout | [RFC7252] |
| 5.05 | Proxying Not Supported | [RFC7252] |
+------+------------------------------+-----------+
Table 6: CoAP Response Codes
表6:CoAP响应代码
The Response Codes 3.00-3.31 are Reserved for future use. All other Response Codes are Unassigned.
响应代码3.00-3.31保留供将来使用。所有其他响应代码均未分配。
The IANA policy for future additions to this sub-registry is "IETF Review or IESG Approval" as described in [RFC5226].
如[RFC5226]所述，本子注册中心未来新增的IANA政策为“IETF审查或IESG批准”。
The documentation of a Response Code should specify the semantics of a response with that code, including the following properties:
响应代码的文档应使用该代码指定响应的语义，包括以下属性：
o The methods the Response Code applies to.
o 响应代码应用于的方法。
o Whether payload is required, optional, or not allowed.
o 有效负载是必需的、可选的还是不允许的。
o The semantics of the payload. For example, the payload of a 2.05 (Content) response is a representation of the target resource; the payload in an error response is a human-readable diagnostic payload.
o 有效负载的语义。例如，2.05（内容）响应的有效载荷是目标资源的表示；错误响应中的有效负载是人类可读的诊断有效负载。
o The format of the payload. For example, the format in a 2.05 (Content) response is indicated by the Content-Format Option; the format of the payload in an error response is always Net-Unicode text.
o 有效负载的格式。例如，2.05（内容）响应中的格式由内容格式选项指示；错误响应中的有效负载格式始终为Net Unicode文本。
o Whether the response is cacheable according to the freshness model.
o 根据新鲜度模型，响应是否可缓存。
o Whether the response is validatable according to the validation model.
o 根据验证模型，响应是否可验证。
o Whether the response causes a cache to mark responses stored for the request URI as not fresh.
o 响应是否导致缓存将为请求URI存储的响应标记为非新响应。
This document defines a sub-registry for the Option Numbers used in CoAP options within the "CoRE Parameters" registry. The name of the sub-registry is "CoAP Option Numbers".
本文件定义了“核心参数”注册表中CoAP选项中使用的选项编号的子注册表。子注册表的名称为“CoAP选项编号”。
Each entry in the sub-registry must include the Option Number, the name of the option, and a reference to the option's documentation.
子注册表中的每个条目必须包括选项编号、选项名称以及对选项文档的引用。
Initial entries in this sub-registry are as follows:
此子注册表中的初始条目如下：
+--------+------------------+-----------+
| Number | Name | Reference |
+--------+------------------+-----------+
| 0 | (Reserved) | [RFC7252] |
| 1 | If-Match | [RFC7252] |
| 3 | Uri-Host | [RFC7252] |
| 4 | ETag | [RFC7252] |
| 5 | If-None-Match | [RFC7252] |
| 7 | Uri-Port | [RFC7252] |
| 8 | Location-Path | [RFC7252] |
| 11 | Uri-Path | [RFC7252] |
| 12 | Content-Format | [RFC7252] |
| 14 | Max-Age | [RFC7252] |
| 15 | Uri-Query | [RFC7252] |
| 17 | Accept | [RFC7252] |
| 20 | Location-Query | [RFC7252] |
| 35 | Proxy-Uri | [RFC7252] |
| 39 | Proxy-Scheme | [RFC7252] |
| 60 | Size1 | [RFC7252] |
| 128 | (Reserved) | [RFC7252] |
| 132 | (Reserved) | [RFC7252] |
| 136 | (Reserved) | [RFC7252] |
| 140 | (Reserved) | [RFC7252] |
+--------+------------------+-----------+
+--------+------------------+-----------+
| Number | Name | Reference |
+--------+------------------+-----------+
| 0 | (Reserved) | [RFC7252] |
| 1 | If-Match | [RFC7252] |
| 3 | Uri-Host | [RFC7252] |
| 4 | ETag | [RFC7252] |
| 5 | If-None-Match | [RFC7252] |
| 7 | Uri-Port | [RFC7252] |
| 8 | Location-Path | [RFC7252] |
| 11 | Uri-Path | [RFC7252] |
| 12 | Content-Format | [RFC7252] |
| 14 | Max-Age | [RFC7252] |
| 15 | Uri-Query | [RFC7252] |
| 17 | Accept | [RFC7252] |
| 20 | Location-Query | [RFC7252] |
| 35 | Proxy-Uri | [RFC7252] |
| 39 | Proxy-Scheme | [RFC7252] |
| 60 | Size1 | [RFC7252] |
| 128 | (Reserved) | [RFC7252] |
| 132 | (Reserved) | [RFC7252] |
| 136 | (Reserved) | [RFC7252] |
| 140 | (Reserved) | [RFC7252] |
+--------+------------------+-----------+
Table 7: CoAP Option Numbers
表7:CoAP选项编号
The IANA policy for future additions to this sub-registry is split into three tiers as follows. The range of 0..255 is reserved for options defined by the IETF (IETF Review or IESG Approval). The range of 256..2047 is reserved for commonly used options with public specifications (Specification Required). The range of 2048..64999 is for all other options including private or vendor-specific ones, which undergo a Designated Expert review to help ensure that the option semantics are defined correctly. The option numbers between 65000 and 65535 inclusive are reserved for experiments. They are not meant for vendor-specific use of any kind and MUST NOT be used in operational deployments.
IANA对该子注册中心未来添加的政策分为三层，如下所示。0..255的范围保留给IETF定义的选项（IETF审查或IESG批准）。256..2047的范围保留给具有公共规范（需要规范）的常用选项。2048..64999的范围适用于所有其他选项，包括私人或特定于供应商的选项，这些选项经过指定专家审查，以帮助确保正确定义选项语义。65000和65535（含65000和65535）之间的选项号保留用于实验。它们不适用于任何类型的供应商特定用途，也不得用于操作部署。
+-------------+---------------------------------------+
| Range | Registration Procedures |
+-------------+---------------------------------------+
| 0-255 | IETF Review or IESG Approval |
| 256-2047 | Specification Required |
| 2048-64999 | Expert Review |
| 65000-65535 | Experimental use (no operational use) |
+-------------+---------------------------------------+
+-------------+---------------------------------------+
| Range | Registration Procedures |
+-------------+---------------------------------------+
| 0-255 | IETF Review or IESG Approval |
| 256-2047 | Specification Required |
| 2048-64999 | Expert Review |
| 65000-65535 | Experimental use (no operational use) |
+-------------+---------------------------------------+
Table 8: CoAP Option Numbers: Registration Procedures
表8:CoAP选项编号：注册程序
The documentation of an Option Number should specify the semantics of an option with that number, including the following properties:
选项编号的文档应指定具有该编号的选项的语义，包括以下属性：
o The meaning of the option in a request.
o 请求中选项的含义。
o The meaning of the option in a response.
o 响应中选项的含义。
o Whether the option is critical or elective, as determined by the Option Number.
o 选项是关键选项还是可选选项，取决于选项编号。
o Whether the option is Safe-to-Forward, and, if yes, whether it is part of the Cache-Key, as determined by the Option Number (see Section 5.4.2).
o 该选项是否可以安全转发，如果是，则它是否是由选项编号确定的缓存密钥的一部分（见第5.4.2节）。
o The format and length of the option's value.
o 选项值的格式和长度。
o Whether the option must occur at most once or whether it can occur multiple times.
o 选项是否必须最多出现一次，或者是否可以出现多次。
o The default value, if any. For a critical option with a default value, a discussion on how the default value enables processing by implementations that do not support the critical option (Section 5.4.4).
o 默认值（如果有）。对于具有默认值的关键选项，讨论默认值如何允许不支持关键选项的实现进行处理（第5.4.4节）。
Internet media types are identified by a string, such as "application/xml" [RFC2046]. In order to minimize the overhead of using these media types to indicate the format of payloads, this document defines a sub-registry for a subset of Internet media types to be used in CoAP and assigns each, in combination with a content-coding, a numeric identifier. The name of the sub-registry is "CoAP Content-Formats", within the "CoRE Parameters" registry.
Internet媒体类型由字符串标识，例如“application/xml”[RFC2046]。为了最大限度地减少使用这些媒体类型指示有效载荷格式的开销，本文档为要在CoAP中使用的互联网媒体类型子集定义了一个子注册表，并结合内容编码为每个子注册表分配一个数字标识符。子注册表的名称为“核心参数”注册表中的“CoAP内容格式”。
Each entry in the sub-registry must include the media type registered with IANA, the numeric identifier in the range 0-65535 to be used for that media type in CoAP, the content-coding associated with this identifier, and a reference to a document describing what a payload with that media type means semantically.
子注册表中的每个条目必须包括IANA注册的媒体类型、CoAP中用于该媒体类型的0-65535范围内的数字标识符、与该标识符关联的内容编码，以及对描述该媒体类型有效负载语义含义的文档的引用。
CoAP does not include a separate way to convey content-encoding information with a request or response, and for that reason the content-encoding is also specified for each identifier (if any). If multiple content-encodings will be used with a media type, then a separate Content-Format identifier for each is to be registered. Similarly, other parameters related to an Internet media type, such as level, can be defined for a CoAP Content-Format entry.
CoAP不包括通过请求或响应传递内容编码信息的单独方式，因此，还为每个标识符（如果有）指定了内容编码。如果一个媒体类型将使用多个内容编码，则将为每个媒体类型注册一个单独的内容格式标识符。类似地，可以为CoAP内容格式条目定义与互联网媒体类型相关的其他参数，例如级别。
Initial entries in this sub-registry are as follows:
此子注册表中的初始条目如下：
+--------------------------+----------+----+------------------------+
| Media type | Encoding | ID | Reference |
+--------------------------+----------+----+------------------------+
| text/plain; | - | 0 | [RFC2046] [RFC3676] |
| charset=utf-8 | | | [RFC5147] |
| application/link-format | - | 40 | [RFC6690] |
| application/xml | - | 41 | [RFC3023] |
| application/octet-stream | - | 42 | [RFC2045] [RFC2046] |
| application/exi | - | 47 | [REC-exi-20140211] |
| application/json | - | 50 | [RFC7159] |
+--------------------------+----------+----+------------------------+
+--------------------------+----------+----+------------------------+
| Media type | Encoding | ID | Reference |
+--------------------------+----------+----+------------------------+
| text/plain; | - | 0 | [RFC2046] [RFC3676] |
| charset=utf-8 | | | [RFC5147] |
| application/link-format | - | 40 | [RFC6690] |
| application/xml | - | 41 | [RFC3023] |
| application/octet-stream | - | 42 | [RFC2045] [RFC2046] |
| application/exi | - | 47 | [REC-exi-20140211] |
| application/json | - | 50 | [RFC7159] |
+--------------------------+----------+----+------------------------+
Table 9: CoAP Content-Formats
表9:CoAP内容格式
The identifiers between 65000 and 65535 inclusive are reserved for experiments. They are not meant for vendor-specific use of any kind and MUST NOT be used in operational deployments. The identifiers between 256 and 9999 are reserved for future use in IETF specifications (IETF Review or IESG Approval). All other identifiers are Unassigned.
65000和65535之间的标识符保留用于实验。它们不适用于任何类型的供应商特定用途，也不得用于操作部署。256和9999之间的标识符保留用于IETF规范（IETF审查或IESG批准）中的未来使用。所有其他标识符均未分配。
Because the namespace of single-byte identifiers is so small, the IANA policy for future additions in the range 0-255 inclusive to the sub-registry is "Expert Review" as described in [RFC5226]. The IANA policy for additions in the range 10000-64999 inclusive is "First Come First Served" as described in [RFC5226]. This is summarized in the following table.
由于单字节标识符的名称空间非常小，因此对于子注册表中0-255范围内的未来添加，IANA策略为[RFC5226]中所述的“专家评审”。如[RFC5226]所述，对于10000-64999（含10000-64999）范围内的新增项目，IANA政策为“先到先得”。下表对此进行了总结。
+-------------+---------------------------------------+
| Range | Registration Procedures |
+-------------+---------------------------------------+
| 0-255 | Expert Review |
| 256-9999 | IETF Review or IESG Approval |
| 10000-64999 | First Come First Served |
| 65000-65535 | Experimental use (no operational use) |
+-------------+---------------------------------------+
+-------------+---------------------------------------+
| Range | Registration Procedures |
+-------------+---------------------------------------+
| 0-255 | Expert Review |
| 256-9999 | IETF Review or IESG Approval |
| 10000-64999 | First Come First Served |
| 65000-65535 | Experimental use (no operational use) |
+-------------+---------------------------------------+
Table 10: CoAP Content-Formats: Registration Procedures
表10:CoAP内容格式：注册程序
In machine-to-machine applications, it is not expected that generic Internet media types such as text/plain, application/xml or application/octet-stream are useful for real applications in the long term. It is recommended that M2M applications making use of CoAP request new Internet media types from IANA indicating semantic information about how to create or parse a payload. For example, a Smart Energy application payload carried as XML might request a more specific type like application/se+xml or application/se-exi.
在机器对机器的应用程序中，一般的Internet媒体类型（如文本/普通、应用程序/xml或应用程序/八位字节流）从长远来看并不适用于实际应用程序。建议使用CoAP的M2M应用程序从IANA请求新的Internet媒体类型，指示有关如何创建或解析有效负载的语义信息。例如，作为XML携带的智能能源应用程序负载可能会请求更具体的类型，如application/se+XML或application/se-exi。
This document contains the request for the registration of the Uniform Resource Identifier (URI) scheme "coap". The registration request complies with [RFC4395].
本文件包含注册统一资源标识符（URI）方案“coap”的请求。注册请求符合[RFC4395]。
URI scheme name. coap
URI方案名称。哄骗
Status. Permanent.
地位永久的
URI scheme syntax. Defined in Section 6.1 of [RFC7252].
URI方案语法。定义见[RFC7252]第6.1节。
URI scheme semantics. The "coap" URI scheme provides a way to identify resources that are potentially accessible over the Constrained Application Protocol (CoAP). The resources can be located by contacting the governing CoAP server and operated on by sending CoAP requests to the server. This scheme can thus be compared to the "http" URI scheme [RFC2616]. See Section 6 of [RFC7252] for the details of operation.
URI模式语义。“coap”URI方案提供了一种方法来识别通过受限应用程序协议（coap）可能访问的资源。可以通过联系管理CoAP服务器来定位资源，并通过向服务器发送CoAP请求来操作资源。因此，可以将此方案与“http”URI方案[RFC2616]进行比较。操作详情见[RFC7252]第6节。
Encoding considerations. The scheme encoding conforms to the encoding rules established for URIs in [RFC3986], i.e., internationalized and reserved characters are expressed using UTF-8-based percent-encoding.
编码注意事项。方案编码符合[RFC3986]中为URI建立的编码规则，即国际化和保留字符使用基于UTF-8的百分比编码表示。
Applications/protocols that use this URI scheme name. The scheme is used by CoAP endpoints to access CoAP resources.
使用此URI方案名称的应用程序/协议。CoAP端点使用该方案访问CoAP资源。
Interoperability considerations. None.
互操作性考虑。没有一个
Security considerations. See Section 11.1 of [RFC7252].
安全考虑。见[RFC7252]第11.1节。
Contact. IETF Chair <chair@ietf.org>
联系IETF主席<chair@ietf.org>
Author/Change controller.
IESG <iesg@ietf.org>
Author/Change controller.
IESG <iesg@ietf.org>
References. [RFC7252]
参考资料。[RFC7252]
This document contains the request for the registration of the Uniform Resource Identifier (URI) scheme "coaps". The registration request complies with [RFC4395].
本文件包含注册统一资源标识符（URI）方案“COAP”的请求。注册请求符合[RFC4395]。
URI scheme name. coaps
URI方案名称。哄骗
Status. Permanent.
地位永久的
URI scheme syntax. Defined in Section 6.2 of [RFC7252].
URI方案语法。定义见[RFC7252]第6.2节。
URI scheme semantics. The "coaps" URI scheme provides a way to identify resources that are potentially accessible over the Constrained Application Protocol (CoAP) using Datagram Transport Layer Security (DTLS) for transport security. The resources can be located by contacting the governing CoAP server and operated on by sending CoAP requests to the server. This scheme can thus be compared to the "https" URI scheme [RFC2616]. See Section 6 of [RFC7252] for the details of operation.
URI模式语义。“coaps”URI方案提供了一种使用数据报传输层安全性（DTLS）来识别可能通过受限应用程序协议（CoAP）访问的资源的方法。可以通过联系管理CoAP服务器来定位资源，并通过向服务器发送CoAP请求来操作资源。因此，可以将此方案与“https”URI方案[RFC2616]进行比较。操作详情见[RFC7252]第6节。
Encoding considerations. The scheme encoding conforms to the encoding rules established for URIs in [RFC3986], i.e., internationalized and reserved characters are expressed using UTF-8-based percent-encoding.
编码注意事项。方案编码符合[RFC3986]中为URI建立的编码规则，即国际化和保留字符使用基于UTF-8的百分比编码表示。
Applications/protocols that use this URI scheme name. The scheme is used by CoAP endpoints to access CoAP resources using DTLS.
使用此URI方案名称的应用程序/协议。CoAP端点使用该方案使用DTL访问CoAP资源。
Interoperability considerations. None.
互操作性考虑。没有一个
Security considerations. See Section 11.1 of [RFC7252].
安全考虑。见[RFC7252]第11.1节。
Contact. IETF Chair <chair@ietf.org>
联系IETF主席<chair@ietf.org>
Author/Change controller.
IESG <iesg@ietf.org>
Author/Change controller.
IESG <iesg@ietf.org>
References. [RFC7252]
参考资料。[RFC7252]
One of the functions of CoAP is resource discovery: a CoAP client can ask a CoAP server about the resources offered by it (see Section 7). To enable resource discovery just based on the knowledge of an IP address, the CoAP port for resource discovery needs to be standardized.
CoAP的功能之一是资源发现：CoAP客户端可以向CoAP服务器询问它提供的资源（参见第7节）。为了仅基于IP地址的知识实现资源发现，需要对用于资源发现的CoAP端口进行标准化。
IANA has assigned the port number 5683 and the service name "coap", in accordance with [RFC6335].
IANA已根据[RFC6335]分配了端口号5683和服务名称“coap”。
Besides unicast, CoAP can be used with both multicast and anycast.
除了单播，CoAP还可以与多播和选播一起使用。
Service Name. coap
服务名称。哄骗
Transport Protocol. udp
传输协议。udp
Assignee. IESG <iesg@ietf.org>
受让人。IESG<iesg@ietf.org>
Contact. IETF Chair <chair@ietf.org>
联系IETF主席<chair@ietf.org>
Description. Constrained Application Protocol (CoAP)
描述受限应用协议（CoAP）
Reference. [RFC7252]
参考[RFC7252]
Port Number. 5683
端口号。5683
CoAP resource discovery may also be provided using the DTLS-secured CoAP "coaps" scheme. Thus, the CoAP port for secure resource discovery needs to be standardized.
还可以使用DTLS安全CoAP“CoAP”方案提供CoAP资源发现。因此，安全资源发现的CoAP端口需要标准化。
IANA has assigned the port number 5684 and the service name "coaps", in accordance with [RFC6335].
IANA已根据[RFC6335]分配了端口号5684和服务名称“coaps”。
Besides unicast, DTLS-secured CoAP can be used with anycast.
除了单播之外，DTLS安全CoAP还可以与选播一起使用。
Service Name. coaps
服务名称。哄骗
Transport Protocol. udp
传输协议。udp
Assignee. IESG <iesg@ietf.org>
受让人。IESG<iesg@ietf.org>
Contact. IETF Chair <chair@ietf.org>
联系IETF主席<chair@ietf.org>
Description. DTLS-secured CoAP
描述DTLS安全CoAP
Reference. [RFC7252]
参考[RFC7252]
Port Number. 5684
端口号。5684
Section 8, "Multicast CoAP", defines the use of multicast. IANA has assigned the following multicast addresses for use by CoAP nodes:
第8节“多播CoAP”定义了多播的使用。IANA已分配以下多播地址供CoAP节点使用：
IPv4 -- "All CoAP Nodes" address 224.0.1.187, from the "IPv4 Multicast Address Space Registry". As the address is used for discovery that may span beyond a single network, it has come from the Internetwork Control Block (224.0.1.x, RFC 5771).
IPv4--“IPv4多播地址空间注册表”中的“所有CoAP节点”地址224.0.1.187。由于地址用于可能跨越单个网络的发现，因此它来自网络间控制块（224.0.1.x，RFC 5771）。
IPv6 -- "All CoAP Nodes" address FF0X::FD, from the "IPv6 Multicast Address Space Registry", in the "Variable Scope Multicast Addresses" space (RFC 3307). Note that there is a distinct multicast address for each scope that interested CoAP nodes should listen to; CoAP needs the Link-Local and Site-Local scopes only.
IPv6--“可变作用域多播地址”空间（RFC 3307）中“IPv6多播地址空间注册表”中的“所有CoAP节点”地址FF0X:：FD。注意，对于感兴趣的CoAP节点应该侦听的每个作用域，都有一个不同的多播地址；CoAP只需要链接本地范围和站点本地范围。
Brian Frank was a contributor to and coauthor of early versions of this specification.
Brian Frank是该规范早期版本的贡献者和合著者。
Special thanks to Peter Bigot, Esko Dijk, and Cullen Jennings for substantial contributions to the ideas and text in the document, along with countless detailed reviews and discussions.
特别感谢Peter Bigot、Esko Dijk和Cullen Jennings对文件中的想法和文本做出了重大贡献，以及无数详细的评论和讨论。
Thanks to Floris Van den Abeele, Anthony Baire, Ed Beroset, Berta Carballido, Angelo P. Castellani, Gilbert Clark, Robert Cragie, Pierre David, Esko Dijk, Lisa Dusseault, Mehmet Ersue, Thomas Fossati, Tobias Gondrom, Bert Greevenbosch, Tom Herbst, Jeroen Hoebeke, Richard Kelsey, Sye Loong Keoh, Ari Keranen, Matthias Kovatsch, Avi Lior, Stephan Lohse, Salvatore Loreto, Kerry Lynn, Andrew McGregor, Alexey Melnikov, Guido Moritz, Petri Mutka, Colin O'Flynn, Charles Palmer, Adriano Pezzuto, Thomas Poetsch, Robert Quattlebaum, Akbar Rahman, Eric Rescorla, Dan Romascanu, David Ryan, Peter Saint-Andre, Szymon Sasin, Michael Scharf, Dale Seed, Robby Simpson, Peter van der Stok, Michael Stuber, Linyi Tian, Gilman Tolle, Matthieu Vial, Maciej Wasilak, Fan Xianyou, and Alper Yegin for helpful comments and discussions that have shaped the document. Special thanks also to the responsible IETF area director at the time of completion, Barry Leiba, and the IESG reviewers, Adrian Farrel, Martin Stiemerling, Pete Resnick, Richard Barnes, Sean Turner, Spencer Dawkins, Stephen Farrell, and Ted Lemon, who contributed in-depth reviews.
感谢Floris Van den Abele、Anthony Baire、Ed Beroset、Berta Carballido、Angelo P.Castellani、Gilbert Clark、Robert Cragie、Pierre David、Esko Dijk、Lisa Dusseault、Mehmet Ersue、Thomas Fossati、Tobias Gondrom、Bert Greevenbosch、Tom Herbst、Jeroen Hoebek、Richard Kelsey、Sye Long Keoh、Ari Keranen、Matthias Kovatsch、Avi Lior、，斯蒂芬·洛斯、萨尔瓦托·洛雷托、克里·林恩、安德鲁·麦格雷戈、阿列克西·梅尔尼科夫、吉多·莫里茨、佩特里·穆特卡、科林·奥弗林、查尔斯·帕尔默、阿德里亚诺·佩祖托、托马斯·波奇、罗伯特·夸特鲍姆、阿克巴·拉赫曼、埃里克·雷索拉、丹·罗马斯坎努、大卫·瑞安、彼得·圣安德烈、西蒙·萨辛、迈克尔·沙夫、戴尔·塞德、罗比·辛普森、彼得·范德斯托克、，Michael Stuber、Tian Linyi、Gilman Tolle、Matthieu Vial、Maciej Wasilak、Fan Xianyou和Alper Yegin为形成该文件的有用评论和讨论提供了帮助。还特别感谢完成时负责的IETF区域总监Barry Leiba和IESG评审员Adrian Farrel、Martin Stiemerling、Pete Resnick、Richard Barnes、Sean Turner、Spencer Dawkins、Stephen Farrell和Ted Lemon，他们提供了深入的评审。
Some of the text has been borrowed from the working documents of the IETF HTTPBIS working group.
部分文本借用了IETF HTTPBIS工作组的工作文件。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023]Murata，M.，St.Laurent，S.，和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC3676] Gellens, R., "The Text/Plain Format and DelSp Parameters", RFC 3676, February 2004.
[RFC3676]Gellens，R.，“文本/普通格式和DelSp参数”，RFC 36762004年2月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.
[RFC4279]Eronen，P.和H.Tschofenig，“用于传输层安全（TLS）的预共享密钥密码套件”，RFC 4279，2005年12月。
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006.
[RFC4395]Hansen，T.，Hardie，T.，和L.Masinter，“新URI方案的指南和注册程序”，BCP 35，RFC 4395，2006年2月。
[RFC5147] Wilde, E. and M. Duerst, "URI Fragment Identifiers for the text/plain Media Type", RFC 5147, April 2008.
[RFC5147]Wilde，E.和M.Duerst，“文本/普通媒体类型的URI片段标识符”，RFC 5147，2008年4月。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[RFC5198]Klensin，J.和M.Padlipsky，“网络交换的Unicode格式”，RFC 51982008年3月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009.
[RFC5480]Turner，S.，Brown，D.，Yiu，K.，Housley，R.，和T.Polk，“椭圆曲线加密主题公钥信息”，RFC 54802009年3月。
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010.
[RFC5785]诺丁汉，M.和E.Hammer Lahav，“定义众所周知的统一资源标识符（URI）”，RFC 5785，2010年4月。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[RFC5952]Kawamura，S.和M.Kawashima，“IPv6地址文本表示的建议”，RFC 59522010年8月。
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[RFC5988]诺丁汉，M.，“网络链接”，RFC 5988，2010年10月。
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[RFC6066]Eastlake，D.，“传输层安全（TLS）扩展：扩展定义”，RFC6066，2011年1月。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，2012年1月。
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, August 2012.
[RFC6690]Shelby，Z.“受限RESTful环境（核心）链接格式”，RFC 66902012年8月。
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, April 2013.
[RFC6920]Farrell，S.，Kutscher，D.，Dannewitz，C.，Ohlman，B.，Keranen，A.，和P.Hallam Baker，“用哈希命名事物”，RFC 6920，2013年4月。
[RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, June 2014.
[RFC7250]Wouters，P.，Tschofenig，H.，Gilmore，J.，Weiler，S.，和T.Kivinen，“在传输层安全性（TLS）和数据报传输层安全性（DTLS）中使用原始公钥”，RFC 7250，2014年6月。
[RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 7251, June 2014.
[RFC7251]McGrew，D.，Bailey，D.，Campagna，M.，和R.Dugal，“用于传输层安全（TLS）的AES-CCM椭圆曲线密码（ECC）密码套件”，RFC 72512014年6月。
[BLOCK] Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", Work in Progress, October 2013.
[BLOCK]Bormann，C.和Z.Shelby，“CoAP中的区块转移”，正在进行的工作，2013年10月。
[CoAP-MISC] Bormann, C. and K. Hartke, "Miscellaneous additions to CoAP", Work in Progress, December 2013.
[CoAP MISC]Bormann，C.和K.Hartke，“CoAP的其他补充”，在建工程，2013年12月。
[EUI64] IEEE Standards Association, "Guidelines for 64-bit Global Identifier (EUI-64 (TM))", Registration Authority Tutorials, April 2010, <http://standards.ieee.org/regauth/ oui/tutorials/EUI64.html>.
[EUI64]IEEE标准协会，“64位全局标识符（EUI-64（TM））指南”，注册机构教程，2010年4月<http://standards.ieee.org/regauth/ oui/tutorials/EUI64.html>。
[GROUPCOMM] Rahman, A. and E. Dijk, "Group Communication for CoAP", Work in Progress, December 2013.
[GROUPCOMM]Rahman，A.和E.Dijk，“CoAP的团队沟通”，正在进行的工作，2013年12月。
[HHGTTG] Adams, D., "The Hitchhiker's Guide to the Galaxy", Pan Books ISBN 3320258648, 1979.
[HHGTTG]亚当斯，D.，《银河系搭便车指南》，潘书ISBN 33202586481979。
[IEEE1003.1] IEEE and The Open Group, "Portable Operating System Interface (POSIX)", The Open Group Base Specifications Issue 7, IEEE 1003.1, 2013 Edition, <http://pubs.opengroup.org/onlinepubs/9699919799/>.
[IEEE1003.1]IEEE和开放组，“便携式操作系统接口（POSIX）”，开放组基本规范第7期，IEEE 1003.12013版<http://pubs.opengroup.org/onlinepubs/9699919799/>.
[IPsec-CoAP] Bormann, C., "Using CoAP with IPsec", Work in Progress, December 2012.
[IPsec-CoAP]Bormann，C.，“将CoAP与IPsec结合使用”，正在进行的工作，2012年12月。
[MAPPING] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and E. Dijk, "Guidelines for HTTP-CoAP Mapping Implementations", Work in Progress, February 2014.
[MAPPING]Castellani，A.，Loreto，S.，Rahman，A.，Fossati，T.，和E.Dijk，“HTTP CoAP映射实施指南”，进展中的工作，2014年2月。
[OBSERVE] Hartke, K., "Observing Resources in CoAP", Work in Progress, April 2014.
[观察]Hartke，K.，“CoAP中的观察资源”，正在进行的工作，2014年4月。
[REC-exi-20140211] Schneider, J., Kamiya, T., Peintner, D., and R. Kyusakov, "Efficient XML Interchange (EXI) Format 1.0 (Second Edition)", W3C Recommendation REC-exi-20140211, February 2014, <http://www.w3.org/TR/2014/REC-exi-20140211/>.
[REC-exi-20140211]Schneider，J.，Kamiya，T.，Peintner，D.，和R.Kyusakov，“高效XML交换（exi）格式1.0（第二版）”，W3C建议REC-exi-20140211，2014年2月<http://www.w3.org/TR/2014/REC-exi-20140211/>.
[REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", Ph.D. Dissertation, University of California, Irvine, 2000, <http://www.ics.uci.edu/~fielding/pubs/dissertation/ fielding_dissertation.pdf>.
[REST]Fielding，R.，“架构风格和基于网络的软件架构的设计”，博士。学位论文，加利福尼亚大学，尔湾，2000，<http://www.ics.uci.edu/~fielding/pubs/demission/fielding\u demission.pdf>。
[RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20, October 1969.
[RFC0020]Cerf，V.，“网络交换的ASCII格式”，RFC 20，1969年10月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280]Housley，R.，Polk，W.，Ford，W.，和D.Solo，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）概要”，RFC 32802002年4月。
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003.
[RFC3542]Stevens，W.，Thomas，M.，Nordmark，E.，和T.Jinmei，“IPv6的高级套接字应用程序接口（API）”，RFC 3542，2003年5月。
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
[RFC3828]Larzon，L-A.，Degermark，M.，Pink，S.，Jonsson，L-E.，和G.Fairhurst，“轻量级用户数据报协议（UDP Lite）”，RFC 38282004年7月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]Conta，A.，Deering，S.和M.Gupta，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月。
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, May 2006.
[RFC4492]Blake Wilson，S.，Bolyard，N.，Gupta，V.，Hawk，C.，和B.Moeller，“用于传输层安全（TLS）的椭圆曲线密码（ECC）密码套件”，RFC 4492，2006年5月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 48212007年3月。
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007.
[RFC4944]黑山，G.，Kushalnagar，N.，Hui，J.，和D.Culler，“通过IEEE 802.15.4网络传输IPv6数据包”，RFC 49442007年9月。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC5405]Eggert，L.和G.Fairhurst，“应用程序设计者的单播UDP使用指南”，BCP 145，RFC 5405，2008年11月。
[RFC5489] Badra, M. and I. Hajjeh, "ECDHE_PSK Cipher Suites for Transport Layer Security (TLS)", RFC 5489, March 2009.
[RFC5489]Badra，M.和I.Hajjeh，“用于传输层安全（TLS）的ECDHE_PSK密码套件”，RFC 5489，2009年3月。
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011.
[RFC6090]McGrew，D.，Igoe，K.，和M.Salter，“基本椭圆曲线密码算法”，RFC 60902011年2月。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6120]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：核心”，RFC61202011年3月。
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, September 2011.
[RFC6282]Hui，J.和P.Thubert，“基于IEEE 802.15.4的网络上IPv6数据报的压缩格式”，RFC 6282，2011年9月。
[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, August 2011.
[RFC6335]Cotton，M.，Eggert，L.，Touch，J.，Westerlund，M.，和S.Cheshire，“互联网分配号码管理局（IANA）服务名称和传输协议端口号注册管理程序”，BCP 165，RFC 63352011年8月。
[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for Transport Layer Security (TLS)", RFC 6655, July 2012.
[RFC6655]McGrew，D.和D.Bailey，“用于传输层安全（TLS）的AES-CCM密码套件”，RFC 66552012年7月。
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, April 2013.
[RFC6936]Fairhurst，G.和M.Westerlund，“使用具有零校验和的IPv6 UDP数据报的适用性声明”，RFC 69362013年4月。
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, June 2013.
[RFC6960]Santesson，S.，Myers，M.，Ankney，R.，Malpani，A.，Galperin，S.，和C.Adams，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC 69602013年6月。
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension", RFC 6961, June 2013.
[RFC6961]Pettersen，Y.，“传输层安全（TLS）多证书状态请求扩展”，RFC 69612013年6月。
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014.
[RFC7159]Bray，T.，“JavaScript对象表示法（JSON）数据交换格式”，RFC 7159，2014年3月。
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, May 2014.
[RFC7228]Bormann，C.，Ersue，M.和A.Keranen，“受限节点网络的术语”，RFC 7228，2014年5月。
[RTO-CONSIDER] Allman, M., "Retransmission Timeout Considerations", Work in Progress, May 2012.
[RTO-THINE]Allman，M.，“重传超时考虑”，正在进行的工作，2012年5月。
[W3CXMLSEC] Wenning, R., "Report of the XML Security PAG", W3C XML Security PAG, October 2012, <http://www.w3.org/2011/xmlsec-pag/pagreport.html>.
[W3CXMLSEC]Wenning，R.，“XML安全PAG报告”，W3C XML安全PAG，2012年10月<http://www.w3.org/2011/xmlsec-pag/pagreport.html>.
This section gives a number of short examples with message flows for GET requests. These examples demonstrate the basic operation, the operation in the presence of retransmissions, and multicast.
本节给出了一些简短的示例，其中包含GET请求的消息流。这些示例演示了基本操作、存在重传时的操作和多播。
Figure 16 shows a basic GET request causing a piggybacked response: The client sends a Confirmable GET request for the resource coap://server/temperature to the server with a Message ID of 0x7d34. The request includes one Uri-Path Option (Delta 0 + 11 = 11, Length 11, Value "temperature"); the Token is left empty. This request is a total of 16 bytes long. A 2.05 (Content) response is returned in the Acknowledgement message that acknowledges the Confirmable request, echoing both the Message ID 0x7d34 and the empty Token value. The response includes a Payload of "22.3 C" and is 11 bytes long.
图16显示了一个基本的GET请求，该请求导致了一个搭载响应：客户端为资源发送一个可确认的GET请求coap://server/temperature 发送到消息ID为0x7d34的服务器。请求包括一个Uri路径选项（增量0+11=11，长度11，值“temperature”）；令牌为空。此请求的总长度为16字节。在确认可确认请求的确认消息中返回2.05（内容）响应，响应消息ID 0x7d34和空令牌值。响应包括“22.3 C”的有效负载，长度为11字节。
Client Server
| |
| |
+----->| Header: GET (T=CON, Code=0.01, MID=0x7d34)
| GET | Uri-Path: "temperature"
| |
| |
|<-----+ Header: 2.05 Content (T=ACK, Code=2.05, MID=0x7d34)
| 2.05 | Payload: "22.3 C"
| |
Client Server
| |
| |
+----->| Header: GET (T=CON, Code=0.01, MID=0x7d34)
| GET | Uri-Path: "temperature"
| |
| |
|<-----+ Header: 2.05 Content (T=ACK, Code=2.05, MID=0x7d34)
| 2.05 | Payload: "22.3 C"
| |
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 0 | GET=1 | MID=0x7d34 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 11 | 11 | "temperature" (11 B) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 0 | GET=1 | MID=0x7d34 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 11 | 11 | "temperature" (11 B) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 | 0 | 2.05=69 | MID=0x7d34 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| "22.3 C" (6 B) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 | 0 | 2.05=69 | MID=0x7d34 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| "22.3 C" (6 B) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Confirmable Request; Piggybacked Response
图16：可确认的请求；背负式响应
Figure 17 shows a similar example, but with the inclusion of an non-empty Token (Value 0x20) in the request and the response, increasing the sizes to 17 and 12 bytes, respectively.
图17显示了一个类似的示例，但在请求和响应中包含了一个非空令牌（值0x20），分别将大小增加到17和12字节。
Client Server
| |
| |
+----->| Header: GET (T=CON, Code=0.01, MID=0x7d35)
| GET | Token: 0x20
| | Uri-Path: "temperature"
| |
| |
|<-----+ Header: 2.05 Content (T=ACK, Code=2.05, MID=0x7d35)
| 2.05 | Token: 0x20
| | Payload: "22.3 C"
| |
Client Server
| |
| |
+----->| Header: GET (T=CON, Code=0.01, MID=0x7d35)
| GET | Token: 0x20
| | Uri-Path: "temperature"
| |
| |
|<-----+ Header: 2.05 Content (T=ACK, Code=2.05, MID=0x7d35)
| 2.05 | Token: 0x20
| | Payload: "22.3 C"
| |
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 1 | GET=1 | MID=0x7d35 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 11 | 11 | "temperature" (11 B) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 1 | GET=1 | MID=0x7d35 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 11 | 11 | "temperature" (11 B) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 | 1 | 2.05=69 | MID=0x7d35 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| "22.3 C" (6 B) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 | 1 | 2.05=69 | MID=0x7d35 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| "22.3 C" (6 B) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Confirmable Request; Piggybacked Response
图17：可确认的请求；背负式响应
In Figure 18, the Confirmable GET request is lost. After ACK_TIMEOUT seconds, the client retransmits the request, resulting in a piggybacked response as in the previous example.
在图18中，可确认的GET请求丢失。在ACK_超时秒之后，客户机重新传输请求，产生如前一示例中所示的附带响应。
Client Server
| |
| |
+----X | Header: GET (T=CON, Code=0.01, MID=0x7d36)
| GET | Token: 0x31
| | Uri-Path: "temperature"
TIMEOUT |
| |
+----->| Header: GET (T=CON, Code=0.01, MID=0x7d36)
| GET | Token: 0x31
| | Uri-Path: "temperature"
| |
| |
|<-----+ Header: 2.05 Content (T=ACK, Code=2.05, MID=0x7d36)
| 2.05 | Token: 0x31
| | Payload: "22.3 C"
| |
Client Server
| |
| |
+----X | Header: GET (T=CON, Code=0.01, MID=0x7d36)
| GET | Token: 0x31
| | Uri-Path: "temperature"
TIMEOUT |
| |
+----->| Header: GET (T=CON, Code=0.01, MID=0x7d36)
| GET | Token: 0x31
| | Uri-Path: "temperature"
| |
| |
|<-----+ Header: 2.05 Content (T=ACK, Code=2.05, MID=0x7d36)
| 2.05 | Token: 0x31
| | Payload: "22.3 C"
| |
Figure 18: Confirmable Request (Retransmitted); Piggybacked Response
图18：可确认请求（重新传输）；背负式响应
In Figure 19, the first Acknowledgement message from the server to the client is lost. After ACK_TIMEOUT seconds, the client retransmits the request.
在图19中，从服务器到客户端的第一条确认消息丢失。确认超时秒后，客户端重新传输请求。
Client Server
| |
| |
+----->| Header: GET (T=CON, Code=0.01, MID=0x7d37)
| GET | Token: 0x42
| | Uri-Path: "temperature"
| |
| |
| X----+ Header: 2.05 Content (T=ACK, Code=2.05, MID=0x7d37)
| 2.05 | Token: 0x42
| | Payload: "22.3 C"
TIMEOUT |
| |
+----->| Header: GET (T=CON, Code=0.01, MID=0x7d37)
| GET | Token: 0x42
| | Uri-Path: "temperature"
| |
| |
|<-----+ Header: 2.05 Content (T=ACK, Code=2.05, MID=0x7d37)
| 2.05 | Token: 0x42
| | Payload: "22.3 C"
| |
Client Server
| |
| |
+----->| Header: GET (T=CON, Code=0.01, MID=0x7d37)
| GET | Token: 0x42
| | Uri-Path: "temperature"
| |
| |
| X----+ Header: 2.05 Content (T=ACK, Code=2.05, MID=0x7d37)
| 2.05 | Token: 0x42
| | Payload: "22.3 C"
TIMEOUT |
| |
+----->| Header: GET (T=CON, Code=0.01, MID=0x7d37)
| GET | Token: 0x42
| | Uri-Path: "temperature"
| |
| |
|<-----+ Header: 2.05 Content (T=ACK, Code=2.05, MID=0x7d37)
| 2.05 | Token: 0x42
| | Payload: "22.3 C"
| |
Figure 19: Confirmable Request; Piggybacked Response (Retransmitted)
图19：可确认的请求；背载响应（重传）
In Figure 20, the server acknowledges the Confirmable request and sends a 2.05 (Content) response separately in a Confirmable message. Note that the Acknowledgement message and the Confirmable response do not necessarily arrive in the same order as they were sent. The client acknowledges the Confirmable response.
在图20中，服务器确认可确认请求，并在可确认消息中分别发送2.05（内容）响应。请注意，确认消息和可确认响应的到达顺序不一定与发送顺序相同。客户确认可确认的响应。
Client Server
| |
| |
+----->| Header: GET (T=CON, Code=0.01, MID=0x7d38)
| GET | Token: 0x53
| | Uri-Path: "temperature"
| |
| |
|<- - -+ Header: (T=ACK, Code=0.00, MID=0x7d38)
| |
| |
|<-----+ Header: 2.05 Content (T=CON, Code=2.05, MID=0xad7b)
| 2.05 | Token: 0x53
| | Payload: "22.3 C"
| |
| |
+- - ->| Header: (T=ACK, Code=0.00, MID=0xad7b)
| |
Client Server
| |
| |
+----->| Header: GET (T=CON, Code=0.01, MID=0x7d38)
| GET | Token: 0x53
| | Uri-Path: "temperature"
| |
| |
|<- - -+ Header: (T=ACK, Code=0.00, MID=0x7d38)
| |
| |
|<-----+ Header: 2.05 Content (T=CON, Code=2.05, MID=0xad7b)
| 2.05 | Token: 0x53
| | Payload: "22.3 C"
| |
| |
+- - ->| Header: (T=ACK, Code=0.00, MID=0xad7b)
| |
Figure 20: Confirmable Request; Separate Response
图20：可确认的请求；单独答复
Figure 21 shows an example where the client loses its state (e.g., crashes and is rebooted) right after sending a Confirmable request, so the separate response arriving some time later comes unexpected. In this case, the client rejects the Confirmable response with a Reset message. Note that the unexpected ACK is silently ignored.
图21显示了一个示例，其中客户端在发送可确认请求后立即失去状态（例如崩溃和重新启动），因此稍后到达的单独响应是意外的。在这种情况下，客户机使用重置消息拒绝可确认响应。请注意，意外的ACK将被静默忽略。
Client Server
| |
| |
+----->| Header: GET (T=CON, Code=0.01, MID=0x7d39)
| GET | Token: 0x64
| | Uri-Path: "temperature"
CRASH |
| |
|<- - -+ Header: (T=ACK, Code=0.00, MID=0x7d39)
| |
| |
|<-----+ Header: 2.05 Content (T=CON, Code=2.05, MID=0xad7c)
| 2.05 | Token: 0x64
| | Payload: "22.3 C"
| |
| |
+- - ->| Header: (T=RST, Code=0.00, MID=0xad7c)
| |
Client Server
| |
| |
+----->| Header: GET (T=CON, Code=0.01, MID=0x7d39)
| GET | Token: 0x64
| | Uri-Path: "temperature"
CRASH |
| |
|<- - -+ Header: (T=ACK, Code=0.00, MID=0x7d39)
| |
| |
|<-----+ Header: 2.05 Content (T=CON, Code=2.05, MID=0xad7c)
| 2.05 | Token: 0x64
| | Payload: "22.3 C"
| |
| |
+- - ->| Header: (T=RST, Code=0.00, MID=0xad7c)
| |
Figure 21: Confirmable Request; Separate Response (Unexpected)
图21：可确认的请求；单独响应（意外）
Figure 22 shows a basic GET request where the request and the response are Non-confirmable, so both may be lost without notice.
图22显示了一个基本的GET请求，其中请求和响应是不可确认的，因此可能会在不通知的情况下丢失。
Client Server
| |
| |
+----->| Header: GET (T=NON, Code=0.01, MID=0x7d40)
| GET | Token: 0x75
| | Uri-Path: "temperature"
| |
| |
|<-----+ Header: 2.05 Content (T=NON, Code=2.05, MID=0xad7d)
| 2.05 | Token: 0x75
| | Payload: "22.3 C"
| |
Client Server
| |
| |
+----->| Header: GET (T=NON, Code=0.01, MID=0x7d40)
| GET | Token: 0x75
| | Uri-Path: "temperature"
| |
| |
|<-----+ Header: 2.05 Content (T=NON, Code=2.05, MID=0xad7d)
| 2.05 | Token: 0x75
| | Payload: "22.3 C"
| |
Figure 22: Non-confirmable Request; Non-confirmable Response
图22：不可确认的请求；不可确认响应
In Figure 23, the client sends a Non-confirmable GET request to a multicast address: all nodes in link-local scope. There are 3 servers on the link: A, B and C. Servers A and B have a matching resource, therefore they send back a Non-confirmable 2.05 (Content) response. The response sent by B is lost. C does not have matching response, therefore it sends a Non-confirmable 4.04 (Not Found) response.
在图23中，客户端向一个多播地址发送一个不可确认的GET请求：链路本地范围内的所有节点。链接上有3台服务器：A、B和C。服务器A和B有一个匹配的资源，因此它们返回一个不可确认的2.05（内容）响应。B发送的响应丢失。C没有匹配的响应，因此它发送一个不可确认的4.04（未找到）响应。
Client ff02::1 A B C
| | | | |
| | | | |
+------>| | | | Header: GET (T=NON, Code=0.01, MID=0x7d41)
| GET | | | | Token: 0x86
| | | | Uri-Path: "temperature"
| | | |
| | | |
|<------------+ | | Header: 2.05 (T=NON, Code=2.05, MID=0x60b1)
| 2.05 | | | Token: 0x86
| | | | Payload: "22.3 C"
| | | |
| | | |
| X------------+ | Header: 2.05 (T=NON, Code=2.05, MID=0x01a0)
| 2.05 | | | Token: 0x86
| | | | Payload: "20.9 C"
| | | |
| | | |
|<------------------+ Header: 4.04 (T=NON, Code=4.04, MID=0x952a)
| 4.04 | | | Token: 0x86
| | | |
Client ff02::1 A B C
| | | | |
| | | | |
+------>| | | | Header: GET (T=NON, Code=0.01, MID=0x7d41)
| GET | | | | Token: 0x86
| | | | Uri-Path: "temperature"
| | | |
| | | |
|<------------+ | | Header: 2.05 (T=NON, Code=2.05, MID=0x60b1)
| 2.05 | | | Token: 0x86
| | | | Payload: "22.3 C"
| | | |
| | | |
| X------------+ | Header: 2.05 (T=NON, Code=2.05, MID=0x01a0)
| 2.05 | | | Token: 0x86
| | | | Payload: "20.9 C"
| | | |
| | | |
|<------------------+ Header: 4.04 (T=NON, Code=4.04, MID=0x952a)
| 4.04 | | | Token: 0x86
| | | |
Figure 23: Non-confirmable Request (Multicast); Non-confirmable Response
图23：不可确认请求（多播）；不可确认响应
The following examples demonstrate different sets of Uri options, and the result after constructing an URI from them. In addition to the options, Section 6.5 refers to the destination IP address and port, but not all paths of the algorithm cause the destination IP address and port to be included in the URI.
下面的示例演示了不同的Uri选项集，以及用它们构造Uri后的结果。除了选项之外，第6.5节还提到了目标IP地址和端口，但并非算法的所有路径都会导致目标IP地址和端口包含在URI中。
o Input:
o 输入：
Destination IP Address = [2001:db8::2:1]
Destination UDP Port = 5683
Destination IP Address = [2001:db8::2:1]
Destination UDP Port = 5683
Output:
输出：
coap://[2001:db8::2:1]/
coap://[2001:db8::2:1]/
o Input:
o 输入：
Destination IP Address = [2001:db8::2:1]
Destination UDP Port = 5683
Uri-Host = "example.net"
Destination IP Address = [2001:db8::2:1]
Destination UDP Port = 5683
Uri-Host = "example.net"
Output:
输出：
coap://example.net/
coap://example.net/
o Input:
o 输入：
Destination IP Address = [2001:db8::2:1]
Destination UDP Port = 5683
Uri-Host = "example.net"
Uri-Path = ".well-known"
Uri-Path = "core"
Destination IP Address = [2001:db8::2:1]
Destination UDP Port = 5683
Uri-Host = "example.net"
Uri-Path = ".well-known"
Uri-Path = "core"
Output:
输出：
coap://example.net/.well-known/core
coap://example.net/.well-known/core
o Input:
o 输入：
Destination IP Address = [2001:db8::2:1]
Destination UDP Port = 5683
Uri-Host = "xn--18j4d.example"
Uri-Path = the string composed of the Unicode characters U+3053
U+3093 U+306b U+3061 U+306f, usually represented in UTF-8 as
E38193E38293E381ABE381A1E381AF hexadecimal
Destination IP Address = [2001:db8::2:1]
Destination UDP Port = 5683
Uri-Host = "xn--18j4d.example"
Uri-Path = the string composed of the Unicode characters U+3053
U+3093 U+306b U+3061 U+306f, usually represented in UTF-8 as
E38193E38293E381ABE381A1E381AF hexadecimal
Output:
输出：
coap://xn--18j4d.example/
%E3%81%93%E3%82%93%E3%81%AB%E3%81%A1%E3%81%AF
coap://xn--18j4d.example/
%E3%81%93%E3%82%93%E3%81%AB%E3%81%A1%E3%81%AF
(The line break has been inserted for readability; it is not part of the URI.)
（为了可读性，插入了换行符；它不是URI的一部分。）
o Input:
o 输入：
Destination IP Address = 198.51.100.1
Destination UDP Port = 61616
Uri-Path = ""
Uri-Path = "/"
Uri-Path = ""
Uri-Path = ""
Uri-Query = "//"
Uri-Query = "?&"
Destination IP Address = 198.51.100.1
Destination UDP Port = 61616
Uri-Path = ""
Uri-Path = "/"
Uri-Path = ""
Uri-Path = ""
Uri-Query = "//"
Uri-Query = "?&"
Output:
输出：
coap://198.51.100.1:61616//%2F//?%2F%2F&?%26
coap://198.51.100.1:61616//%2F//?%2F%2F&?%26
Authors' Addresses
作者地址
Zach Shelby ARM 150 Rose Orchard San Jose, CA 95134 USA
美国加利福尼亚州圣何塞玫瑰园150号Zach Shelby ARM 95134
Phone: +1-408-203-9434
EMail: zach.shelby@arm.com
Phone: +1-408-203-9434
EMail: zach.shelby@arm.com
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
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