[dtn] (no subject)

Loiseau lucien <loiseau.lucien@gmail.com> Sat, 12 January 2019 18:16 UTC

Return-Path: <loiseau.lucien@gmail.com>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5088B1277BB for <dtn@ietfa.amsl.com>; Sat, 12 Jan 2019 10:16:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Xc-erntJzNSy for <dtn@ietfa.amsl.com>; Sat, 12 Jan 2019 10:16:55 -0800 (PST)
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C3BE124C04 for <dtn@ietf.org>; Sat, 12 Jan 2019 10:16:55 -0800 (PST)
Received: by mail-qt1-x836.google.com with SMTP id p17so22414328qtl.5 for <dtn@ietf.org>; Sat, 12 Jan 2019 10:16:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=qKyuCUHC57KEJRlgAbjezb9tMcXs7A3QjO3M2d3Be70=; b=brR2iPAERX9cLVgJyDDmEPEzUBDE3+KE81XBHnNTfJoowEOdRSTJzu9U/DxtCjlPG0 fzFL98jaZswp+evxdhiMu2kE5gb8lFfuiA+55zyJ78cH/IwwWn2eE1kXnNJAn96RuQVW A4joP5w5hKH/weFrHK9ziZfhGiF0EiCS5ZS9aT/HCXPBXBjXiu29AYEtGj7nKEMrOY4a TRxKWWO9XHQvxPRGVtA7rbZqfqFGIGWowMMGABYQU4xOXc50wlaDih77JxjlER+S5ltc bYjMkpIpDkREXfmDkkjJrfSNQI5oklhT6YX6pfQIf641g2tdfxTQJvwe1+MZD7uR9/pW d7iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=qKyuCUHC57KEJRlgAbjezb9tMcXs7A3QjO3M2d3Be70=; b=nAZkdCNDYUZZfiDx0pZrev+WgiLONbtdhXDWQo50rIp1RR3B/O3+tefeLcRE9G2ROw TogpGC0ntHSfqDjAS5NbjW83MLJwNhaRxdufWlZnZn6l7AXI13RvEug/QG2K5XFQSc3j YFu9gHRyeXYKRg4VQ//iSbVZ3XDkafdWajNI1Pk8eAowGfAREHTDbE0PKcoFwq77O9Sa 1BMlxl/T0KrgkK1E0rVJ2iWIT2fVRfRJlx31xtC7TAoS+8xFL7xgxP/ZHdlkhvz+vnES vUoocgwfVBnBNYWSb5CB5xplVW8g8CJU6EQnMty8AocwQ3hPVISIjL2CgjaOukafYxes gMDw==
X-Gm-Message-State: AJcUukd7RapT935VsxBkNUcneO2h1ritoBqVKPGGsB5YV+eBp108qTHb oZ/RCYKP5F+2XExf2XKvAtt4wqUN368Vt5+YD/gnBW+N
X-Google-Smtp-Source: ALg8bN7wxCpeImS/DVb1i5fmq+Ts+ErzKOCYLkbcFix/0zHzDfTK0nxr9X3PH6Mlvc29V/BObSkqT/iaZ7zIYBYYw1c=
X-Received: by 2002:a0c:9257:: with SMTP id 23mr18175616qvz.142.1547317014328; Sat, 12 Jan 2019 10:16:54 -0800 (PST)
MIME-Version: 1.0
From: Loiseau lucien <loiseau.lucien@gmail.com>
Date: Sat, 12 Jan 2019 19:16:43 +0100
Message-ID: <CANoKrvZZhzcPXupNTtup8rjJyWA0LevVRwqmn8qijJ3qn4dLEg@mail.gmail.com>
To: dtn@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/HTUm35qX-6YJPCGz4Erl5UQikPo>
Subject: [dtn] (no subject)
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 12 Jan 2019 18:16:57 -0000

Hi,

I noticed that since bpbis-10, the block data length was removed from
the Canonical Block Header, I imagine to reuse the length given as a
header of the CBOR byte string that constitutes the payload of the
block.

However CBOR encoding authorizes a byte string to be "indefinite" so
that the cbor header would be -1 and then follows a series of byte
chunk with definite size. In that case, it may be impossible to
allocate memory for the whole payload, instead we would have to
readjust buffer as chunks are coming in. Another limitation with a
payload encoded as an indefinite cbor byte string is that it would be
impossible to refuse a large bundle until we fully decoded it or hit
the limit.

Best Regards,
Lucien