File formats:

Status:

INFORMATIONAL

Authors:

A. Bhattacharyya
S. Bandyopadhyay
A. Pal
T. Bose

Stream:

INDEPENDENT

Cite this RFC: TXT  |  XML  |   BibTeX

DOI:  10.17487/RFC7967

Discuss this RFC: Send questions or comments to the mailing list [email protected]

Other actions: Submit Errata  |  Find IPR Disclosures from the IETF  |  View History of RFC 7967

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.

For the definition of Status, see RFC 2026.

For the definition of Stream, see RFC 8729.