Subject: [dtn] (no subject)

From: Loiseau lucien <[email-masked]>
Date: Sat, 12 Jan 2019 19:16:43 +0100

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

---

From: Felix Walter <[email-masked]>
Date: Mon, 14 Jan 2019 10:23:38 +0100

Hi Lucien,

Good point! I actually suggested this change at some point, not only
because a second length value is redundant, but also because it leads to
problems if you want to serialize a bundle as a stream using a CBOR
library - the first length value depends on the encoding of the length
inside the byte string header. Thus, you have to serialize the byte
string separately and then concatenate it with the length plus the rest
of the serialized bundle, either resulting in a lot of code handling
this special case or significant memory overhead.

I don't see good use cases for the CBOR indefinite-length byte strings
in a serialized bundle. It would rather lead to a lot of problems with
parsing bundles as you mentioned.

@Scott: Couldn't we simply forbid the use of that representation for the
block payload?

Felix

Am 12.01.19 um 19:16 schrieb Loiseau lucien:
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Mon, 14 Jan 2019 20:21:11 +0000

Sure, we can change the 5th bullet of 4.2.3 to say "Block-type-specific data represented as a single definite-length CBOR byte string, i.e., a CBOR byte string that is not of indefinite length."

Scott

-----Original Message-----
From: dtn <[email-masked]> On Behalf Of Felix Walter
Sent: Monday, January 14, 2019 1:24 AM
To: [email-masked]
Subject: Re: [dtn] (no subject)

Hi Lucien,

Good point! I actually suggested this change at some point, not only because a second length value is redundant, but also because it leads to problems if you want to serialize a bundle as a stream using a CBOR library - the first length value depends on the encoding of the length inside the byte string header. Thus, you have to serialize the byte string separately and then concatenate it with the length plus the rest of the serialized bundle, either resulting in a lot of code handling this special case or significant memory overhead.

I don't see good use cases for the CBOR indefinite-length byte strings in a serialized bundle. It would rather lead to a lot of problems with parsing bundles as you mentioned.

@Scott: Couldn't we simply forbid the use of that representation for the block payload?

Felix