Re: [core] Payloads and BLOCK2 for various methods

Christian Amsüss <christian@amsuess.com> Wed, 05 August 2020 16:05 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 A04D23A0C32 for <core@ietfa.amsl.com>; Wed, 5 Aug 2020 09:05:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 OMYMRHGF9FLZ for <core@ietfa.amsl.com>; Wed, 5 Aug 2020 09:05:26 -0700 (PDT)
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 24F9F3A0C0B for <core@ietf.org>; Wed, 5 Aug 2020 09:05:25 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 6F1C840760; Wed, 5 Aug 2020 18:05:22 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id F27A2AB; Wed, 5 Aug 2020 18:05:20 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:947b:e942:281b:482c]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 6BF65180; Wed, 5 Aug 2020 18:05:20 +0200 (CEST)
Received: (nullmailer pid 3502950 invoked by uid 1000); Wed, 05 Aug 2020 16:05:20 -0000
Date: Wed, 05 Aug 2020 18:05:20 +0200
From: Christian Amsüss <christian@amsuess.com>
To: Jim Schaad <ietf@augustcellars.com>
Cc: core@ietf.org
Message-ID: <20200805160520.GA3470838@hephaistos.amsuess.com>
References: <009501d6629a$509165c0$f1b43140$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="sdtB3X0nJg68CQEu"
Content-Disposition: inline
In-Reply-To: <009501d6629a$509165c0$f1b43140$@augustcellars.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/p7UyXhg4dQzEEjhDl6paRKtSRFI>
Subject: Re: [core] Payloads and BLOCK2 for various methods
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
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, 05 Aug 2020 16:05:29 -0000

Hello Jim,

On Sat, Jul 25, 2020 at 08:43:14AM -0700, Jim Schaad wrote:
> I was going through my code because I found a problem with one of my
> blockwise implementations and I found that I did not know where the text was
> about sending payloads for NUM > 1 blocks.   The only statement that I have
> found on this seems to be in Figure 10 of RFC 7959.  If it is elsewhere then
> I have missed it.  The problem with this is a) it is an example rather than
> a statement in the text and 2) it needs to be inferred that this applies to
> more than just POST.

I relied on the same figure for my implementations, and on checking
again found nothing to support the behavior either.

(The best indication I found is the sentence in 2.7 that "To continue
this Block2 transfer, the client continues to send requests similar to
the requests in the Block1 phase, but leaves out the Block1 Options and
includes a Block2 request option with non-zero NUM" -- without a Block1
option, there is no payload that makes sense there to send).

> I also ended up looking at RFC 8132 and, to my surprise, I found that
> blockwise is to be supported for FETCH, but there is no statement about
> PATCH and iPATCH.   Given the explicit statement for FETCH, it is my
> assumption that PATCH and iPATCH are not to be used with blockwise.  Does
> that match what was intended?

I'd assume that on PATCH and iPATCH it generally says less because
they're already so close to PUT and POST that everything on block-wise
with PUT and POST applies equally.

Both would make good corr-clar material.

KR
c

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom