[pcap-ng-format] Proposal for new "custom" option codes

[Hadriel Kaplan]

On Wed, Jul 22, 2015 at 1:54 PM, Guy Harris <guy at alum.mit.edu> wrote:
>
> And the rationale for this is?
>
> Is the idea that this would be the right way for a vendor to implement vendor-specific options, rather than picking a random option number with the MSB set (which means there's a risk of collision between vendor-specific options) or requesting that the pcap-ng maintainers allocate an option for them (which means more process to go through)?

Yup, exactly. In hind-sight, I think one would conclude the MSB flag
concept for block/option codes was a bad idea. The draft says it means
the block/option is "reserved for local use by the application", which
is a rather meaningless statement, imo.  It's a *file*, and there is
no way to force a file to remain "local"... and to an application all
files are "local". :)

I think we need a way for blocks/options:
 1) To survive file "re-writing" - i.e., being merged, filter-based
exported, etc.
 2) To be understood on other machines, if the same vendor's
pcapng-reader/plugin is used.
 3) To at least let the human user know what to google for if they’re
not understood.
 4) To be potentially well-known someday, so that others can decode or
use them; without colliding with other options.
 5) To apply to any Block type, without colliding with other option
code numbers.

What triggered this though is a proposed change someone uploaded to
Wireshark's gerrit review site recently, to enable hooking a dissector
into the frame's comment - because they were putting information in
the frame comments that they wanted to read back when opening a file.
(i.e., it was info for their program code, not really for the human
user)  Since I had also been tempted to do that in the past, for Lua
plugins in wireshark, I thought we might as well have a real field for
such things instead of overloading the comments in evil ways.

-hadriel