Subject: Re: [core] Please have another look at no-response (Re: WG last-call (WGLC) of draft-ietf-core-http-mapping-07)

From: Abhijan Bhattacharyya <[email-masked]>
Date: Tue, 13 Oct 2015 13:13:51 +0530

Hi Carsten,

> ... provide Abhijan (and the core WG list, if you like) with your
> feedback, preferably so that he has time to react before the Yokohama
> I-D deadline (maybe send in the comments before 2015-10-12).

While the tentative deadline set for sharing the comments is over, we have 
so far received one comment from Akbar. It is about mentioning the 
behaviour of a reverse proxy in the context of applications requiring 
No-Response at the CoAP end (
http://www.ietf.org/mail-archive/web/core/current/msg06506.html).

Should we consider the final review process to be over by now?
Requesting your suggestion regarding the way forward.
Awaiting your response soon as Yokohama deadlines are approaching fast.

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
____________________________________________

Carsten Bormann <[email-masked]> wrote on 09/24/2015 02:47:07 AM:

> From: Carsten Bormann <[email-masked]>
> To: "Rahman, Akbar" <[email-masked]>
> Cc: Abhijan Bhattacharyya <[email-masked]>, core 
> <[email-masked]>, "[email-masked] WG" <[email-masked]>
> Date: 09/24/2015 02:47 AM
> Subject: Please have another look at no-response (Re: [core] WG 
> last-call (WGLC) of draft-ietf-core-http-mapping-07)
> 
> Rahman, Akbar wrote:
> > Any feedback?
> 
> We'll need to have a reference.
> 
> That (and the current discussion in ACE about unidirectional exchanges)
> reminds me that the draft for Option 284 could still benefit from some
> final review.  So, if you are interested in this topic, please have a
> look at
> 
>     http://tools.ietf.org/html/draft-tcs-coap-no-response-option-11.txt
> 
> and provide Abhijan (and the core WG list, if you like) with your
> feedback, preferably so that he has time to react before the Yokohama
> I-D deadline (maybe send in the comments before 2015-10-12).
> 
> (To avoid confusion, I'll add that we decided not to make a WG document
> out of this option, but there has been some review and some support
> already, and we all should be interested in facilitating the extension
> registration processes defined in RFC 7252.)
> 
> Grüße, Carsten
=====-----=====-----=====
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: "Dijk, Esko" <[email-masked]>
Date: Tue, 13 Oct 2015 15:48:24 +0000

Hello Abhijan, Carsten,

Below some more review comments for this draft!  Some points may be a repetition of some of my previous review comments but I send them nevertheless.
I did not understand fully why the document is not going to be a WG draft. I did miss the discussion on this. Anyhow it appears to me as a quite useful option to have in the "official" CoAP repertoire.

1.
"Using this option with CON type of requests may not have any
      significance if piggybacked responses are triggered. Even if the
      response is suppressed it does not reduce any traffic in that
      case."

I don't fully agree with the second sentence; since an ACK message without the response inside can be very short while an ACK with the complete response (payload) inside can be quite lengthy. The first sentence I agree with ("may not have any significance" suggests that in some cases it *may* have significance).

Also in the same paragraph "reduces one additional traffic" -> maybe replace it by "reduce traffic by one message" to be more correct.

2.
"This option is not applicable and should have no effect for usual
   GET requests asking for resource representation."

Don't agree on this - the option should just do its work whether it is inside a GET, PUT, POST or DELETE.

3. Table 2, row DELETE: remove the SHOULD / SHOULD NOT language here perhaps? Again if a client wants to send DELETE with no-response then the client can do so. The expectation is that the option is parsed by the server and applied, assuming the server knows/understands the elective option. On the previous rows a SHOULD NOT etc. was also not necessary.

4. Section 1: "This option enables to express disinterest in all kinds of response by default." -> incorrect, by default it expresses interest in all classes. Also replace "kinds" by "classes" preferably.

5. Table 3, first row: "<empty>" is possible but also 00000000 binary is possible there - by making the option length 1 instead of 0. That has the same effect as empty, so good to list it in the table as well! Maybe within the same table cell.

6. Section 4.1: "However, a request with No-Response does not have any response path."
-> replace by "However, a request with No-Response typically does not have a guaranteed response path."
(since e.g. for the default option value 0 there is a guaranteed response path.)

7. Section 4.1: "SHOULD use a unique token for request with No-Response" -> "SHOULD use a unique token for each request with No-Response to the same server endpoint"

8. Section 4.1 starting with "NON_LIFETIME and MAX_LATENCY are defined in 4.8.2 ...." up to the end of the section: I don't understand here why "Leisure" and the equations are used here for unicast requests. It is only defined in RFC 7252 for multicast requests and their associated unicast response. Suggestion: replace text by something that does not depend on Leisure.  (Or else describe why Leisure plays a role for unicast requests!)

Best regards
Esko

From: core [mailto:[email-masked]] On Behalf Of Abhijan Bhattacharyya
Sent: Tuesday, October 13, 2015 09:44
To: Carsten Bormann <[email-masked]>
Cc: core <[email-masked]>; [email-masked] WG <[email-masked]>
Subject: Re: [core] Please have another look at no-response (Re: WG last-call (WGLC) of draft-ietf-core-http-mapping-07)
Importance: High

Hi Carsten,

> I-D deadline (maybe send in the comments before 2015-10-12).

While the tentative deadline set for sharing the comments is over, we have so far received one comment from Akbar. It is about mentioning the behaviour of a reverse proxy in the context of applications requiring No-Response at the CoAP end (http://www.ietf.org/mail-archive/web/core/current/msg06506.html).

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
____________________________________________

Carsten Bormann <[email-masked]<mailto:[email-masked]>> wrote on 09/24/2015 02:47:07 AM:

> From: Carsten Bormann <[email-masked]<mailto:[email-masked]>>
> To: "Rahman, Akbar" <[email-masked]<mailto:[email-masked]>>
> Cc: Abhijan Bhattacharyya <[email-masked]<mailto:[email-masked]>>, core
> <[email-masked]<mailto:[email-masked]>>, "[email-masked] WG<mailto:[email-masked]%20WG>" <[email-masked]<mailto:[email-masked]>>

________________________________
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: Thu, 15 Oct 2015 09:24:41 +0530

Hi Esko,
Thanks for your detail comments and your support. Here are my responses:

> I did not understand fully why the document is not going to be a WG 
> draft.

We could not get enough hands raised for WG adaptation. :) So taking the 
individual submission route as suggested by Carsten.

> 1.
> “Using this option with CON type of requests may not have any
>       case.”
> I don’t fully agree with the second sentence; since an ACK message 
> without the response inside can be very short while an ACK with the 
> complete response (payload) inside can be quite lengthy. The first 
> sentence I agree with (“may not have any significance” suggests that
> in some cases it *may* have significance).

Good point. Accepted. May be the 'may' should be "MAY". :))

> Also in the same paragraph “reduces one additional traffic” -> maybe
> replace it by “reduce traffic by one message” to be more correct.

OK

> 2.
> “This option is not applicable and should have no effect for usual
>    GET requests asking for resource representation.”
> 
> Don’t agree on this – the option should just do its work whether it 
> is inside a GET, PUT, POST or DELETE. 

Actually we did not have any use case which would require a GET not to 
send any response payload, other than the case of observe-cancellation. We 
kept the restriction to ensure that any accidental use of No-Response with 
usual GET does not suppress the response payload, which would be actually 
intended. If you have any use case then would request you to please share.

> 3. Table 2, row DELETE: remove the SHOULD / SHOULD NOT language here
> perhaps? ....

OK

> 4. Section 1: “This option enables to express disinterest in all 
> kinds of response by default.” -> incorrect, by default it expresses
> interest in all classes. Also replace “kinds” by “classes” preferably.

Yes. This error crept in after we changed the option values in the last 
draft. Will correct.

> 5. Table 3, first row: “<empty>” is possible but also 00000000 
> binary is possible there – by making the option length 1 instead of 
> 0.

This is done in accordance with canonical representation. There was some 
discussion in the past on this in mailing list.

> 6. Section 4.1: “However, a request with No-Response does not have 
> any response path.”
> -> replace by “However, a request with No-Response typically does 
> not have a guaranteed response path.”

O.K.

> 7. Section 4.1: “SHOULD use a unique token for request with No-
> Response” -> “SHOULD use a unique token for each request with No-
> Response to the same server endpoint”

OK. Good to be precise.

