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

[Abhijan Bhattacharyya <[e-mail]>]

Dear all,
We have submitted a new version of the No-Response draft. This addresses the last comments received from Esko.

Carsten, 
May I please request you to update the version number in the meeting materials. Sorry for the late action. Was stuck with some issues with my mail server.  

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


-----Forwarded by Abhijan Bhattacharyya/KOL/TCS on 11/02/2015 04:00PM -----

>To: "Soma Bandyopadhyay" <[e-mail]>, "Abhijan
>Bhattacharyya" <[e-mail]>, "Arpan Pal"
><[e-mail]>, "Tulika Bose" <[e-mail]>
>From: [e-mail]
>Date: 11/02/2015 03:59PM
>Subject: New Version Notification for
>draft-tcs-coap-no-response-option-13.txt
>
>A new version of I-D, draft-tcs-coap-no-response-option-13.txt
>has been successfully submitted by Abhijan Bhattacharyya and posted
>to the
>IETF repository.
>
>Name: draft-tcs-coap-no-response-option
>Revision:	13
>Title:	CoAP option for no server-response
>Document date:	2015-11-02
>Group:	Individual Submission
>Pages:	17
>URL:
>https://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-optio
>n-13.txt
>Status:
>https://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option/
>Htmlized:
>https://tools.ietf.org/html/draft-tcs-coap-no-response-option-13
>Diff:
>https://www.ietf.org/rfcdiff?url2=draft-tcs-coap-no-response-option-1
>3
>
>Abstract:
> There can be M2M scenarios where responses from server against
> requests from client might be considered 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 simultaneously updating a bulk of
> resources or updating a resource with a very high frequency. CoAP
> already provides a non-confirmable (NON) mode of message exchange
> where the server end-point does not respond with ACK. However,
> obeying the request/response semantics, the server end-point
> responds back with a status code indicating "the result of the
> attempt to understand and satisfy the request".
>
> This draft introduces a header option for CoAP called
>'No-Response'.
> Using this option the client explicitly tells the server to
>suppress
> responses against the particular request. This option also
>provides
> granular control to enable suppression of a particular class or a
> combination of response-classes. This option may be effective for
> both unicast and multicast requests. Present draft also discusses
> few exemplary applications which benefit from this option.
>
>
> 
>
>
>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