Re: [core] Using draft-tcs-coap-no-response-option to *enable* responses

[Abhijan Bhattacharyya <[e-mail]>]

Hi Esko,
Thanks for responding. The discussion is leading to exactly what I was 
thinking about.
So, if we enhance the text as below would it be good for the purpose? 
Please comment.

"The server MUST send back responses of the classes for which the client 
has not expressed any dis-interest. There are instances where a server, on 
its own, may decide to suppress responses like the multicast servers as 
described in section 2.7 of  [RFC7390]. If the server receives a request 
with No-Response showing 'interest' in certain responses then such 
behaviour of suppressing responses by servers MUST be over-ridden for 
those responses which are of interest to the client. The server MUST send 
those responses for which the client has not expressed any disinterest 
(i.e., expressed 'interest'). So, for example, if a multicast server 
decides to suppress all responses and receives a request with No-Response 
option expressing disinterest only in success responses but not in errors 
then the server MUST send back a response if the concerned request causes 
an error. "

 Hopefully, this will solve a potential problem when the client actually 
wants to debug the lights through granular No-Response but the servers 
decide not to send a response as default behaviour and the client is never 
aware of that. However, it would be good if the above could be 
reciprocated by some specification which deals with the server-side 
behaviour.

Waiting to hear from you.

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 05/03/2016 01:25:01 AM:

> From: "Dijk, Esko" <[e-mail]>
> To: Abhijan Bhattacharyya <[e-mail]>
> Cc: "[e-mail] WG" <[e-mail]>, Nevil Brownlee <rfc-ise@rfc-
> editor.org>
> Date: 05/03/2016 01:25 AM
> Subject: RE: Using draft-tcs-coap-no-response-option to *enable* 
responses
> 
> Hi,
> 
> > "The server MUST send back responses of the classes for which the 
> client has not expressed any dis-interest." - 
> This covers part of my use case; however it is not clear how this 
> "MUST" interacts with the "MAY suppress" of RFC 7252 for the 
> multicast case. Can the server still decide to suppress the 
> multicast response even if the No-Response Option sent by the client
> says not to? Thinking about it, it would be perhaps good if draft-
> tcs-coap-no-response-option would make that clear. The "MUST" and 
> the use case 4.2.1 suggest that the default suppression choices of 
> the server are overridden by the No-Response option but that is not 
> written explicitly yet.  If that is the case, my use case is fully 
> covered by your draft I think.
> 
> An update or successor to the Groupcomm RFC could indeed describe 
> how the No-Response Option can be used for multicast use cases. It 
> would be great if that could be done without needing further 
> modifications to draft-tcs-coap-no-response-option!
> 
> regards
> Esko
> 
> From: Abhijan Bhattacharyya [mailto:[e-mail]] 
> Sent: Monday, May 02, 2016 5:19
> To: Dijk, Esko <[e-mail]>
> Cc: [e-mail] WG <[e-mail]>; Nevil Brownlee 
<[e-mail]>
> Subject: RE: Using draft-tcs-coap-no-response-option to *enable* 
responses
> Importance: High
> 
> Hi Esko, 
> The existing version -16 has the following text in section 2.1 (page 5) 
: 
> "The server MUST send back responses of the classes for which the 
> client has not expressed any dis-interest." 
> So, that way the client has actually expressed its interest (or 
> request for enablement) in all the responses for which it has not 
> expressed explicit disinterest. Does that help to control the 
> special server-side behaviour as the server knows which all 
> responses the client is interested in and it MUST send a response 
> back ? I shall submit another version with some editorial changes 
> before the draft goes to IESG. So we have some more room for 
> modification. If you have some comments on this in the line of the 
> discussion we are having, please let us know. I shall wait for your 
> views before submitting the updated version. 
> 
> Anyway, a separate draft (or, possibly, an updated groupcomm RFC?) 
> is a good idea. No-Response assumes the usual request/response 
> symantics and it mainly addresses the client side behaviour and 
> issues. Considering such special behaviour of groupcomm servers, it 
> would be good to handle separately. 
> 
> Waiting to hear from you. 
> 
> 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 05/02/2016 03:10:24 AM:
> 
> > From: "Dijk, Esko" <[e-mail]> 
> > To: Abhijan Bhattacharyya <[e-mail]> 
> > Cc: "[e-mail] WG" <[e-mail]>, Nevil Brownlee <rfc-ise@rfc-
> > editor.org> 
> > Date: 05/02/2016 03:10 AM 
> > Subject: RE: Using draft-tcs-coap-no-response-option to *enable* 
responses 
> > 
> > Hello Abhijan, 
> > 
> > > Mandating such server behaviour from the client side will be a bit
> > out-of-sync with the spirit of the specification. 
> > This is not fully clear to me yet … the client does not mandate 
> > anything from the server; it just expresses its interest (0-bits) 
> > and disinterest (1-bits). The server can always not parse the option
> > (elective) or choose not to bother about it. 
> > This does keep the client waiting for a possible response that never
> > comes; but that is the same in the general multicast case : the 
> > client can never know if or when a response will come, the server 
> > MAY always choose to not respond. 
> > 
> > So what I propose is to use the "indication of interest" to specific
> > response classes in a new way; namely to enable certain response 
> > classes that are suppressed by default.  It just happens that the 
> > same Option syntax is very well suited for that purpose. A separate 
> > draft could be written for that perhaps if you think it does not fit
> > in draft-tcs-coap-no-response-option or if it is too late for that. 
> > The we can point to the syntax of the No-Response Option and re-use 
> > it completely. 
> > 
> > regards 
> > Esko 
> > 
> > From: Abhijan Bhattacharyya [mailto:[e-mail]] 
> > Sent: Friday, April 22, 2016 17:17
> > To: Dijk, Esko <[e-mail]>
> > Cc: [e-mail] WG <[e-mail]>; Nevil Brownlee 
<[e-mail]
> >
> > Subject: Re: Using draft-tcs-coap-no-response-option to *enable* 
responses 
> > 
> > Hi Esko, 
> > Thanks for your mail. 
> > First of all let me just bring this to your (as well as the mailing 
> > list's) notice that the latest version of the draft is: 
> > https://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-
> option-16.txt
> > 
> > This version "officially" closes the technical reviews and is with 
> > the RFC editor through the IS track. 
> > 
> > Now coming to your use case (and indeed it is an interesting one) 
> > one thing that we should consider is that the No-Response option was
> > deliberately designed not to mandate anything for the server side 
> > mainly to ensure that it does not disrupt the many usefulness of the
> > usual request/response symantics. The draft all along deals with the
> > requesting client's behaviour and its expression of interest to the 
> > server. Since this option is elective we leave it upto the server 
> > implementation to honour the client's interest. 
> > 
> > Now, as per usual request/response symantics the responses are 
> > always enabled. The behaviour in groupcomm server in terms of 
> > suppressing the responses on its own is something special and, 
> > generally speaking, the clients are not aware of such special 
behaviour. 
> > 
> > So, it would be justified to handle the situation at the server's 
> > end. Here is the idea: 
> > While No-Response is to expresses client's dis-interest in some or 
> > all of the responses depending on the option value, it is also true 
> > that the option automatically expresses interest in all other 
> > responses (marked by 0's in the respective positions). The client is
> > going to wait for these responses upto a given timeout. Now, if the 
> > server behaviour is modified like this : "I have closed my door for 
> > all out going response. **BUT**, if I see a fellow requesting with 
> > No-Response and keeping windows open to some responses then I assume
> > that this guy really needs those kind of responses. In that case let
> > me be linient and let me open the door for such responses. This 
> > fellow must be available to listen to them as per the prescribed 
> > behaviour in the No-Response specification." 
> > 
> > Mandating such server behaviour from the client side will be a bit 
> > out-of-sync with the spirit of the specification. 
> > 
> > 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
> > ____________________________________________
> > 
> > 
> > 
> > 
> > From:        "Dijk, Esko" <[e-mail]> 
> > To:        Abhijan Bhattacharyya <[e-mail]> 
> > Cc:        Nevil Brownlee <[e-mail]>, "[e-mail] WG" 
<
> > [e-mail]> 
> > Date:        04/22/2016 05:43 PM 
> > Subject:        Using draft-tcs-coap-no-response-option to 
> *enable* responses 
> > 
> > 
> > 
> > 
> > Hello Abhijan,
> > 
> > in our project we see a clear use case of using the No-Response 
> > Option to *enable* certain responses that are by default suppressed.
> > CoAP allows suppression of multicast responses by default, which is 
> > what we use for a lighting multicast use case. However for 
> > diagnostic usage we'd like to enable these responses again using the
> > No-Response option which is perfectly suited for that. However, the 
> > draft text currently only talks about suppressing responses (not 
enabling).
> > 
> > Hence my request: could we modify/add some text to show that also 
> > the option can be used to enable responses in case where they are 
> > normally (by default -- server decision) suppressed?
> > Just to clarify such usage; which is quite useful in my view.
> > 
> > regards
> > Esko
> > 
> > ________________________________
> > 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. 
> > =====-----=====-----=====
> > 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.