Re: [core] Questions dealing with Blockwise Transfer

Christian Amsüss <christian@amsuess.com> Mon, 06 April 2020 16:30 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 9E2533A0486 for <core@ietfa.amsl.com>; Mon, 6 Apr 2020 09:30:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level:
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 vBzubTX5t-Tc for <core@ietfa.amsl.com>; Mon, 6 Apr 2020 09:30:10 -0700 (PDT)
Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CDA43A047F for <core@ietf.org>; Mon, 6 Apr 2020 09:30:10 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 0883F40146; Mon, 6 Apr 2020 18:30:08 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 32DF379; Mon, 6 Apr 2020 18:30:07 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:2d54:7976:cdc9:1eab]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id F256E367; Mon, 6 Apr 2020 18:30:06 +0200 (CEST)
Received: (nullmailer pid 2700067 invoked by uid 1000); Mon, 06 Apr 2020 16:30:06 -0000
Date: Mon, 06 Apr 2020 18:30:06 +0200
From: Christian Amsüss <christian@amsuess.com>
To: Jim Schaad <ietf@augustcellars.com>
Cc: core@ietf.org
Message-ID: <20200406163006.GC2688660@hephaistos.amsuess.com>
References: <022401d60918$9a2d3f50$ce87bdf0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="tqI+Z3u+9OQ7kwn0"
Content-Disposition: inline
In-Reply-To: <022401d60918$9a2d3f50$ce87bdf0$@augustcellars.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/dSLnk9tL1bEjKb9Fau0NSj38o2o>
Subject: Re: [core] Questions dealing with Blockwise Transfer
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: Mon, 06 Apr 2020 16:30:12 -0000

Hello Jim,

On Thu, Apr 02, 2020 at 11:00:29AM -0700, Jim Schaad wrote:
> 1.  [...] might return some "large" size error resources.

Good questions.

> 2.  The document does not explicitly give any way for a server to stop a
> block transfer half way through.  While it would make sense to an error
> status is returned, I do not know if the block option is also supposed to be
> returned or not.  Note that this would not necessarily interact well with
> the idea of doing a blockwise return for an error status content.

Section 2.3 item 1 (on descriptive usage) clearly relates the numand
block size to the payload of that message. Thus, an error would only use
Block2 in descriptive use if the error payload is being fragmented.

(I know, that does not answer all the question.)

KR
c

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