Re: [core] Block-wise coap vs. options
Carsten Bormann <cabo@tzi.org> Mon, 07 October 2019 15:34 UTC
Return-Path: <cabo@tzi.org>
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 152881208A5 for <core@ietfa.amsl.com>; Mon, 7 Oct 2019 08:34:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 rACwLkZwvWwZ for <core@ietfa.amsl.com>; Mon, 7 Oct 2019 08:34:17 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E61B41208BF for <core@ietf.org>; Mon, 7 Oct 2019 08:34:16 -0700 (PDT)
Received: from sev.informatik.uni-bremen.de (sev.informatik.uni-bremen.de [134.102.218.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46n4K32CLbzyWK; Mon, 7 Oct 2019 17:34:15 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <03e317ad57993f9d2c059a951e25958042a82be1.camel@jablotron.cz>
Date: Mon, 07 Oct 2019 17:34:15 +0200
Cc: "core@ietf.org" <core@ietf.org>
X-Mao-Original-Outgoing-Id: 592155254.273599-2555439e0903f352f3a136b0b957e6e9
Content-Transfer-Encoding: quoted-printable
Message-Id: <0A096168-ACC8-44CC-A58A-6CED65B8CFF1@tzi.org>
References: <03e317ad57993f9d2c059a951e25958042a82be1.camel@jablotron.cz>
To: Geiger Pavel <pavel.geiger@jablotron.cz>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/eZ62wRGqmbCh4YHRiU5l008wXe8>
Subject: Re: [core] Block-wise coap vs. options
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, 07 Oct 2019 15:34:26 -0000
Hi Pavel, > On Oct 7, 2019, at 15:15, Geiger Pavel <pavel.geiger@jablotron.cz> wrote: > > Hi, we have implemented CoAP library with support for block-wise coap. What we have problem with is, that block-wise coap doesnt fragment options. By our understanding they are still transfered together in single CoAP datagram. Therefore, if we have CoAP option with payload larger than MTU (for example uri-query), there is no way, how to transfer it reliably with respect to the MTU. Indeed, the assumption is that CoAP options are small enough they don’t need to be segmented. What is the context in which this happens? Maybe you are using uri-query in a way for which we normally would use FETCH (RFC 8132) payloads (which do support block-wise transfer). Grüße, Carsten
- [core] Block-wise coap vs. options Geiger Pavel
- Re: [core] Block-wise coap vs. options Carsten Bormann