CoRE
Independent Submission                                  A. Bhattacharyya
Internet Draft
Request for Comments: 7967                              S. Bandyopadhyay
Intended status:
Category: Informational                                           A. Pal
Expires: November 2016
ISSN: 2070-1721                                                  T. Bose
                                          Tata Consultancy Services Ltd.
                                                           May 12,
                                                             August 2016

                    CoAP option

 Constrained Application Protocol (CoAP) Option for no server-response
                   draft-tcs-coap-no-response-option-17 No Server Response

Abstract

   There can be M2M machine-to-machine (M2M) scenarios where responses from a server against
   requests from
   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 a bulk of many resources simultaneously, simultaneously or updating a resource
   with a very high frequency. 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".
   request", per RFC 7252.

   This specification introduces a CoAP option called 'No-Response'.
   Using this option 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 class or a combination of
   response-classes.
   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 the
   No-Response option in the request.  This option may be effective for
   both unicast and multicast requests.  This document also discusses a
   few exemplary examples of applications which that benefit from this option.

Status of this This Memo

   This Internet-Draft document is submitted in full conformance with not an Internet Standards Track specification; it is
   published for informational purposes.

   This is a contribution to the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents RFC Series, independently of the Internet Engineering
   Task Force (IETF), any other
   RFC stream.  The RFC Editor has chosen to publish this document at
   its areas, discretion and makes no statement about its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid value for a maximum of six
   months and may be updated, replaced,
   implementation or obsoleted deployment.  Documents approved for publication by other documents
   at
   the RFC Editor are not a candidate for any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list status of Internet-Draft Shadow Directories can this document, any errata,
   and how to provide feedback on it may be accessed obtained at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on November 12, 2016.
   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. 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 Introduction ....................................................3
      1.1. Potential Benefits........................................3 Benefits .........................................4
      1.2. Terminology...............................................4 Terminology ................................................4
   2. Option Definition..............................................4 Definition ...............................................5
      2.1. Granular Control over Response Suppression................5 Suppression .................5
      2.2. Method-specific Method-Specific Applicability Consideration...............7 Considerations ...............8
   3. Miscellaneous Aspects..........................................8 Aspects ...........................................9
      3.1. Re-using Tokens...........................................9 Reusing Tokens .............................................9
      3.2. Taking Care of Congestion Control and Server-side Server-Side
           Flow
      Control.......................................................10 Control ..............................................10
      3.3. Considerations Regarding regarding Caching of Responses............11 Responses .............11
      3.4. Handling the No-Response Option for a HTTP-to-CoAP
           Reverse Proxy
      ..............................................................11 .............................................11
   4. Exemplary Application Scenarios...............................11 Scenarios ..........................................12
      4.1. Frequent Update of Geo-location Geolocation from Vehicles to
           Backend
      Server........................................................11 Server ............................................12
           4.1.1. Using No-Response with PUT..........................13 PUT .........................13
           4.1.2. Using No-Response with POST.........................13 POST ........................14
                  4.1.2.1. POST updating Updating a fixed target resource..........13 Fixed Target Resource .....14
                  4.1.2.2. POST updating Updating through query-string.............14 Query String ........15
      4.2. Multicasting Actuation Command from a Handheld Device
           to a Group of Appliances...........................................15 Appliances ..................................15
           4.2.1. Using Granular Response Suppression.................16 Suppression ................16
   5. IANA Considerations...........................................16 Considerations ............................................16
   6. Security Considerations.......................................16 Considerations ........................................16
   7. Acknowledgments...............................................16
   8. References....................................................16
      8.1. References .....................................................16
      7.1. Normative References.....................................16
      8.2. References ......................................16
      7.2. Informative References...................................17 References ....................................17
   Acknowledgments ...................................................18
   Authors' Addresses ................................................18

