ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] New RFCs for 1) pcap file format and 2) rpcapd protocol?

From: Eliot Lear <lear@xxxxxxxxxxxxxxxxxxx>
Date: Sun, 22 Mar 2020 12:25:38 +0100
This very much depends on how stable you wish the spec to be.  If you
want to to be entirely osified, I recommend actual RFCs.  Otherwise,
perhaps a renamed team like "pcap-format" (or whatever the people on the
team want to call it)?

Eliot

On 21.03.20 22:15, Guy Harris wrote:
> There should probably be RFC-style specifications for 1) the pcap file format and 2) the rpcapd protocol used for remote capturing.
>
> Currently, on GitHub, there's a "pcapng" team:
>
> 	https://github.com/pcapng
>
> with one repository containing the pcapng specification, and a "the-tcpdump-group" team:
>
> 	https://github.com/the-tcpdump-group
>
> with repositories for libpcap, tcpdump, and the tcpdump.org Web site.
>
> It makes sense to me to keep those specifications on a site such as GitHub; GitHub comes to mind first because that's where pcapng currently is.
>
> The options I see are:
>
> 	1) add them as repositories to the pcapng team;
>
> 	2) add them as repositories to the the-tcpdump-group team;
>
> 	3) give them each their own teams.
>
> I see pcapng - and the pcap file format and rpcapd protocol - as not being directly tied to libpcap.  *Historically*, pcap originated as the format that libpcap read and wrote, and rpcap was a protocol initially implemented in the WinPcap derivative of libpcap, but:
>
> 	1) pcapng arose independently, and one of the earliest implementations was in Wireshark (where the internal APIs were easier to change; libpcap's support currently works through the existing API, but that hides a lot of the capabilities of pcapng);
>
> 	2) code other than libpcap code reads and writes pcap files (including, but not limited to, Wireshark's code);
>
> 	3) some devices either implement an rpcap server or could perhaps usefully do so, and they might have reasons to have independent implementations rather than basing their implementations on libpcap's rpcapd.
>
> So I'm not inclined to go with option 2) - and if we do go with option 2), whatever arguments are offered for that would probably apply to pcapng as well, so it would, in that case, make sense to move the pcapng repository to that team as well.
>
> 1) has the slight disadvantage that the name for the team suggests it's for pcapng only; it appears that teams can be renamed:
>
> 	https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/renaming-a-team
>
> Were we to rename it, I don't know what would be a good new name.
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>

Attachment: signature.asc
Description: OpenPGP digital signature