From 28192463c3a1c9ffb5b4ecec4ba5363cf41bab2e Mon Sep 17 00:00:00 2001 From: crimson Date: Sun, 3 Mar 2024 10:42:39 +0100 Subject: [PATCH] Editorial --- draft-ietf-core-groupcomm-proxy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-core-groupcomm-proxy.md b/draft-ietf-core-groupcomm-proxy.md index 11ff1c2..d6ca70a 100644 --- a/draft-ietf-core-groupcomm-proxy.md +++ b/draft-ietf-core-groupcomm-proxy.md @@ -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.