1.  Introduction

   This specification defines a new option for the Constrained
   Application Protocol (CoAP) [RFC7252] called 'No-Response'.  This
   option enables clients to explicitly express their disinterests disinterest in
   receiving responses back from the server.  The disinterest can be
   expressed at the granularity of response classes (e.g., 2.xx 2.xx) or the a
   combination of classes (e.g., 2.xx and 5.xx).  By default 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.

   Along with the technical details details, this document presents some
   practical application scenarios which bring out that highlight the usefulness of this
   option.

   Wherever, in  [ITS-LIGHT] and [CoAP-ADAPT] contain the background research
   for this document.

   In this document, when it is mentioned that a request from a client
   is with No-Response No-Response, the intended meaning is that the client
   expresses its disinterest for all or some selected classes of
   responses.

1.1.  Potential Benefits

   Use

   The use of the No-Response option should be driven by typical
   application
   requirement requirements and, particularly, characteristics of the
   information to be updated.  If this option is opportunistically used
   in a fitting M2M application application, then the concerned system may benefit
   in the following aspects (however, it is to be noted, aspects.  (However, note that this option is
   elective
   elective, and servers can simply ignore the preference expressed by
   the client): client.)

      *  Reduction in network congestion due to effective reduction of
         the overall traffic.

      *  Reduction in server-side load by relieving the server from
         responding to each request when requests for which responses are not necessary.

      *  Reduction in battery consumption at the constrained end-
   point(s).
         endpoint(s).

      *  Reduction in overall communication cost.

1.2.  Terminology

   The terms used in this document are in conformance with those defined
   in [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 RFC-2119. [RFC2119].

2.  Option Definition

   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.

   +--------+---+---+---+---+-------------+--------+--------+---------+
   | Number | C | U | N | R |   Name      | Format | Length | Default |
   +--------+---+---+---+---+-------------+--------+--------+---------+
   |   258  |   | X | - |   | No-Response |  uint  |  0-1   |    0    |
   +--------+---+---+---+---+-------------+--------+--------+---------+

                       Table 1: Option Properties

   This option is a request option.  It is Elective elective and Non-Repeatable. not repeatable.
   This option is Unsafe-to-forward Unsafe-to-Forward, as the intermediary MUST know how
   to interpret this option. Otherwise  Otherwise, the intermediary, without intermediary (without
   knowledge about the special unidirectional nature of the request, 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).
      (Confirmable/Non-confirmable).  So, even the absence of a message
      sub-layer (ex.
      CoAP-over-TCP [I-D.ietf-core-coap-tcp-tls-01]) (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 type of messages are best fitting with suited
      to this option, considering option because of the expected benefits
      out of it. benefits.  Using
      No-Response with NON messages gets rid of any kind of reverse traffic
      traffic, and the interaction becomes completely
      open-loop. open loop.

      Using this option with CON type of requests may not serve the desired
      purpose if piggybacked responses are triggered.  But, in
      case if the
      server responds with a separate response (which, perhaps, the
      client does not care about) about), then this option can be useful.
      Suppressing the separate response reduces traffic by one
      additional CoAP message in this case.

   This option contains values to indicate disinterest in all or a
   particular class or combination of classes of responses as described
   in the next sub-section. Section 2.1.

2.1.  Granular Control over Response Suppression

   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.

   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' No-Response option enables the clients 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.

   The server MUST send back responses of the classes for which the
   client has not expressed any dis-interest. 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 behaviour behavior of suppressing response, responses, if present, MUST be
   overridden to deliver those responses which that are of interest to the
   client.

   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/5.xx 4.xx
   and 5.xx in this case. Then  Thus, the server must send back a response if
   the concerned request caused an error.

   The option value is defined as a bit-map bit map (Table 2) to achieve
   granular suppression.  Its length can be 0 byte (empty value) bytes (empty) or 1 byte.

   +-------+-----------------------+---------------------------------+

   +-------+-----------------------+-----------------------------------+
   | 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 Values
   The conventions used in deciding the option values are:

   1.  To suppress an individual class: Set bit number (n-1) starting
       from the LSB least significant bit (bit number 0) to suppress all
       responses belonging to class n.xx.  So,

               option value to suppress n.xx class = 2**(n-1). 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 (Ref. (see Section 12.1.2 of [RFC7252]) defines 2.xx, 4.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].

   Note: When No-Response is used with value 26 in a request request, the client
      end-point
      endpoint SHOULD cease listening to response(s) against to the particular
      request.  On the other hand, showing interest in at least one
      class of response means that the client end-point endpoint can no longer
      completely cease listening activity and must be configured to
      listen up to during some application specific time-out period for the
      particular request.  The client end-point 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) 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). A point to be noted  Note
      that in this context is that there may be situations when the response on to
      errors might get lost.  In such a situation situation, the client would wait up to
      during the time-out period but
      will would not receive any response. But
      However, this should not lead to the
      impression to give the client the impression that the
      request was necessarily successful.  In other words, in this case case,
      the client cannot distinguish between response suppression and
      message loss.  The application designer needs to tackle such 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 time to time if
      periodically that things are fine at the server end and the server
      is actively responding.

