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

["Dijk, Esko" <[e-mail]>]

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]<mailto:[e-mail]>
Website: http://www.tcs.com<http://www.tcs.com/>
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Consulting
____________________________________________


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

> From: "Dijk, Esko" <[e-mail]<mailto:[e-mail]>>
> To: Abhijan Bhattacharyya <[e-mail]<mailto:[e-mail]>>, Carsten
> Bormann <[e-mail]<mailto:[e-mail]>>
> Cc: "[e-mail] WG<mailto:[e-mail]%20WG>" <[e-mail]<mailto:[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]<mailto:[e-mail]>>
> Cc: core <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> WG <[e-mail]<mailto:[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]<mailto:[e-mail]>
> Website: http://www.tcs.com<http://www.tcs.com/>
> ____________________________________________
> Experience certainty.        IT Services
>                        Business Solutions
>                        Consulting
> ____________________________________________
>
>
> Carsten Bormann <[e-mail]<mailto:[e-mail]>> wrote on 09/24/2015 02:47:07 AM:
>
> > From: Carsten Bormann <[e-mail]<mailto:[e-mail]>>
> > To: "Rahman, Akbar" <[e-mail]<mailto:[e-mail]>>
> > Cc: Abhijan Bhattacharyya <[e-mail]<mailto:[e-mail]>>, core
> > <[e-mail]<mailto:[e-mail]>>, "[e-mail] WG<mailto:[e-mail]%20WG>" <[e-mail]<mailto:[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.