> 8. Section 4.1 starting with “NON_LIFETIME and MAX_LATENCY are 
> defined in 4.8.2 ….” up to the end of the section: I don’t 
> understand here why “Leisure” and the equations are used here for 
> unicast requests. It is only defined in RFC 7252 for multicast 
> requests and their associated unicast response. Suggestion: replace 
> text by something that does not depend on Leisure.  (Or else 
> describe why Leisure plays a role for unicast requests!)

'Leisure' is a component of the total time the client should wait when 
suppressing responses selectively. We are re-using the definition of the 
leisure as a common parameter for both unicast and multicast. We just 
wanted to keep clarity on how leisure can be defined as a general 
definition and unicast  becomes a special case.

Regards
Abhijan Bhattacharyya
Associate Consultant

"Dijk, Esko" <[email-masked]> wrote on 10/13/2015 09:18:24 PM:

> From: "Dijk, Esko" <[email-masked]>
> To: Abhijan Bhattacharyya <[email-masked]>, Carsten 
> Bormann <[email-masked]>
> Cc: "[email-masked] WG" <[email-masked]>
> Date: 10/13/2015 09:20 PM
> Subject: RE: [core] Please have another look at no-response (Re: WG 
> Below some more review comments for this draft!  Some points may be 
> a repetition of some of my previous review comments but I send them 
> nevertheless.
> I did not understand fully why the document is not going to be a WG 
> draft. I did miss the discussion on this. Anyhow it appears to me as
> a quite useful option to have in the “official” CoAP repertoire. 
> 
> 1.
> “Using this option with CON type of requests may not have any
>       case.”
> I don’t fully agree with the second sentence; since an ACK message 
> without the response inside can be very short while an ACK with the 
> complete response (payload) inside can be quite lengthy. The first 
> sentence I agree with (“may not have any significance” suggests that
> in some cases it *may* have significance).
> 
> Also in the same paragraph “reduces one additional traffic” -> maybe
> replace it by “reduce traffic by one message” to be more correct.
> 
> 2.
> “This option is not applicable and should have no effect for usual
>    GET requests asking for resource representation.”
> 
> Don’t agree on this – the option should just do its work whether it 
> is inside a GET, PUT, POST or DELETE. 
> 
> 3. Table 2, row DELETE: remove the SHOULD / SHOULD NOT language here
> perhaps? Again if a client wants to send DELETE with no-response 
> then the client can do so. The expectation is that the option is 
> parsed by the server and applied, assuming the server knows/
> understands the elective option. On the previous rows a SHOULD NOT 
> etc. was also not necessary.
> 
> 4. Section 1: “This option enables to express disinterest in all 
> kinds of response by default.” -> incorrect, by default it expresses
> interest in all classes. Also replace “kinds” by “classes” preferably.
> 
> 5. Table 3, first row: “<empty>” is possible but also 00000000 
> binary is possible there – by making the option length 1 instead of 
> 0. That has the same effect as empty, so good to list it in the 
> table as well! Maybe within the same table cell.
> 
> 6. Section 4.1: “However, a request with No-Response does not have 
> any response path.”
> -> replace by “However, a request with No-Response typically does 
> not have a guaranteed response path.”
> 7. Section 4.1: “SHOULD use a unique token for request with No-
> Response” -> “SHOULD use a unique token for each request with No-
> Response to the same server endpoint”
> 
> 8. Section 4.1 starting with “NON_LIFETIME and MAX_LATENCY are 
> defined in 4.8.2 ….” up to the end of the section: I don’t 
> understand here why “Leisure” and the equations are used here for 
> unicast requests. It is only defined in RFC 7252 for multicast 
> requests and their associated unicast response. Suggestion: replace 
> text by something that does not depend on Leisure.  (Or else 
> describe why Leisure plays a role for unicast requests!)
> 
> Best regards
> Esko
> 
> Subject: Re: [core] Please have another look at no-response (Re: WG 
> While the tentative deadline set for sharing the comments is over, 
> we have so far received one comment from Akbar. It is about 
> mentioning the behaviour of a reverse proxy in the context of 
> applications requiring No-Response at the CoAP end (http://
> www.ietf.org/mail-archive/web/core/current/msg06506.html). 
> 
> 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: "Dijk, Esko" <[email-masked]>
Date: Thu, 15 Oct 2015 10:56:53 +0000

Hello Abhijan,

Thanks and some further remarks for discussion below:

> Actually we did not have any use case which would require a GET not to send any response payload, other than the case of observe-cancellation.  We kept the restriction to ensure that any accidental use of No-Response with usual GET does not suppress the response payload, which would be actually intended. If you have any use case then would request you to please share.

Well if it has no use case why would anyone accidentally include the No-Response option?  I would argue that the first person who does this probably has found an obscure use case that we did not yet think about. We should aim to have the simplest possible concept and also simplest implementation (least amount of rules or exceptions), I think.  And keeping the option’s behavior the same for all methods makes sense in this respect.
One common use case from the Web/HTTP domain is for example doing HTTP GET requests with some non-RESTful, modifying side effect effected by supplying query arguments. (A bit like doing a POST “execute resource” – anything may occur) There the response may not be of interest. Why do people implement a web server in such a foolish way going against all conventions ? I don’t know all the reasons – I only know I did this once myself ;) one reason is that a HTTP GET with query arguments is available in the address line of any web browser. While POST with some specific request payload is not.
Another use case may be that you want the GET response but only if successful, not the error ones to save on bandwidth. (E.g. if you’re scanning a lot of URI paths from a client to find out which ones a server supports, i.e. “reverse engineer” a server design).

If we just put in that “a client SHOULD NOT send a GET request with a No-Response option that suppresses one or more classes of responses” that should be enough. It implies that a server MAY expect to get a GET with No-Response option that suppresses some responses in case of one of those obscure use cases. Also it seems to make the server implementation simpler (less exceptions to rules). Would that be a good idea?

> 'Leisure' is a component of the total time the client should wait when suppressing responses selectively. We are re-using the definition of the leisure as a common parameter for both unicast and multicast. We just wanted to keep clarity on how leisure can be defined as a general definition and unicast  becomes a special case.

Ok, clear – you use it in a slightly different way to have a good estimate for the time it takes the server to transmit back the response. Good to keep this; however the current text to explain this is not very explicit and could be improved. Maybe explain that although this Leisure concept comes from the multicast usage of CoAP, you have taken and re-used it to get a suitable estimated upper bound for the transfer time of the response back to the client. (or so)

Regards,
Esko

From: Abhijan Bhattacharyya [mailto:[email-masked]]
Sent: Thursday, October 15, 2015 05:55
To: Dijk, Esko <[email-masked]>
Cc: Carsten Bormann <[email-masked]>; [email-masked] WG <[email-masked]>
Subject: RE: [core] Please have another look at no-response (Re: WG last-call (WGLC) of draft-ietf-core-http-mapping-07)

Hi Esko,

> I did not understand fully why the document is not going to be a WG

We could not get enough hands raised for WG adaptation. :) So taking the individual submission route as suggested by Carsten.

