Search RFCs

RFC Editor

File formats:

Status:

INFORMATIONAL

Authors:

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

Stream:

INDEPENDENT

Cite this RFC:TXT  | XML  |  BibTeX

DOI:  https://doi.org/10.17487/RFC7967

Discuss this RFC: Send questions or comments to the mailing listrfc-ise@rfc-editor.org

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 toclient requests are redundant. This kind of open-loop exchange(with no response path from the server to the client) may be desiredto minimize resource consumption in constrained systems whileupdating many resources simultaneously or performing high-frequency updates.CoAP already provides Non-confirmable (NON) messages that are not acknowledgedby the recipient. However, the request/response semantics still require theserver 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 serverits disinterest in all responses against the particular request.This option also provides granular control to enable expression ofdisinterest to a particular response class or a combination ofresponse classes. The server MAY decide to suppress the response bynot transmitting it back to the client according to the value of theNo-Response option in the request. This option may be effective forboth unicast and multicast requests. This document also discusses afew examples of applications that benefit from this option.

For the definition ofStatus,seeRFC 2026.

For the definition ofStream, seeRFC 8729.