Constrained Application Protocol (CoAP) Option for No Server Response
RFC 7967

Document Type RFC - Informational (August 2016; No errata)
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