2.2. Method-specific  Method-Specific Applicability Consideration Considerations

   The following table provides a ready-reference ready reference on the possible
   applicability of this option for all the with four REST methods.  This table is prepared in view of
   for the type of possible interactions foreseen at the time of
   preparing this specification. Capitalization of  The key words like from RFC 2119 such as
   "SHOULD NOT", etc. etc., deliberately have not been deliberately used in this table as this table is
   because it only suggestive. contains suggestions.

   +-------------+----------------------------------------------------+
   | Method Name |              Remarks on applicability 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 has have side |
   |     GET     | effects.  For instance, the proactive 'cancellation'| cancellation |
   |             | procedure for observing a request [RFC7641] requires        |
   |             | requires a client to issue a GET request with Observe option| the  |
   |             | Observe option set to 1 ('deregister'). In case  If it is more  |
   |             | more efficient to use this deregistration instead of  |
   |             | 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| 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 | 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 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 and if action.  If the    |
   |    DELETE   | client likes wants to ensure that the deletion request   |
   |             | was properly executed executed, then this option should not |
   |             | be used with the request.                          |
   +-------------+----------------------------------------------------+

    Table 3: Suggested applicability Applicability of No-Response for different with REST
                                  methods Methods

3.  Miscellaneous Aspects

   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] [RFC7390], and [RFC5405]) for the application developer.

3.1. Re-using  Reusing Tokens

   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  Then, the Token can again be re-used. 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 which 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 which that has not implemented this option
   will respond back.  This leads to the following two scenarios:

   The first scenario is, 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 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 request (with the same Token, Token) is without No-Response.  In this
   case
   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 Token,
   then in most practical cases the client implementation SHOULD
   implement an application specific 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:

   TOKEN_REUSE_TIME = NON_LIFETIME + MAX_SERVER_RESPONSE_DELAY +
                      MAX_LATENCY.
                      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
   from the particular server to
   which 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". 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  Therefore, the upper bound
   can be estimated by taking N (N>>1) times the lower bound lb_Leisure:

                          lb_Leisure = S * G / R

   (S

   where
   S = estimated response size; R = data transfer rate; size
   G = group size
                                 estimate) estimate
   R = data transfer rate

   Any estimate of MAX_SERVER_RESPONSE_DELAY MUST be larger than
   DEFAULT_LEISURE
   DEFAULT_LEISURE, as defined in [RFC7252].

   Note: If it is not possible for the client to get a reasonable
      estimate of the MAX_SERVER_RESPONSE_DELAY MAX_SERVER_RESPONSE_DELAY, then the client, to be
      safe, SHOULD use a unique Token for each stream of message. messages.

