Proxy Operations in Group Communication for the Constrained Application Protocol (CoAP)

Proxy Operations in Group Communication for the Constrained Application Protocol (CoAP) RISE AB

Isafjordsgatan 22 Kista 164 40 Sweden marco.tiloca@ri.se

IoTconsultancy.nl

Utrecht The Netherlands esko.dijk@iotconsultancy.nl

CoRE Working Group Internet-Draft This document defines a specific realization of proxy intended for scenarios that use group communication for the Constrained Application Protocol (CoAP). Such a proxy processes a single request sent by a client typically over unicast and distributes the request to a group of servers, e.g., over UDP/IP multicast as the defined default transport protocol. Then, the proxy collects the individual responses from those servers and relays those responses back to the client, in a way that allows the client to distinguish the responses and their origin servers through embedded addressing information. This document updates RFC7252 with respect to caching of response messages at proxies. Discussion Venues Discussion of this document takes place on the Constrained RESTful Environments Working Group mailing list (core@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction The Constrained Application Protocol (CoAP) allows the presence of proxies, as intermediary entities supporting clients by performing requests on their behalf and relaying back responses. CoAP supports group communication , e.g., over UDP and IP multicast, so that a group request can be addressed to multiple recipient servers, each of which may reply with an individual unicast response. As discussed in Sections and of , this group communication scenario poses a number of issues and limitations to proxy operations. In particular, the client typically sends to the proxy a single unicast request, which the proxy forwards to a group of CoAP servers, e.g., using UDP/IP multicast as the defined default transport protocol for CoAP group requests (see ). Later on, the proxy replies to the client's original unicast request, by relaying back the responses from the servers. As per , a CoAP-to-CoAP proxy relays those responses to the client as separate CoAP messages, all matching (by Token value) 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 pose issues. This document takes the former approach and accordingly defines a specific realization of proxy intended for scenarios that use group communication for CoAP. 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 defined realization of proxy addresses all the related issues raised in Sections and of . To this end, this document specifies a dedicated signaling protocol based on two new CoAP options, which is used by the client and the proxy. By using this protocol, the client explicitly confirms its intent to have a group request proxied and its support for receiving multiple responses as a result, i.e., one or more from each origin server. Also, the client indicates for how long it is willing to wait for those responses. When relaying to the client a response to the group request, the proxy indicates addressing information pertaining to 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 requests to the indicated addresses. In doing these follow-up unicast requests, the client can optionally bypass the proxy. Like , this document refers to UDP/IP multicast as the transport protocol that a proxy uses to forward a CoAP group request to a group of servers. While other transport protocols such as broadcast, non-IP multicast, and geocast can also be possible to employ, their use is not considered in this document. This document also defines how the proposed protocol is used between an HTTP client and an HTTP-to-CoAP cross-proxy, in order to forward an HTTP group request from the client to a group of CoAP servers and relay back the individual CoAP responses as HTTP responses. Finally, this document defines a caching model for proxies and specifies how they can serve a group request by using cached responses. Therefore, this document updates .

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Readers are expected to be familiar with the terms and concepts from the following specifications:

CoAP and group communication for CoAP .
Object Security for Constrained RESTful Environments (OSCORE) and Group Object Security for Constrained RESTful Environments (Group OSCORE) .
Concise Data Definition Language (CDDL) , Concise Binary Object Representation (CBOR) , and CBOR sequences
Constrained Resource Identifiers (CRIs) .

Unless specified otherwise, the term "proxy" refers to a CoAP-to-CoAP forward-proxy, as defined in . This document also uses the following terminology.

Individual request: a request that an origin client sends to a single origin server within a group, either directly or instead indirectly via a proxy.

The Multicast-Timeout Option The Multicast-Timeout Option defined in this section has the properties summarized in , which extends Table 4 of . The Multicast-Timeout Option is elective, unsafe to forward, and not repeatable. Since the option is not Safe-to-Forward, the column "N" indicates a dash for "not applicable". The value of the Multicast-Timeout Option specifies a timeout value in seconds, encoded as an unsigned integer (see ). The Multicast-Timeout Option. C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable

No.	C	U	N	R	Name	Format	Length	Default
TBD2		x	-		Multicast-Timeout	uint	0-4	(none)

Note to RFC Editor: Please replace "TBD2" in with the assigned option number. Then please delete this paragraph. This document specifically defines how a client uses this option in a CoAP request, in order to indicate to a proxy its support for and interest in receiving multiple responses to a proxied CoAP group request (i.e., one or more responses from each origin server) and for how long it is willing to wait for receiving those responses via that proxy (see and ). When sending a CoAP group request to a proxy via IP unicast, to be forwarded by the proxy to a targeted group of servers, the client includes the Multicast-Timeout Option in the request. The option value indicates after how much time in seconds the client will stop accepting responses matching its original unicast request, with the exception of notifications if the CoAP Observe Option is used in the same request. This allows the proxy to stop relaying responses back to the client, if those are received from servers after the indicated amount of time has elapsed. The Multicast-Timeout Option is of class U in terms of OSCORE processing (see ).

The Reply-From Option The Reply-From Option defined in this section has the properties summarized in , which extends Table 4 of . The option is intended only for inclusion in CoAP responses and builds on the Base-Uri Option from . The Reply-From Option is elective, safe to forward, and not repeatable. Since the option is intended only for responses, the column "N" indicates a dash for "not applicable". The Reply-From Option. C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable, (*) See below

No.	C	U	N	R	Name	Format	Length	Default
TBD248			-		Reply-From	(*)	5-1034	(none)

Note to RFC Editor: Please replace "TBD248" in with the assigned option number. Then please delete this paragraph. This document specifically defines how this option is used by a proxy that can perform proxied CoAP group requests. Upon receiving a response to such a request from an origin server, the proxy includes the Reply-From Option in the response sent to the origin client (see ). The proxy uses the option to indicate addressing information pertaining to that origin server, which the client can use in order to send an individual request intended to that server. In particular, the client can use the addressing information specified in the option in order to identify the response originator and to possibly send it individual unicast requests later on, either directly or instead indirectly via the proxy. When used as defined in this document, the option value is set to the byte serialization of a CBOR sequence , which is composed of at most two CBOR arrays.

The first CBOR array is REQUIRED and specifies a CRI . In particular, both 'scheme' and 'authority' are given, while 'path', 'query', and 'fragment' are not given.
The second CBOR array is OPTIONAL and specifies a CRI reference . In particular, 'scheme' is set to null (0xf6), at least one of 'authority' and 'path' is given, and both 'query' and 'fragment' are not given. If 'authority' is given in this CRI reference, then the CRI specified by the first CBOR array MUST NOT have 'host' of the form host-name within 'authority'. This CRI reference is relevant in some scenarios where the proxy is a reverse-proxy (see ).

The detailed use of this option is specified in and when the proxy is a forward-proxy, and in and when the proxy is a reverse-proxy. The Reply-From Option is of class U in terms of OSCORE processing (see ).

Requirements and Objectives In this section, the word "proxy" is not limited to forward-proxies. Instead, it comprises also reverse-proxies and HTTP-to-CoAP proxies. This document assumes that the following requirements are fulfilled.

REQ1. The proxy is explicitly configured with an allow-list for performing proxied group requests on behalf of specific allowed clients.
REQ2. The proxy MUST identify a client sending a unicast group request to be proxied, in order to verify whether the client is allowed-listed to do so. For example, this can rely on one of the following security associations.
- A TLS or DTLS channel between the client and the proxy, where the client has been authenticated during the secure channel establishment.
- A pairwise OSCORE Security Context between the client and the proxy, as defined in .
REQ3. If end-to-end secure communication is required between the client and the servers in the CoAP group, exchanged messages MUST be protected by using Group OSCORE , as discussed in Sections and of . This requires the client and the servers to have previously joined the correct OSCORE group, for instance by using the approach described in . The correct OSCORE group to join can be pre-configured or alternatively discovered, for instance by using the approach described in .

This document defines how to achieve the following objectives.

OBJ1. The proxy gets an indication from the client that the client is in fact interested in multiple responses to a proxied group request and is capable to handle those. With particular reference to a unicast CoAP group request sent to the proxy, this means that the client is capable to receive those responses as separate CoAP responses, each matching with the original unicast request.
OBJ2. The proxy learns for how long it should wait for responses to a proxied group request, before starting to ignore following responses to it (except for notifications, if a CoAP Observe Option is used ).
OBJ3. The proxy relays to the client any multiple responses to the proxied group request. With particular reference to a client's original CoAP unicast request sent to the proxy, the corresponding responses are sent to the client as separate CoAP responses, each matching with the original unicast request.
OBJ4. The client is able to distinguish the different responses to the proxied group request, as well as their corresponding origin servers.
OBJ5. The client is enabled to optionally contact one or more of the responding origin servers, either directly or via the proxy.

Protocol Description This section specifies the steps of the signaling protocol.

Request Sending at the Client This section defines the operations performed by the client, for sending a request targeting a group of servers via the proxy.

Request Sending The client proceeds according to the following steps.

The client prepares a unicast CoAP group request addressed to the proxy and specifies the group URI where the request has to be forwarded to. The client can specify the group URI as a string in the Proxy-Uri Option, or by using the Proxy-Scheme Option together with the Uri-* options (see ). Alternatively, the client can rely on the analogous options defined in , i.e., the Proxy-Cri Option conveying a CRI equivalent to the group URI, or the Proxy-Scheme-Number Option together with the Uri-* options. When applicable, the client can specify the URI path of the group URI by using the Uri-Path-Abbrev Option , consistent with the restrictions defined in .
The client MUST retain the Token value used for this original unicast request beyond the reception of a first CoAP response matching with the request. To this end, the client follows the same rules for Token retention that are defined for multicast CoAP requests in . In particular, the client picks an amount of time T that it is fine to wait for before freeing up the Token value. Specifically, the value of T MUST be such that:
- T < T_r , where T_r is the amount of time that the client is fine to wait for before potentially reusing the Token value. Specifically, T_r MUST NOT be less than MIN_TOKEN_REUSE_TIME defined in .
- T should be at least the expected worst-case amount of time taken by the request and response processing on the proxy and on the servers in the addressed CoAP group.
- T should be at least the expected worst-case round-trip delay between the client and the proxy plus the worst-case round-trip delay between the proxy and any of the origin servers.
The client MUST include the Multicast-Timeout Option defined in in the unicast request to send to the proxy. The option value specifies an amount of time T' < T. The difference (T - T') should be at least the expected worst-case round-trip time between the client and the proxy. The client can specify T' = 0 as option value, thus indicating to be not interested in receiving responses from the origin servers through the proxy. As per , the option value 0 is represented with an empty option value (a zero-length sequence of bytes). In such a case, the client SHOULD also include a No-Response Option with value 26 (suppress all response codes), if it supports that option. If the unicast request to send to the proxy was already intended to include a No-Response Option with value 26, the client SHOULD specify T' = 0 as value of the Multicast-Timeout Option.
The client processes the request as defined in and also as in when secure group communication is used between the client and the servers.
The client sends the request to the proxy as a unicast CoAP message. When doing so, the client protects the request according to the security association that it has with the proxy.

