[core] Strictness of RFC7959
Christian Amsüss <christian@amsuess.com> Mon, 05 March 2018 22:20 UTC
Return-Path: <christian@amsuess.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 B094312EAB0; Mon, 5 Mar 2018 14:20:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X42Gd3PJujwu; Mon, 5 Mar 2018 14:19:55 -0800 (PST)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E270812E9DD; Mon, 5 Mar 2018 14:19:49 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 1750849535; Mon, 5 Mar 2018 23:19:47 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 6164D61; Mon, 5 Mar 2018 23:19:46 +0100 (CET)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::db8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 2F5215E; Mon, 5 Mar 2018 23:19:46 +0100 (CET)
Received: (nullmailer pid 9182 invoked by uid 1000); Mon, 05 Mar 2018 22:19:45 -0000
Date: Mon, 05 Mar 2018 23:19:45 +0100
From: Christian Amsüss <christian@amsuess.com>
To: draft-ietf-core-block@ietf.org
Cc: Core WG mailing list <core@ietf.org>
Message-ID: <20180305221945.GA25693@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf"
Content-Disposition: inline
User-Agent: Mutt/1.9.3 (2018-01-21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/I-6LzAL6lIUVDA6_g9YM3Zjhg8E>
Subject: [core] Strictness of RFC7959
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 05 Mar 2018 22:20:05 -0000
Hello block-wise authors, hello CoRE, I am uncertain about the behavior RFC7959 actually prescribes to servers: How liberal is it for servers about which blocks can be acted on together (or when to send 4.08 Request Entity Incomplete)? The last paragraph of section 2.4 implies that the Cache-Key[1] is what messages are grouped by (which makes sense and would make the specification of Request-Tag much shorter), but nowhere else is the cache key mentioned in the document. What is the expected behavior of a server (or let's say proxy, as the proxy needs to do block-wise too but doesn't need to know elective options) in presence of similar-but-not-quite-alike messages from the same source that could be a blockwise operation? Group by URI? By Cach-Key? By all options unless it knows it's irrelevant from the option's description? May the server choose depending on the application? And can I rely on that behavior in echo-request-tag? Best regards Christian [1]: Actually Cache-Key without request body after RFC7252 errata, as that body is not represented in Block2 phase when combining. -- Reflection. Surprise. Terror. For the future. -- Kosh
- [core] Strictness of RFC7959 Christian Amsüss
- Re: [core] Strictness of RFC7959 Christian Amsüss