[rfc-dist] RFC 7967 on Constrained Application Protocol (CoAP) Option for No Server Response

rfc-editor at rfc-editor.org (rfc-editor at rfc-editor.org) Tue, 30 August 2016 00:45 UTC

From: "rfc-editor at rfc-editor.org"
Date: Mon, 29 Aug 2016 17:45:23 -0700
Subject: [rfc-dist] RFC 7967 on Constrained Application Protocol (CoAP) Option for No Server Response
Message-ID: <20160830004523.C67BAB80C69@rfc-editor.org>

A new Request for Comments is now available in online RFC libraries.

        
        RFC 7967

        Title:      Constrained Application Protocol (CoAP) Option 
                    for No Server Response 
        Author:     A. Bhattacharyya, S. Bandyopadhyay,
                    A. Pal, T. Bose
        Status:     Informational
        Stream:     Independent
        Date:       August 2016
        Mailbox:    abhijan.bhattacharyya at tcs.com, 
                    soma.bandyopadhyay at tcs.com, 
                    arpan.pal at tcs.com, 
                    tulika.bose at tcs.com
        Pages:      18
        Characters: 40314
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-tcs-coap-no-response-option-17.txt

        URL:        https://www.rfc-editor.org/info/rfc7967

        DOI:        http://dx.doi.org/10.17487/RFC7967

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.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor at rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC