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

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

Hello Abhijan,

Agreed; below a proposed updated text that separates the example from the specification part. The number of MUSTs is also reduced to two. (Might be even reduced to one – only the first, but leaving that to the editing process… I think an example typically does not have a MUST)

---
The server MUST send back responses of the classes for which the client has not expressed any disinterest. There are instances where a server, on its own, decides to suppress responses like the multicast servers described in Section 2.7 of  [RFC7390]. If such a server receives a request with a No-Response Option showing interest in specific response classes, then any default behaviour of suppressing responses – if present – MUST be overridden to deliver those responses which are of interest to the client.

So, for example, if a multicast server suppresses all responses by default and receives a request with a No-Response Option expressing disinterest in 2.xx success responses, and interest in error responses 4.xx/5.xx, then the server must send back a response if the concerned request caused an error.
---

regards,
Esko

From: Abhijan Bhattacharyya [mailto:[e-mail]]
Sent: Tuesday, May 03, 2016 21:53
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 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]<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 05/03/2016 01:25:01 AM:

> From: "Dijk, Esko" <[e-mail]<mailto:[e-mail]>>
> To: Abhijan Bhattacharyya <[e-mail]<mailto:[e-mail]>>
> Cc: "[e-mail] WG<mailto:[e-mail]%20WG>" <[e-mail]<mailto:[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]<mailto:[e-mail]>>
> Cc: [e-mail]<mailto:[e-mail]> WG <[e-mail]<mailto:[e-mail]>>; Nevil Brownlee <[e-mail]<mailto:[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]<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 05/02/2016 03:10:24 AM:
>
> > From: "Dijk, Esko" <[e-mail]<mailto:[e-mail]>>
> > To: Abhijan Bhattacharyya <[e-mail]<mailto:[e-mail]>>
> > Cc: "[e-mail] WG<mailto:[e-mail]%20WG>" <[e-mail]<mailto:[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]<mailto:[e-mail]>>
> > Cc: [e-mail]<mailto:[e-mail]> WG <[e-mail]<mailto:[e-mail]>>; Nevil Brownlee <[e-mail]
<mailto:[e-mail]%0b>> >
> > 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]<mailto:[e-mail]>
> > Website: http://www.tcs.com<http://www.tcs.com/>
> > ____________________________________________
> > Experience certainty.        IT Services
> >                        Business Solutions
> >                        Consulting
> > ____________________________________________
> >
> >
> >
> >
> > From:        "Dijk, Esko" <[e-mail]<mailto:[e-mail]>>
> > To:        Abhijan Bhattacharyya <[e-mail]<mailto:[e-mail]>>
> > Cc:        Nevil Brownlee <[e-mail]<mailto:[e-mail]>>, "[e-mail] WG<mailto:[e-mail]%20WG>" <
> > [e-mail]<mailto:[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.

________________________________
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.