[core] [Errata Verified] RFC7252 (4948)
RFC Errata System <rfc-editor@rfc-editor.org> Wed, 18 January 2023 09:14 UTC
Return-Path: <wwwrun@rfcpa.amsl.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE548C14CE24; Wed, 18 Jan 2023 01:14:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.948
X-Spam-Level:
X-Spam-Status: No, score=-3.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcF9Tt5ERS84; Wed, 18 Jan 2023 01:14:15 -0800 (PST)
Received: from rfcpa.amsl.com (rfc-editor.org [50.223.129.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5CA5C14CEFC; Wed, 18 Jan 2023 01:14:15 -0800 (PST)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id B75D5961FB; Wed, 18 Jan 2023 01:14:15 -0800 (PST)
To: hartke@tzi.org, zach.shelby@arm.com, hartke@tzi.org, cabo@tzi.org
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: francesca.palombini@ericsson.com, iesg@ietf.org, core@ietf.org, iana@iana.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20230118091415.B75D5961FB@rfcpa.amsl.com>
Date: Wed, 18 Jan 2023 01:14:15 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/dxOLkZ5g5lPQVtn_vNEN0tQoCZc>
Subject: [core] [Errata Verified] RFC7252 (4948)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jan 2023 09:14:19 -0000
The following errata report has been verified for RFC7252, "The Constrained Application Protocol (CoAP)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid4948 -------------------------------------- Status: Verified Type: Technical Reported by: Klaus Hartke <hartke@tzi.org> Date Reported: 2017-02-22 Verified by: Francesca Palombini (IESG) Section: 5.6 Original Text ------------- For a presented request, a CoAP endpoint MUST NOT use a stored response, unless: o the presented request method and that used to obtain the stored response match, o all options match between those in the presented request and those of the request used to obtain the stored response (which includes the request URI), except that there is no need for a match of any request options marked as NoCacheKey (Section 5.4) or recognized by the Cache and fully interpreted with respect to its specified cache behavior (such as the ETag request option described in Section 5.10.6; see also Section 5.4.2), and o the stored response is either fresh or successfully validated as defined below. The set of request options that is used for matching the cache entry is also collectively referred to as the "Cache-Key". Corrected Text -------------- For a presented request, a CoAP endpoint MUST NOT use a stored response, unless: o the presented request method and that used to obtain the stored response match, o all options match between those in the presented request and those of the request used to obtain the stored response (which includes the request URI), except that there is no need for a match of any request options marked as NoCacheKey (Section 5.4) or recognized by the Cache and fully interpreted with respect to its specified cache behavior (such as the ETag request option described in Section 5.10.6; see also Section 5.4.2), o the payload of the presented request and the payload of the request used to obtain the stored response match, and o the stored response is either fresh or successfully validated as defined below. The set of request options that is used for matching the cache entry plus (if applicable) the request payload are also collectively referred to as the "Cache-Key". Notes ----- CoAP servers may return error responses in reply to requests that are invalid at the CoAP level (e.g., 4.02 Bad Option if the client includes an unrecognized option) or at the application level above (e.g., 4.00 Bad Request if the client includes a malformed payload according to application semantics). If the error response does not depend on the request payload, then it is desirable that repeated requests that differ only in the payload can be satisfied with the same cached response. E.g., repeated requests for a non-existing resource should result in a cached 4.04 Not Found response as often as possible, regardless of the payload, rather than hit the server every time. If the error response depends on the request payload, then it is not desirable that cached responses are reused for repeated requests that differ only in the payload. E.g., a client should not receive an error response for a valid request payload because another client sent an identical request but with a malformed request payload. In this case, including the request payload in the Cache-Key would give the expected result. The original text does not include the request in the Cache-Key, which may lead to unexpected results. The corrected text changes that. Since CoAP does not provide any indication in responses to distinguish between the two cases, caches generally cannot determine whether the response depends on the request payload or not and thus must always include the request payload in the Cache-Key to give the expected result. (As an exception, a cache at an origin server may be able to determine whether a cached response depends on the request payload or not, and thus can reuse responses accordingly. This already applies to responses that do not depend on the request method.) -------------------------------------- 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] [Errata Verified] RFC7252 (4948) RFC Errata System