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

Hi Achim,
(ccing DOTS WG)

Thank you for sharing your thoughts.

I'm personally OK with any wording which makes clear that distinct tokens are generated to differentiate among concurrent requests involving the same source/destination endpoints.  

I'm not sure to understand what you meant by "per simultaneous request", though.  

Cheers,
Med

> -----Message d'origine-----
> De : Kraus Achim (INST/ECS4) [mailto:Achim.Kraus@bosch-si.com]
> Envoyé : mercredi 14 mars 2018 12:59
> À : RFC Errata System; 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 : BOUCADAIR Mohamed IMT/OLN; core@ietf.org
> Objet : RE: [core] [Technical Errata Reported] RFC7252 (5284)
> 
> Hi,
> 
> if the current definition "tokens currently in use" is interpreted as for
> "all pending requests", I can't see, that adding "per request" improves the
> RFC.
> If something is added, I would recommend to precise that also with the time-
> scope,
> e.g. "per simultaneous request".
> 
> Mit freundlichen Grüßen / Best regards
> 
>  Achim Kraus
> 
> (INST/ECS4)
> Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332 Waiblingen |
> GERMANY | www.bosch-si.com
> 
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.
> Stefan Ferber, Michael Hahn
> 
> -----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