Re: [core] RFC 7967 (No-Response) together with block-wise transfers in CoAP

Hi Fredrik,

I’m not sure I entirely understand the message exchanges you envision; maybe you can provide an example.

RFC 7967 has a way to suppress responses based on the response code.
Unfortunately, the granularity is on the class only at the moment.
The option that carries this information isn’t explicitly defined as an extension point.  Still, someone (the original author?  The WG?) might want to go ahead, e.g., by defining a bit in the option value that says “Not interested in 2.31 responses”.  (Maybe we want to understand what exactly a client would not be interested in a bit more before we go ahead allocating bits like this.)

Abhijan, what do you think?

Grüße, Carsten

> On Jun 26, 2019, at 13:30, Fredrik Wegelid <fredrik.wegelid@wittra.se> wrote:
> 
> Hi,
> 
> I hope that I am using this email list in the correct way. I apologise if that is not the case.
> I have some questions/thoughts about using the No-Response option (RFC 7967) together with block-wise transfers in COAP.
> 
> In my team we are using CoAP to send messages from devices to a server. The messages are of such a size that we need to make block-wise transfers. In an attempt to reduce the amount of traffic in the network we have looked at using the No-Response option. We are however not clear on how this would work if used together with block-wise transfers. We would like to use the No-Response option to make the server omit the 2.31 Continue responses from the server on each block. We would however still like to be able to get a response on the last block to indicate the status of the entire block sequence. 
> 
> Does this make sense? In RFC 7967 block-wise transfers are not mentioned. Are they meant to be used together?
> 
> Best regards,
> Fredrik Wegelid
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
> 