The exact method that the client uses to estimate the worst-case processing times and round-trip delays mentioned above is out of the scope of this document. However, such a method is expected to be already used by the client when generally determining an appropriate Token lifetime and reuse interval.

Supporting Observe When using CoAP Observe , the client follows what is specified in , with the difference that it sends a unicast request to the proxy, to be forwarded to the group of servers as defined in of this document. Furthermore, the client especially follows what is specified in , i.e., it registers its interest to be an observer with the proxy, as if it was communicating with the servers.

Cancellation of Ongoing Response Forwarding After having sent the unicast request to the proxy but before timeout expiration, the client might become not interested in receiving further corresponding responses, i.e., from that point in time until T seconds have elapsed since the request was sent to the proxy. In such a case, the client MAY ask the proxy for an early stop of the ongoing response forwarding, i.e., to not forward to the client any further response received from the servers as a reply to the forwarded group request. To this end, the client can rely on one of the following two approaches:

The client acts like it would at timeout expiration (see ), i.e., it simply frees up its local Token value associated with the original unicast request sent to the proxy. Consequently, further responses forwarded by the proxy would result in the client sending a CoAP Reset message (RST), which the proxy would interpret as a loss of interest from the client. While this approach would work when using CoAP over UDP between the client and the proxy, it might not be suitable if a different transport is used instead.
The client sends to the proxy a new CoAP unicast request, namely Early Stop Request, such that:
- It MUST use the request method GET.
- It MUST use the same Token value of the original unicast request sent to the proxy. This explicitly relates the present Early Stop Request to the original unicast request.
- It MUST include the Multicast-Timeout Option, specifying 0 as option value. As per , the option value 0 is represented with an empty option value (a zero-length sequence of bytes). This explicitly indicates the client's wish to stop receiving further responses to the original unicast request.
- It MUST NOT include any of the following: the Proxy-Uri Option or the Proxy-Cri Option; the Proxy-Scheme Option or the Proxy-Scheme-Number Option, together with the Uri-* options (also comprising the Uri-Path-Abbrev Option ). This explicitly indicates the proxy to not forward the Early Stop Request.
After sending the Early Stop Request, the client frees up its local Token value associated with the original unicast request sent to the proxy.

Note that, irrespective of the approach used by the client, freeing up the Token value does not make it eligible for possible reuse yet (see ).

Request Processing at the Proxy This section defines the operations performed by the proxy, when receiving a request to forward to a group of servers.

Request Processing Upon receiving the request from the client, the proxy proceeds according to the following steps.

The proxy decrypts and verifies the request, according to the security association that it has with the client.
The proxy identifies the client and verifies that the client is in fact allowed-listed to have its requests proxied to CoAP group URIs. In particular, the proxy verifies that the client is allowed-listed to have its requests proxied to the group URI specified in the present request. If the verification fails, the proxy MUST stop processing the request and MUST reply to the client with a 4.01 (Unauthorized) response. The proxy protects the response according to the security association that it has with the client.
The proxy verifies the presence of the Multicast-Timeout Option, as a confirmation that the client is fine to receive multiple CoAP responses matching with the same original request. If the Multicast-Timeout Option is not present, the proxy MUST stop processing the request and MUST reply to the client with a 4.00 (Bad Request) response. The proxy protects the response according to the security association that it has with the client. The response MUST include a Multicast-Timeout Option, whose value MUST be set to 0. As per , the option value 0 is represented with an empty option value (a zero-length sequence of bytes). By doing so, the proxy indicates that the Multicast-Timeout Option was missing and has to be included in the request. As per , the response should include a diagnostic payload.
The proxy retrieves the value T' from the Multicast-Timeout Option and then removes the option from the client's request.
The proxy forwards the client's request to the group of servers. In particular, the proxy sends it as a CoAP group request over UDP/IP multicast, addressed to the group URI specified by the client.
The proxy sets a timeout with the value T' retrieved from the Multicast-Timeout Option of the original unicast request. In the case that T' > 0, the proxy will ignore responses to the forwarded group request coming from servers, if received after the timeout expiration, with the exception of Observe notifications (see ). In the case that T' = 0, the proxy will ignore all responses to the forwarded group request coming from servers.

If the proxy supports caching of responses, it can serve the original unicast request also by using cached responses, as per .

Supporting Observe When using CoAP Observe , the proxy takes the role of the client and registers its own interest to observe the target resource with the servers as per . When doing so, the proxy especially follows what is specified for the client in , by forwarding the group request to the servers over UDP/IP multicast as defined in of this document.

Cancellation of Ongoing Response Forwarding As defined in , the client might ask the proxy for an early stop of the ongoing response forwarding, i.e., to stop forwarding to the client any further responses received from the servers as a reply to the forwarded group request. In particular, the proxy stops forwarding such responses to the client, after receiving a CoAP Reset message (RST) in reply to one of such responses, or after receiving an Early Stop Request related to the ongoing response forwarding (i.e., conveying the same Token value of the original unicast request from the client). After that, if the proxy receives further responses to the forwarded group request from the servers, the proxy MUST NOT forward those responses to the client. In fact, the proxy can safely free up its local Token value associated with that group request, which results in discarding any further responses to the same group request received from then on from the servers.

Request and Response Processing at the Server This section defines the operations performed by the server, when receiving a group request from the proxy.

Request and Response Processing Upon receiving the request from the proxy, the server proceeds according to the following steps.

The server processes the group request as defined in and also as in when secure group communication is used between the client and the server.
The server processes the response to be relayed to the client as defined in and also as in when secure group communication is used between the client and the server.

Supporting Observe When using CoAP Observe , the server especially follows what is specified in and .

Response Processing at the Proxy This section defines the operations performed by the proxy, when receiving a response matching with a forwarded group request.

Response Processing Upon receiving a response matching with the group request before the amount of time T' has elapsed (see Step 6 in ), the proxy proceeds according to the following steps.

The proxy MUST include the Reply-From Option defined in in the response. The proxy sets the option value as follows:
- The CRI present as first element of the CBOR sequence specifies the addressing information of the server generating the response.
- The second element of the CBOR sequence MUST NOT be present.
If the proxy supports caching of responses (see ), the proxy MUST include the Reply-From Option in the response before caching the response. This ensures that a response to a group request conveys the addressing information of the origin server that generated the response, also when the response is forwarded to a client as retrieved from the proxy's cache.
The proxy forwards the response back to the client. When doing so, the proxy protects the response according to the security association that it has with the client.

As discussed in , it is possible that the same server replies with multiple responses to the same group request, i.e., conveying the same Token value. As long as the proxy forwards responses to a group request back to the origin client, the proxy MUST follow the steps defined above and forward also such multiple responses "as they come". Upon timeout expiration, i.e., T' seconds after having sent the group request over IP multicast, the proxy frees up its local Token value associated with that request. Thus, following late responses to the same group request will be discarded and not forwarded back to the client.

Supporting Observe When using CoAP Observe , the proxy acts as a client registered with the servers, as described earlier in . Furthermore, the proxy takes the role of a server when forwarding notifications from origin servers back to the client. To this end, the proxy follows what is specified in and , with the following additions.

At Step 1 in , the proxy includes the Reply-From Option in every notification, including non-2.xx notifications resulting in removing the proxy from the list of observers of the origin server.
The proxy frees up its Token value used for a group observation only if, after the timeout expiration, no 2.xx (Success) responses matching with the group request and also including an Observe Option have been received from any origin server. Otherwise, after the timeout expiration and as long as observations are active with servers in the group for the target resource of the group request, notifications from those servers are forwarded back to the client as defined in , and the Token value used for the group observation is not freed during this time.

Finally, the proxy SHOULD regularly verify that the client is still interested in receiving observe notifications for a group observation. To this end, the proxy can rely on the same approach discussed for servers in , with more details available in .

Response Processing at the Client This section defines the operations performed by the client, when receiving a response matching with a request that targeted a group of servers via the proxy.

Response Processing Upon receiving from the proxy a response matching with the original unicast request before the amount of time T has elapsed (see Step 2 in ), the client proceeds according to the following steps.

The client processes the response as defined in . When doing so, the client decrypts and verifies the response according to the security association that it has with the proxy.
If secure group communication is used end-to-end between the client and the servers, the client processes the response resulting at the end of Step 1, as defined in .
The client retrieves the CRI from the value of the Reply-From Option and identifies the origin server whose addressing information is specified by the CRI. This allows the client to distinguish different responses as generated by different origin servers. Optionally, the client can contact one or more of those servers individually, i.e., directly (bypassing the proxy) or instead indirectly (via a proxied unicast request). To this end, the client composes the correct URI for the individual request to the origin server, by using the information specified in the CRI retrieved from the Reply-From Option. In order to individually reach the origin server again through the proxy, the client is not required to support the transport protocol indicated by the CRI and used between the proxy and the origin server. That is, the client uses the transport protocol that it supports and has used before to send the unicast request to the proxy. In particular, the client simply specifies the URI for the individual request in the unicast request to the proxy. To this end, the client can specify the URI as a string in the Proxy-Uri Option, or by using the Proxy-Scheme Option together with the Uri-* options. Alternatively, the client can rely on the analogous options defined in , i.e., on the Proxy-Cri Option conveying a CRI equivalent to the URI, or on the Proxy-Scheme-Number Option together with the Uri-* options. When applicable, the client can specify the URI path for the individual request by using the Uri-Path-Abbrev Option , consistent with the restrictions defined in .

