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

[Richard Sharpe]

On Sat, Jun 30, 2012 at 4:32 PM, Guy Harris <guy at alum.mit.edu> wrote:
>
> 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.

Ahhh. The value of dialog. Thank you. That is a more meaty set of objectives.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)