RFC 7252, "The Constrained Application Protocol (CoAP)", June 2014Source of RFC: core (app)
Errata ID: 5284
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2018-03-09
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.
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.