%% You should probably cite rfc7967 instead of this I-D. @techreport{tcs-coap-no-response-option-16, number = {draft-tcs-coap-no-response-option-16}, type = {Internet-Draft}, institution = {Internet Engineering Task Force}, publisher = {Internet Engineering Task Force}, note = {Work in Progress}, url = {https://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option/16/}, author = {Abhijan Bhattacharyya and Soma Bandyopadhyay and Arpan Pal and Tulika Bose}, title = {{CoAP option for no server-response}}, pagetotal = 18, year = 2016, month = apr, day = 12, abstract = {There can be M2M scenarios where responses from a server against requests from client are redundant. This kind of open-loop exchange (with no response path from the server to the client) may be desired to minimize resource consumption in constrained systems while updating a bulk of resources simultaneously, or updating a resource with a very high frequency. CoAP already provides Non-confirmable (NON) messages that are not acknowledged by the recipient. However, the request/response semantics still require the server to respond with a status code indicating "the result of the attempt to understand and satisfy the request". This specification introduces a CoAP option called 'No-Response'. Using this option the client can explicitly express to the server its disinterest in all responses against the particular request. This option also provides granular control to enable expression of disinterest to a particular class of response or a combination of response-classes. The server MAY decide to suppress the response by not transmitting it back to the client according to the value of No- Response option in the request. This option may be effective for both unicast and multicast requests. This document also discusses a few exemplary applications which benefit from this option.}, }