On May 4, 2018, at 2:32 PM, Ahmad Fatoum <ahmad@xxxxxx> wrote:
>> On 4May 2018, at 19:10, Guy Harris <guy@xxxxxxxxxxxx> wrote:
>>
>> That might *also* be useful, but the advantage of blocks that *aren't* tied to Wireshark is that *other* programs can use the data without having to track Wireshark.
>
> I see, but to support multiple protocols in a capture,
"Support multiple protocols in a capture" in what sense?
> some authority that allocates protocol identifiers would be desirable
If this is going to be in pcapng files, the authority would be the pcapng file format maintainers.
> and I think Wireshark protocol names are very suited for this (after renaming SSL to TLS :-).
>
> Maybe:
> - Standardize some prefs_register_key_preference API for key supplement in Wireshark that wraps existing UAT/preference use and provides key preferences in a uniform format
> - Agree on a specific format for those key preferences inside pcapng blocks
Once they're in pcapng blocks, unless the block is Wireshark-specific, the preferences would be managed entirely by the pcapng developers, not the Wireshark developers.
The point here is to have something *independent* of particular packet analyzers.