OK

> is inside a GET, PUT, POST or DELETE.

Actually we did not have any use case which would require a GET not to send any response payload, other than the case of observe-cancellation.  We kept the restriction to ensure that any accidental use of No-Response with usual GET does not suppress the response payload, which would be actually intended. If you have any use case then would request you to please share.

OK

> interest in all classes. Also replace “kinds” by “classes” preferably.

Yes. This error crept in after we changed the option values in the last draft. Will correct.

> binary is possible there – by making the option length 1 instead of

This is done in accordance with canonical representation. There was some discussion in the past on this in mailing list.

O.K.

OK. Good to be precise.

> describe why Leisure plays a role for unicast requests!)

'Leisure' is a component of the total time the client should wait when suppressing responses selectively. We are re-using the definition of the leisure as a common parameter for both unicast and multicast. We just wanted to keep clarity on how leisure can be defined as a general definition and unicast  becomes a special case.

Regards
Abhijan Bhattacharyya
Associate Consultant

"Dijk, Esko" <[email-masked]<mailto:[email-masked]>> wrote on 10/13/2015 09:18:24 PM:

> From: "Dijk, Esko" <[email-masked]<mailto:[email-masked]>>
> To: Abhijan Bhattacharyya <[email-masked]<mailto:[email-masked]>>, Carsten
> Bormann <[email-masked]<mailto:[email-masked]>>
> Cc: "[email-masked] WG<mailto:[email-masked]%20WG>" <[email-masked]<mailto:[email-masked]>>
> To: Carsten Bormann <[email-masked]<mailto:[email-masked]>>
> Cc: core <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> WG <[email-masked]<mailto:[email-masked]>>

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Thu, 15 Oct 2015 16:37:19 +0530

