[pcap-ng-format] UTF-8 strings in pcap-NG files - null-terminated or not?

[Guy Harris]

Somebody asked on the Wireshark-dev list

> In a pcapng file, does the string stored in an opt_comment option have
> to be 0-terminated? I couldn't find anything explicit about this in the
> specification. Pcapng options have a length field, therefore I'd guess
> the 0 termination is not required. What do you think?

The Wireshark code to read pcap-NG files assumes UTF-8 strings are not null-terminated, and the spec doesn't say they should be, so I'd be inclined to say that they're not null-terminated, *but* that they shouldn't contain a null character (so that programs in languages/environments with null-terminated strings can handle them).

Either

	1) the spec should say they should be null-terminated *but* say that programs reading files must not assume that they are

or

	2) the spec should say that they're counted and not null-terminated *but* say that they should not contain null characters.

Also, for the if_filter field in the Interface Description Block, if we stay with the field having an initial type byte followed by whatever form a filter of that type takes (note that Wireshark currently writes out that field in that form, using the implied 0x00 value for "libpcap filter string"), if the filter is a libpcap filter string, presumably it should follow the same convention for other strings, i.e. UTF-8, and either null-terminated or counted.  We should also at least specify the code values for libpcap string and BPF code filters, i.e. we should create appendix XXX.