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

[Jasper Bongertz]

Hi,

interesting idea, I like it. As long as nobody comes up with a good
reason why this is a bad idea I support it.

Out of curiosity - how/why did you choose those four option code
numbers?

Cheers,
Jasper

> 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/
> _______________________________________________
> pcap-ng-format mailing list
> pcap-ng-format at winpcap.org
> https://www.winpcap.org/mailman/listinfo/pcap-ng-format

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3681 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.winpcap.org/pipermail/pcap-ng-format/attachments/20150722/96a2a058/attachment.bin>