[pcap-ng-format] Plans to finalize pcap-ng 1.1 spec during July

[Guy Harris]

On Jun 30, 2012, at 10:55 AM, Richard Sharpe wrote:

> That being the case, I would like to make two changes to the spec and
> then release 1.1 towards the end of July or early August. Since the
> draft version specifies that it is 1.0, there are captures out there
> that claim to be version 1.0 captures, so we have to rev the spec to
> make any changes.
> 
> 1. Specify that the block total length must be a multiple of four.
> This allows simple minded parses to skip blocks they don't understand
> without having to do any work. This aspect is ambiguous, I believe, in
> the draft spec. It states that the contents of the block must be
> aligned to 32 bits but the wording for the block total length does not
> stipulate that, and there are example captures where the length is
> two-byte aligned.

...which means that any code that reads pcap-ng files needs to either

	1) handle a block total length that's not a multiple of 4;

	2) reject 1.0 files out of hand without going past the SHB;

	3) fail as soon as they see a block with a length that's not a multiple of 4.

If we're going to use the 1.1 spec to deal with ambiguities and other errors, I'd also like to see us:

	specify whether UTF-8 strings in pcap-ng files must be null-terminated or if it's sufficient for them to be counted (they all have lengths, so null-termination is redundant, and any program that reads pcap-ng files has to *somehow* handle non-null-terminated strings, either by rejecting them or by adding a null if the program is using string processing operators that require null terminators, so my inclination is *not* to require null termination);

	explicitly state that the "record length" in the Name Resolution Block is the length of the record *value*, not the record as a whole (including the record type and length);

	note that a Simple Packet Block can have options (section 2.5 says "*All* the block bodies have the possibility to embed optional fields.", emphasis mine) and therefore that

		The amount of packet data is the minimum value among the SnapLen (present in the Interface Description Block) and the Packet Len (present in this header).  The length of the Packet Data field is the amount of packet data, rounded up to a multiple of 4 bytes.

	note that software that reads pcap-ng files must not assume that no packet will have more packet data than the SnapLen for the interface on which they arrived (i.e., do *NOT* allocate a buffer with the SnapLen as its size and blithely copy data from a packet block ito that buffer);

as per some other messages I sent to the list.

In addition, we should get rid of Appendices C and D and, instead, point to

	http://www.tcpdump.org/linktypes.html

as the official registry of link-layer header types.

> However, I wonder if we should simply issue a final 1.0 version of the
> spec with just the changes to specify a mechanism for changing the
> spec?

...and perhaps those changes listed above that resolve ambiguities (*IF* we decide that UTF-8 strings are counted and not null-terminated, I would consider that a change to put into 1.0, as code that reads 1.0 files has to handle non-null-terminated strings already), as well as the removal of Appendices C and D.