Hi Esko,

> If we just put in that “a client SHOULD NOT send a GET request with 
> a No-Response option that suppresses one or more classes of 
> responses” 

We are in sync. Actually I modified the draft a bit before receiving your 
mail. The modified text reads:
 
This SHOULD NOT be used with GET under usual   circumstances when the 
client requests the contents of a resource.

Thanks for your thoughtful comments.

Regards
Abhijan Bhattacharyya
Associate Consultant

"Dijk, Esko" <[email-masked]> wrote on 10/15/2015 04:26:53 PM:

> To: Abhijan Bhattacharyya <[email-masked]>
> Cc: Carsten Bormann <[email-masked]>, "[email-masked] WG" <[email-masked]>
> Date: 10/15/2015 04:27 PM
> > Actually we did not have any use case which would require a GET 
> not to send any response payload, other than the case of observe-
> cancellation.  We kept the restriction to ensure that any accidental
> use of No-Response with usual GET does not suppress the response 
> payload, which would be actually intended. If you have any use case 
> then would request you to please share.
> 
> Well if it has no use case why would anyone accidentally include the
> No-Response option?  I would argue that the first person who does 
> this probably has found an obscure use case that we did not yet 
> think about. We should aim to have the simplest possible concept and
> also simplest implementation (least amount of rules or exceptions), 
> I think.  And keeping the option’s behavior the same for all methods
> makes sense in this respect.
> One common use case from the Web/HTTP domain is for example doing 
> HTTP GET requests with some non-RESTful, modifying side effect 
> effected by supplying query arguments. (A bit like doing a POST 
> “execute resource” – anything may occur) There the response may not 
> be of interest. Why do people implement a web server in such a 
> foolish way going against all conventions ? I don’t know all the 
> reasons – I only know I did this once myself ;) one reason is that a
> HTTP GET with query arguments is available in the address line of 
> any web browser. While POST with some specific request payload is not.
> Another use case may be that you want the GET response but only if 
> successful, not the error ones to save on bandwidth. (E.g. if you’re
> scanning a lot of URI paths from a client to find out which ones a 
> server supports, i.e. “reverse engineer” a server design).
> 
> If we just put in that “a client SHOULD NOT send a GET request with 
> a No-Response option that suppresses one or more classes of 
> responses” that should be enough. It implies that a server MAY 
> expect to get a GET with No-Response option that suppresses some 
> responses in case of one of those obscure use cases. Also it seems 
> to make the server implementation simpler (less exceptions to 
> rules). Would that be a good idea? 
> 
> > 'Leisure' is a component of the total time the client should wait 
> when suppressing responses selectively. We are re-using the 
> definition of the leisure as a common parameter for both unicast and
> multicast. We just wanted to keep clarity on how leisure can be 
> defined as a general definition and unicast  becomes a special case.
> 
> Ok, clear – you use it in a slightly different way to have a good 
> estimate for the time it takes the server to transmit back the 
> response. Good to keep this; however the current text to explain 
> this is not very explicit and could be improved. Maybe explain that 
> although this Leisure concept comes from the multicast usage of 
> CoAP, you have taken and re-used it to get a suitable estimated 
> upper bound for the transfer time of the response back to the client. 
(or so)

> We could not get enough hands raised for WG adaptation. :) So taking
> the individual submission route as suggested by Carsten. 
> 
> > 1. 

> Actually we did not have any use case which would require a GET not 
> to send any response payload, other than the case of observe-
> cancellation.  We kept the restriction to ensure that any accidental
> use of No-Response with usual GET does not suppress the response 
> payload, which would be actually intended. If you have any use case 
> then would request you to please share. 
> 

> This is done in accordance with canonical representation. There was 
> some discussion in the past on this in mailing list. 
> 
> 'Leisure' is a component of the total time the client should wait 
> when suppressing responses selectively. We are re-using the 
> definition of the leisure as a common parameter for both unicast and
> multicast. We just wanted to keep clarity on how leisure can be 
> defined as a general definition and unicast  becomes a special case. 
> 
> Regards
> Abhijan Bhattacharyya
> Associate Consultant