Subject: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-04.txt

From: Abhijan Bhattacharyya <[email-masked]>
Date: Thu, 10 Oct 2013 00:43:27 +0530

Hi All,
A new version for no-response option has been uploaded. This version addresses most of the recent comments from Carsten and Klaus.

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services Limited
Mailto: [email-masked]
Website: http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Consulting
____________________________________________

-----Forwarded by Abhijan Bhattacharyya/KOL/TCS on 10/10/2013 12:41AM ----- 
To: Abhijan Bhattacharyya <[email-masked]>, Soma Bandyopadhyay <[email-masked]>, Arpan Pal <[email-masked]>
From: [email-masked]
Date: 10/10/2013 12:36AM
Subject: New Version Notification for draft-tcs-coap-no-response-option-04.txt

A new version of I-D, draft-tcs-coap-no-response-option-04.txt
has been successfully submitted by Abhijan Bhattacharyya and posted to the
IETF repository.

Filename: draft-tcs-coap-no-response-option
Revision: 04
Title: CoAP option for no server-response
Creation date: 2013-10-09
Group: Individual Submission
Number of pages: 15
URL:             http://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-04.txt
Status:          http://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option
Htmlized:        http://tools.ietf.org/html/draft-tcs-coap-no-response-option-04
Diff:            http://www.ietf.org/rfcdiff?url2=draft-tcs-coap-no-response-option-04

Abstract:
   There can be typical M2M scenarios where responses from the data
   sink to the data source against request/ notification from the
   source might be considered redundant. This kind of open-loop
   exchange (with no reverse path from the sink to the source) may be
   desired while updating resources in constrained systems looking for
   maximized throughput with minimized resource consumption. CoAP
   already provides a non-confirmable (NON) mode of exchange where The
   receiving end-point does not respond with ACK. However, the
   receiving end-point responds the sender with a status code
   indicating "the result of the attempt to understand and satisfy the
   request".

   This draft introduces a header option: 'No-Response' to suppress
   responses from the receiver and discusses exemplary use cases which
   motivated this proposition based on real experience. This option
   also provides granularity by allowing suppression of a typical class
   or a combination of classes of responses. This option may be
   effective for both unicast and multicast scenarios.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you