doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc7967.txt b/doc/rfc/rfc7967.txt
new file mode 100644
index 0000000..79d2422
--- /dev/null
+++ b/doc/rfc/rfc7967.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+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 ................16
+   5. IANA Considerations ............................................16
+   6. Security Considerations ........................................16
+   7. References .....................................................16
+      7.1. Normative References ......................................16
+      7.2. Informative 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 disinterest in
+   receiving responses back from the server.  The disinterest can be
+   expressed at the granularity of response classes (e.g., 2.xx) or a
+   combination of classes (e.g., 2.xx and 5.xx).  By 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.
+
+
+
+
+
+
+Bhattacharyya, et al.         Informational                     [Page 3]
+
+RFC 7967                 CoAP No-Response Option             August 2016
+
+
+   Along with the technical details, this document presents some
+   practical application scenarios that highlight the usefulness of this
+   option.  [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, the intended meaning is that the client
+   expresses its disinterest for all or some selected classes of
+   responses.
+
+1.1.  Potential Benefits
+
+   The use of the No-Response option should be driven by typical
+   application requirements and, particularly, characteristics of the
+   information to be updated.  If this option is opportunistically used
+   in a fitting M2M application, then the concerned system may benefit
+   in the following aspects.  (However, note that this option is
+   elective, and servers can simply ignore the preference expressed by
+   the 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 requests for which responses are not necessary.
+
+      *  Reduction in battery consumption at the constrained
+         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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+Bhattacharyya, et al.         Informational                     [Page 4]
+
+RFC 7967                 CoAP No-Response Option             August 2016
+
+
+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 and not repeatable.
+   This option is Unsafe-to-Forward, as the intermediary MUST know how
+   to interpret this option.  Otherwise, the intermediary (without
+   knowledge about the special unidirectional nature of the 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).  So, even the absence of a message
+      sub-layer (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 messages are best suited
+      to this option because of the expected benefits.  Using
+      No-Response with NON messages gets rid of any kind of reverse
+      traffic, and the interaction becomes completely open loop.
+
+      Using this option with CON requests may not serve the desired
+      purpose if piggybacked responses are triggered.  But, if the
+      server responds with a separate response (which, perhaps, the
+      client does not care 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 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
+
+
+
+Bhattacharyya, et al.         Informational                     [Page 5]
+
+RFC 7967                 CoAP No-Response Option             August 2016
+
+
+   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 option enables the 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 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 behavior of suppressing responses, if present, MUST be
+   overridden to deliver those responses 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
+   and 5.xx in this case.  Thus, the server must send back a response if
+   the concerned request caused an error.
+
+   The option value is defined as a bit map (Table 2) to achieve
+   granular suppression.  Its length can be 0 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
+
+
+
+
+Bhattacharyya, et al.         Informational                     [Page 6]
+
+RFC 7967                 CoAP No-Response Option             August 2016
+
+
+   The conventions used in deciding the option values are:
+
+   1.  To suppress an individual class: Set bit number (n-1) starting
+       from the 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.  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 (see Section 12.1.2 of [RFC7252]) defines 2.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, the client
+      endpoint SHOULD cease listening to response(s) to the particular
+      request.  On the other hand, showing interest in at least one
+      class of response means that the client endpoint can no longer
+      completely cease listening activity and must be configured to
+      listen during some application specific time-out period for the
+      particular request.  The client 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), 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).  Note
+      that in this context there may be situations when the response to
+      errors might get lost.  In such a situation, the client would wait
+      during the time-out period but would not receive any response.
+      However, this should not give the client the impression that the
+      request was necessarily successful.  In other words, in this case,
+      the client cannot distinguish between response suppression and
+      message loss.  The application designer needs to tackle 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
+      periodically that things are fine at the server end and the server
+      is actively responding.
+
+
+
+
+
+
+
+
+
+
+Bhattacharyya, et al.         Informational                     [Page 7]
+
+RFC 7967                 CoAP No-Response Option             August 2016
+
+
+2.2.  Method-Specific Applicability Considerations
+
+   The following table provides a ready reference on the possible
+   applicability of this option with four REST methods.  This table is
+   for the type of possible interactions foreseen at the time of
+   preparing this specification.  The key words from RFC 2119 such as
+   "SHOULD NOT", etc., deliberately have not been used in this table
+   because it only contains suggestions.
+
+   +-------------+----------------------------------------------------+
+   | Method Name |              Remarks on 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 have side |
+   |     GET     | effects.  For instance, the proactive cancellation |
+   |             | procedure for observing a request [RFC7641]        |
+   |             | requires a client to issue a GET request with the  |
+   |             | Observe option set to 1 ('deregister').  If it is  |
+   |             | more efficient to use this deregistration instead  |
+   |             | 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 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|
+   |             | important to ensure that a resource was actually   |
+   |             | created rather than updating an existing resource. |
+   +-------------+----------------------------------------------------+
+   |             | If POST is used to update a target 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.  If the    |
+   |    DELETE   | client wants to ensure that the deletion request   |
+   |             | was properly executed, then this option should not |
+   |             | be used with the request.                          |
+   +-------------+----------------------------------------------------+
+
+    Table 3: Suggested Applicability of No-Response with REST Methods
+
+
+
+Bhattacharyya, et al.         Informational                     [Page 8]
+
+RFC 7967                 CoAP No-Response Option             August 2016
+
+
+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], and [RFC5405]) for the application developer.
+
+3.1.  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, the Token can again be 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 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 that has not implemented this option
+   will respond back.  This leads to the following two scenarios:
+
+   The first scenario 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, 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 the same Token) is without No-Response.  In this
+   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,
+   then in most practical cases the client implementation SHOULD
+   implement an 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
+
+   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
+
+
+
+Bhattacharyya, et al.         Informational                     [Page 9]
+
+RFC 7967                 CoAP No-Response Option             August 2016
+
+
+   from the particular server to 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", 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, the upper bound
+   can be estimated by taking N (N>>1) times the lower bound lb_Leisure:
+
+                          lb_Leisure = S * G / R
+
+   where
+   S = estimated response size
+   G = group size estimate
+   R = data transfer rate
+
+   Any estimate of MAX_SERVER_RESPONSE_DELAY MUST be larger than
+   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, then the client, to be
+      safe, SHOULD use a unique Token for each stream of messages.
+
+3.2.  Taking Care of Congestion Control and 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, then the interaction
+   becomes completely open loop.  The absence of any feedback from the
+   server-end affects congestion-control mechanisms.  In this 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, per [RFC5405], a 3-second interval is suggested as
+   the minimum interval between successive updates, and it is suggested
+   to use an even less aggressive rate when possible.  However, in case
+   of a higher rate of updates, the application MUST have some knowledge
+   about the channel, and an application developer MUST interweave
+   occasional closed-loop exchanges (e.g., NON messages without
+   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 [CoAP-PUBSUB], a
+
+
+
+Bhattacharyya, et al.         Informational                    [Page 10]
+
+RFC 7967                 CoAP No-Response Option             August 2016
+
+
+   broker MAY return 4.29 (Too Many 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 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, 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 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 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 requirement.  In this case, it is
+   RECOMMENDED that the reverse proxy 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.
+
+   If the reverse proxy applies No-Response for one or more classes of
+   responses, it will wait for responses up to an application-specific
+   maximum time (T_max) before responding to the HTTP side.  If a
+   response of a desired class is received within T_max, then the
+   response gets translated to HTTP as defined in [HTTP-to-CoAP].
+   However, if the proxy does not receive any response within T_max, it
+   is RECOMMENDED that the reverse Proxy send an HTTP response with
+   status code 204 (No Content) when allowed for the specific HTTP
+   request method.
+
+
+
+
+
+
+
+
+
+
+
+Bhattacharyya, et al.         Informational                    [Page 11]
+
+RFC 7967                 CoAP No-Response Option             August 2016
+
+
+4.  Application Scenarios
+
+   This section describes some examples of application scenarios that
+   may potentially benefit from the use of the No-Response option.
+
+4.1.  Frequent Update of Geolocation from Vehicles to Backend Server
+
+   Let us consider an intelligent traffic system (ITS) consisting of
+   vehicles equipped with a sensor gateway comprising sensors like GPS
+   and accelerometer sensors.  The sensor gateway acts as a CoAP client.
+   It connects to the Internet using a low-bandwidth cellular connection
+   (e.g., General Packet Radio Service (GPRS)).  The GPS coordinates of
+   the vehicle are periodically updated to the backend server.
+
+   While performing frequent location updates, retransmitting (through
+   the CoAP CON mechanism) a location coordinate that the vehicle has
+   already left 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, the cumulative load on the network will be quite
+   significant.  Also, the client in this case may not be interested in
+   getting responses to location update requests for a location it has
+   already passed and when the next location update is imminent.
+
+   On the contrary, if the client endpoints on the vehicles explicitly
+   declare that they do not need any status response back from the
+   server, then load will be reduced significantly.  The assumption is
+   that the high rate of updates will compensate for the stray losses in
+   geolocation reports.
+
+   Note: It may be argued that the above example application can also be
+      implemented using the Observe option [RFC7641] with NON
+      notifications.  But, in practice, implementing with Observe would
+      require lot of bookkeeping at the data collection endpoint at the
+      backend (observer).  The observer needs to maintain all the
+      observe relationships with each vehicle.  The data collection
+      endpoint may be unable to know all its data sources beforehand.
+      The client endpoints at vehicles may go offline or come back
+      online randomly.  In the case of Observe, the onus is always on
+      the data collection endpoint to establish an observe relationship
+      with each data source.  On the other hand, implementation will be
+      much simpler if initiating is left to the data source to carry out
+      updates using the No-Response option.  Another way of looking at
+      it is that the implementation choice depends on where there is
+      interest to initiate the update.  In an Observe scenario, the
+      interest is expressed by the data consumer.  In contrast, the
+
+
+
+
+Bhattacharyya, et al.         Informational                    [Page 12]
+
+RFC 7967                 CoAP No-Response Option             August 2016
+
+
+      classic update case applies when the interest is from the data
+      producer.  The No-Response option makes classic updates consume
+      even less resources.
+
+   The following subsections illustrate some 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 using NON 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 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: Example of Unreliable Update with No-Response Option
+                                Using PUT
+
+
+
+
+
+
+
+
+
+
+
+
+Bhattacharyya, et al.         Informational                    [Page 13]
+
+RFC 7967                 CoAP No-Response Option             August 2016
+
+
+4.1.2.  Using No-Response with POST
+
+4.1.2.1.  POST Updating a Fixed Target Resource
+
+   In this 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 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: Example of Unreliable Update with No-Response Option
+                   Using POST as the Update Method
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bhattacharyya, et al.         Informational                    [Page 14]
+
+RFC 7967                 CoAP No-Response Option             August 2016
+
+
+4.1.2.2.  POST Updating through Query String
+
+   It may be possible that the backend infrastructure deploys a
+   dedicated database to store the location updates.  In such a case,
+   the client can update through a POST by sending a query string in the
+   URI.  The query string contains the name/value pairs for each update.
+   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 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: Example of Unreliable Update with No-Response Option
+    Using POST with a Query String to 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., a smart phone) may be programmed to act as
+   an IP-enabled switch to remotely operate on one or more IP-enabled
+   appliances.  For example, a multicast request to switch on/off all
+   the lights of a building can be sent.  In this case, the IP switch
+
+
+
+
+
+Bhattacharyya, et al.         Informational                    [Page 15]
+
+RFC 7967                 CoAP No-Response Option             August 2016
+
+
+   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, 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, the lights 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 had previously assigned number 284 to this option in the
+   "CoAP Option Numbers" registry.  IANA has updated this as shown
+   below:
+
+            +--------+--------------+-------------+
+            | Number |     Name     |  Reference  |
+            +--------+--------------+-------------+
+            |   258  | No-Response  |  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.  References
+
+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., and C. Bormann, "The Constrained
+              Application Protocol (CoAP)", RFC 7252,
+              DOI 10.17487/RFC7252, June 2014,
+              <http://www.rfc-editor.org/info/rfc7252>.
+
+
+
+
+Bhattacharyya, et al.         Informational                    [Page 16]
+
+RFC 7967                 CoAP No-Response Option             August 2016
+
+
+7.2.  Informative References
+
+   [CoAP-ADAPT]
+              Bandyopadhyay, S., Bhattacharyya, A., and A. Pal,
+              "Adapting protocol characteristics of CoAP using sensed
+              indication for vehicular analytics", 11th ACM Conference
+              on Embedded Networked Sensor Systems (SenSys '13),
+              DOI 10.1145/2517351.2517422, November 2013.
+
+   [CoAP-PUBSUB]
+              Koster, M., Keranen, A., and J. Jimenez, "Publish-
+              Subscribe Broker for the Constrained Application Protocol
+              (CoAP)", Work in Progress, draft-koster-core-coap-
+              pubsub-05, July 2016.
+
+   [CoAP-TCP-TLS]
+              Bormann, C., 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
+              E. Dijk, "Guidelines for HTTP-to-CoAP Mapping
+              Implementations", Work in Progress, draft-ietf-core-http-
+              mapping-13, July 2016.
+
+   [ITS-LIGHT]
+              Bhattacharyya, A., Bandyopadhyay, S., and A. Pal,
+              "ITS-light: Adaptive lightweight scheme to resource
+              optimize intelligent transportation tracking system (ITS)
+              - Customizing CoAP for opportunistic optimization", 10th
+              International Conference on Mobile and Ubiquitous Systems:
+              Computing, Networking and Services (MobiQuitous 2013),
+              DOI 10.1007/978-3-319-11569-6_58, December 2013.
+
+   [RFC5405]  Eggert, L. and 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., Ed., and E. Dijk, Ed., "Group Communication
+              for the Constrained Application Protocol (CoAP)", RFC
+              7390, DOI 10.17487/RFC7390, October 2014,
+              <http://www.rfc-editor.org/info/rfc7390>.
+
+
+
+
+
+
+Bhattacharyya, et al.         Informational                    [Page 17]
+
+RFC 7967                 CoAP No-Response Option             August 2016
+
+
+   [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
+
+
+
+
+
+
+
+
+
+
+
+
+Bhattacharyya, et al.         Informational                    [Page 18]
+