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)
|
|
|---|---|---|---|
| Last updated | 2016-08-29 | ||
| Stream | ISE | ||
| Formats | plain text pdf html bibtex | ||
| IETF conflict review | conflict-review-tcs-coap-no-response-option | ||
| Stream | ISE state | Published RFC | |
| Consensus Boilerplate | Unknown | ||
| Document shepherd | Nevil Brownlee | ||
| 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
Show full document text