Re: [dtn] (no subject)

[Felix Walter <[e-mail]>]

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:
> 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
>
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn