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

From: Abhijan Bhattacharyya <[email-masked]>
Date: Fri, 6 Sep 2013 20:43:33 +0530

Carsten, Esko, Bert and all,
Thanks for the responses on the first version of this draft. We have 
incorporated the comments we received and enhanced the draft. The details 
are below. Would like your views on this one please.

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 09/06/2013 08:39 PM 
-----

From:
[email-masked]
To:
Abhijan Bhattacharyya <[email-masked]>, Soma Bandyopadhyay 
<[email-masked]>, Arpan Pal <[email-masked]>
Date:
09/06/2013 08:38 PM
Subject:
New Version Notification for draft-tcs-coap-no-response-option-01.txt

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

Filename:                 draft-tcs-coap-no-response-option
Revision:                 01
Title:                            CoAP option for no server-response
Creation date:            2013-09-06
Group:                            Individual Submission
Number of pages: 10
URL:             
http://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-01.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-01
Diff:            
http://www.ietf.org/rfcdiff?url2=draft-tcs-coap-no-response-option-01

Abstract:
   The server end-point does not respond with acknowledgment (ACK) in
   non-confirmable (NON) mode of CoAP. However, the server responds the
   client with a status code indicating "the result of the attempt to
   understand and satisfy the request". But there may be typical
   scenarios, while updating resources in NON mode, where any kind of
   response from the server may be considered redundant. Thus, in this
   case, the transaction becomes completely open-loop with no reverse
   path from the server to the client. This kind of exchange may be
   useful in constrained systems looking for maximized throughput with
   minimized resource consumption. This draft introduces a header
   option: 'No-Resp' to suppress responses from the server and
   discusses an exemplary but practical use case which actually
   motivated this proposition based on real experience. This option not
   only allows suppressing any kind of responses but allows suppressing
   a typical class or a combination of classes of responses. This
   option is applicable for both request/ response as well as resource-
   observe mode and 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