[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