Re: [dtn] "Block data length" field in BPbis

Felix, sorry, I am finally replying to this email: you are right that CBOR representation would provide all of the individual lengths of the block-type-specific data fields that are summed in the block data length field, and as such the block data length field is redundant.  My first impulse on re-reading your email was simply to revise the definition of "Block data length" as you suggest.  But on reflection I think it actually makes more sense to remove block data length from the specification and instead specifically require that all block-type-specific data fields appear in CBOR representation.

I want to post version 11 of this specification later today, before version 10 expires, and at this point I plan to go ahead with removal of the block data length field.  If anyone has a technical argument to make in defense of retaining block data length in bpbis, please speak up this afternoon?

Scott

-----Original Message-----
From: dtn <dtn-bounces@ietf.org> On Behalf Of Felix Walter
Sent: Friday, March 23, 2018 9:22 AM
To: dtn@ietf.org
Subject: [dtn] "Block data length" field in BPbis

Hi,

We just had a short talk with Scott, Ed, and Rick about the "Block data length" [1] field of the canonical block in BPbis that I would like to forward to the list. As far as I understand it, this value is the count of (serialized) bytes still belonging to the block, but following the length field.

Because CBOR is used for the block-type-specific data, the length field by itself is redundant. For example, in the payload block, it will always be followed by a "CBOR byte string" representing the payload data. (This contains a length as well.) It needs to be considered in implementations that all these length fields are variable-length themselves - however, this turned out to be no big issue. I also see the point of having the "Block data length"
available to the parser, to be able to skip over the whole block data of complex extension blocks without even parsing them.

Are there any further reasons for having the "Block data length"
available which I have missed? Or does anyone have a strong opinion on whether this should be removed or kept?

By the way, the language concerning the "Block data length" should probably be modified slightly as it refers to "[...] the aggregate length of all remaining fields of the block, i.e., the block-type-specific data fields.", though, this may (now) be followed by the CRC checksum.

Felix

[1] https://tools.ietf.org/html/draft-ietf-dtn-bpbis-10#section-4.2.3

_______________________________________________
dtn mailing list
dtn@ietf.org
https://www.ietf.org/mailman/listinfo/dtn