3.2.  Taking Care of Congestion Control and Server-side Server-Side Flow Control

   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 messages, then the interaction
   becomes completely open-loop. Absence open loop.  The absence of any feedback from the
   server-end affects congestion-control mechanism. mechanisms.  In this case 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, following
   [RFC5405].  Hence, per [RFC5405], a 3 seconds 3-second interval is suggested as
   the minimum interval between successive updates updates, and it is suggested
   to use an even less aggressive rate when possible.  However, in case
   of more
   frequent update rates a higher rate of updates, the application MUST have some knowledge
   about the channel channel, and an application developer MUST interweave
   occasional closed-loop exchanges (e.g. (e.g., NON messages without No-Response
   No-Response, or CON messages) to get an RTT estimate between the
   endpoints.

   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 [I-D.koster-core-
   coap-pubsub], [CoAP-PUBSUB], a
   broker MAY return "4.29 Too 4.29 (Too Many Requests" 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.

3.3.  Considerations Regarding regarding Caching of Responses

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

   For example, if a request with No-Response triggers a cacheable
   response of 4.xx class with Max-Age !=0 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 is has not
   elapsed.

3.4.  Handling the No-Response Option for a HTTP-to-CoAP Reverse Proxy

   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 application-specific requirement.  In this case case, it is
   RECOMMENDED that the reverse proxy generates 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.

   In case

   If the reverse proxy applies No-Response for particular
   class(es) one or more classes of response(s)
   responses, it will wait for responses up to an
   application specific application-specific
   maximum time (T_max) before responding back to the HTTP-side. HTTP side.  If a
   response of a desired class is received within
   T_max T_max, then the
   response gets translated to HTTP as defined in [I-
   D.ietf-core-http-mapping]. However [HTTP-to-CoAP].
   However, if the proxy does not receive any response within T_max, it
   is RECOMMENDED that the reverse Proxy
   sends send an HTTP response with
   status code 204 (No Content) when allowed for the specific HTTP
   request method.

4. Exemplary  Application Scenarios

   This section describes some exemplary examples of application scenarios which that
   may potentially benefit from the use of the No-Response option.

4.1.  Frequent Update of Geo-location Geolocation from Vehicles to Backend Server

   Let us consider an intelligent traffic system (ITS) consisting of
   vehicles equipped with a sensor-gateway sensor gateway comprising sensors like GPS
   and Accelerometer. accelerometer sensors.  The sensor-gateway sensor gateway acts as a CoAP client.
   It connects to the Internet using a low-bandwidth cellular (e.g. GPRS)
   connection. connection
   (e.g., General Packet Radio Service (GPRS)).  The GPS co-ordinates coordinates of
   the vehicle are periodically updated to the backend server.

   While performing frequent location update, updates, retransmitting (through
   the CoAP CON mechanism) a location co-ordinate which coordinate that the vehicle has
   already left in the meantime 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  Thus, the cumulative load on the network will be quite
   significant.  Also, the client in this case may not be interested in
   getting responses against to location update request requests for
   the a location it has
   already crossed in the meantime passed and a when the next location update is imminent.

   On the contrary, if the client end-points endpoints on the vehicles explicitly
   declare that they do not need any status response back from the
   server
   server, then load will be reduced significantly.  The assumption is
   that, since
   that the update high rate is high, of updates will compensate for the stray losses in geo-location
   reports will be compensated with the large update rate.
   geolocation reports.

   Note: It may be argued that the above example application can also be
      implemented using the Observe option ([RFC7641]) [RFC7641] with NON
      notifications.  But, in practice, implementing with Observe would
      require lot of book-keeping bookkeeping at the data-collection end-point data collection endpoint at the
      backend (observer).  The observer needs to maintain all the
      observe relationships with each vehicle.  The data collection end-
      point
      endpoint may be unable to know all its data sources beforehand.
      The client end-points endpoints at vehicles may go offline or come back
      online randomly.  In the case of Observe Observe, the onus is always on
      the data collection end-point endpoint to establish an observe relationship
      with each data-source. data source.  On the other hand, implementation will be
      much simpler if the initiative initiating is left on to the data-source data source to carry out
      updates using the No-Response option.  Another way of looking at
      it
      is, is that the implementation choice depends on the perspective of where there is
      interest to initiate the update.  In an Observe scenario scenario, the
      interest is expressed by the data-consumer. On the contrary, data consumer.  In contrast, the
      classic update case applies when the interest is from the data- data
      producer.  The 'No-Response' No-Response option enables to make makes classic updates further consume
      even less resource consuming.

   Following resources.

   The following subsections illustrate some exemplary sample exchanges based on
   the application described above.

4.1.1.  Using No-Response with PUT

   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 over using NON type of messages.  The No-Response option
   causes the server not to respond back.

   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 20s.] 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: Exemplary unreliable update Example of Unreliable Update with No-Response option using
                                   PUT. Option
                                Using PUT

