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

[Hadriel Kaplan]

Howdy,
I'd like to propose a couple new option codes be allocated for a
"Custom String Option" and "Custom Binary Option", and the format be
specified/added to the draft.

The format I'd like to propose is this:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Custom Option = XXX       |         Option Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Private Enterprise Number (PEN)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                       Custom payload                          /
   /              variable length, padded to 32 bits               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


This format would be common to both the "Custom String Option" and
"Custom Binary Option". The PEN field is an IANA-allocated PEN number,
and would be the PEN of the creator of the option in the file.
Multiple such options may be in the file, using the same or different
PEN numbers. The option may appear in any block type, and multiple
times in the same block.

Fundamentally the two different options are semantically equivalent,
except the "Custom String Option" contains a UTF-8 string in its
custom payload, whereas the "Binary" one contains arbitrary bytes. The
rationale for this separation is that an appplication which does not
understand the specific PEN's custom option can still display it to a
human as a string if it's a string type, rather than as hex-ascii of
the bytes.

I propose the option code number 2988 be reserved for "Custom String
Option", and 2989 for "Custom Binary Option". I'd also like to reserve
the option codes 19372 and 19373, for the same options but with the
added semantic of "do not copy", meaning a PCAPNG file merger/editor
application would not copy the options with the codes 19372 or 19373
to the new file.

I can, of course, supply text for the draft for this change as well.

There are a couple of proposed code changes for Wireshark/tshark for
this proposal [1], but they're still a work in progress and will be
changed to support whatever the final code number(s) and format are.

-hadriel

[1] https://code.wireshark.org/review/#/c/9729/ and
https://code.wireshark.org/review/#/c/9731/