As discussed in , it is possible that the client receives multiple responses to the same group request (i.e., conveying the same Token) from the same origin server. The specific client implementation determines at which layer deduplication of responses is performed, or whether it is necessary in an application at all. If the processing of a response succeeds, then the client delivers the response to the application as usual. Depending on its available context information, the application itself can be in a good position to decide how to handle such responses. Upon the timeout expiration, i.e., T seconds after having sent the original unicast request to the proxy, the client frees up its local Token value associated with that request, except for the case where CoAP Observe is used (see ). Note that, upon this timeout expiration, the Token value is not eligible for possible reuse yet (see ). Thus, until the actual amount of time before enabling Token reuse has elapsed, following late responses to the same request forwarded by the proxy will be discarded, as these are not matching (by Token value) with any active request from the client.

Supporting Observe When using CoAP Observe , the client frees up its Token value only if, after the timeout T expiration, no 2.xx (Success) responses matching with the original unicast request and also including an Observe Option have been received. Instead, if at least one such response has been received, the client continues receiving those notifications as they are forwarded by the proxy, as long as the observation for the target resource of the original unicast request is active.

Example The example in this section refers to the following actors.

One origin client C, with address C_ADDR and port number C_PORT.
One proxy P, with address P_ADDR and port number P_PORT.
Two origin servers S1 and S2, where the server Sx has address Sx_ADDR and port number Sx_PORT.

The origin servers are members of a CoAP group with IP multicast address G_ADDR and port number G_PORT. Also, the origin servers are members of the same application group and share the same resource at /r. The communication between C and P is based on CoAP over UDP, as per . The communication between P and the origin servers is based on CoAP over UDP and IP multicast, as per . Finally, cri'X' denotes a CRI corresponding to the URI X, i.e., a CRI that can be converted to the URI X using the procedure defined in .

Reverse-Proxies The use of reverse-proxies in group communication scenarios is defined in . This section clarifies how the Multicast-Timeout Option is effective also in such a context, in order for:

The proxy to effectively reveal itself as a reverse-proxy to the client.
The client to indicate to the proxy about being aware that it is communicating with a reverse-proxy and for how long it is willing to receive responses to a proxied group request.

This practically addresses the additional issues compared to the case with a forward-proxy, as compiled in . provides examples with a reverse-proxy.

Processing on the Proxy Side If the proxy receives a CoAP request and determines that it should be forwarded to a group of servers over IP multicast, then the proxy performs the steps defined in . In particular, when such a request does not include a Multicast-Timeout Option, the proxy effectively reveals itself as a reverse-proxy, by replying with a 4.00 (Bad Request) response including a Multicast-Timeout Option with value 0 (which is ultimately represented with an empty option value, as per ). The proxy processes the CoAP responses forwarded back to the client as defined in , with the following additions.

As a first possible case, the proxy stands in both for the whole group of servers and for the individual origin servers in the group. That is, the origin client cannot reach the individual servers directly, but only through the proxy. In such a case, within a response forwarded back to the client, the value of the Reply-From Option specifies an addressing information TARGET that is directly associated with the proxy. The addressing information is such that, when receiving a unicast request that has been sent according to what is specified in TARGET, the proxy forwards the request to the origin server that generated the response. In particular, the proxy sets the option value as follows.
- The CRI that is present as the first element of the CBOR sequence specifies an addressing information TARGET_1, such that a unicast request reaches the proxy if it is sent according to TARGET_1.
- A CRI reference MUST be present as the second element of the CBOR sequence if, upon receiving a unicast request that has been sent according to TARGET_1, the proxy forwards the request based on further information than TARGET_1 and relying on what is specified by the options Uri-Host, Uri-Port, and Uri-Path or Uri-Path-Abbrev included in the request. The CRI reference specifies the same information that the proxy expects to be specified in the options Uri-Host, Uri-Port, and Uri-Path or Uri-Path-Abbrev of such a unicast request. Otherwise, the second element of the CBOR sequence MUST NOT be present, in which case the proxy forwards the unicast request solely based on the addressing information TARGET_1 according to which the request has been sent to.
The client will be able to communicate individually with the origin server that generated the response, by sending a follow-up unicast request to the proxy as per the specified addressing information TARGET, according to which the proxy forwards the request to that server. This is further specified in . Examples are provided in and .
As a second possible case, the proxy stands in only for the whole group of servers, but not for the individual servers in the group. That is, the origin client can reach the individual servers directly, without recourse to the proxy. In such a case, within a response forwarded back to the client, the value of the Reply-From Option specifies an addressing information TARGET that is directly associated with the origin server that generated the response. In particular, the proxy sets the option value as follows.
- The CRI present as the first element of the CBOR sequence specifies the addressing information TARGET, such that a unicast request reaches the origin server if sent according to TARGET.
- The second element of the CBOR sequence MUST NOT be present.
The client will be able to use that information for sending a follow-up unicast request directly to that server, i.e., bypassing the proxy. This is further specified in . An example is provided in .

Processing on the Client Side If a client sends a CoAP request intended to a group of servers and is aware of actually communicating with a reverse-proxy, then the client MUST perform the steps defined in . In particular, this results in a request sent to the proxy including a Multicast-Timeout Option. The client processes the CoAP responses forwarded back by the proxy as defined in , with the following differences at Step 3.

If the client wishes to send a follow-up unicast request intended only to the origin server that generated the response, then the client sends such a request according to the addressing information specified by the CRI retrieved from the value of the Reply-From Option. Effectively, the client sends the unicast request either directly to the origin server (in the case that the proxy stands in only for the whole group of servers, but not for the individual servers in the group), or to the proxy (in the case that the proxy stands in for both the whole group of servers and the individual servers in the group). If the value of the Reply-From Option specifies also a CRI reference as the second element of the CBOR sequence, then the client includes the options Uri-Host, Uri-Port, and Uri-Path or Uri-Path-Abbrev in the unicast request, according to what is specified by the corresponding elements of the CRI reference. When doing so, the following applies:
- If 'authority' is given in the CRI reference and it does not include 'port', this in itself MUST NOT result in the client including the Uri-Port Option in the unicast request.
- If the client wants to specify additional path segments that identify a specific resource at the origin server, then the corresponding Uri-Path Options are included in the request after the Uri-Path Options corresponding to the path component of the CRI reference.

Caching A proxy MAY cache responses to a group request, as defined in . In particular, the same rules apply to determine the set of request options used as "Cache-Key" and to determine the max-age values offered for responses served from the cache. A cache entry is associated with one server and stores one response from that server, regardless of whether it is a response to a unicast request or to a group request. The following two types of requests can produce a hit to a cache entry.

A matching request intended to that server, i.e., to the corresponding unicast URI. When the stored response is a response to a unicast request to the server, the unicast URI of the matching request is the same target URI used for the original unicast request. When the stored response is a response to a group request to the CoAP group, the unicast URI of the matching request is the target URI obtained by replacing the authority component of the group URI in the original group request with the transport-layer source address and port number of the response.
A matching group request intended to the CoAP group, i.e., to the corresponding group URI. That is, a matching group request can produce a hit to multiple cache entries, each of which is associated with one of the CoAP servers in the CoAP group. As per the freshness model defined in , the proxy can serve a group request exclusively from its cached responses only when it knows all the CoAP servers that are current members of the CoAP group and it has a valid cache entry for each of those.

When forwarding a GET or FETCH group request to the servers in the CoAP group, the proxy behaves like a CoAP client as defined in , with the following additions:

As discussed in , the proxy can receive multiple responses to the same group request from the same origin server and forwards them back to the origin client "as they come". When this happens, each of such multiple responses is stored in the cache entry associated with the server "as it comes", possibly replacing an already stored response from that server.
As discussed in , when communications in the group are secured with Group OSCORE , additional means are required to enable cacheability of responses at the proxy.

The following subsections define the freshness model and validation model that the proxy uses for cached responses.

Freshness Model The proxy relies on the same freshness model defined in , by taking the role of a CoAP client with respect to the servers in the CoAP group. In particular, when receiving a unicast group request from the client, the proxy MAY serve it by using exclusively cached responses without forwarding the group request to the servers in the CoAP group, but only if both the following conditions hold:

The proxy knows all the CoAP servers that are currently members of the CoAP group for which the group request is intended.
The proxy's cache currently stores a fresh response for each of those CoAP servers.

The specific way that the proxy uses to determine the CoAP servers that are currently members of the target CoAP group is out of scope for this document. As possible examples, the proxy can synchronize with a group manager server; rely on well-known time patterns used by the application or in the network for the addition of new CoAP group members; observe group join requests or IGMP/MLD multicast group join messages, e.g., if the proxy is embedded in a multicast router. When forwarding the group request to the servers, the proxy could have fresh responses stored in its cache for (some of) those servers. In such a case, the proxy uses (also) those cached responses to serve the original unicast group request, as defined below.

The request processing in is extended as follows. After setting the timeout with value T' > 0 at Step 6, the proxy checks whether its cache currently stores fresh responses to the group request. For each of such responses, the proxy compares the residual lifetime L of the corresponding cache entry against the value T'. If a cached response X is such that L < T', then the proxy forwards X back to the client at its earliest convenience. Otherwise, the proxy does not forward X back to the client at the moment, and instead it waits for approaching the timeout expiration as discussed in the next point.
The response processing in is extended as follows. Before the timeout with original value T' > 0 expires and the proxy stops accepting responses to the group request, the proxy checks whether it stores in its cache any fresh response X to the group request such that both the following conditions hold:
- The cache entry E storing X was already existing when the proxy forwarded the group request.
- The proxy has received no response to the forwarded group request from the server associated with E.
Then, the proxy sends back to the client each response X stored in its cache and selected as above, before the timeout expires. Note that, from the forwarding of the group request until the timeout expiration, the proxy still forwards responses to the group request back to the client "as they come" (see ). Also, such responses possibly refresh older responses from the same servers that the proxy has stored in its cache, as defined earlier in .

Validation Model This section defines the revalidation of responses, separately between the proxy and the origin servers as well as between the origin client and the proxy.

