RFC Errata
RFC 7252, "The Constrained Application Protocol (CoAP)", June 2014
Note: This RFC has been updated by RFC 7959, RFC 8613, RFC 8974, RFC 9175
Source of RFC: core (wit)
Errata ID: 5284
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2018-03-09
Rejected by: Francesca Palombini
Date Rejected: 2023-01-18
Section 5.3.1 says:
The client SHOULD generate tokens in such a way that tokens currently in use for a given source/destination endpoint pair are unique.
It should say:
The client SHOULD generate tokens in such a way that tokens currently in use for a given source/destination endpoint pair are unique per request.
Notes:
Multiple requests may be active for a given source/destination
endpoint pair. The OLD text is thus broken.
The NEW text is aligned with the definition of the Token:
A token is intended for use as a client-local identifier for
differentiating between concurrent requests (see Section 5.3); it
could have been called a "request ID".
Further, using the same token for a given source/destination endpoint
pair have some implications, for example, for applications which
require the support of multiple observe queries because RFC7641
states the following:
The entry in the list of observers is keyed by the client endpoint
and the token specified by the client in the request. If an entry
with a matching endpoint/token pair is already present in the list
(which, for example, happens when the client wishes to reinforce
its interest in a resource), the server MUST NOT add a new entry
but MUST replace or update the existing one.
--VERIFIER NOTES--
After discussing with the working group, it was agreed that the original text is correct and that the addition is redundant and does not help clarify it.