CoAP option for no server-response
draft-tcs-coap-no-response-option-17

Document Type Active Internet-Draft (individual)
Last updated 2016-07-06 (latest revision 2016-05-12)
Stream ISE
Intended RFC status Informational
Formats plain text pdf html bibtex
IETF conflict review conflict-review-tcs-coap-no-response-option
Stream ISE state Sent to the RFC Editor
Consensus Boilerplate Unknown
Document shepherd Nevil Brownlee
Shepherd write-up Show (last changed 2016-06-07)
IESG IESG state I-D Exists
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
CoRE                                                   A. Bhattacharyya
Internet Draft                                         S. Bandyopadhyay
Intended status: Informational                                   A. Pal
Expires: November 2016                                          T. Bose
                                         Tata Consultancy Services Ltd.
                                                           May 12, 2016

                    CoAP option for no server-response
                   draft-tcs-coap-no-response-option-17

   Abstract

   There can be M2M scenarios where responses from a server against
   requests from client 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 a bulk of resources simultaneously, or updating a resource
   with a very high frequency. 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".

   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 class of response 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 No-
   Response option in the request. This option may be effective for
   both unicast and multicast requests. This document also discusses a
   few exemplary applications which benefit from this option.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

Bhattacharyya, et al. Expires November 12, 2016                [Page 1]
Internet-Draft   draft-tcs-coap-no-response-option-17          May 2016

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on November 12, 2016.

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. 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.

Table of Contents

   1. Introduction...................................................3
      1.1. Potential Benefits........................................3
      1.2. Terminology...............................................4
   2. Option Definition..............................................4
      2.1. Granular Control over Response Suppression................5
      2.2. Method-specific Applicability Consideration...............7
   3. Miscellaneous Aspects..........................................8
      3.1. Re-using 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 No-Response Option for a HTTP-to-CoAP Reverse Proxy
      ..............................................................11
   4. Exemplary Application Scenarios...............................11
      4.1. Frequent Update of Geo-location from Vehicles to Backend
      Server........................................................11

Bhattacharyya, et al. Expires November 12, 2016                [Page 2]
Show full document text