Proxy-Servers Revalidation with Unicast Requests The proxy MAY revalidate a cached response by making a GET or FETCH request on the related unicast request URI, i.e., by taking the role of a CoAP client with respect to a server in the CoAP group. As discussed in , this is however not possible for the proxy if communications in the group are secured end-to-end between origin client and origin servers by using Group OSCORE . [ TODO It can be actually possible to enable revalidation of responses between proxy and server, also in this case where Group OSCORE is used end-to-end between client and origin servers. Fundamentally, this requires to define the possible use of the ETag Option also as an outer option for OSCORE. Thus, in addition to the normal inner ETag, a server can add also an outer ETag Option intended to the proxy. Since validation of responses assumes that cacheability of responses is possible in the first place, it would be convenient to define the use of ETag as outer option in . If OSCORE is also used between the proxy and an individual origin server as per , then the outer ETag Option would be seamlessly protected with the OSCORE Security Context shared between the proxy and the origin server. The following text can be used to replace the last paragraph above.
As discussed in , the following applies when Group OSCORE is used to secure communications end-to-end between the origin client and the origin servers in the group.

Additional means are required to enable cacheability of responses at the proxy (see ).
If a cached response included an outer ETag Option intended to the proxy, then the proxy can perform revalidation of the cached response, by making a request to the unicast URI targeting the server, and including outer ETag Option(s). This is possible also in the case that the proxy and the origin server use OSCORE to further protect the exchanged request and response, as defined in . In such a case, the originally outer ETag Option is protected with the OSCORE Security Context shared between the proxy and the origin server, before transferring the message over the communication leg between the proxy and origin server.

]

Proxy-Servers Revalidation with Group Requests When forwarding a group request to the servers in the CoAP group, the proxy MAY revalidate one or more stored responses that it has cached. To this end, the proxy relies on the same validation model defined in and using the ETag Option, by taking the role of a CoAP client with respect to the servers in the CoAP group. As discussed in , this is however not possible for the proxy if communications in the group are secured end-to-end between origin client and origin servers by using Group OSCORE . [ TODO See the notes in . The following text can be used to replace the last paragraph above.
As discussed in , the following applies when Group OSCORE is used to secure communications end-to-end between the origin client and the origin servers in the group.

Additional means are required to enable cacheability of responses at the proxy (see ).
If a cached response included an outer ETag Option intended to the proxy, then the proxy can perform revalidation of the cached response, by making a request to the group URI targeting the CoAP group, and including outer ETag Option(s). This is possible also in the case that the proxy and the origin servers use Group OSCORE to further protect the exchanged request and response, as defined in . In such a case, the originally outer ETag Option is protected with the Group OSCORE Security Context shared between the proxy and the origin server, before transferring the message over the communication leg between the proxy and origin server.

]

Client-Proxy Revalidation with Group Requests A client MAY revalidate the full set of responses to a group request by leveraging the corresponding cache entries at the proxy. To this end, this document defines the new Group-ETag Option. The Group-ETag Option has the properties summarized in , which extends Table 4 of . The Group-ETag Option is elective, safe to forward, part of the Cache-Key, and repeatable. The option is intended for group requests sent to a proxy to be forwarded to the servers in a CoAP group as well as for the associated responses. The Group-ETag Option. C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable

No.	C	U	N	R	Name	Format	Length	Default
TBD24				x	Group-ETag	opaque	1-8	(none)

Note to RFC Editor: Please replace "TBD24" in with the assigned option number. Then please delete this paragraph. The Group-ETag Option has the same properties of the ETag Option defined in . The Group-ETag Option is of class U in terms of OSCORE processing (see ). A proxy MUST NOT provide this form of validation if it is not in a position to serve a group request by using exclusively cached responses, i.e., without sending the group request to the servers in the CoAP group (see ). If the proxy supports this form of response revalidation, the following applies.

The proxy defines J as a joint set including all the cache entries currently storing fresh responses that satisfy a group request. A set J is "complete" if it includes a valid cache entry for each of the CoAP servers that are currently members of the CoAP group.
When the set J becomes "complete", the proxy assigns it an entity-tag value. The proxy MUST update the current entity-tag value, when J is "complete" and one of its cache entry is updated.
When forwarding to the client a 2.05 (Content) response to a GET or FETCH group request, the proxy MAY include one Group-ETag Option, if the set J is "complete". Such a response MUST NOT include more than one Group-ETag Option. The option value specifies the entity-tag value currently associated with the set J.

When sending to the proxy a GET or FETCH request to be forwarded to the servers in the CoAP group, the client MAY include one or more Group-ETag Options. Each option specifies one entity-tag value, as applicable to the set J of cache entries that can be hit by the group request. The proxy MAY perform the following actions, if the group request produces a hit to the cache entry of each CoAP server that is currently a member of the CoAP group, i.e., if the set J associated with the group request is "complete".

The proxy checks whether the current entity-tag value of the set J matches with one of the entity-tag values specified in the Group-ETag Options of the unicast group request from the client.
In the case of a positive match, the proxy replies with a single 2.03 (Valid) response. This response has no payload and MUST include one Group-ETag Option, specifying the current entity-tag value of the set J.

That is, the 2.03 (Valid) response from the proxy indicates to the client that the stored responses identified by the entity-tag given in the response's Group-ETag Option can be reused, after updating each of them as described in . In effect, the client can determine if any of the stored representations from the respective cache entries at the proxy is current, without needing to transfer any of them again.

Caching of End-To-End Protected Responses at Proxies When using Group OSCORE to protect communications end-to-end between a client and multiple servers in the group, it is normally not possible for an intermediary proxy to effectively cache protected responses. In fact, when starting from the same plain CoAP message, different clients generate different protected requests to send on the wire. This prevents different clients to generate potential cache hits and thus makes response caching at the proxy pointless.

Deterministic Requests to Achieve Cacheability For application scenarios that use secure group communication, it is still possible to achieve cacheability of responses at proxies by using the approach defined in , which is based on Deterministic Requests protected with the pairwise mode of Group OSCORE. This approach is limited to group requests that are safe (in the RESTful sense) to process and do not yield side effects at the servers. As for any protected group request, it requires the clients and all the servers in the CoAP group to have already joined the correct OSCORE group. Starting from the same plain CoAP request, this allows different clients in the OSCORE group to deterministically generate the same request protected with Group OSCORE, which is sent to the proxy for being forwarded to the CoAP group. The proxy can now effectively cache the resulting responses from the servers in the CoAP group, since the same plain CoAP request will result again in the same Deterministic Request and thus will produce a cache hit. When the caching of responses protected with Group OSCORE is enabled at the proxy, the same as defined in applies, with respect to cache entries and their lifetimes. Note that different Deterministic Requests result in different cache entries at the proxy. This includes the case where different plain group requests differ only in their set of ETag Options, as defined in . That is, even though the servers would produce the same plain CoAP responses when replying to two different Deterministic Requests, those will result in different protected responses to each respective Deterministic Request, hence in different cache entries at the proxy. Thus, given a plain group request, a client needs to reuse the same set of ETag Options in order to send that group request as a Deterministic Request that can actually produce a cache hit at the proxy. While this would prevent the caching at the proxy from being inefficient and unnecessarily redundant, it would also limit the flexibility of end-to-end response revalidation for a client.

Validation of Responses Response revalidation remains possible end-to-end between the client and the servers in the group, by including inner ETag Options as defined in Sections and of . Furthermore, it remains possible for a client to attempt revalidating responses to a group request from a "complete" set of cache entries at the proxy, by using the Group-ETag Option as defined in . When directly interacting with the servers in the CoAP group to refresh its cache entries, the proxy cannot rely on response revalidation anymore. This applies to the case where the request is addressed to a single server and is sent to the related unicast URI (see ) as well as to the case where the request is a group request addressed to the CoAP group and is sent to the related group URI (see ). [ TODO See the notes in . The following text can be used to replace the last paragraph above.
When directly interacting with the servers in the CoAP group to refresh its cache entries, the proxy also remains able to perform response revalidation. That is, if a cached response included an outer ETag Option intended to the proxy, then the proxy can perform revalidation of the cached response, by making a request to the unicast URI addressed to a single server and sent to the related unicast URI (see ) or a group request addressed to the CoAP group and sent to the related group URI (see ). ]

Chain of Proxies A client may be interested in accessing a resource at a group of origin servers that is reached through a chain of two or more proxies. That is, these proxies are configured into a chain, where each non-last proxy is configured to forward (group) requests to the next hop towards the origin servers. Also, each non-first proxy is configured to forward back responses to the previous hop towards the origin client. This section specifies how the signaling protocol defined in is used in that setting. Except for the last proxy before the origin servers, every other proxy in the chain takes the role of client with respect to the next hop towards the origin servers. Also, every proxy in the chain except the first takes the role of server towards the previous proxy closer to the origin client. Accordingly, possible caching of responses at each proxy works as defined in and . Also, possible revalidation of responses cached at each proxy and based on the Group-ETag Option works as defined in and . The requirements REQ1 and REQ2 defined in MUST be fulfilled for each proxy in the chain. That is, every proxy in the chain has to be explicitly configured with an allow-list that allows proxied group requests from specific senders and MUST identify those senders upon receiving their group request. For the first proxy in the chain, that sender is the origin client. For each other proxy in the chain, that sender is the proxy acting as the previous hop closer to the origin client. In either case, a proxy can identify the sender of a group request by the same means mentioned in .

Request Processing at the Proxy Upon receiving a group request to be forwarded to a CoAP group URI, a proxy proceeds as follows. If the proxy is the last one in the chain, i.e., it is the last hop before the origin servers, the proxy performs the steps defined in , with no modifications. Otherwise, the proxy performs the steps defined in , with the following differences.

At Steps 1-3, "client" refers to the origin client when the proxy is the first one in the chain, or to the proxy acting as the previous hop closer to the origin client otherwise.
At Step 4, the proxy rather performs the following actions.
1. The proxy retrieves the value T' from the Multicast-Timeout Option and does not remove the option.
2. If T' > 0, the proxy picks an amount of time T that it is fine to wait for before freeing up its local Token value to use with the next hop towards the origin servers. To this end, the proxy MUST follow what is defined at Step 2 of for the origin client, with the following differences.
  - T MUST be greater than the retrieved value T', i.e., T' < T.
  - The worst-case message processing time takes into account all the next hops towards the origin servers, as well as the origin servers themselves.
  - The worst-case round-trip delay takes into account all the legs between the proxy and the origin servers.
