Re: [core] #177: Response suppression for multicast not defined

[Carsten Bormann <[e-mail]>]

On Mar 15, 2012, at 10:53, Dijk, Esko wrote:

> What is not explicit in core-coap is how a CoAP proxy sends multicast responses back to a client (that used the Proxy-URI option), and hence what a client should expect to get back from the proxy. Maybe the general idea is obvious: proxy does not perform any processing/filtering/aggregation but sends back the individual responses to the client.

I don't think we want to constrain what intermediaries do here before gaining more experience with this.

> One remaining question; what if a client sends a unicast CON request to a CoAP proxy containing the Proxy-URI option, and then receives from the proxy multiple responses resulting from the CoAP multicast. Would it get NON responses from the proxy, or CON, or is that up to the implementation?

Right.  Again, we have not constrained it, and I think that is the right decision.

> NON would be preferable for congestion control reasons

Actually, (at least partially using) CON would enable getting some congestion control feedback.  With NON, you send into thin air.

> but this is not explicitly mandated by core-coap. CON would be logical if the aim of the proxy is to reply CON to a CON proxy-request following section 5.2.3. It could also be left as an implementation decision. (Without any extra guiding text, my guess would be that it becomes implementation-specific behavior.)

Yes, and I think at this stage that is fine.

Grüße, Carsten