RFC 7967
Constrained Application Protocol (CoAP) Option for No Server Response
Constrained Application Protocol (CoAP) Option for No Server Response 🦋
okay bestie, this RFC is an Informational doc from the Independent Submission stream, so nobody's making it an official Internet Standard 💅. It's by A. Bhattacharyya, S. Bandyopadhyay, A. Pal, and T. Bose from Tata Consultancy Services Ltd., published August 2016. It's RFC 7967, the ISSN is 2070-1721, and there's no Obsoletes or Updates line in the header, so it doesn't touch any earlier RFCs 🌸
Independent Submission A. Bhattacharyya
Request for Comments: 7967 S. Bandyopadhyay
Category: Informational A. Pal
ISSN: 2070-1721 T. Bose
Tata Consultancy Services Ltd.
August 2016Abstract
okay so picture this 🧚 there are machine-to-machine (M2M) setups where the server's replies to client requests are literally just redundant. That's an open-loop exchange, meaning no response path from the server back to the client. You'd want that to save resources on constrained devices, especially when you're updating loads of resources at once or doing high-frequency updates 🔥
CoAP already has Non-confirmable (NON) messages, which the recipient doesn't acknowledge. BUT the request/response semantics still make the server reply with a status code saying "the result of the attempt to understand and satisfy the request", per RFC 7252. So the vibe is still "reply anyway" 💀
This spec adds a CoAP option called 'No-Response' ✨ With it, the client can clearly tell the server it's not interested in any of the responses to that request. There's also granular control, so the client can skip one response class or a combo of classes 💖 The server MAY decide to suppress the response, meaning it doesn't send it back, based on the No-Response value in the request. It can work for both unicast and multicast requests 🌈 The doc also walks through a few application examples that benefit from this option 🫶
Status of This Memo
this doc is not an Internet Standards Track spec, it's just published for info purposes 🎀
It's a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor picked to publish it at their discretion and makes no statement about its value for implementation or deployment. Docs the RFC Editor approves aren't candidates for any level of Internet Standard. See Section 2 of RFC 7841 for that 🍓
For the current status, any errata, and how to send feedback, check 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. Please read these carefully, since they spell out your rights and restrictions for this doc 💜
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 ................................................181. Introduction ✨
okay so this spec defines a brand new option for the Constrained Application Protocol (CoAP) [RFC7252] called 'No-Response' 🦋 It lets clients clearly say they're not interested in getting responses back from the server 💅 That disinterest can be expressed per response class (like 2.xx) or a combo of classes (like 2.xx and 5.xx) 💖 By default the option says "yep, interested in all response classes" 🎀 And the server MAY decide to suppress the response, meaning it doesn't send it back, based on the No-Response value in the request.
The doc also goes through some practical application scenarios that show why this option is actually useful 🌈 [ITS-LIGHT] and [CoAP-ADAPT] hold the background research behind all of this 🧚
Also, whenever this doc says a client's request is "with No-Response", it means the client is expressing disinterest in 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, especially, by the characteristics of the info being updated 🍓 If you opportunistically use this option in a fitting M2M app, your system might get these perks (but heads up, the option is elective, so servers can just ignore what the client prefers 💀):
- Less network congestion, because the overall traffic actually goes down 🌊
- Less server-side load, since the server doesn't have to respond to requests where responses aren't needed 🙌
- Less battery drain at the constrained endpoint(s) 🔋
- Lower overall communication cost 💸
1.2. Terminology
the terms in this doc match the ones 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] 🎀
2. Option Definition 🌸
the properties of the No-Response option are in Table 1 🧚 In this table, the C, U, N, and R columns stand for Critical, Unsafe, NoCacheKey, and Repeatable, in that order 💜
+--------+---+---+---+---+-------------+--------+--------+---------+
| Number | C | U | N | R | Name | Format | Length | Default |
+--------+---+---+---+---+-------------+--------+--------+---------+
| 258 | | X | - | | No-Response | uint | 0-1 | 0 |
+--------+---+---+---+---+-------------+--------+--------+---------+
Table 1: Option Propertiesthis option is a request option 💖 It's elective and not repeatable 🫶 It's Unsafe-to-Forward, because the intermediary MUST know how to interpret this option 😭 Otherwise, an intermediary that doesn't know about the special one-way nature of the request would just sit there waiting for responses 💀
Note: since CoAP keeps the request/response layer and the message sub-layer clearly separated, this option doesn't depend on the message type (Confirmable/Non-confirmable). So even if there's no message sub-layer at all (like CoAP over TCP [CoAP-TCP-TLS]), it shouldn't change how the option gets interpreted 🌈 That said, if you're talking CoAP-over-UDP [RFC7252], NON messages are the best fit for this option because of the expected benefits ✨ Using No-Response with NON messages gets rid of all reverse traffic, so the whole interaction becomes completely open loop 🦋 Using this option with CON requests might not do what you want if piggybacked responses get triggered 🙈 But if the server sends a separate response (which the client might not even care about), then this option can still be useful 💅 Suppressing that separate response cuts out one additional CoAP message in this case 👑
this option contains values that show disinterest in all responses, or in a particular class or combo of classes, as described in Section 2.1 🎀
2.1. Granular Control over Response Suppression
okay so this option gives you granular control over response suppression 💅 The client can say "not interested" in a typical class or combo of classes of responses. For example, a client can tell the receiver that no response is needed unless something 'bad' happens. In that case, a 4.xx or 5.xx response is still fed back to the client 😭 No 2.xx response is required in that situation 🎀
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 doesn't know anything about that 🙈 The No-Response option, though, lets the client explicitly tell the servers that it's not interested in responses. That kind of explicit control on the client side can be really 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 times when a server decides on its own to suppress responses, like the suppression by multicast servers described in Section 2.7 of [RFC7390]. If such a server gets a request with a No-Response option showing 'interest' in specific response classes (meaning it isn't expressing disinterest in those options), then any default behavior of suppressing responses, if present, MUST be overridden so those responses that the client cares about get delivered 💖
So, for example, suppose a multicast server suppresses all responses by default and gets a request with a No-Response option expressing disinterest in 2.xx (success) responses only. The option value naturally expresses interest in error responses 4.xx and 5.xx in this case 👀 So the server must send back a response if the request caused an error 🔥
The option value is defined as a bit map (Table 2) so you can get 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 ValuesThe conventions used for deciding the option values are:
- To suppress an individual class: Set bit number (n-1), counting 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)- 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 the 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 suppression of 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 the client endpoint can no longer completely cease listening activity, and it 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. So, 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 where the response to errors gets lost. In such a situation, the client would wait during the time-out period but wouldn't 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 the No-Response option into a series of requests with No-Response, to check periodically that things are fine at the server end and that the server is actively responding 💜
2.2. Method-Specific Applicability Considerations
The following table is 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., were deliberately not 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 Methods3. Miscellaneous Aspects
This section digs into the 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 🎀
okay so Tokens are the matching criteria 💅 that link a request to its response. A Token's life starts when it gets assigned to a request and ends when the final matching response arrives. Only then can it be reused again 🦋. BUT a request with No-Response typically doesn't have any guaranteed response path, so the client has to decide on its own when it can retire a Token that was used in an earlier request, so it can be reused in a future request. And since No-Response is 'elective' 🙈, a server that hasn't implemented this option will just respond anyway. That leads to two scenarios:
The first scenario is when the client is never going to care about any response coming back, or about relating a response to the original request. In that case, it MAY reuse the Token value at liberty. ✨
However, the second scenario is messier 😭. Say the client sends two requests. The first one is with No-Response, and the second one (using the same Token) is without No-Response. Now a delayed response to the first request can be interpreted as a response to the second request (the client needs a response in the second case) if the time interval between using the same Token isn't long enough. That 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 to the one in Section 2.5 of [RFC7390], SHOULD be used:
TOKEN_REUSE_TIME = NON_LIFETIME + MAX_SERVER_RESPONSE_DELAY +
MAX_LATENCYNON_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 that particular server to the 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, which is what's needed here. Therefore, the upper bound can be estimated by taking N (N>>1) times the lower bound lb_Leisure:
lb_Leisure = S * G / Rwhere
S = estimated response size
G = group size estimate
R = data transfer rateAny 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 gives guidelines for basic congestion control. Better congestion control mechanisms can be designed as future work. ⭐
If this option is used with NON messages, the interaction becomes completely open loop. Without any feedback from the server end, congestion-control mechanisms get affected. 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]. So, 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, if there's 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 broker MAY return 4.29 (Too Many Requests) to ask a client to slow down its request rate. Interweaving requests without No-Response lets the client listen for that response. 👑
3.3. Considerations regarding Caching of Responses 💜
The cacheability of CoAP responses doesn't depend on the request method. It depends on the Response Code. The No-Response option has no impact on the 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 for as long as the Max-Age hasn't 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 that indicates 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 a 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 doesn't 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. 💅
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 🚗
Okay so picture an intelligent traffic system (ITS) made of vehicles with a sensor gateway that has sensors like GPS and accelerometer sensors 🛰️. The sensor gateway acts as a CoAP client. It connects to the Internet over a low-bandwidth cellular connection (e.g., General Packet Radio Service (GPRS)). The vehicle's GPS coordinates get periodically updated to the backend server. 🎀
While doing frequent location updates, retransmitting (through the CoAP CON mechanism) a location coordinate the vehicle has already left is not efficient, because it adds redundant traffic to the network. So the updates are done using NON messages. But with a huge number of vehicles updating frequently, the NON exchange will also trigger a huge number of responses from the backend, so the cumulative load on the network gets pretty significant 😩. Also, the client in this case may not care about getting responses to location update requests for a location it has already passed, especially when the next location update is imminent.
On the contrary, if the client endpoints on the vehicles explicitly declare that they don't need any status response back from the server, the load will drop a lot. The assumption is that the high rate of updates will make up 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. With Observe, the onus is always on the data collection endpoint to establish an observe relationship with each data source. On the other hand, implementation is much simpler if initiating is left to the data source, which carries out updates using the No-Response option. Another way of looking at it: the implementation choice depends on where the interest to initiate the update lies. In an Observe scenario, the interest is expressed by the data consumer. In contrast, the classic update case applies when the interest comes 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 PUT4.1.2. Using No-Response with POST 🌈
4.1.2.1. POST Updating a Fixed Target Resource ✨
okay so in this case POST acts exactly like PUT 💅 The exchanges are the same as above, and the updated values ride along as the POST payload. see 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 Method4.1.2.2. POST Updating through Query String ✨
okay this one is giving database 🗄️ It may be possible that the backend infrastructure has a dedicated database storing the location updates. In that case, the client can update through a POST by putting a query string in the URI, with the name/value pairs for each update in it. No-Response works here the same way it does for updating fixed resources 🫶 The scenario is shown 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 Database4.2. Multicasting Actuation Command from a Handheld Device to a Group of Appliances 📱
so a handheld device, like a smart phone, can be programmed to act as an IP-enabled switch 🔦 and remotely operate one or more IP-enabled appliances. For example, you can send a multicast request to switch all the lights in a building on or off ✨ Here the IP switch application can use the No-Response option in a NON request message, which cuts down on the traffic from every light all replying at once 🙈
so yes, No-Response helps lower the overall communication cost and the chance of network congestion in this scenario 💜
4.2.1. Using Granular Response Suppression 🎯
the IP switch application may optionally use granular response suppression so that error responses are NOT suppressed. Wait, sorry, let me say that properly: error responses are not suppressed. Then any light that couldn't carry out the request would still respond and be easy to spot 👀 So explicit suppression of option classes by the multicast client can be really useful for debugging 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 since updated it 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>.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>.
[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📦 where this page comes from
- ietf: rfc7967 2016-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms