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

[Abhijan Bhattacharyya <[e-mail]>]

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