3. If T' > 0, the proxy replaces the value of the Multicast-Timeout Option with a new value T'', such that:
  - T'' < T. The difference (T - T'') should be at least the expected worst-case round-trip time between the proxy and the next hop towards the origin servers; and
  - T'' < T'. The difference (T' - T'') should be at least the expected worst-case round-trip time between the proxy and the (previous hop closer to the) origin client.
  If the proxy is not able to determine a value T'' that fulfills both the requirements above, the proxy MUST stop processing the request and MUST reply with a 5.05 (Proxying Not Supported) error response to the (previous hop closer to the) origin client. The proxy SHOULD include a Multicast-Timeout Option, set to the minimum value T' that would be acceptable in the Multicast-Timeout Option of a group request to forward. If the proxy is the first one in the chain, then the error response is sent to the origin client. Upon receiving the error response, the origin client MAY send an updated group request to the same first proxy in the chain. In the updated request, the Multicast-Timeout Option SHOULD specify a value T' such that: it is greater than the one specified in the original group request; and it is greater than or equal to the one specified in the error response (if present therein). Otherwise, upon receiving the error response, any other proxy in the chain MAY send an updated group request to the next hop towards the origin servers. In the updated group request, the Multicast-Timeout Option MUST specify a value T' such that: it is greater than the one specified in the previous forwarded request; and it is greater than or equal to the one specified in the error response (if present therein). If the proxy does not send an updated group request, the proxy MUST also send a 5.05 (Proxying Not Supported) error response to the proxy acting as the previous hop closer to the origin client. Like the received one, also this error response SHOULD include a Multicast-Timeout Option, set to the minimum value T' acceptable by the proxy sending the error response.
At Step 5, the proxy forwards the request to the next hop towards the origin servers.
At Step 6, the proxy sets a timeout with the value T' retrieved from the Multicast-Timeout Option of the request received from the (previous hop closer to the) origin client. In the case that T' > 0, the proxy will ignore responses to the forwarded group request coming from the next hop towards the origin servers, if received after the timeout expiration, with the exception of Observe notifications (see ). In the case that T' = 0, the proxy will ignore all responses to the forwarded group request coming from the next hop towards the origin servers.

Supporting Observe When using CoAP Observe , what is defined in applies for the last proxy in the chain, i.e., the last hop before the origin servers. Any other proxy in the chain acts as a client and registers its own interest to observe the target resource with the next hop towards the origin servers, as per .

Cancellation of Ongoing Response Forwarding Consistent with what is described in , a proxy might be asked by the (previous hop closer to the) origin client for an early stop of the ongoing response forwarding. That is, the proxy is asked to stop forwarding to the (previous hop closer to the) origin client any further responses received to the forwarded group request from the (next hop towards the) origin servers. When this happens, the proxy proceeds as described in . Furthermore, if the proxy is not the last one in the chain, the proxy MAY send to the next hop towards the origin servers an Early Stop Request (see ), with the same Token value of the group request that the proxy forwarded to the next hop towards the origin servers.

Response Processing at the Proxy Upon receiving a response matching with the group request before the amount of time T' has elapsed, the proxy proceeds as follows. If the proxy is the last one in the chain, i.e., it is the last hop before the origin servers, the proxy performs the steps defined in if it is a forward-proxy or in if it is a reverse-proxy, with no modifications. Otherwise, the proxy performs the steps defined in , with the following differences.

In any of the two following cases, the proxy skips Step 1, hence the proxy MUST NOT remove, alter, or replace the Reply-From Option.
- The chain is composed of forward-proxies.
- The chain is composed of reverse-proxies and the last reverse-proxy (in fact, the whole chain) stands in only for the whole group of servers, but not for the individual servers in the group (see ).
This ensures that, when receiving a response to a group request and consuming the Reply-From Option, the origin client can retrieve addressing information that is directly associated with the origin server that generated the response.
At Step 1, the following applies if the chain is composed of reverse-proxies and, at the same time, the last reverse-proxy (in fact, the whole chain) stands in both for the whole group of servers and for the individual origin servers in the group (see ). In the Reply-From Option, the proxy MUST replace the old option value TARGET_OLD. The new option value TARGET_NEW specifies addressing information directly associated with the proxy. The new option value is such that, when receiving a unicast request that has been sent according to what is specified in TARGET_NEW, the proxy forwards the request according to what was specified in TARGET_OLD, i.e., to the next hop towards the origin server that generated the response. This ensures that, when receiving a response to a group request and consuming the Reply-From Option, the origin client can retrieve addressing information that is directly associated with the first reverse-proxy in the chain, i.e., with the next hop towards the origin server that generated the response.
At Step 2, "client" refers to the origin client when the proxy is the first one in the chain, or to the proxy acting as the previous hop closer to the origin client otherwise.

As to the possible reception of multiple responses to the same group request from the same (next hop towards the) origin server, the same as defined in applies. That is, as long as the proxy forwards responses to a group request back to the (previous hop closer to the) origin client, the proxy MUST follow the steps above and forward also such multiple responses "as they come". Upon timeout expiration, i.e., T' seconds after having forwarded the group request to the next hop towards the origin servers, the proxy frees up its local Token value associated with that request. Thus, following late responses to the same group request will be discarded and not forwarded back to the (previous hop closer to the) origin client.

Supporting Observe When using CoAP Observe , what is defined in applies for the last proxy in the chain, i.e., the last hop before the origin servers. As to any other proxy in the chain, the following applies.

The proxy acts as a client registered with the next hop towards the origin servers, as described earlier in .
The proxy takes the role of a server when forwarding notifications from the next hop towards the origin servers back to the (previous hop closer to the) origin client, as per .
The proxy frees up its Token value used for a group observation only if, after the timeout expiration, no 2.xx (Success) responses matching with the group request and also including an Observe Option have been received from the next hop towards the origin servers. Otherwise, after the timeout expiration and as long as the observation for the target resource of the group request is active with the next hop towards the origin servers in the group, notifications from that hop are forwarded back to the (previous hop closer to the) origin client, as defined in .
The proxy SHOULD regularly verify that the (previous hop closer to the) origin client is still interested in receiving observe notifications for a group observation. To this end, the proxy can rely on the same approach defined in .

HTTP-to-CoAP Proxies This section defines the components needed to use the signaling protocol specified in this document, when an HTTP client wishes to send a group request to the servers of a CoAP group via an HTTP-to-CoAP cross-proxy. The following builds on the mapping of the CoAP request/response model to HTTP and vice versa as defined in , as well as on the additional details about the HTTP-to-CoAP mapping defined in . Furthermore, the components defined in are used to map and transport OSCORE-protected messages over HTTP. This allows an HTTP client to use Group OSCORE end-to-end with the servers in the CoAP group.

The HTTP Multicast-Timeout Header Field The HTTP Multicast-Timeout header field (see ) is used for carrying the information that is normally specified in the CoAP Multicast-Timeout Option defined in . Using the Augmented Backus-Naur Form (ABNF) notation of and including the core ABNF syntax rule DIGIT (decimal digits) defined by that specification, the HTTP Multicast-Timeout header field value is as follows. Multicast-Timeout = *DIGIT The empty header field is equivalent to the header field conveying the value 0. When translating a CoAP message into an HTTP message, the HTTP Multicast-Timeout header field is set with the value of the CoAP Multicast-Timeout Option, or is left empty if the option is empty. When translating an HTTP message into a CoAP message, the CoAP Multicast-Timeout Option is set with the content of the HTTP Multicast-Timeout header field, or is left empty if the header field is empty.

The HTTP Reply-From Header Field The HTTP Reply-From header field (see ) is used for carrying the information that is normally specified in the CoAP Reply-From Option defined in . Its use is intended only for HTTP responses. Reply-From is a List Structured Header Field . The List MUST be composed of exactly one or two members. Each member of the List MUST be a Byte Sequence Item. Any deviation from such format MUST cause the entire header field to be ignored. The value of the header field specifies addressing information pertaining to the origin server that generated the CoAP response corresponding to the HTTP response. The client can use this information in order to send an individual request intended to that server. When translating a CoAP message into an HTTP message, the value of the HTTP Reply-From header field is built as follows.

The first Byte Sequence Item encodes the byte serialization of the first CBOR array of the CBOR sequence that is specified as the value of the CoAP Reply-From Option.
The second Byte Sequence Item encodes the byte serialization of the second CBOR array (if present) of the CBOR sequence that is specified as the value of the CoAP Reply-From Option. If the CBOR sequence specified in the value of the CoAP Reply-From Option does not include the second CBOR array, then this Byte Sequence Item MUST NOT be included in the List of the HTTP Reply-From header field.

When translating an HTTP message into a CoAP message, the value of the CoAP Reply-From Option is built as follows.

The first CBOR array of the CBOR sequence is obtained by decoding the first Byte Sequence Item in the List that is specified as the value of the HTTP Reply-From header field.
The second CBOR array of the CBOR sequence is obtained by decoding the second Byte Sequence Item (if present) in the List that is specified as the value of the HTTP Reply-From header field. If the List of the HTTP Reply-From header field does not include the second Byte Sequence Item, then this second CBOR array MUST NOT be included in the CBOR sequence specified in the value of the CoAP Reply-From Option.

The HTTP Group-ETag Header Field The HTTP Group-ETag header field (see ) is used for carrying the information that is normally specified in the CoAP Group-ETag Option defined in . Group-ETag is a List Structured Header Field . The List MUST be composed of one or more members in HTTP requests and by exactly one member in HTTP responses. Each member of the List MUST be a Byte Sequence Item. Any deviation from such format MUST cause the entire header field to be ignored. The value of the header field specifies a set of entity-tag values, each of which is associated with a set of cache entries at the proxy that can be hit by a group request (see ). When translating a CoAP message into an HTTP message, the value of the HTTP Group-ETag header field is built as follows.

When translating a CoAP request to an HTTP request, the List of the HTTP Group-ETag header field MUST include N members, where N is the number of CoAP Group-ETag Options in the CoAP request. The i-th member of the List encodes the value specified in the i-th CoAP Group-ETag Option in the CoAP request.
When translating a CoAP response to an HTTP response, the List of the HTTP Group-ETag header field MUST include one member, which encodes the value specified in the CoAP Group-ETag Option in the CoAP response.

When translating an HTTP message into a CoAP message, the value of the CoAP Group-ETag Options is built as follows.

