Skip to content

Commit

Permalink
Editorial
Browse files Browse the repository at this point in the history
  • Loading branch information
marco-tiloca-sics committed Mar 3, 2024
1 parent 2b53eef commit 2819246
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion draft-ietf-core-groupcomm-proxy.md
Original file line number Diff line number Diff line change
Expand Up @@ -80,7 +80,7 @@ In particular, the client sends to the proxy a single unicast request, which the

As per {{RFC7252}}, a CoAP-to-CoAP proxy relays those responses to the client as separate CoAP messages, all matching (by Token) with the client's original unicast request. A possible alternative approach for aggregating those responses into a single CoAP response sent to the client would require a specific aggregation content-format, which is not available yet. Both these approaches have open issues.

This document considers the former approach. That is, after forwarding a CoAP group request from the client to the group of CoAP servers, the proxy relays the individual responses back to the client as separate CoAP messages. The described method addresses all the related issues raised in {{Section 3.5 of I-D.ietf-core-groupcomm-bis}}. To this end, a dedicated signaling protocol is defined, using two new CoAP options.
This document considers the former approach. That is, after forwarding a CoAP group request from the client to the group of CoAP servers, the proxy relays the individual responses back to the client as separate CoAP messages. The described method addresses all the related issues raised in {{Section 3.5 of I-D.ietf-core-groupcomm-bis}}. To this end, this document defines a dedicated signaling protocol based on two new CoAP options and used by the client and the proxy.

Using this protocol, the client explicitly confirms its intent to perform a proxied group request and its support for receiving multiple responses as a result, i.e., one or more from each origin server. Also, the client signals for how long it is willing to wait for responses. When relaying to the client a response to the group request, the proxy indicates the addressing information of the origin server. This enables the client to distinguish multiple different responses by origin and to possibly contact one or more of the respective servers by sending individual unicast request(s) to the indicated address(es). In doing these follow-up unicast requests, the client may optionally bypass the proxy.

Expand Down

0 comments on commit 2819246

Please sign in to comment.