4.1.2.  Using No-Response with POST

4.1.2.1.  POST updating Updating a fixed target resource Fixed Target Resource

   In this case 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.

   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 20s.] 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: Exemplary unreliable update Example of Unreliable Update with No-Response option using Option
                   Using POST as the update-method. Update Method

4.1.2.2.  POST updating Updating through query-string Query String

   It may be possible that the backend infrastructure deploys a
   dedicated database to store the location updates.  In such a case case,
   the client can update through a POST by sending a query string in the
   URI.  The query-string query string contains the name/value pairs for each update.
   'No-Response'
   No-Response can be used in the same manner as for updating fixed
   resources.  The scenario is depicted in Figure 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 secs.] 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: Exemplary unreliable update Example of Unreliable Update with No-Response option using Option
    Using POST with a query-string to insert update information Query String to backend
                                 database. Insert Update Information
                     into the Backend Database

4.2.  Multicasting Actuation Command from a Handheld Device to a Group
      of Appliances

   A handheld device (e.g. (e.g., a smart phone) may be programmed to act as
   an IP enabled IP-enabled switch to remotely operate on a single one or group of IP
   enabled more IP-enabled
   appliances.  For example, a multicast request to switch on/
   off on/off all
   the lights of a building can be sent.  In this case case, the IP switch
   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.

   Thus

   Thus, No-Response helps in reducing overall communication cost and
   the probability of network congestion in this case.

4.2.1.  Using Granular Response Suppression

   The IP switch application may optionally use granular response
   suppression such that the error responses are not suppressed.  In
   that case case, the lights which 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.

5.  IANA Considerations

   The IANA has had previously assigned number 284 to this option in the
   CoAP
   "CoAP Option Numbers Registry. Numbers" registry.  IANA is requested to change has updated this as shown
   below:

          +--------+--------------+----------------------------+

            +--------+--------------+-------------+
            | Number |     Name     |  Reference  |
          +--------+--------------+----------------------------+
            +--------+--------------+-------------+
            |   258  | No-Response  | Section 2 of this document  RFC 7967   |
          +--------+--------------+----------------------------+
            +--------+--------------+-------------+

6.  Security Considerations

   The No-Response option defined in this document presents no security
   considerations beyond those in Section 11 of the base CoAP
   specification [RFC7252].

7. Acknowledgments

   Thanks to Carsten Bormann, Matthias Kovatsch, Esko Dijk, Bert
   Greevenbosch, Akbar Rahman and Klaus Hartke for their valuable
   inputs.

8.  References

8.1.

7.1.  Normative References

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

   [RFC7252]  Shelby, Z., Hartke, K. K., and C. Bormann, C.,"Constrained "The Constrained
              Application Protocol (CoAP)", RFC 7252, June, 2014

8.2.
              DOI 10.17487/RFC7252, June 2014,
              <http://www.rfc-editor.org/info/rfc7252>.

7.2.  Informative References

   [RFC7641]

   Hartke, K.," Observing Resources in the Constrained Application
   Protocol (CoAP)", RFC 7641, September, 2015

   [RFC7390]

   Rahman, A. and Dijk, E.,"Group Communication for CoAP", RFC 7390,
   October, 2014

   [RFC5405]

   Eggert, L. and Fairhurst, G.," Unicast UDP Usage Guidelines for
   Application Designers", RFC 5405, November, 2008

   [I-D.ietf-core-http-mapping]

   Castellani,

   [CoAP-ADAPT]
              Bandyopadhyay, S., Bhattacharyya, A., et al., "Guidelines and A. Pal,
              "Adapting protocol characteristics of CoAP using sensed
              indication for HTTP-CoAP Mapping
   Implementations", draft-ietf-core-http-mapping-09, April 6, 2016

   [I-D.koster-core-coap-pubsub] vehicular analytics", 11th ACM Conference
              on Embedded Networked Sensor Systems (SenSys '13),
              DOI 10.1145/2517351.2517422, November 2013.

   [CoAP-PUBSUB]
              Koster, M., et al., "Publish-Subscribe Keranen, A., and J. Jimenez, "Publish-
              Subscribe Broker for the Constrained Application Protocol
              (CoAP)", draft-koster-core-coap-pubsub-04,
   November 5, 2015

   [I-D.ietf-core-coap-tcp-tls-01] Work in Progress, draft-koster-core-coap-
              pubsub-05, July 2016.

   [CoAP-TCP-TLS]
              Bormann, C., et al., "A TCP 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.

   [HTTP-to-CoAP]
              Castellani, A., Loreto, S., Rahman, A., Fossati, T., and TLS Transport
              E. Dijk, "Guidelines for the Constrained
   Application Protocol (CoAP)", draft-ietf-core-coap-tcp-tls-01,
   November 19, 2015

   [Mobiquitous 2013] HTTP-to-CoAP Mapping
              Implementations", Work in Progress, draft-ietf-core-http-
              mapping-13, July 2016.

   [ITS-LIGHT]
              Bhattacharyya, A., Bandyopadhyay, S. S., and A. Pal, A.,
              "ITS-light: Adaptive lightweight scheme to resource
              optimize intelligent transportation tracking system (ITS)-Customizing (ITS)
              - Customizing CoAP for opportunistic optimization", 10th
              International Conference on Mobile and Ubiquitous Systems:
              Computing, Networking and Services
   (Mobiquitous (MobiQuitous 2013), December,
              DOI 10.1007/978-3-319-11569-6_58, December 2013.

   [Sensys 2013]

   Bandyopadhyay, S., Bhattacharyya, A.

   [RFC5405]  Eggert, L. and Pal, 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>.

   [RFC7390]  Rahman, A., "Adapting protocol
   characteristics of CoAP using sensed indication Ed., and E. Dijk, Ed., "Group Communication
              for vehicular
   analytics", 11th ACM Conference on Embedded Networked Sensor Systems
   (Sensys 2013), November, 2013. the Constrained Application Protocol (CoAP)", RFC
              7390, DOI 10.17487/RFC7390, October 2014,
              <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>.

Acknowledgments

   Thanks to Carsten Bormann, Matthias Kovatsch, Esko Dijk, Bert
   Greevenbosch, Akbar Rahman, and Klaus Hartke for their valuable
   input.

Authors' Addresses

   Abhijan Bhattacharyya
   Tata Consultancy Services Ltd.
   Kolkata, India

   Email: abhijan.bhattacharyya@tcs.com

   Soma Bandyopadhyay
   Tata Consultancy Services Ltd.
   Kolkata, India

   Email: soma.bandyopadhyay@tcs.com

   Arpan Pal
   Tata Consultancy Services Ltd.
   Kolkata, India

   Email: arpan.pal@tcs.com

   Tulika Bose
   Tata Consultancy Services Ltd.
   Kolkata, India

   Email: tulika.bose@tcs.com