When translating an HTTP request to a CoAP request, N CoAP Group-ETag Options are included in the CoAP request, where N is the number of members of the List of the HTTP Group-ETag header field. The value of the i-th CoAP Group-ETag Option is obtained by decoding the i-th member of the List of the HTTP Group-ETag header field.
When translating an HTTP response to a CoAP response, one CoAP Group-ETag Option is included in the CoAP response. The value of the CoAP Group-ETag Option is obtained by decoding the only member of the List of the HTTP Group-ETag header field.

When sending to the HTTP-to-CoAP proxy an HTTP GET request to be translated into a CoAP GET request intended to the CoAP group, the client MAY include one HTTP Group-ETag header field in the request. The field value is a list of one or more members, each of which encodes one entity-tag value that is applicable to the set J of cache entries that can be hit by the request (see ). An HTTP-to-CoAP proxy that performs the form of validation defined in proceeds like defined in for a CoAP-to-CoAP proxy, with the following differences.

When sending to the client an HTTP 200 (OK) response to an HTTP GET request that was translated into a CoAP GET request sent to the CoAP group, the proxy MAY include one HTTP Group-ETag header field in the response, if the set J is "complete". The field value is a List composed of one member, which encodes the entity-tag value currently associated with the set J.
When the HTTP-to-CoAP proxy receives an HTTP GET request to be translated into a CoAP GET request intended to the CoAP group and that includes an HTTP Group-ETag header field, the following applies.
- As to the entity-tag values used to check for possible cache hits, the HTTP-to-CoAP proxy obtains those values by decoding the members of the List of the HTTP Group-ETag header field in the HTTP request.
- If the same conditions for which a CoAP-to-CoAP proxy would reply with a single CoAP 2.03 (Valid) response hold, then the HTTP-to-CoAP proxy replies with a single HTTP 304 (Not Modified) response. The response MUST include one HTTP Group-ETag header field whose value is a List composed of one member, which encodes the current entity-tag value of the set J.

An HTTP 304 (Not Modified) response from the HTTP-to-CoAP proxy indicates to the client that it is possible to reuse the stored responses identified by the entity-tag encoded by the only member of the List of the HTTP Group-ETag header field.

Request Sending at the Client The client proceeds according to the following steps.

The client prepares an HTTP request to send to the proxy via IP unicast and to be forwarded by the proxy to the targeted group of CoAP servers over UDP/IP multicast. With reference to , the request is addressed to a Hosting HTTP URI, such that the proxy can extract the Target CoAP URI as the group URI where to forward the request.
The client determines the amount of time T that it is fine to wait for a response to the request from the proxy. Then, the client determines the amount of time T' < T, where the difference (T - T') should be at least the expected worst-case round-trip time between the client and the proxy.
If Group OSCORE is used end-to-end between the client and the servers, the client translates the HTTP request into a CoAP request, as per . Then, the client protects the resulting CoAP request by using Group OSCORE, as defined in . Finally, the protected CoAP request is mapped to HTTP as defined in . Later on, the resulting HTTP request MUST be sent in compliance with the rules in .
The client includes the HTTP Multicast-Timeout header field in the request, specifying T' as its value. The client can specify T' = 0, thus indicating to be not interested in receiving responses from the origin servers through the proxy.
If the client wishes to revalidate responses to a previous group request from the corresponding cache entries at the proxy (see ), the client includes one or multiple HTTP Group-ETag header fields in the request (see ), each specifying an entity-tag value like they would in a corresponding CoAP Group E-Tag Option.
The client sends the request to the proxy, as a unicast HTTP message. In particular, the client protects the request according to the security association that it has with the proxy.

Request Processing at the Proxy The proxy translates the HTTP request to a CoAP request, as per . The additional rules for HTTP messages with the HTTP Multicast-Timeout header field and HTTP Group-ETag header field are defined in and , respectively. Once translated the HTTP request into a CoAP request, the proxy performs the steps defined in . If the proxy supports caching of responses, it can serve the unicast request also by using cached responses as per , considering the CoAP request above as the potentially matching request. In addition, if the HTTP Multicast-Timeout header field had value 0, the proxy replies to the client with an HTTP response with status code 204 (No Content), right after forwarding the group request to the group of servers.

Response Processing at the Proxy Upon receiving a CoAP response matching with the group request before the amount of time T' > 0 has elapsed, the proxy includes the Reply-From Option in the response, as per Step 1 of . Then, the proxy translates the CoAP response to an HTTP response, as per and , as well as if Group OSCORE is used end-to-end between the client and servers. The additional rules for CoAP messages specifying the Reply-From Option are defined in . After that, the proxy stores the resulting HTTP response until the timeout with original value T' > 0 expires. If, before then, the proxy receives another response to the same group request from the same CoAP server, the proxy performs the steps above and stores the resulting HTTP response by replacing the currently stored one from that server. When the timeout expires, if no responses have been received from the servers, the proxy replies to the client's original unicast group request with an HTTP response with status code 204 (No Content). Otherwise, the proxy relays to the client all the collected and stored HTTP responses to the group request, according to the following steps.

The proxy prepares a single HTTP batch response, which MUST have 200 (OK) status code and MUST have its HTTP Content-Type header field with value multipart/mixed .
For each stored individual HTTP response RESP, the proxy prepares a corresponding batch part to include in the HTTP batch response, such that:
- The batch part has its own HTTP Content-Type header field with value application/http .
- The body of the batch part is the individual HTTP response RESP, including its status code, headers, and body.
The proxy includes each batch part prepared at Step 2 in the HTTP batch response.
The proxy replies to the client's original unicast group request, by sending the HTTP batch response. When doing so, the proxy protects the response according to the security association that it has with the client.

Response Processing at the Client When it receives an HTTP response as a reply to the original unicast group request, the client proceeds as follows:

The client decrypts and verifies the response, according to the security association that it has with the proxy.
From the resulting HTTP batch response, the client extracts the different batch parts.
From each of the extracted batch parts, the client extracts the body as one of the individual HTTP response RESP.
For each individual HTTP response RESP, the client performs the following steps: a. If Group OSCORE is used end-to-end between the client and servers, the client translates the HTTP response RESP into a CoAP response, as per . Then, the client decrypts and verifies the resulting CoAP response by using Group OSCORE, as defined in . Finally, the decrypted CoAP response is mapped to HTTP as per as well as . The additional rules for HTTP messages with the HTTP Reply-From header field are defined in . b. The client delivers the individual HTTP response to the application. Similarly to Step 3 in , the client identifies the origin server that originated the CoAP response corresponding to the HTTP response RESP, by means of the addressing information specified as the value of the HTTP Reply-From header field. This allows the client to distinguish different individual HTTP responses as corresponding to different CoAP responses from the servers in the CoAP group.

Example The examples in this section build on , with the difference that the origin client C is an HTTP client and the proxy P is an HTTP-to-CoAP cross-proxy. The examples are simply illustrative and are not to be intended as a test vector. The following is an example of unicast group request sent by C to P. The URI mapping and notation are based on the "Simple Form" defined in . Content-Type: text/plain Multicast-Timeout: 60 Body: Do that! ]]>
The following is an example of HTTP batch response sent by P to C, as a reply to the client's original unicast group request. For readability, base64url(cri'X') denotes the base64url encoding of cri'X' without padding (see ) and cri'X' denotes the byte serialization of a CRI corresponding to the URI X, i.e., of a CRI that can be converted to the URI X using the procedure defined in . Content-Type: multipart/mixed; boundary=batch_foo_bar --batch_foo_bar Content-Type: application/http HTTP/1.1 200 OK Content-Type: text/plain Content-Length: Reply-From: base64url(cri'coap://S1_ADDR:G_PORT') Body: Done! --batch_foo_bar Content-Type: application/http HTTP/1.1 200 OK Content-Type: text/plain Content-Length: Reply-From: base64url(cri'coap://S2_ADDR:S2_PORT') Body: More than done! --batch_foo_bar-- ]]>

Streamed Delivery of Responses to the Client [ TODO The proxy might still be able to forward back individual responses to the client in a streamed fashion. Individual responses can be forwarded back one by one as they come (like a CoAP-to-CoAP proxy does), or as soon as a certain amount of them has been received from the servers. This can be achieved by combining the Content-Type multipart/mixed used in the previous sections with the Transfer-Coding "chunked" specified in RFC 9112. The above applies to HTTP 1.1, while HTTP/2 has its own mechanisms for data streaming. ]

Reverse-Proxies If an HTTP-to-CoAP proxy acts specifically as a reverse-proxy, the same principles defined in apply, as specified in the following subsections.

Processing on the Client Side If an HTTP client sends a request intended to a group of servers and is aware of actually communicating with a reverse-proxy, then the client performs the steps defined in . In particular, this results in a request sent to the proxy and including a Multicast-Timeout header field. The client processes the HTTP response forwarded back by the proxy as defined in . If the client wishes to send a follow-up unicast request intended only for one of the CoAP servers that generated the response, the same concepts defined in apply to the composition of HTTP requests.

Processing on the Proxy Side If the proxy receives a request and determines that the request should be forwarded to a group of servers over UDP/IP multicast, then the same as defined in applies, with the following difference.

Once translated the HTTP request into a CoAP request, the proxy performs what is defined in .

The proxy processes the HTTP response sent to the client as defined in .

Security Considerations The security considerations from , , , and hold for this document. When a chain of proxies is used (see ), the secure communication between any two adjacent hops is independent of that between any other two adjacent hops. When Group OSCORE is used for end-to-end secure group communication between the origin client and the origin servers, this security association is unaffected by the possible presence of a proxy or a chain of proxies. Furthermore, the following additional considerations hold.

