[core] Questions dealing with Blockwise Transfer
Jim Schaad <ietf@augustcellars.com> Thu, 02 April 2020 18:00 UTC
Return-Path: <ietf@augustcellars.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 348F13A0FCD for <core@ietfa.amsl.com>; Thu, 2 Apr 2020 11:00:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 AdsRNlsIxeoy for <core@ietfa.amsl.com>; Thu, 2 Apr 2020 11:00:41 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 034AA3A0FC3 for <core@ietf.org>; Thu, 2 Apr 2020 11:00:40 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 2 Apr 2020 11:00:31 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: core@ietf.org
Date: Thu, 02 Apr 2020 11:00:29 -0700
Message-ID: <022401d60918$9a2d3f50$ce87bdf0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdYIWnsiWRxZxUYsSFC1zgO0qK7v8A==
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/BBXL3NlJmL9m9YVYGhMsGAbAl0E>
Subject: [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: Thu, 02 Apr 2020 18:00:49 -0000
I am running into a couple of issues when getting my OSCORE secure blockwise transfer debugged. I accidentally introduced an error in my OSCORE decryption code and that caused my blockwise code to fall over. 1. Based on the below text, I am not sure if this is saying that only success status codes are permitted to use blockwise or if you can use this for error status codes as well. This question comes about partly due to the draft https://www.ietf.org/id/draft-fossati-core-coap-problem-02.html which might return some "large" size error resources. Hence, for the methods defined in [RFC7252], Block1 is useful with the payload-bearing POST and PUT requests and their responses. Block2 is useful with GET, POST, and PUT requests and their payload- bearing responses (2.01, 2.02, 2.04, and 2.05 -- see Section 5.5 of [RFC7252]). 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. Jim
- [core] Questions dealing with Blockwise Transfer Jim Schaad
- Re: [core] Questions dealing with Blockwise Trans… Christian Amsüss