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

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

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]<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