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

From: Abhijan Bhattacharyya <[email-masked]>
Date: Wed, 3 Jun 2015 16:49:26 +0530

Dear all,
A new version of the draft for proposed No-Response option has been 
uploaded. The major highlights are (thanks to some important inputs from 
Carsten and Klaus ):
1. The No-Response option now has a number assigned from IANA. The option 
number is 284. (http://www.iana.org/assignments/core-parameters). So, the 
option-definition table has been updated accordingly.
   +--------+---+---+---+---+-------------+--------+--------+---------+
   | Number | C | U | N | R |   Name      | Format | Length | Default |
   +--------+---+---+---+---+-------------+--------+--------+---------+
   |   284  |   |   | X |   | No-Response |  uint  |  0-1   |    0    |
   +--------+---+---+---+---+-------------+--------+--------+---------+

2. The option values has changed and the convention for assigning the 
values has been clearly explained in Section 2.1:

This option is defined as a bit-map (Table 3) to achieve granular
   suppression.

   +-------+-----------------------+---------------------------------+
   | Value | Binary Representation |          Description            |
   +-------+-----------------------+---------------------------------+
   |   0   |      <empty>          |       Allow all responses.      |
   +-------+-----------------------+---------------------------------+
   |   2   |      00000010         |       Suppress 2.xx responses.  |
   +-------+-----------------------+---------------------------------+
   |   8   |      00001000         |       Suppress 4.xx responses.  |
   +-------+-----------------------+---------------------------------+
   |   16  |      00010000         |       Suppress 5.xx responses.  |
   +-------+-----------------------+---------------------------------+
   |   127 |      01111111         |       Suppress all responses.   |
   +-------+-----------------------+---------------------------------+
                          Table 3: Option values

   The conventions used in deciding the option values are:

   1. To suppress an individual class: Set bit number (n-1) starting
   from the LSB (bit number 0) to suppress all responses belonging to
   class n.xx. So,

             option value to suppress n.xx class = 2**(n-1).

   2. To suppress combination of classes: Set each corresponding bit
   according to point 1 above. Example: The option value will be 18
   (binary: 00010010) to suppress both 2.xx and 5.xx responses. This is
   essentially bitwise OR of the corresponding individual values for
   suppressing 2.xx and 5.xx. At present the "CoAP Response Codes"
   registry (Ref. Section 12.1.2 of [RFC7252]) defines only 2.xx, 4.xx
   and 5.xx responses.

   So, an option value of 22 (binary: 00010110) will effectively
   suppress all currently defined response codes.

   3. To suppress all possible responses: The maximum reserved response
   code for CoAP is 7.31 (Ref. Section 12.1 of [RFC7252]). So, setting
   bit positions 0-6 will suppress all responses according to the
   combination operation defined in point 2 above. Hence, the value to
   block all present and possible future responses is: 2**7 - 1 = 127.

Now that the No-Response option has got a number from IANA, may we request 
the implementers to include this option in respective implementations and 
share their experiences/ comments (if any).
Looking forward to meet you all in Prague.

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: [email-masked]
Website: http://www.tcs.com
____________________________________________
Experience certainty.   IT Services
                        Business Solutions
                        Consulting
____________________________________________
----- Forwarded by Abhijan Bhattacharyya/KOL/TCS on 06/03/2015 04:36 PM 
-----

From:   [email-masked]
To:     "Soma Bandyopadhyay" <[email-masked]>, "Abhijan 
Bhattacharyya" <[email-masked]>, "Arpan Pal" 
<[email-masked]>, "Arpan Pal" <[email-masked]>, "Soma Bandyopadhyay" 
<[email-masked]>, "Abhijan Bhattacharyya" 
<[email-masked]>
Date:   06/03/2015 04:34 PM
Subject:        New Version Notification for 
draft-tcs-coap-no-response-option-11.txt

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

Name:                            draft-tcs-coap-no-response-option
Revision:                11
Title:                           CoAP option for no server-response
Document date:           2015-06-03
Group:                           Individual Submission
Pages:                           17
URL:            
https://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-11.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-11
Diff:           
https://www.ietf.org/rfcdiff?url2=draft-tcs-coap-no-response-option-11

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