Skip to content

Commit

Permalink
Generalized resending of a group request with different Message ID
Browse files Browse the repository at this point in the history
  • Loading branch information
marco-tiloca-sics committed Sep 5, 2024
1 parent 797af34 commit dcfc911
Showing 1 changed file with 3 additions and 1 deletion.
4 changes: 3 additions & 1 deletion draft-ietf-core-groupcomm-bis.md
Original file line number Diff line number Diff line change
Expand Up @@ -500,7 +500,7 @@ Any default response suppression by a server SHOULD be performed consistently, a
### Repeating a Request ###
A CoAP client MAY repeat a group request using the same Token value and same Message ID value, in order to ensure that enough (or all) members of the CoAP group have been reached with the request. This is useful in case a number of members of the CoAP group did not respond to the initial request and the client suspects that the request did not reach these group members. However, in case one or more servers did receive the initial request but the response to that request was lost, this repeat does not help to retrieve the lost response(s) if the server(s) implement the optional Message ID based deduplication ({{Section 4.5 of RFC7252}}).

A CoAP client MAY repeat a group request using the same Token value and a different Message ID, in which case all servers that received the initial request will again process the repeated request since it appears within a new CoAP message. This is useful in case a client suspects that one or more response(s) to its original request were lost and the client needs to collect more, or even all, responses from members of the CoAP group, even if this comes at the cost of the overhead of certain group members responding twice (once to the original request, and once to the repeated request with different Message ID).
A CoAP client MAY repeat a group request using a different Message ID (and the same or a different Token value), in which case all servers that received the initial request will again process the repeated request since it appears within a new CoAP message. This is useful in case a client suspects that one or more response(s) to its original request were lost and the client needs to collect more, or even all, responses from members of the CoAP group, even if this comes at the cost of the overhead of certain group members responding twice (once to the original request, and once to the repeated request with different Message ID).

### Request/Response Matching and Distinguishing Responses ###
A CoAP client can distinguish the origin of multiple server responses by the source IP address of the message containing the CoAP response and/or any other available application-specific source identifiers contained in the CoAP response payload or CoAP response options, such as an application-level unique ID associated with the server. If secure communication is provided with Group OSCORE (see {{chap-oscore}}), additional security-related identifiers in the CoAP response enable the client to retrieve the right security material for decrypting each response and authenticating its source.
Expand Down Expand Up @@ -1730,6 +1730,8 @@ Client A B C

## Version -11 to -12 ## {#sec-11-12}

* Generalized resending of a group request with different Message ID.

* Switched SHOULD to MAY on changing port number from group request to response.

* Further generalized the handling of multiple responses from the same server to the same request.
Expand Down

0 comments on commit dcfc911

Please sign in to comment.