Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

[Jim Schaad <[e-mail]>]

-----Original Message-----
From: Klaus Hartke <[e-mail]> 
Sent: Tuesday, March 31, 2020 4:46 AM
To: Esko Dijk <[e-mail]>
Cc: Achim Kraus <[e-mail]>; Jim Schaad <[e-mail]>; [e-mail]
Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

Esko Dijk wrote:
> However CoAP does define that a Server responds from the same endpoint that received the request, I believe. See below text quotes and analysis.

Yes. In the simple CoAP-over-UDP unicast NoSec case, if a request message is sent from an endpoint 192.168.0.1:54321 ("client") to an endpoint 192.168.0.100:5683 ("server"), the response message must be sent from the endpoint 192.168.0.100:5683 to the endpoint 192.168.0.1:54321.

The response message cannot be sent from any other endpoint, because then the client couldn't match the incoming message to its pending request (it would appear to come from a different server). The response message also cannot be sent to any other endpoint, because then the client wouldn't get the message (it would be sent to a different client).

I view multicast messages basically like e-mail mailing lists. E.g.
(IMO): A request message is sent from the endpoint 192.168.0.1:54321 to the special endpoint 224.0.1.187:9999, the message magically shows up as incoming message at the endpoint 192.168.0.100:5683, and the response message must be sent from the endpoint 192.168.0.100:5683 to the endpoint 192.168.0.1:54321.

[JLS] What he said.  And then after the first message comes in from 192.168.0.100:5683, all of the messages from that endpoint are correlated together so that you can do things like blockwise.

Klaus