Independent Submission A. Bhattacharyya
Request for Comments: 7967 S. Bandyopadhyay
Category: Informational A. Pal
ISSN: 2070-1721 T. Bose
Tata Consultancy Services Ltd.
August 2016
Independent Submission A. Bhattacharyya
Request for Comments: 7967 S. Bandyopadhyay
Category: Informational A. Pal
ISSN: 2070-1721 T. Bose
Tata Consultancy Services Ltd.
August 2016
Constrained Application Protocol (CoAP) Option for No Server Response
无服务器响应的受限应用程序协议（CoAP）选项
Abstract
摘要
There can be machine-to-machine (M2M) scenarios where server responses to client requests are redundant. This kind of open-loop exchange (with no response path from the server to the client) may be desired to minimize resource consumption in constrained systems while updating many resources simultaneously or performing high-frequency updates. CoAP already provides Non-confirmable (NON) messages that are not acknowledged by the recipient. However, the request/response semantics still require the server to respond with a status code indicating "the result of the attempt to understand and satisfy the request", per RFC 7252.
可能存在机器对机器（M2M）场景，其中服务器对客户端请求的响应是冗余的。这种开环交换（没有从服务器到客户机的响应路径）可能需要最小化受限系统中的资源消耗，同时更新多个资源或执行高频更新。CoAP已经提供了收件人未确认的不可确认（非）消息。然而，根据RFC 7252，请求/响应语义仍然要求服务器响应一个状态代码，指示“尝试理解和满足请求的结果”。
This specification introduces a CoAP option called 'No-Response'. Using this option, the client can explicitly express to the server its disinterest in all responses against the particular request. This option also provides granular control to enable expression of disinterest to a particular response class or a combination of response classes. The server MAY decide to suppress the response by not transmitting it back to the client according to the value of the No-Response option in the request. This option may be effective for both unicast and multicast requests. This document also discusses a few examples of applications that benefit from this option.
本规范引入了一个名为“无响应”的CoAP选项。使用此选项，客户机可以显式地向服务器表示它对针对特定请求的所有响应不感兴趣。此选项还提供粒度控制，以支持对特定响应类或响应类组合的不感兴趣的表达。服务器可以根据请求中No response选项的值，通过不将响应发送回客户端来决定抑制响应。此选项可能对单播和多播请求都有效。本文档还讨论了一些从该选项中获益的应用程序示例。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7967.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7967.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
Table of Contentstranslate error, please retry
1. Introduction ....................................................3
1.1. Potential Benefits .........................................4
1.2. Terminology ................................................4
2. Option Definition ...............................................5
2.1. Granular Control over Response Suppression .................5
2.2. Method-Specific Applicability Considerations ...............8
3. Miscellaneous Aspects ...........................................9
3.1. Reusing Tokens .............................................9
3.2. Taking Care of Congestion Control and Server-Side
Flow Control ..............................................10
3.3. Considerations regarding Caching of Responses .............11
3.4. Handling the No-Response Option for a HTTP-to-CoAP
Reverse Proxy .............................................11
4. Application Scenarios ..........................................12
4.1. Frequent Update of Geolocation from Vehicles to
Backend Server ............................................12
4.1.1. Using No-Response with PUT .........................13
4.1.2. Using No-Response with POST ........................14
4.1.2.1. POST Updating a Fixed Target Resource .....14
4.1.2.2. POST Updating through Query String ........15
4.2. Multicasting Actuation Command from a Handheld Device
to a Group of Appliances ..................................15
4.2.1. Using Granular Response Suppression ................16
5. IANA Considerations ............................................16
6. Security Considerations ........................................16
7. References .....................................................16
7.1. Normative References ......................................16
7.2. Informative References ....................................17
Acknowledgments ...................................................18
Authors' Addresses ................................................18
1. Introduction ....................................................3
1.1. Potential Benefits .........................................4
1.2. Terminology ................................................4
2. Option Definition ...............................................5
2.1. Granular Control over Response Suppression .................5
2.2. Method-Specific Applicability Considerations ...............8
3. Miscellaneous Aspects ...........................................9
3.1. Reusing Tokens .............................................9
3.2. Taking Care of Congestion Control and Server-Side
Flow Control ..............................................10
3.3. Considerations regarding Caching of Responses .............11
3.4. Handling the No-Response Option for a HTTP-to-CoAP
Reverse Proxy .............................................11
4. Application Scenarios ..........................................12
4.1. Frequent Update of Geolocation from Vehicles to
Backend Server ............................................12
4.1.1. Using No-Response with PUT .........................13
4.1.2. Using No-Response with POST ........................14
4.1.2.1. POST Updating a Fixed Target Resource .....14
4.1.2.2. POST Updating through Query String ........15
4.2. Multicasting Actuation Command from a Handheld Device
to a Group of Appliances ..................................15
4.2.1. Using Granular Response Suppression ................16
5. IANA Considerations ............................................16
6. Security Considerations ........................................16
7. References .....................................................16
7.1. Normative References ......................................16
7.2. Informative References ....................................17
Acknowledgments ...................................................18
Authors' Addresses ................................................18
This specification defines a new option for the Constrained Application Protocol (CoAP) [RFC7252] called 'No-Response'. This option enables clients to explicitly express their disinterest in receiving responses back from the server. The disinterest can be expressed at the granularity of response classes (e.g., 2.xx) or a combination of classes (e.g., 2.xx and 5.xx). By default, this option indicates interest in all response classes. The server MAY decide to suppress the response by not transmitting it back to the client according to the value of the No-Response option in the request.
本规范为受限应用协议（CoAP）[RFC7252]定义了一个称为“无响应”的新选项。此选项使客户端能够明确表示他们对从服务器接收响应的兴趣。不感兴趣可以用响应类的粒度（例如2.xx）或类的组合（例如2.xx和5.xx）表示。默认情况下，此选项表示对所有响应类感兴趣。服务器可以根据请求中No response选项的值，通过不将响应发送回客户端来决定抑制响应。
Along with the technical details, this document presents some practical application scenarios that highlight the usefulness of this option. [ITS-LIGHT] and [CoAP-ADAPT] contain the background research for this document.
除了技术细节之外，本文档还介绍了一些实际应用场景，强调了此选项的有用性。[ITS-LIGHT]和[CoAP ADAPT]包含本文件的背景研究。
In this document, when it is mentioned that a request from a client is with No-Response, the intended meaning is that the client expresses its disinterest for all or some selected classes of responses.
在本文档中，当提到来自客户机的请求没有响应时，其意图是客户机表示对所有或某些选定的响应类别不感兴趣。
The use of the No-Response option should be driven by typical application requirements and, particularly, characteristics of the information to be updated. If this option is opportunistically used in a fitting M2M application, then the concerned system may benefit in the following aspects. (However, note that this option is elective, and servers can simply ignore the preference expressed by the client.)
无响应选项的使用应根据典型的应用要求，尤其是待更新信息的特征来决定。如果在合适的M2M应用中有机会使用此选项，则相关系统可能在以下方面受益。（但是，请注意，此选项是可选的，服务器可以忽略客户端表示的首选项。）
* Reduction in network congestion due to effective reduction of the overall traffic.
* 由于有效减少了总流量，减少了网络拥塞。
* Reduction in server-side load by relieving the server from responding to requests for which responses are not necessary.
* 通过减轻服务器对不需要响应的请求的响应，减少服务器端负载。
* Reduction in battery consumption at the constrained endpoint(s).
* 减少受约束端点处的电池消耗。
* Reduction in overall communication cost.
* 降低总体通信成本。
The terms used in this document are in conformance with those defined in [RFC7252].
本文件中使用的术语与[RFC7252]中定义的术语一致。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The properties of the No-Response option are given in Table 1. In this table, the C, U, N, and R columns indicate the properties Critical, Unsafe, NoCacheKey, and Repeatable, respectively.
表1给出了无响应选项的属性。在此表中，C、U、N和R列分别表示临界、不安全、NoCacheKey和Repeatable属性。
+--------+---+---+---+---+-------------+--------+--------+---------+
| Number | C | U | N | R | Name | Format | Length | Default |
+--------+---+---+---+---+-------------+--------+--------+---------+
| 258 | | X | - | | No-Response | uint | 0-1 | 0 |
+--------+---+---+---+---+-------------+--------+--------+---------+
+--------+---+---+---+---+-------------+--------+--------+---------+
| Number | C | U | N | R | Name | Format | Length | Default |
+--------+---+---+---+---+-------------+--------+--------+---------+
| 258 | | X | - | | No-Response | uint | 0-1 | 0 |
+--------+---+---+---+---+-------------+--------+--------+---------+
Table 1: Option Properties
表1：期权属性
This option is a request option. It is elective and not repeatable. This option is Unsafe-to-Forward, as the intermediary MUST know how to interpret this option. Otherwise, the intermediary (without knowledge about the special unidirectional nature of the request) would wait for responses.
此选项是一个请求选项。它是选修的，不可重复。此选项转发不安全，因为中间人必须知道如何解释此选项。否则，中介（不知道请求的特殊单向性质）将等待响应。
Note: Since CoAP maintains a clear separation between the request/response and the message sub-layer, this option does not have any dependency on the type of message (Confirmable/Non-confirmable). So, even the absence of a message sub-layer (e.g., CoAP over TCP [CoAP-TCP-TLS]) should have no effect on the interpretation of this option. However, considering the CoAP-over-UDP scenario [RFC7252], NON messages are best suited to this option because of the expected benefits. Using No-Response with NON messages gets rid of any kind of reverse traffic, and the interaction becomes completely open loop.
注意：由于CoAP在请求/响应和消息子层之间保持清晰的分隔，因此此选项不依赖于消息的类型（可确认/不可确认）。因此，即使没有消息子层（例如，CoAP over TCP[CoAP TCP TLS]），也不会对该选项的解释产生影响。但是，考虑到UDP上的CoAP场景[RFC7252]，非消息最适合此选项，因为它具有预期的好处。对非消息使用无响应可以消除任何类型的反向通信，并且交互变成完全开放的循环。
Using this option with CON requests may not serve the desired purpose if piggybacked responses are triggered. But, if the server responds with a separate response (which, perhaps, the client does not care about), then this option can be useful. Suppressing the separate response reduces traffic by one additional CoAP message in this case.
如果触发了附带响应，则将此选项用于CON请求可能无法达到预期目的。但是，如果服务器用一个单独的响应进行响应（客户机可能不关心这个响应），那么这个选项可能很有用。在这种情况下，抑制单独的响应会通过一条额外的CoAP消息来减少通信量。
This option contains values to indicate disinterest in all or a particular class or combination of classes of responses as described in Section 2.1.
该选项包含表示对第2.1节所述的所有或特定类别或类别组合不感兴趣的值。
This option enables granular control over response suppression by allowing the client to express its disinterest in a typical class or combination of classes of responses. For example, a client may explicitly tell the receiver that no response is required unless
此选项允许客户端在典型的响应类或响应类组合中表达其不感兴趣，从而实现对响应抑制的粒度控制。例如，客户机可能会明确地告诉接收者不需要响应，除非
something 'bad' happens and a response of class 4.xx or 5.xx is to be fed back to the client. No response of the class 2.xx is required in such case.
发生了一些“坏”情况，需要将类4.xx或5.xx的响应反馈给客户端。在这种情况下，不需要2.xx级的响应。
Note: Section 2.7 of [RFC7390] describes a scheme where a server in the multicast group may decide on its own to suppress responses for group communication with granular control. The client does not have any knowledge about that. However, on the other hand, the No-Response option enables the client to explicitly inform the servers about its disinterest in responses. Such explicit control on the client side may be helpful for debugging network resources. An example scenario is described in Section 4.2.1.
注：[RFC7390]的第2.7节描述了一种方案，其中多播组中的服务器可自行决定抑制具有粒度控制的组通信响应。客户对此一无所知。但是，另一方面，No Response选项使客户机能够显式地通知服务器它对响应不感兴趣。客户端的这种显式控制可能有助于调试网络资源。第4.2.1节描述了一个示例场景。
The server MUST send back responses of the classes for which the client has not expressed any disinterest. There may be instances where a server, on its own, decides to suppress responses. An example is suppression of responses by multicast servers as described in Section 2.7 of [RFC7390]. If such a server receives a request with a No-Response option showing 'interest' in specific response classes (i.e., not expressing disinterest for these options), then any default behavior of suppressing responses, if present, MUST be overridden to deliver those responses that are of interest to the client.
服务器必须发回客户端未表示不感兴趣的类的响应。在某些情况下，服务器可能会自行决定抑制响应。例如，如[RFC7390]第2.7节所述，多播服务器抑制响应。如果这样的服务器接收到一个请求，其中的无响应选项显示出对特定响应类的“兴趣”（即，不表示对这些选项不感兴趣），则必须覆盖任何抑制响应的默认行为（如果存在），以交付客户机感兴趣的响应。
So, for example, suppose a multicast server suppresses all responses by default and receives a request with a No-Response option expressing disinterest in 2.xx (success) responses only. Note that the option value naturally expresses interest in error responses 4.xx and 5.xx in this case. Thus, the server must send back a response if the concerned request caused an error.
因此，例如，假设一个多播服务器在默认情况下抑制所有响应，并接收到一个请求，其中没有响应选项仅表示对2.xx（成功）响应不感兴趣。注意，在本例中，选项值自然表示对错误响应4.xx和5.xx感兴趣。因此，如果相关请求导致错误，服务器必须发回响应。
The option value is defined as a bit map (Table 2) to achieve granular suppression. Its length can be 0 bytes (empty) or 1 byte.
选项值定义为位图（表2），以实现粒度抑制。其长度可以是0字节（空）或1字节。
+-------+-----------------------+-----------------------------------+
| Value | Binary Representation | Description |
+-------+-----------------------+-----------------------------------+
| 0 | <empty> | Interested in all responses. |
+-------+-----------------------+-----------------------------------+
| 2 | 00000010 | Not interested in 2.xx responses. |
+-------+-----------------------+-----------------------------------+
| 8 | 00001000 | Not interested in 4.xx responses. |
+-------+-----------------------+-----------------------------------+
| 16 | 00010000 | Not interested in 5.xx responses. |
+-------+-----------------------+-----------------------------------+
+-------+-----------------------+-----------------------------------+
| Value | Binary Representation | Description |
+-------+-----------------------+-----------------------------------+
| 0 | <empty> | Interested in all responses. |
+-------+-----------------------+-----------------------------------+
| 2 | 00000010 | Not interested in 2.xx responses. |
+-------+-----------------------+-----------------------------------+
| 8 | 00001000 | Not interested in 4.xx responses. |
+-------+-----------------------+-----------------------------------+
| 16 | 00010000 | Not interested in 5.xx responses. |
+-------+-----------------------+-----------------------------------+
Table 2: Option Values
表2：选项值
The conventions used in deciding the option values are:
确定选项值时使用的约定为：
1. To suppress an individual class: Set bit number (n-1) starting from the least significant bit (bit number 0) to suppress all responses belonging to class n.xx. So,
1. 抑制单个类别：设置从最低有效位（位号0）开始的位号（n-1）以抑制属于类别n.xx的所有响应。所以
option value to suppress n.xx class = 2**(n-1)
option value to suppress n.xx class = 2**(n-1)
2. To suppress a combination of classes: Set each corresponding bit according to point 1 above. Example: The option value will be 18 (binary: 00010010) to suppress both 2.xx and 5.xx responses. This is essentially bitwise OR of the corresponding individual values for suppressing 2.xx and 5.xx. The "CoAP Response Codes" registry (see Section 12.1.2 of [RFC7252]) defines 2.xx, 4.xx, and 5.xx responses. So, an option value of 26 (binary: 00011010) will request to suppress all response codes defined in [RFC7252].
2. 要抑制类的组合：根据上面的第1点设置每个对应的位。示例：选项值将为18（二进制：00010010），以抑制2.xx和5.xx响应。这基本上是按位或对应的单个值，用于抑制2.xx和5.xx。“CoAP响应代码”注册表（见[RFC7252]第12.1.2节）定义了2.xx、4.xx和5.xx响应。因此，选项值26（二进制：0001010）将请求抑制[RFC7252]中定义的所有响应代码。
Note: When No-Response is used with value 26 in a request, the client endpoint SHOULD cease listening to response(s) to the particular request. On the other hand, showing interest in at least one class of response means that the client endpoint can no longer completely cease listening activity and must be configured to listen during some application specific time-out period for the particular request. The client endpoint never knows whether the present request will be a success or a failure. Thus, for example, if the client decides to open up the response for errors (4.xx and 5.xx), then it has to wait for the entire time-out period -- even for the instances where the request is successful (and the server is not supposed to send back a response). Note that in this context there may be situations when the response to errors might get lost. In such a situation, the client would wait during the time-out period but would not receive any response. However, this should not give the client the impression that the request was necessarily successful. In other words, in this case, the client cannot distinguish between response suppression and message loss. The application designer needs to tackle this situation. For example, while performing frequent updates, the client may strategically interweave requests without No-Response option into a series of requests with No-Response to check periodically that things are fine at the server end and the server is actively responding.
注意：当请求中没有使用值为26的响应时，客户端端点应该停止侦听特定请求的响应。另一方面，对至少一类响应表现出兴趣意味着客户端端点不能再完全停止侦听活动，并且必须配置为在特定于应用程序的特定超时期间侦听特定请求。客户端端点永远不知道当前请求是成功还是失败。因此，例如，如果客户机决定打开错误响应（4.xx和5.xx），那么它必须等待整个超时时间段——即使是请求成功的实例（并且服务器不应该发回响应）。请注意，在这种情况下，可能会出现错误响应丢失的情况。在这种情况下，客户端将在超时期间等待，但不会收到任何响应。但是，这不应给客户留下请求一定成功的印象。换句话说，在这种情况下，客户端无法区分响应抑制和消息丢失。应用程序设计者需要解决这种情况。例如，在执行频繁更新时，客户机可以策略性地将没有响应选项的请求交织成一系列没有响应的请求，以定期检查服务器端的情况是否良好，以及服务器是否正在积极响应。
The following table provides a ready reference on the possible applicability of this option with four REST methods. This table is for the type of possible interactions foreseen at the time of preparing this specification. The key words from RFC 2119 such as "SHOULD NOT", etc., deliberately have not been used in this table because it only contains suggestions.
下表提供了有关此选项可能适用于四种REST方法的现成参考。本表为编制本规范时预计的可能相互作用类型。RFC 2119中的关键词，如“不应”等，故意未在本表中使用，因为它仅包含建议。
+-------------+----------------------------------------------------+
| Method Name | Remarks on Applicability |
+-------------+----------------------------------------------------+
| | This should not be used with a conventional GET |
| | request when the client requests the contents |
| | of a resource. However, this option may be useful |
| | for exceptional cases where GET requests have side |
| GET | effects. For instance, the proactive cancellation |
| | procedure for observing a request [RFC7641] |
| | requires a client to issue a GET request with the |
| | Observe option set to 1 ('deregister'). If it is |
| | more efficient to use this deregistration instead |
| | of reactive cancellation (rejecting the next |
| | notification with RST), the client MAY express its |
| | disinterest in the response to such a GET request. |
+-------------+----------------------------------------------------+
| | Suitable for frequent updates (particularly in NON |
| | messages) on existing resources. Might not be |
| | useful when PUT is used to create a new resource, |
| | as it may be important for the client to know that |
| PUT | the resource creation was actually successful in |
| | order to carry out future actions. Also, it may be|
| | important to ensure that a resource was actually |
| | created rather than updating an existing resource. |
+-------------+----------------------------------------------------+
| | If POST is used to update a target resource, |
| | then No-Response can be used in the same manner as |
| | in PUT. This option may also be useful while |
| POST | updating through query strings rather than updating|
| | a fixed target resource (see Section 4.1.2.2 for an|
| | example). |
+-------------+----------------------------------------------------+
| | Deletion is usually a permanent action. If the |
| DELETE | client wants to ensure that the deletion request |
| | was properly executed, then this option should not |
| | be used with the request. |
+-------------+----------------------------------------------------+
+-------------+----------------------------------------------------+
| Method Name | Remarks on Applicability |
+-------------+----------------------------------------------------+
| | This should not be used with a conventional GET |
| | request when the client requests the contents |
| | of a resource. However, this option may be useful |
| | for exceptional cases where GET requests have side |
| GET | effects. For instance, the proactive cancellation |
| | procedure for observing a request [RFC7641] |
| | requires a client to issue a GET request with the |
| | Observe option set to 1 ('deregister'). If it is |
| | more efficient to use this deregistration instead |
| | of reactive cancellation (rejecting the next |
| | notification with RST), the client MAY express its |
| | disinterest in the response to such a GET request. |
+-------------+----------------------------------------------------+
| | Suitable for frequent updates (particularly in NON |
| | messages) on existing resources. Might not be |
| | useful when PUT is used to create a new resource, |
| | as it may be important for the client to know that |
| PUT | the resource creation was actually successful in |
| | order to carry out future actions. Also, it may be|
| | important to ensure that a resource was actually |
| | created rather than updating an existing resource. |
+-------------+----------------------------------------------------+
| | If POST is used to update a target resource, |
| | then No-Response can be used in the same manner as |
| | in PUT. This option may also be useful while |
| POST | updating through query strings rather than updating|
| | a fixed target resource (see Section 4.1.2.2 for an|
| | example). |
+-------------+----------------------------------------------------+
| | Deletion is usually a permanent action. If the |
| DELETE | client wants to ensure that the deletion request |
| | was properly executed, then this option should not |
| | be used with the request. |
+-------------+----------------------------------------------------+
Table 3: Suggested Applicability of No-Response with REST Methods
表3:REST方法无响应的建议适用性
This section further describes important implementation aspects worth considering while using the No-Response option. The following discussion contains guidelines and requirements (derived by combining [RFC7252], [RFC7390], and [RFC5405]) for the application developer.
本节进一步描述了在使用无响应选项时值得考虑的重要实现方面。以下讨论包含应用程序开发人员的指南和要求（通过结合[RFC7252]、[RFC7390]和[RFC5405]得出）。
Tokens provide a matching criteria between a request and the corresponding response. The life of a Token starts when it is assigned to a request and ends when the final matching response is received. Then, the Token can again be reused. However, a request with No-Response typically does not have any guaranteed response path. So, the client has to decide on its own about when it can retire a Token that has been used in an earlier request so that the Token can be reused in a future request. Since the No-Response option is 'elective', a server that has not implemented this option will respond back. This leads to the following two scenarios:
令牌提供请求和相应响应之间的匹配条件。令牌的生命周期从分配给请求时开始，到接收到最终匹配响应时结束。然后，令牌可以再次被重用。但是，没有响应的请求通常没有任何保证的响应路径。因此，客户机必须自行决定何时可以停用在早期请求中使用的令牌，以便在将来的请求中重用该令牌。由于无响应选项是“可选的”，因此未实现此选项的服务器将进行响应。这将导致以下两种情况：
The first scenario is when the client is never going to care about any response coming back or about relating the response to the original request. In that case, it MAY reuse the Token value at liberty.
第一种情况是，客户机永远不会关心返回的任何响应，也不会关心将响应与原始请求关联。在这种情况下，它可以随意重用令牌值。
However, as a second scenario, let us consider that the client sends two requests where the first request is with No-Response and the second request (with the same Token) is without No-Response. In this case, a delayed response to the first one can be interpreted as a response to the second request (client needs a response in the second case) if the time interval between using the same Token is not long enough. This creates a problem in the request-response semantics.
然而，作为第二种情况，让我们考虑客户端发送两个请求，其中第一个请求没有响应，第二个请求（同一个令牌）是没有响应的。在这种情况下，如果使用相同令牌之间的时间间隔不够长，则对第一个令牌的延迟响应可以解释为对第二个请求的响应（在第二种情况下，客户端需要响应）。这会在请求-响应语义中产生问题。
The most ideal solution would be to always use a unique Token for requests with No-Response. But if a client wants to reuse a Token, then in most practical cases the client implementation SHOULD implement an application-specific reuse time after which it can reuse the Token. A minimum reuse time for Tokens with a similar expression as in Section 2.5 of [RFC7390] SHOULD be used:
最理想的解决方案是始终对没有响应的请求使用唯一的令牌。但是，如果客户机希望重用令牌，那么在大多数实际情况下，客户机实现应该实现特定于应用程序的重用时间，在该时间之后，它可以重用令牌。应使用[RFC7390]第2.5节中类似表达式的令牌的最小重用时间：
TOKEN_REUSE_TIME = NON_LIFETIME + MAX_SERVER_RESPONSE_DELAY + MAX_LATENCY
令牌复用时间=非生命周期+最大服务器响应延迟+最大延迟
NON_LIFETIME and MAX_LATENCY are defined in Section 4.8.2 of [RFC7252]. MAX_SERVER_RESPONSE_DELAY has the same interpretation as in Section 2.5 of [RFC7390] for a multicast request. For a unicast request, since the message is sent to only one server, MAX_SERVER_RESPONSE_DELAY means the expected maximum response delay
[RFC7252]第4.8.2节定义了非_寿命和最大_延迟。最大服务器响应延迟与[RFC7390]第2.5节中对多播请求的解释相同。对于单播请求，由于消息仅发送到一台服务器，因此最大服务器响应延迟表示预期的最大响应延迟
from the particular server to that client that sent the request. For multicast requests, MAX_SERVER_RESPONSE_DELAY has the same interpretation as in Section 2.5 of [RFC7390]. So, for multicast it is the expected maximum server response delay "over all servers that the client can send a multicast request to", per [RFC7390]. This response delay for a given server includes its specific Leisure period; where Leisure is defined in Section 8.2 of [RFC7252]. In general, the Leisure for a server may not be known to the client. A lower bound for Leisure, lb_Leisure, is defined in [RFC7252], but not an upper bound as is needed in this case. Therefore, the upper bound can be estimated by taking N (N>>1) times the lower bound lb_Leisure:
从特定服务器发送到发送请求的客户端。对于多播请求，最大服务器响应延迟与[RFC7390]第2.5节中的解释相同。因此，对于多播，根据[RFC7390]，它是“客户端可以向其发送多播请求的所有服务器上”的预期最大服务器响应延迟。给定服务器的此响应延迟包括其特定空闲时间；[RFC7252]第8.2节定义了休闲。通常，客户端可能不知道服务器的空闲时间。[RFC7252]中定义了休闲的下限lb_Leisure，但不是本例中所需的上限。因此，可以通过取下限lb_的N（N>>1）倍来估计上限：
lb_Leisure = S * G / R
lb_Leisure = S * G / R
where S = estimated response size G = group size estimate R = data transfer rate
其中S=估计响应大小G=组大小估计R=数据传输速率
Any estimate of MAX_SERVER_RESPONSE_DELAY MUST be larger than DEFAULT_LEISURE, as defined in [RFC7252].
根据[RFC7252]中的定义，最大服务器响应延迟的任何估计值必须大于默认值。
Note: If it is not possible for the client to get a reasonable estimate of the MAX_SERVER_RESPONSE_DELAY, then the client, to be safe, SHOULD use a unique Token for each stream of messages.
注意：如果客户端无法合理估计最大服务器响应延迟，那么为了安全起见，客户端应该为每个消息流使用唯一的令牌。
This section provides guidelines for basic congestion control. Better congestion control mechanisms can be designed as future work.
本节提供基本拥塞控制指南。可以设计更好的拥塞控制机制作为未来的工作。
If this option is used with NON messages, then the interaction becomes completely open loop. The absence of any feedback from the server-end affects congestion-control mechanisms. In this case, the communication pattern maps to the scenario where the application cannot maintain an RTT estimate as described in Section 3.1.2 of [RFC5405]. Hence, per [RFC5405], a 3-second interval is suggested as the minimum interval between successive updates, and it is suggested to use an even less aggressive rate when possible. However, in case of a higher rate of updates, the application MUST have some knowledge about the channel, and an application developer MUST interweave occasional closed-loop exchanges (e.g., NON messages without No-Response, or CON messages) to get an RTT estimate between the endpoints.
如果此选项与非消息一起使用，则交互将变成完全开环。服务器端没有任何反馈会影响拥塞控制机制。在这种情况下，通信模式映射到应用程序无法维持[RFC5405]第3.1.2节所述RTT估计的场景。因此，根据[RFC5405]，建议将3秒的间隔作为连续更新之间的最小间隔，并且建议在可能的情况下使用更低的攻击性速率。但是，在更新率较高的情况下，应用程序必须对通道有一些了解，并且应用程序开发人员必须交织偶尔的闭环交换（例如，无响应的非消息或CON消息），以获得端点之间的RTT估计。
Interweaving requests without No-Response is a MUST in case of an aggressive request rate for applications where server-side flow control is necessary. For example, as proposed in [CoAP-PUBSUB], a
对于需要服务器端流量控制的应用程序，如果请求速率过高，则必须在没有响应的情况下交织请求。例如，正如[CoAP PUBSUB]中所建议的
broker MAY return 4.29 (Too Many Requests) in order to request a client to slow down the request rate. Interweaving requests without No-Response allows the client to listen to such a response.
代理可能返回4.29（太多请求），以请求客户端降低请求速率。无响应的交织请求允许客户机侦听此类响应。
The cacheability of CoAP responses does not depend on the request method, but it depends on the Response Code. The No-Response option does not lead to any impact on cacheability of responses. If a request containing No-Response triggers a cacheable response, then the response MUST be cached. However, the response MAY not be transmitted considering the value of the No-Response option in the request.
CoAP响应的可缓存性并不取决于请求方法，而是取决于响应代码。“无响应”选项不会对响应的可缓存性产生任何影响。如果不包含响应的请求触发可缓存响应，则必须缓存该响应。然而，考虑到请求中无响应选项的值，可能不会发送响应。
For example, if a request with No-Response triggers a cacheable response of 4.xx class with Max-Age not equal to 0, then the response must be cached. The cache will return the response to subsequent similar requests without No-Response as long as the Max-Age has not elapsed.
例如，如果没有响应的请求触发4.xx类的可缓存响应，且最大年龄不等于0，则必须缓存响应。缓存将返回对后续类似请求的响应，而无需响应，只要未超过最大期限。
A HTTP-to-CoAP reverse proxy MAY translate an incoming HTTP request to a corresponding CoAP request indicating that no response is required (showing disinterest in all classes of responses) based on some application-specific requirement. In this case, it is RECOMMENDED that the reverse proxy generate an HTTP response with status code 204 (No Content) when such response is allowed. The generated response is sent after the proxy has successfully sent out the CoAP request.
HTTP-to-CoAP反向代理可以将传入的HTTP请求转换为相应的CoAP请求，根据某些特定于应用程序的要求，该请求指示不需要响应（显示对所有响应类的不感兴趣）。在这种情况下，建议反向代理在允许HTTP响应时生成状态代码为204（无内容）的HTTP响应。生成的响应在代理成功发送CoAP请求后发送。
If the reverse proxy applies No-Response for one or more classes of responses, it will wait for responses up to an application-specific maximum time (T_max) before responding to the HTTP side. If a response of a desired class is received within T_max, then the response gets translated to HTTP as defined in [HTTP-to-CoAP]. However, if the proxy does not receive any response within T_max, it is RECOMMENDED that the reverse Proxy send an HTTP response with status code 204 (No Content) when allowed for the specific HTTP request method.
如果反向代理不对一个或多个响应类应用任何响应，则在响应HTTP端之前，它将等待响应，等待时间最长可达应用程序特定的最长时间（T_max）。如果在T_max内收到所需类的响应，则响应将被转换为[HTTP to CoAP]中定义的HTTP。但是，如果代理在T_max内没有收到任何响应，建议反向代理在特定HTTP请求方法允许时发送状态代码为204（无内容）的HTTP响应。
This section describes some examples of application scenarios that may potentially benefit from the use of the No-Response option.
本节介绍了一些应用程序场景的示例，这些应用程序场景可能会从使用无响应选项中受益。
Let us consider an intelligent traffic system (ITS) consisting of vehicles equipped with a sensor gateway comprising sensors like GPS and accelerometer sensors. The sensor gateway acts as a CoAP client. It connects to the Internet using a low-bandwidth cellular connection (e.g., General Packet Radio Service (GPRS)). The GPS coordinates of the vehicle are periodically updated to the backend server.
让我们考虑一种智能交通系统（ITS），它由装有传感器网关的车辆组成，传感器网关包括GPS和加速度传感器等传感器。传感器网关充当CoAP客户端。它使用低带宽蜂窝连接（例如，通用分组无线业务（GPRS））连接到互联网。车辆的GPS坐标会定期更新到后端服务器。
While performing frequent location updates, retransmitting (through the CoAP CON mechanism) a location coordinate that the vehicle has already left is not efficient as it adds redundant traffic to the network. Therefore, the updates are done using NON messages. However, given the huge number of vehicles updating frequently, the NON exchange will also trigger a huge number of responses from the backend. Thus, the cumulative load on the network will be quite significant. Also, the client in this case may not be interested in getting responses to location update requests for a location it has already passed and when the next location update is imminent.
在执行频繁的位置更新时，重新传输（通过CoAP CON机制）车辆已经离开的位置坐标是无效的，因为它会向网络添加冗余流量。因此，更新是使用非消息完成的。然而，鉴于频繁更新的车辆数量巨大，非交换也将引发后端的大量响应。因此，网络上的累积负载将相当大。此外，在这种情况下，客户机可能不想获得对其已经通过的位置的位置更新请求的响应，以及下一个位置更新即将到来的时间。
On the contrary, if the client endpoints on the vehicles explicitly declare that they do not need any status response back from the server, then load will be reduced significantly. The assumption is that the high rate of updates will compensate for the stray losses in geolocation reports.
相反，如果车辆上的客户端端点明确声明它们不需要从服务器返回任何状态响应，那么负载将显著降低。假设高更新率将补偿地理定位报告中的偶然损失。
Note: It may be argued that the above example application can also be implemented using the Observe option [RFC7641] with NON notifications. But, in practice, implementing with Observe would require lot of bookkeeping at the data collection endpoint at the backend (observer). The observer needs to maintain all the observe relationships with each vehicle. The data collection endpoint may be unable to know all its data sources beforehand. The client endpoints at vehicles may go offline or come back online randomly. In the case of Observe, the onus is always on the data collection endpoint to establish an observe relationship with each data source. On the other hand, implementation will be much simpler if initiating is left to the data source to carry out updates using the No-Response option. Another way of looking at it is that the implementation choice depends on where there is interest to initiate the update. In an Observe scenario, the interest is expressed by the data consumer. In contrast, the
注：可以认为，上述示例应用程序也可以使用带有非通知的观察选项[RFC7641]来实现。但是，在实践中，使用Observe实现需要在后端（Observe）的数据收集端点进行大量簿记。观察者需要保持与每辆车的所有观察关系。数据收集端点可能无法事先知道其所有数据源。车辆上的客户端端点可能脱机或随机恢复联机。在观察的情况下，ONU总是在数据收集端点上与每个数据源建立观察关系。另一方面，如果让数据源使用无响应选项执行更新，则实现将简单得多。从另一个角度来看，实现的选择取决于启动更新的兴趣所在。在观察场景中，兴趣由数据使用者表示。相比之下
classic update case applies when the interest is from the data producer. The No-Response option makes classic updates consume even less resources.
当兴趣来自数据生产者时，经典更新案例适用。无响应选项使经典更新消耗更少的资源。
The following subsections illustrate some sample exchanges based on the application described above.
以下小节说明了基于上述应用程序的一些示例交换。
Each vehicle is assigned a dedicated resource "vehicle-stat-<n>", where <n> can be any string uniquely identifying the vehicle. The update requests are sent using NON messages. The No-Response option causes the server not to respond back.
为每辆车分配一个专用资源“vehicle stat-<n>”，其中<n>可以是唯一标识车辆的任何字符串。更新请求使用非消息发送。No Response选项导致服务器不响应。
Client Server
| |
| |
+----->| Header: PUT (T=NON, Code=0.03, MID=0x7d38)
| PUT | Token: 0x53
| | Uri-Path: "vehicle-stat-00"
| | Content Type: text/plain
| | No-Response: 26
| | Payload:
| | "VehID=00&RouteID=DN47&Lat=22.5658745&Long=88.4107966667&
| | Time=2013-01-13T11:24:31"
| |
[No response from the server. Next update in 20 s.]
| |
+----->| Header: PUT (T=NON, Code=0.03, MID=0x7d39)
| PUT | Token: 0x54
| | Uri-Path: "vehicle-stat-00"
| | Content Type: text/plain
| | No-Response: 26
| | Payload:
| | "VehID=00&RouteID=DN47&Lat=22.5649015&Long=88.4103511667&
| | Time=2013-01-13T11:24:51"
Client Server
| |
| |
+----->| Header: PUT (T=NON, Code=0.03, MID=0x7d38)
| PUT | Token: 0x53
| | Uri-Path: "vehicle-stat-00"
| | Content Type: text/plain
| | No-Response: 26
| | Payload:
| | "VehID=00&RouteID=DN47&Lat=22.5658745&Long=88.4107966667&
| | Time=2013-01-13T11:24:31"
| |
[No response from the server. Next update in 20 s.]
| |
+----->| Header: PUT (T=NON, Code=0.03, MID=0x7d39)
| PUT | Token: 0x54
| | Uri-Path: "vehicle-stat-00"
| | Content Type: text/plain
| | No-Response: 26
| | Payload:
| | "VehID=00&RouteID=DN47&Lat=22.5649015&Long=88.4103511667&
| | Time=2013-01-13T11:24:51"
Figure 1: Example of Unreliable Update with No-Response Option Using PUT
图1：使用PUT的无响应选项的不可靠更新示例
In this case, POST acts the same way as PUT. The exchanges are the same as above. The updated values are carried as payload of POST as shown in Figure 2.
在这种情况下，POST的作用方式与PUT相同。交易所同上。更新后的值作为POST的有效载荷携带，如图2所示。
Client Server
| |
| |
+----->| Header: POST (T=NON, Code=0.02, MID=0x7d38)
| POST | Token: 0x53
| | Uri-Path: "vehicle-stat-00"
| | Content Type: text/plain
| | No-Response: 26
| | Payload:
| | "VehID=00&RouteID=DN47&Lat=22.5658745&Long=88.4107966667&
| | Time=2013-01-13T11:24:31"
| |
[No response from the server. Next update in 20 s.]
| |
+----->| Header: POST (T=NON, Code=0.02, MID=0x7d39)
| POST | Token: 0x54
| | Uri-Path: "vehicle-stat-00"
| | Content Type: text/plain
| | No-Response: 26
| | Payload:
| | "VehID=00&RouteID=DN47&Lat=22.5649015&Long=88.4103511667&
| | Time=2013-01-13T11:24:51"
Client Server
| |
| |
+----->| Header: POST (T=NON, Code=0.02, MID=0x7d38)
| POST | Token: 0x53
| | Uri-Path: "vehicle-stat-00"
| | Content Type: text/plain
| | No-Response: 26
| | Payload:
| | "VehID=00&RouteID=DN47&Lat=22.5658745&Long=88.4107966667&
| | Time=2013-01-13T11:24:31"
| |
[No response from the server. Next update in 20 s.]
| |
+----->| Header: POST (T=NON, Code=0.02, MID=0x7d39)
| POST | Token: 0x54
| | Uri-Path: "vehicle-stat-00"
| | Content Type: text/plain
| | No-Response: 26
| | Payload:
| | "VehID=00&RouteID=DN47&Lat=22.5649015&Long=88.4103511667&
| | Time=2013-01-13T11:24:51"
Figure 2: Example of Unreliable Update with No-Response Option Using POST as the Update Method
图2：使用POST作为更新方法的无响应选项的不可靠更新示例
It may be possible that the backend infrastructure deploys a dedicated database to store the location updates. In such a case, the client can update through a POST by sending a query string in the URI. The query string contains the name/value pairs for each update. No-Response can be used in the same manner as for updating fixed resources. The scenario is depicted in Figure 3.
后端基础设施可能会部署一个专用数据库来存储位置更新。在这种情况下，客户机可以通过POST在URI中发送查询字符串进行更新。查询字符串包含每个更新的名称/值对。不能以更新固定资源的相同方式使用响应。该场景如图3所示。
Client Server
| |
| |
+----->| Header: POST (T=NON, Code=0.02, MID=0x7d38)
| POST | Token: 0x53
| | Uri-Path: "updateOrInsertInfo"
| | Uri-Query: "VehID=00"
| | Uri-Query: "RouteID=DN47"
| | Uri-Query: "Lat=22.5658745"
| | Uri-Query: "Long=88.4107966667"
| | Uri-Query: "Time=2013-01-13T11:24:31"
| | No-Response: 26
| |
[No response from the server. Next update in 20 s.]
| |
+----->| Header: POST (T=NON, Code=0.02, MID=0x7d39)
| POST | Token: 0x54
| | Uri-Path: "updateOrInsertInfo"
| | Uri-Query: "VehID=00"
| | Uri-Query: "RouteID=DN47"
| | Uri-Query: "Lat=22.5649015"
| | Uri-Query: "Long=88.4103511667"
| | Uri-Query: "Time=2013-01-13T11:24:51"
| | No-Response: 26
| |
Client Server
| |
| |
+----->| Header: POST (T=NON, Code=0.02, MID=0x7d38)
| POST | Token: 0x53
| | Uri-Path: "updateOrInsertInfo"
| | Uri-Query: "VehID=00"
| | Uri-Query: "RouteID=DN47"
| | Uri-Query: "Lat=22.5658745"
| | Uri-Query: "Long=88.4107966667"
| | Uri-Query: "Time=2013-01-13T11:24:31"
| | No-Response: 26
| |
[No response from the server. Next update in 20 s.]
| |
+----->| Header: POST (T=NON, Code=0.02, MID=0x7d39)
| POST | Token: 0x54
| | Uri-Path: "updateOrInsertInfo"
| | Uri-Query: "VehID=00"
| | Uri-Query: "RouteID=DN47"
| | Uri-Query: "Lat=22.5649015"
| | Uri-Query: "Long=88.4103511667"
| | Uri-Query: "Time=2013-01-13T11:24:51"
| | No-Response: 26
| |
Figure 3: Example of Unreliable Update with No-Response Option Using POST with a Query String to Insert Update Information into the Backend Database
图3：使用带有查询字符串的POST将更新信息插入后端数据库的无响应不可靠更新的示例
4.2. Multicasting Actuation Command from a Handheld Device to a Group of Appliances
4.2. 从手持设备到一组设备的多播启动命令
A handheld device (e.g., a smart phone) may be programmed to act as an IP-enabled switch to remotely operate on one or more IP-enabled appliances. For example, a multicast request to switch on/off all the lights of a building can be sent. In this case, the IP switch
手持设备（例如，智能手机）可编程为充当IP启用的交换机，以远程操作一个或多个IP启用的设备。例如，可以发送打开/关闭建筑物所有灯光的多播请求。在这种情况下，IP交换机
application can use the No-Response option in a NON request message to reduce the traffic generated due to simultaneous CoAP responses from all the lights.
应用程序可以在非请求消息中使用无响应选项，以减少由于来自所有灯的同时CoAP响应而产生的流量。
Thus, No-Response helps in reducing overall communication cost and the probability of network congestion in this case.
因此，在这种情况下，无响应有助于降低总体通信成本和网络拥塞的概率。
The IP switch application may optionally use granular response suppression such that the error responses are not suppressed. In that case, the lights that could not execute the request would respond back and be readily identified. Thus, explicit suppression of option classes by the multicast client may be useful to debug the network and the application.
IP交换机应用可任选地使用粒度响应抑制，使得错误响应不被抑制。在这种情况下，无法执行请求的指示灯将做出响应，并很容易识别。因此，多播客户机对选项类的显式抑制可能有助于调试网络和应用程序。
The IANA had previously assigned number 284 to this option in the "CoAP Option Numbers" registry. IANA has updated this as shown below:
IANA之前在“CoAP选项编号”注册表中为该选项分配了编号284。IANA对此进行了更新，如下所示：
+--------+--------------+-------------+
| Number | Name | Reference |
+--------+--------------+-------------+
| 258 | No-Response | RFC 7967 |
+--------+--------------+-------------+
+--------+--------------+-------------+
| Number | Name | Reference |
+--------+--------------+-------------+
| 258 | No-Response | RFC 7967 |
+--------+--------------+-------------+
The No-Response option defined in this document presents no security considerations beyond those in Section 11 of the base CoAP specification [RFC7252].
除了基本CoAP规范[RFC7252]第11节中的安全考虑之外，本文件中定义的无响应选项没有其他安全考虑。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <http://www.rfc-editor.org/info/rfc7252>.
[RFC7252]Shelby，Z.，Hartke，K.，和C.Bormann，“受限应用协议（CoAP）”，RFC 7252，DOI 10.17487/RFC7252，2014年6月<http://www.rfc-editor.org/info/rfc7252>.
[CoAP-ADAPT] Bandyopadhyay, S., Bhattacharyya, A., and A. Pal, "Adapting protocol characteristics of CoAP using sensed indication for vehicular analytics", 11th ACM Conference on Embedded Networked Sensor Systems (SenSys '13), DOI 10.1145/2517351.2517422, November 2013.
[CoAP ADAPT]Bandyopadhyay，S.，Bhattacharyya，A.和A.Pal，“使用车辆分析的感应指示调整CoAP的协议特征”，第11届ACM嵌入式网络传感器系统会议（SenSys'13），DOI 10.1145/2517351.2517422，2013年11月。
[CoAP-PUBSUB] Koster, M., Keranen, A., and J. Jimenez, "Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)", Work in Progress, draft-koster-core-coap-pubsub-05, July 2016.
[CoAP PUBSUB]Koster，M.，Keranen，A.，和J.Jimenez，“约束应用程序协议（CoAP）的发布-订阅代理”，正在进行的工作，草稿-Koster-core-CoAP-PUBSUB-052016年7月。
[CoAP-TCP-TLS] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", Work in Progress, draft-ietf-core-coap-tcp-tls-04, August 2016.
[CoAP TCP TLS]Bormann，C.，Lemay，S.，Tschofenig，H.，Hartke，K.，Silverajan，B.，和B.Raymor，Ed.，“TCP，TLS和WebSocket上的CoAP（受限应用协议）”，正在进行的工作，草案-ietf-core-CoAP-TCP-TLS-042016年8月。
[HTTP-to-CoAP] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and E. Dijk, "Guidelines for HTTP-to-CoAP Mapping Implementations", Work in Progress, draft-ietf-core-http-mapping-13, July 2016.
[HTTP到CoAP]Castellani，A.，Loreto，S.，Rahman，A.，Fossati，T.，和E.Dijk，“HTTP到CoAP映射实施指南”，正在进行的工作，草稿-ietf-core-HTTP-Mapping-13，2016年7月。
[ITS-LIGHT] Bhattacharyya, A., Bandyopadhyay, S., and A. Pal, "ITS-light: Adaptive lightweight scheme to resource optimize intelligent transportation tracking system (ITS) - Customizing CoAP for opportunistic optimization", 10th International Conference on Mobile and Ubiquitous Systems: Computing, Networking and Services (MobiQuitous 2013), DOI 10.1007/978-3-319-11569-6_58, December 2013.
[ITS-LIGHT]Bhattacharyya，A.，Bandyopadhyay，S.，和A.Pal，“ITS-LIGHT：资源优化智能交通跟踪系统（ITS）的自适应轻量级方案-为机会主义优化定制CoAP”，第十届移动和普适系统国际会议：计算、网络和服务（MobiQuitous 2013），内政部10.1007/978-3-319-11569-658，2013年12月。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, DOI 10.17487/RFC5405, November 2008, <http://www.rfc-editor.org/info/rfc5405>.
[RFC5405]Eggert，L.和G.Fairhurst，“应用程序设计者的单播UDP使用指南”，BCP 145，RFC 5405，DOI 10.17487/RFC5405，2008年11月<http://www.rfc-editor.org/info/rfc5405>.
[RFC7390] Rahman, A., Ed., and E. Dijk, Ed., "Group Communication for the Constrained Application Protocol (CoAP)", RFC 7390, DOI 10.17487/RFC7390, October 2014, <http://www.rfc-editor.org/info/rfc7390>.
[RFC7390]Rahman，A.，Ed.，和E.Dijk，Ed.“受限应用协议（CoAP）的组通信”，RFC 7390，DOI 10.17487/RFC7390，2014年10月<http://www.rfc-editor.org/info/rfc7390>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, <http://www.rfc-editor.org/info/rfc7641>.
[RFC7641]Hartke，K.，“受限应用协议（CoAP）中的观测资源”，RFC 7641，DOI 10.17487/RFC7641，2015年9月<http://www.rfc-editor.org/info/rfc7641>.
Acknowledgments
致谢
Thanks to Carsten Bormann, Matthias Kovatsch, Esko Dijk, Bert Greevenbosch, Akbar Rahman, and Klaus Hartke for their valuable input.
感谢Carsten Bormann、Matthias Kovatsch、Esko Dijk、Bert Greevenbosch、Akbar Rahman和Klaus Hartke的宝贵意见。
Authors' Addresses
作者地址
Abhijan Bhattacharyya Tata Consultancy Services Ltd. Kolkata, India
印度加尔各答Abhijan Bhattacharyya Tata咨询服务有限公司
Email: abhijan.bhattacharyya@tcs.com
Email: abhijan.bhattacharyya@tcs.com
Soma Bandyopadhyay Tata Consultancy Services Ltd. Kolkata, India
印度加尔各答Soma Bandyopadhyay Tata咨询服务有限公司
Email: soma.bandyopadhyay@tcs.com
Email: soma.bandyopadhyay@tcs.com
Arpan Pal Tata Consultancy Services Ltd. Kolkata, India
印度加尔各答阿邦帕尔塔塔咨询服务有限公司
Email: arpan.pal@tcs.com
Email: arpan.pal@tcs.com
Tulika Bose Tata Consultancy Services Ltd. Kolkata, India
印度加尔各答Tulika Bose Tata咨询服务有限公司
Email: tulika.bose@tcs.com
Email: tulika.bose@tcs.com