Re: [core] [Technical Errata Reported] RFC7252 (5284)

Hi all,

I lost the context about the resolution for this errata. Any update on this one?

Thank you. 

Cheers,
Med

> -----Original Message-----
> From: core [mailto:core-bounces@ietf.org] On Behalf Of RFC Errata
> System
> Sent: Freitag, 9. März 2018 10:34
> To: zach.shelby@arm.com; hartke@tzi.org; cabo@tzi.org;
> ben@nostrum.com; aamelnikov@fastmail.fm; adam@nostrum.com;
> cabo@tzi.org; jaime@iki.fi
> Cc: mohamed.boucadair@orange.com; core@ietf.org; rfc-editor@rfc-
> editor.org
> Subject: [core] [Technical Errata Reported] RFC7252 (5284)
> 
> The following errata report has been submitted for RFC7252, "The
> Constrained Application Protocol (CoAP)".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5284
> 
> --------------------------------------
> Type: Technical
> Reported by: Mohamed Boucadair <mohamed.boucadair@orange.com>
> 
> Section: 5.3.1
> 
> Original Text
> -------------
> The client SHOULD generate tokens in such a way that tokens currently
> in use for a given source/destination endpoint pair are unique.
> 
> Corrected Text
> --------------
> 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.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or rejected.
> When a decision is reached, the verifying party can log in to change
> the status and edit the report, if necessary.
> 
> --------------------------------------
> RFC7252 (draft-ietf-core-coap-18)
> --------------------------------------
> Title               : The Constrained Application Protocol (CoAP)
> Publication Date    : June 2014
> Author(s)           : Z. Shelby, K. Hartke, C. Bormann
> Category            : PROPOSED STANDARD
> Source              : Constrained RESTful Environments APP
> Area                : Applications
> Stream              : IETF
> Verifying Party     : IESG
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core