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

[Abhijan Bhattacharyya <[e-mail]>]

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
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/15/2015 04:26:53 PM:

> From: "Dijk, Esko" <[e-mail]>
> To: Abhijan Bhattacharyya <[e-mail]>
> Cc: Carsten Bormann <[e-mail]>, "[e-mail] WG" <[e-mail]>
> Date: 10/15/2015 04:27 PM
> Subject: RE: [core] Please have another look at no-response (Re: WG 
> last-call (WGLC) of draft-ietf-core-http-mapping-07)
> 
> 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:[e-mail]] 
> Sent: Thursday, October 15, 2015 05:55
> To: Dijk, Esko <[e-mail]>
> Cc: Carsten Bormann <[e-mail]>; [e-mail] WG <[e-mail]>
> Subject: RE: [core] Please have another look at no-response (Re: WG 
> last-call (WGLC) of draft-ietf-core-http-mapping-07)
> 
> 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 
> >       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). 
> 
> 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
> 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/13/2015 09:18:24 PM:
> 
> > From: "Dijk, Esko" <[e-mail]> 
> > To: Abhijan Bhattacharyya <[e-mail]>, Carsten 
> > Bormann <[e-mail]> 
> > Cc: "[e-mail] WG" <[e-mail]> 
> > Date: 10/13/2015 09:20 PM 
> > Subject: RE: [core] Please have another look at no-response (Re: WG 
> > last-call (WGLC) of draft-ietf-core-http-mapping-07) 
> > 
> > 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:[e-mail]] On Behalf Of Abhijan 
Bhattacharyya
> > Sent: Tuesday, October 13, 2015 09:44
> > To: Carsten Bormann <[e-mail]>
> > Cc: core <[e-mail]>; [e-mail] WG <[e-mail]>
> > 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, 
> > 
> > > ... 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: [e-mail]
> > Website: http://www.tcs.com
> > ____________________________________________
> > Experience certainty.        IT Services
> >                        Business Solutions
> >                        Consulting
> > ____________________________________________
> > 
> > 
> > Carsten Bormann <[e-mail]> wrote on 09/24/2015 02:47:07 AM:
> > 
> > > From: Carsten Bormann <[e-mail]> 
> > > To: "Rahman, Akbar" <[e-mail]> 
> > > Cc: Abhijan Bhattacharyya <[e-mail]>, core 
> > > <[e-mail]>, "[e-mail] WG" <[e-mail]> 
> > > 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 
> > 
> > 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. 
> 
> 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.