Client Authentication As per the requirement REQ2 (see ), the client has to authenticate to the proxy when sending a group request to forward. This leverages an established security association between the client and the proxy, which the client uses to protect the group request before sending it to the proxy. If the group request is also protected end-to-end between the client and the origin servers using the group mode of Group OSCORE, the proxy can act as an external signature checker (see ) and authenticate the client by successfully verifying the signature embedded in the group request. However, this requires the proxy to store, for each client to authenticate, the authentication credential that the client uses in the OSCORE group and the public key included therein, and to also store the authentication credential of the Group Manager responsible for the OSCORE group. This in turn would require a form of active synchronization between the proxy and the Group Manager for that group . Furthermore, when specifically acting as an external signature checker for an OSCORE group, the proxy can leverage its knowledge of the authentication credential of the Group Manager for that group, combined with the IP multicast address where to forward a group request and the Group Identifier of the OSCORE group (i.e., the ID Context specified in the OSCORE Option of the group request). Such combined information enables the proxy to fully identify the OSCORE group that the client is communicating in, which might not be desirable for that specific host acting as a proxy. Conversely, if the proxy does not act as an external signature checker and does not have the authentication credential of the Group Manager, the proxy is not able to fully and unambiguously identify the security group that the client is communicating in. Irrespective of the above, the client and the proxy SHOULD still rely on a full-fledged pairwise secure association. In addition to ensuring the integrity of group requests sent to the proxy (see , , and ), this prevents the proxy from forwarding replayed group requests with a valid signature, as possibly injected by an active, on-path adversary. The same considerations above apply when a chain of proxies is used (see ), with each proxy but the last one in the chain acting as a client with the next hop towards the origin servers.

Multicast-Timeout Option The Multicast-Timeout Option is of class U for OSCORE . Hence, also when Group OSCORE is used between the client and the servers , a proxy is able to access the option value and retrieve the timeout value T', as well as to remove the option altogether before forwarding the group request to the servers. When a chain of proxies is used (see ), this also allows each proxy but the last one in the chain to update the option value, as an indication for the next hop towards the origin servers (see ). The security association between the client and the proxy MUST provide message integrity, so that further intermediaries between the two as well as on-path active adversaries are not able to undetectably remove the option or alter its value, before the group request reaches the proxy. Removing the option would result in not forwarding the group request to the servers. Altering the option value would result in the proxy accepting and forwarding back responses for an amount of time different from the one actually indicated by the client. The security association between the client and the proxy SHOULD also provide message confidentiality. Otherwise, any further intermediaries between the two as well as any on-path passive adversaries would be able to access the option value, thereby learning for how long the client is willing to receive responses from the servers in the group via the proxy. This may in turn be used by an on-path active adversary to perform a more efficient, selective suppression of responses from the servers. When the client protects the unicast request sent to the proxy using OSCORE (see ) and/or (D)TLS, both message integrity and message confidentiality are achieved in the leg between the client and the proxy. The same considerations above about security associations apply when a chain of proxies is used (see ), with each proxy but the last one in the chain acting as a client with the next hop towards the origin servers.

Reply-From Option The Reply-From Option is of class U for OSCORE . Hence, also when Group OSCORE is used between the client and the servers , the proxy that has forwarded the group request to the servers is able to include the option into a response, before forwarding this response back to the (previous hop closer to the) origin client. The security association between the client and the proxy MUST provide message integrity, so that further intermediaries between the two as well as on-path active adversaries are not able to undetectably remove the option from a forwarded response or alter its value. This ensures that the client can correctly distinguish the different responses and identify the corresponding origin servers. The security association between the client and the proxy SHOULD also provide message confidentiality. Otherwise, any further intermediaries between the two as well as any on-path passive adversaries would be able to access the option value, thereby learning the addressing information of servers in the group. This may in turn be used by an on-path active adversary to perform a more efficient, selective suppression of follow-up requests that the client sends to a specific server, either directly or instead indirectly via the proxy. When the proxy protects the response forwarded back to the client using OSCORE (see ) and/or (D)TLS, both message integrity and message confidentiality are achieved in the leg between the client and the proxy. The same considerations above about security associations apply when a chain of proxies is used (see ), with each proxy but the last one in the chain acting as a client with the next hop towards the origin servers.

Group-ETag Option The Group-ETag Option is of class U for OSCORE . Hence, also when Group OSCORE is used between the client and the servers , a proxy is able to access the option value and use it to possibly perform response revalidation at its cache entries associated with the servers in the CoAP group, as well as to remove the option altogether before forwarding the group request to the servers. When a chain of proxies is used (see ), this also allows each proxy but the last one in the chain to update the option value, in order to possibly ask the next hop towards the origin servers to perform response revalidation at its cache entries. The security association between the client and the proxy MUST provide message integrity, so that further intermediaries between the two as well as on-path active adversaries are not able to undetectably remove the option or alter its value, before the group request reaches the proxy. Removing the option would result in the proxy not performing response revalidation at its cache entries associated with the servers in the CoAP group, even though that was what the client asked for. Altering the option value in a group request would result in the proxy performing response revalidation based on different entity-tag values from those actually specified by the client. Consequently, the proxy would erroneously reply with multiple 2.05 (Content) responses conveying the full resource representations from its cache entries instead of with a single 2.03 (Valid) response, or vice versa. Instead, altering the option value in a 2.03 (Valid) or 2.05 (Content) response would result in the client wrongly believing that the already stored or the just received representation, respectively, is also the current one, as per the entity value of the tampered Group-ETag Option. The security association between the client and the proxy SHOULD also provide message confidentiality. Otherwise, any further intermediaries between the two as well as any on-path passive adversaries would be able to access the option value, thereby learning the rate and pattern according to which the group resource in question changes over time, as inferable from the entity values read over time. When the client protects the unicast request sent to the proxy using OSCORE (see ) and/or (D)TLS, both message integrity and message confidentiality are achieved in the leg between the client and the proxy. The same considerations above about security associations apply when a chain of proxies is used (see ), with each proxy but the last one in the chain acting as a client with the next hop towards the origin servers. When the caching of responses protected with Group OSCORE is enabled at the proxy, the same as defined in applies, with respect to cache entries and the way they are maintained.

HTTP-to-CoAP Proxies Consistent with what is discussed in , an HTTP client has to authenticate to the HTTP-to-CoAP proxy and they SHOULD rely on a full-fledged pairwise secure association. This can rely on a TLS channel as also recommended in for when OSCORE is used with HTTP, or on a pairwise OSCORE Security Context shared between the client and the proxy as defined in . [ TODO Revisit security considerations from ]

IANA Considerations This document has the following actions for IANA. Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.

CoAP Option Numbers Registry IANA is asked to enter the following option numbers to the "CoAP Option Numbers" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group. Registrations in the CoAP Option Numbers Registry

Number	Name	Reference
TBD2	Multicast-Timeout	[RFC-XXXX]
TBD248	Reply-From	[RFC-XXXX]
TBD24	Group-ETag	[RFC-XXXX]

Note to RFC Editor: Please replace "TBD2", "TBD248", and "TBD24" in with the assigned option numbers. Then please delete this paragraph and the following text within the present . For all the three requested options, it is preferred to assign an option number from the value range 0-255. For the Multicast-Timeout option, the number suggested to IANA is 2. For the Reply-From option, the number suggested to IANA is 248. For the Group-ETag option, the number suggested to IANA is 24.

Hypertext Transfer Protocol (HTTP) Field Name Registry IANA is asked to enter the following HTTP header fields to the "Hypertext Transfer Protocol (HTTP) Field Name Registry" . Registrations in the Hypertext Transfer Protocol (HTTP) Field Name Registry

Field Name	Status	Structured Type	Reference
Multicast-Timeout	permanent		[RFC-XXXX]
Reply-From	permanent	List	[RFC-XXXX]
Group-ETag	permanent	List	[RFC-XXXX]

