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

[Abhijan Bhattacharyya <[e-mail]>]

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
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: [e-mail]
Website: http://www.tcs.com
____________________________________________
Experience certainty.   IT Services
                        Business Solutions
                        Consulting
____________________________________________


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

> From: "Dijk, Esko" <[e-mail]>
> To: Abhijan Bhattacharyya <[e-mail]>, "Rahman, 
> Akbar ([e-mail])" <[e-mail]>
> Cc: "core ([e-mail])" <[e-mail]>
> Date: 10/21/2015 01:19 PM
> Subject: RE: New Version Notification for draft-tcs-coap-no-
> response-option-12.txt
> 
> 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:[e-mail]] 
> Sent: Thursday, October 15, 2015 15:23
> To: Dijk, Esko <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]
> Subject: Fw: New Version Notification for draft-tcs-coap-no-
> response-option-12.txt
> 
> 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: [e-mail]
> 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:        [e-mail] 
> To:        "Soma Bandyopadhyay" <[e-mail]>, "Soma 
> Bandyopadhyay" <[e-mail]>, "Abhijan Bhattacharyya" <
> [e-mail]>, "Arpan Pal" <[e-mail]>, "Arpan 
Pal" <
> [e-mail]>, "Tulika Bose" <[e-mail]>, "Abhijan 
> Bhattacharyya" <[e-mail]>, "Tulika Bose" <
> [e-mail]> 
> 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
> 
> 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.