[pcap-ng-format] Addition of new content

[Guy Harris]

On Sep 4, 2015, at 6:41 AM, Michael Haney <michael-haney at utulsa.edu> wrote:

> On September 4, 2015 2:05:35 AM MDT, Guy Harris <guy at alum.mit.edu> wrote:
>> 
>> On Sep 3, 2015, at 10:23 PM, Michael Haney <michael-haney at utulsa.edu>
>> wrote:
>> 
>>>> capinfos network-tap.pcapng
>>> capinfos: Can't open network-tap.pcapng: The file isn't a capture
>> file in a known format
>> 
>> That's the wrong report - it *should* have said that it was a pcapng
>> file with an unsupported *version*.
>> 
>> Which version of capinfos was that?
> 
> capinfos from the wireshark-dev package on Ubuntu 14.04-lts.
> Wireshark v1.10.6.

Sadly, that's not fixed in the 1.12 branch, although it's fixed in the trunk; I'll see whether the fix can be backported.

> Yep, I agree.  v1.0 allows for custom and private blocks, and I'm
> creating a v1.0 compatible file.  It's not the same as application
> version numbers with additional features.

(Application version numbers are significantly marketing-driven.

*Library* version numbers, at least in UN*Xes where they're visible to the dynamic linker, are more like what you're thinking of there; they aren't something a marketer can arbitrarily change, as they affect the functioning of software.

In the SunOS 4.x versioning system (which influenced the SVR4 versioning system used by ELF-based UN*Xes), if new features are added to a library, so that programs built with the new version might not work with the old version, but programs built with the old version will still work with the new version, the minor version is changed.  (Programs built with the new version, *not* using the new features, should still work with the old version, so the run-time linker only printed a warning in that case.)  The major version is changed if existing APIs are changed in incompatible ways, such as adding a new argument.)

> I see that more clearly
> now.  I guess I was assuming v1.1 would be only an extension of v1.0
> with new block types, and not a correction or change of an existing
> block type.  That would clearly make a difference in how tools try to
> process files.

Yes, what the spec currently says about the version numbers is:

	http://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?url=https://raw.githubusercontent.com/pcapng/pcapng/master/draft-tuexen-opsawg-pcapng.xml&modeAsFormat=html/ascii&type=ascii#rfc.section.4.1

"The meaning of the fields is:

	...

	* Major Version: number of the current mayor version of the format. Current value is 1. This value should change if the format changes in such a way that tools that can read the new format could not read the old format (i.e., the code would have to check the version number to be able to read both formats).
	* Minor Version: number of the current minor version of the format. Current value is 0. This value should change if the format changes in such a way that tools that can read the new format can still automatically read the new format but code that can only read the old format cannot read the new format."

Perhaps we should clarify that "cannot read" means "cannot handle simply by ignoring, or blindly passing through as appropriate, blocks or options that it doesn't understand".