Constrained Application Protocol (CoAP) Option for No Server Response
RFC 7967
Document | Type |
RFC - Informational
(August 2016; No errata)
Was draft-tcs-coap-no-response-option (individual)
|
|
---|---|---|---|
Authors | Abhijan Bhattacharyya , Soma Bandyopadhyay , Arpan Pal , Tulika Bose | ||
Last updated | 2018-12-20 | ||
Stream | ISE | ||
Formats | plain text html pdf htmlized bibtex | ||
IETF conflict review | conflict-review-tcs-coap-no-response-option | ||
Stream | ISE state | Published RFC | |
Consensus Boilerplate | Unknown | ||
Document shepherd | Adrian Farrel | ||
Shepherd write-up | Show (last changed 2016-06-07) | ||
IESG | IESG state | RFC 7967 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | "Nevil Brownlee" <rfc-ise@rfc-editor.org> | ||
IANA | IANA review state | IANA OK - Actions Needed | |
IANA action state | RFC-Ed-Ack |
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 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. 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. Bhattacharyya, et al. Informational [Page 1] RFC 7967 CoAP No-Response Option August 2016 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. 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. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Bhattacharyya, et al. Informational [Page 2] RFC 7967 CoAP No-Response Option August 2016 Table of Contents 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 ................16Show full document text