References Normative References Group Communication for the Constrained Application Protocol (CoAP) IoTconsultancy.nl RISE AB The Constrained Application Protocol (CoAP) is a web transfer protocol for constrained devices and constrained networks. In a number of use cases, constrained devices often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This document specifies the use of CoAP for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces and obsoletes RFC 7390, while it updates RFC 7252 and RFC 7641. Group Object Security for Constrained RESTful Environments (Group OSCORE) RISE AB Ericsson AB Ericsson AB Ericsson AB RISE AB This document defines the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of messages exchanged with the Constrained Application Protocol (CoAP) between members of a group, e.g., sent over IP multicast. In particular, the described protocol defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. Group OSCORE also defines a pairwise mode where each member of the group can efficiently derive a symmetric pairwise key with each other member of the group for pairwise OSCORE communication. Group OSCORE can be used between endpoints communicating with CoAP or CoAP- mappable HTTP. Constrained Resource Identifiers Universität Bremen TZI Fraunhofer SIT The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that represents the URI components in Concise Binary Object Representation (CBOR) rather than as a sequence of characters. This approach simplifies parsing, comparison, and reference resolution in environments with severe limitations on processing power, code size, and memory size. This RFC updates RFC 7595 by adding a column on the "URI Schemes" registry. // (This "cref" paragraph will be removed by the RFC editor:) After // approval of -28 and nit fixes in -29, the present revision -30 // contains two more small fixes for nits that were uncovered in the // RPC intake process. URI Path abbreviation in CoAP Sandelman Software Works Applications built on CoAP face a conflict between the technical need for short message sizes and the interoperability requirement of following BCP190 and thus using (relatively verbose) well-known URI paths. This document introduces the Uri-Path-Abbrev CoAP option that allows expressing well-known URI paths in as little as two bytes. Using this option revealed a subtle flaw in RFC7252 that severely limited the extension point of critical options. This document updates RFC7252 to rectify that. Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types This second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK] The Base16, Base32, and Base64 Data Encodings This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] Augmented BNF for Syntax Specifications: ABNF Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] The Constrained Application Protocol (CoAP) The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. Observing Resources in the Constrained Application Protocol (CoAP) The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server. Constrained Application Protocol (CoAP) Option for No Server Response There can be machine-to-machine (M2M) scenarios where server responses to client requests are redundant. This kind of open-loop exchange (with no response path from the server to the client) may be desired to minimize resource consumption in constrained systems while updating many resources simultaneously or performing high-frequency updates. CoAP already provides Non-confirmable (NON) messages that are not acknowledged by the recipient. However, the request/response semantics still require the server to respond with a status code indicating "the result of the attempt to understand and satisfy the request", per RFC 7252. This specification introduces a CoAP option called 'No-Response'. Using this option, the client can explicitly express to the server its disinterest in all responses against the particular request. This option also provides granular control to enable expression of disinterest to a particular response class or a combination of response classes. The server MAY decide to suppress the response by not transmitting it back to the client according to the value of the No-Response option in the request. This option may be effective for both unicast and multicast requests. This document also discusses a few examples of applications that benefit from this option. Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP) This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the Constrained Application Protocol (CoAP). This will enable an HTTP client to access resources on a CoAP server through the proxy. This document describes how an HTTP request is mapped to a CoAP request and how a CoAP response is mapped back to an HTTP response. This includes guidelines for status code, URI, and media type mappings, as well as additional interworking advice. CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport. Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. Object Security for Constrained RESTful Environments (OSCORE) This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. Concise Binary Object Representation (CBOR) Sequences This document describes the Concise Binary Object Representation (CBOR) Sequence format and associated media type "application/cbor-seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence. Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+cbor-seq" as a structured syntax suffix for CBOR Sequences. Concise Binary Object Representation (CBOR) The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. HTTP/1.1 The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns. This document obsoletes portions of RFC 7230. Structured Field Values for HTTP This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields. This document obsoletes RFC 8941. CoAP Option Numbers IANA Hypertext Transfer Protocol (HTTP) Field Name Registry IANA Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Miscellaneous additions to CoAP Universitaet Bremen TZI Universitaet Bremen TZI This short I-D makes a number of partially interrelated proposals how to solve certain problems in the CoRE WG's main protocol, the Constrained Application Protocol (CoAP). The current version has been resubmitted to keep information about these proposals available; the proposals are not all fleshed out at this point in time. Discovery of OSCORE Groups with the CoRE Resource Directory RISE AB Group communication over the Constrained Application Protocol (CoAP) can be secured by means of Group Object Security for Constrained RESTful Environments (Group OSCORE). At deployment time, devices may not know the exact security groups to join, the respective Group Manager, or other information required to perform the joining process. This document defines how a CoAP endpoint can use descriptions and links of resources registered at the CoRE Resource Directory to discover security groups and to acquire information for joining them through the respective Group Manager. A given security group can be used to protect communications in multiple application groups, which are separately announced in the Resource Directory as sets of endpoints sharing a pool of resources. This approach is consistent with, but not limited to, the joining of security groups based on the ACE framework for Authentication and Authorization in constrained environments. End-to-End Protected and Cacheable CoAP Responses using Group Object Security for Constrained RESTful Environments (Group OSCORE) RISE AB When using the Constrained Application Protocol (CoAP), exchanged messages can be protected end-to-end also across untrusted intermediary proxies. This can be achieved with Object Security for Constrained RESTful Environments (OSCORE) or, in the case of group communication, with Group Object Security for Constrained RESTful Environments (Group OSCORE). However, this sidesteps the proxies' abilities to cache responses from the origin server(s). This document restores cacheability of end-to-end protected responses at proxies, by using Group OSCORE and introducing consensus requests, which any client in an OSCORE group can send to one server or multiple servers in the same group. Key Management for Group Object Security for Constrained RESTful Environments (Group OSCORE) Using Authentication and Authorization for Constrained Environments (ACE) RISE AB Ericsson AB This document defines an application profile of the Authentication and Authorization for Constrained Environments (ACE) framework, to request and provision keying material in group communication scenarios that are based on the Constrained Application Protocol (CoAP) and are secured with Group Object Security for Constrained RESTful Environments (Group OSCORE). This application profile delegates the authentication and authorization of Clients, which join an OSCORE group through a Resource Server acting as Group Manager for that group. This application profile leverages protocol-specific transport profiles of ACE to achieve communication security, server authentication, and proof of possession of a key owned by the Client and bound to an OAuth 2.0 access token. OSCORE-capable Proxies RISE AB RISE AB When using the Constrained Application Protocol (CoAP), messages exchanged between two endpoints can be protected end-to-end at the application layer by means of Object Security for Constrained RESTful Environments (OSCORE), also in the presence of intermediaries such as proxies. This document defines how to use OSCORE for protecting CoAP messages also between an origin application endpoint and an intermediary, or between two intermediaries. Also, it defines rules to escalate the protection of a CoAP option, in order to encrypt and integrity-protect it whenever possible. Finally, it defines how to secure a CoAP message by applying multiple, nested OSCORE protections, e.g., both end-to-end between origin application endpoints; and between an application endpoint and an intermediary or between two intermediaries. Therefore, this document updates RFC 8613. Furthermore, this document updates RFC 8768, by explicitly defining the processing with OSCORE for the CoAP Hop-Limit Option. The approach defined in this document can be seamlessly employed also with Group OSCORE, for protecting CoAP messages when group communication is used in the presence of intermediaries. The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. The Transport Layer Security (TLS) Protocol Version 1.3 This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations.

Examples with a Reverse-Proxy The examples in this section refer to the following actors.

One origin client C, with address C_ADDR and port number C_PORT.
One proxy P, with address P_ADDR and server port number P_PORT.
Two origin servers S1 and S2, where the server Sx has address Sx_ADDR and port number Sx_PORT.

The origin servers are members of a CoAP group with IP multicast address G_ADDR and port number G_PORT. Also, the origin servers are members of the same application group and share the same resource at /r. The communication between C and P is based on CoAP over TCP, as per . The group communication between P and the origin servers is based on CoAP over UDP/IP multicast, as per . Finally, cri'X' denotes a CRI or CRI reference corresponding to the URI or URI reference X, i.e., a CRI or CRI reference that can be converted to the URI or URI reference X using the procedure defined in .

Example 1 The example shown in considers a reverse-proxy P that provides access to both the whole group of servers {S1,S2} and also to each of those servers individually. The client C may not have a way to reach the servers directly (e.g., P is acting as a firewall). After the client C has received two responses to its group request sent via the proxy, it selects one server (S1) and sends a new request again via the proxy, intended only to that server and targeting a different resource at /r1 in unicast. In particular:

In its group request to P, the client C includes the Uri-Host Option with value "group1.com" and the Uri-Path Option with value "r".
The hostname 'group1.com' resolves to the IPv6 multicast address G_ADDR. The proxy P performs this resolution upon receiving the group request from C. Since such a request does not include the Uri-Port Option, P infers G_PORT to be the default port number 5683 for CoAP over UDP with the "coap" URI scheme. Based on this information, P composes the group request and sends it to the CoAP group at G_ADDR:G_PORT.
Typically, S1_PORT and S2_PORT will be equal to G_PORT, but a server Sx is allowed to reply to the multicast request from another port number that is not equal to G_PORT. For this reason, the notation Sx_PORT is used.

Note that this type of reverse-proxy only requires one unicast IP address (P_ADDR) for the proxy, so it scales well with a large number of servers Sx. Instead, the type of reverse-proxy in the example in requires one IP address for each server Sx and one for each CoAP group that the proxy supports.

Example 2 The example shown in considers a reverse-proxy that stands in for both the whole group of servers {S1,S2} and for each of those servers Sx. The client C may not have a way to reach the servers directly (e.g., P is acting as a firewall). After the client C has received two responses to its group request sent via the proxy, it selects one server (S1) and sends a new request again via the proxy, intended only for that server and targeting the same resource at /r in unicast. In particular:

When receiving a request addressed to the unicast address P_ADDR and port number P_PORT, the proxy forwards the request towards the CoAP group at G_ADDR:G_PORT leaving the URI path unchanged.
The address Dx_ADDR and port number Dx_PORT are also used by the proxy, which forwards an incoming request to that address towards the server at Sx_ADDR:Sx_PORT. The different addresses Dx_ADDR are effectively "proxy IP addresses" used to provide access to the servers.

Note that this type of reverse-proxy implementation requires the proxy to use a (potentially) large number of distinct IP addresses, hence it is not very scalable. Instead, the type of reverse-proxy shown in the example in uses only one IPv6 unicast address to provide access to all servers and all CoAP groups that the proxy supports.

Example 3 The example shown in builds on the example in . However, it considers a reverse-proxy that stands in only for the whole group of servers, but not for each individual server Sx. Therefore, it is possible for the client C to reach an individual server directly. The final exchange between C and S1 occurs with CoAP over UDP.

Document Updates

Version -06 to -07

Clarifications:
- Representing the option value 0.
- Checks at the proxy about the client being allowed-listed.
- Privacy benefits if the proxy is not a Group OSCORE signature checker.
Mentioned the possible use of the Uri-Path-Abbrev Option.
Avoided unnecessary normative language.
Use suggested CoAP option numbers in the placeholders.
Updated references.
Editorial improvements.

Version -05 to -06

Updated title.
Updated references.
Clarified handling of the Reply-From Option on the client side.
Extended security considerations on client authentication.
Clarifications and editorial improvements.

Version -04 to -05

Abstract and introduction: the scope is one possible realization of proxy.
Generalized transport indication: still based on the CRI in the Reply-From Option, but not on 'scheme' only.
Suggested option numbers for the three new CoAP options.
Clarifications and editorial improvements.

Version -03 to -04

More appropriate pointers to sections of draft-ietf-core-groupcomm-bis.
More precise semantics for the Reply-From Option.
Defined early cancellation of ongoing response forwarding.
Suggested value ranges for codepoints to register.
Clarifications and editorial improvements.

Version -02 to -03

Made RFC 7967 a normative reference.
Improved error handling for request reception at the proxy.
Improved security considerations for the new CoAP options.
Aligned handling of multiple responses with draft-ietf-core-groupcomm-bis.
Revised HTTP Reply-From header field to be a Structured Header Field.
Revised HTTP Group-ETag header field to be a Structured Header Field.
Clarifications and editorial improvements.

Version -01 to -02

Reply-To Option renamed as Reply-From.
Multicast-Timeout Option set to 0 ultimately yields an empty value.
Removed moot text on reverse-proxies that might use default timeouts.
Improved description on using Proxy-Cri and Proxy-Scheme-Number.
Improved error handling for inadequate timeouts with proxy chains.
Revised the examples of message exchange with a reverse-proxy.
Fixes in the IANA considerations.
Editorial fixes and improvements.

Version -00 to -01

Definition of "individual request" in the terminology.
UDP/IP multicast treated as the default transport protocol.
Always use the Multicast-Timeout Option, also with reverse-proxies.
Response-Forwarding Option:
- Renamed as "Reply-To".
- Revised encoding to use CRIs.
- Revised semantics to better address setups with reverse-proxies.
- Added before possible response caching.
Clarified response processing at reverse-proxies.
Updated IANA considerations.
Editorial fixes and improvements.

Acknowledgments The authors sincerely thank , , , , and for their comments and feedback. The work on this document has been partly supported by the Sweden's Innovation Agency VINNOVA and the Celtic-Next projects CRITISEC and CYPRESS; and by the H2020 project SIFIS-Home (Grant agreement 952652).