[pcap-ng-format] The payload of Custom blocks that can have options must have a length or a terminator

[Guy Harris]

It must be possible, for any block containing options, to determine how much data is in the block before the options; the Block Total Length is insufficient for this purpose, as that only tells you how many bytes the block header, data before the options, options, and block trailer contain, not how that's split between data before the options and options.

That can be done either by

	1) having the data before the options include a field from which the length of the data before the option can be computed (this is how the Enhanced Packet Block and the Packet Block work);

	2) having the data before the options be a sequence of items, with a special item type terminating the sequence (this is how the Name Resolution Block works);

	3) having the data before the options be in some *other* format by which its length can be determined.

Should we:

	1) explicitly specify that the data before the options in a Custom Block must begin with a length field (I prefer lengths to terminators, as they make it easier to find out the length, and work even if that data isn't a sequence of items that can have a terminator);

	2) point out in the specification that, if a particular type of Custom Block is to support options, it must be possible for code that can read the block to determine how much of the block payload is data before the options and how much is options?

My inclination is to go with 2), so as not to constrain the developers of Custom Blocks any more than is absolutely necessary to have them support options at all, but I wouldn't be opposed to adding a "data before the options" length field to the Custom Option.