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

From: Abhijan Bhattacharyya <[email-masked]>
Date: Thu, 15 Oct 2015 18:52:33 +0530

Hi Carsten, Esko, Akbar and all,

Based on the recent inputs we have shared a new version of the No-Response 
draft.

Esko, I have actually removed the 'Leisure' stuff for unicast. Thought it 
was making things a bit complicated.

Akbar, The reverse proxy consideration have been included as a new section 
4.3.

Carsten, requesting your suggestion regarding the next step forward.

Hoping to see you all in Yokohama.

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 10/15/2015 06:45 PM 
-----

From:   [email-masked]
To:     "Soma Bandyopadhyay" <[email-masked]>, "Soma 
Bandyopadhyay" <[email-masked]>, "Abhijan Bhattacharyya" 
<[email-masked]>, "Arpan Pal" <[email-masked]>, "Arpan 
Pal" <[email-masked]>, "Tulika Bose" <[email-masked]>, "Abhijan 
Bhattacharyya" <[email-masked]>, "Tulika Bose" 
<[email-masked]>
Date:   10/15/2015 06:45 PM
Subject:        New Version Notification for 
draft-tcs-coap-no-response-option-12.txt

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

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

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

---

From: "Rahman, Akbar" <[email-masked]>
Date: Sun, 18 Oct 2015 00:17:37 +0000

>Akbar, The reverse proxy consideration have been included as a new section 4.3.

Thanks, Abhijan.  Looks good.

One other question, why does the draft say "Expired" at the top  even though the expiry date is April 2016?

From: Abhijan Bhattacharyya [mailto:[email-masked]]
Sent: Thursday, October 15, 2015 9:23 AM
To: [email-masked]; [email-masked]; [email-masked]; Rahman, Akbar <[email-masked]>
Subject: Fw: New Version Notification for draft-tcs-coap-no-response-option-12.txt

Based on the recent inputs we have shared a new version of the No-Response draft.

Esko, I have actually removed the 'Leisure' stuff for unicast. Thought it was making things a bit complicated.

Akbar, The reverse proxy consideration have been included as a new section 4.3.

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

----- Forwarded by Abhijan Bhattacharyya/KOL/TCS on 10/15/2015 06:45 PM -----

From:        [email-masked]<mailto:[email-masked]>
To:        "Soma Bandyopadhyay" <[email-masked]<mailto:[email-masked]>>, "Soma Bandyopadhyay" <[email-masked]<mailto:[email-masked]>>, "Abhijan Bhattacharyya" <[email-masked]<mailto:[email-masked]>>, "Arpan Pal" <[email-masked]<mailto:[email-masked]>>, "Arpan Pal" <[email-masked]<mailto:[email-masked]>>, "Tulika Bose" <[email-masked]<mailto:[email-masked]>>, "Abhijan Bhattacharyya" <[email-masked]<mailto:[email-masked]>>, "Tulika Bose" <[email-masked]<mailto:[email-masked]>>
Date:        10/15/2015 06:45 PM
Subject:        New Version Notification for draft-tcs-coap-no-response-option-12.txt
________________________________

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

Abstract:

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

---

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 21 Oct 2015 07:48:23 +0000

Hello Abhijan,

Thanks for the update. Here a few more remarks to consider:

1.  Table 2, DELETE method: "MAY NOT" is not defined in RFC 2119 - so better not used.
Here the current text does not give much guidance. And there seems to be no need for requirements language I think? What about:
"If the client wants to ensure that the deletion really happened, it should not make use of the No-Response option. No use cases have been identified so far for DELETE."
I would not capitalize the "should not" in this text, like we have for the GET case.

2. I would separate the option definition from the applicability table 2. So, the text starting with "This option contains values to indicate disinterest in ..." and the table itself could go into a new subsection called "Applicability for CoAP Methods" or similar. Because strictly speaking it is not part of the option definition.

3. The text in the Table 2 on GET talks about 'usual circumstances' which may leave the reader wondering if GET to cancel an observe relation is usual or unusual.
In fact we could say that the option MAY be used in a GET request intended to cancel an Observe relationship; and the option SHOULD NOT be used by the client in other cases - with the exception being that a clear use case for this is identified. Still a server MUST support a combination of GET with the No-Response option.

4. Section 4.3 on the HC Proxy: returning 204 No Content seems not applicable in many cases - e.g. some HTTP methods may not allow for a 204 response (I didn't check it though).
Also the HC Proxy doesn't know whether the request was successful (which 204 implies) or not.   So I don't see why we can give this guideline without knowing the specific (use) cases.
What we can say at least is that: a HTTP PUT request SHOULD be answered with HTTP 204 , if the HC Proxy chose to suppress all classes of responses in the corresponding CoAP PUT request.
(For example if the HC Proxy does partial suppression of only class 2.xx, then it gets more complicated - I could program my HC Proxy to wait a 20 seconds and only if no CoAP error response comes the proxy decides to answer with HTTP 204. This is more intricate than "always answer 204".)

Regards,
Esko

From: Abhijan Bhattacharyya [mailto:[email-masked]]
Sent: Thursday, October 15, 2015 15:23
To: Dijk, Esko <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Fw: New Version Notification for draft-tcs-coap-no-response-option-12.txt

Regards
Abhijan Bhattacharyya
Associate Consultant

----- Forwarded by Abhijan Bhattacharyya/KOL/TCS on 10/15/2015 06:45 PM -----

Abstract:

The IETF Secretariat

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Fri, 23 Oct 2015 17:06:05 +0530

Hi Esko,
Thanks for the comments. The ID submission has been suspended on 19th till 
starting of Yokohama meeting. So will address your comments when it 
re-opens.

However, a few remarks :

> 4. Section 4.3 on the HC Proxy: returning 204 No Content seems not 
> applicable in many cases – e.g. some HTTP methods may not allow for 
> a 204 response (I didn’t check it though).

I did not find "No Content" to be associated with any specific method. The 
definition I found (https://www.ietf.org/rfc/rfc2616.txt) is as below:

"The server has fulfilled the request but does not need to return an 
entity-body, and might want to return updated metainformation. The 
response MAY include new or updated metainformation in the form of 
entity-headers, which if present SHOULD be associated with the requested 
variant.

If the client is a user agent, it SHOULD NOT change its document view from 
that which caused the request to be sent. This response is primarily 
intended to allow input for actions to take place without causing a change 
to the user agent's active document view, although any new or updated 
metainformation SHOULD be applied to the document currently in the user 
agent's active view.

The 204 response MUST NOT include a message-body, and thus is always 
terminated by the first empty line after the header fields."

Please share if you have any further input.

> What we can say at least is that: a HTTP PUT request SHOULD be 
> answered with HTTP 204 , if the HC Proxy chose to suppress all 
> classes of responses in the corresponding CoAP PUT request.
> (For example if the HC Proxy does partial suppression of only class 
> 2.xx, then it gets more complicated – I could program my HC Proxy to
> wait a 20 seconds and only if no CoAP error response comes the proxy
> decides to answer with HTTP 204. This is more intricate than “always
> answer 204”.)

Actually, in the latest version we added a small paragraph in in the 
Introduction (page 3):
" Wherever, in this draft, it is mentioned that a request from client is 
with No-Response the intended meaning is that the client expressed its 
disinterest for all or some selected classes of responses."

So, while writing the proxy consideration we consider the case of 
suppressing all responses. In case of partial suppression (say, allowing 
only the 4.xx error responses) the client (the proxy in this case) will 
nyway wait for some pre-determined amount of time before it sends any 
response to the HTTP side. If the client does not get a response within 
that time then it will send a "No Content". If it receives any error 
response then that response will automatically get translated to the 
relevant HTTP code. 

Does that sound alright? 
We shall put more clear description in the next version.

Regards
Abhijan Bhattacharyya
Associate Consultant

"Dijk, Esko" <[email-masked]> wrote on 10/21/2015 01:18:23 PM:

> From: "Dijk, Esko" <[email-masked]>
> To: Abhijan Bhattacharyya <[email-masked]>, "Rahman, 
> Akbar ([email-masked])" <[email-masked]>
> Cc: "core ([email-masked])" <[email-masked]>
> Date: 10/21/2015 01:19 PM
> Subject: RE: New Version Notification for draft-tcs-coap-no-
> response-option-12.txt
> 
> Hello Abhijan,
> 
> 1.  Table 2, DELETE method: “MAY NOT” is not defined in RFC 2119 – 
> so better not used.
> Here the current text does not give much guidance. And there seems 
> to be no need for requirements language I think? What about:
> “If the client wants to ensure that the deletion really happened, it
> should not make use of the No-Response option. No use cases have 
> been identified so far for DELETE.”
> I would not capitalize the “should not” in this text, like we have 
> for the GET case.
> 
> 2. I would separate the option definition from the applicability 
> table 2. So, the text starting with “This option contains values to 
> indicate disinterest in …” and the table itself could go into a new 
> subsection called “Applicability for CoAP Methods” or similar. 
> Because strictly speaking it is not part of the option definition.
> 
> 3. The text in the Table 2 on GET talks about ‘usual circumstances’ 
> which may leave the reader wondering if GET to cancel an observe 
> relation is usual or unusual.
> In fact we could say that the option MAY be used in a GET request 
> intended to cancel an Observe relationship; and the option SHOULD 
> NOT be used by the client in other cases – with the exception being 
> that a clear use case for this is identified. Still a server MUST 
> support a combination of GET with the No-Response option.
> 
> 4. Section 4.3 on the HC Proxy: returning 204 No Content seems not 
> applicable in many cases – e.g. some HTTP methods may not allow for 
> a 204 response (I didn’t check it though).
> Also the HC Proxy doesn’t know whether the request was successful 
> (which 204 implies) or not.   So I don’t see why we can give this 
> guideline without knowing the specific (use) cases.
> What we can say at least is that: a HTTP PUT request SHOULD be 
> answered with HTTP 204 , if the HC Proxy chose to suppress all 
> classes of responses in the corresponding CoAP PUT request.
> (For example if the HC Proxy does partial suppression of only class 
> 2.xx, then it gets more complicated – I could program my HC Proxy to
> wait a 20 seconds and only if no CoAP error response comes the proxy
> decides to answer with HTTP 204. This is more intricate than “always
> answer 204”.)
> 
> Regards,
> Esko
> 
> Esko, I have actually removed the 'Leisure' stuff for unicast. 
> Thought it was making things a bit complicated. 
> 
-----
> Bandyopadhyay" <[email-masked]>, "Abhijan Bhattacharyya" <
> [email-masked]>, "Arpan Pal" <[email-masked]>, "Arpan 
Pal" <
> [email-masked]>, "Tulika Bose" <[email-masked]>, "Abhijan 
> Bhattacharyya" <[email-masked]>, "Tulika Bose" <
> [email-masked]> 
submission
> The information contained in this message may be confidential and 
> legally protected under applicable law. The message is intended 
> solely for the addressee(s). If you are not the intended recipient, 
> you are hereby notified that any use, forwarding, dissemination, or 
> reproduction of this message is strictly prohibited and may be 
> unlawful. If you are not the intended recipient, please contact the 
> sender by return e-mail and destroy all copies of the original message.