RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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.

Report New Errata



Advanced Search