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

Scott,

great, I think removing the field is the best solution.

Felix

Am 30.05.2018 um 20:54 schrieb Burleigh, Scott C (312B):
> 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
>
> _______________________________________________
> dtn mailing list
> dtn@ietf.org
> https://www.ietf.org/mailman/listinfo/dtn