Summary

  • The 19 September PCAP revision asks to document the legacy capture format as Historic and to register application/pcap. It is an active draft, not a published RFC or completed IANA action.
  • On 23 September, the responsible Area Director returned the document to “Revised I-D Needed” after saying he had not seen a response to his review. The review asks whether the new media type replaces or coexists with application/vnd.tcpdump.pcap and why The Tcpdump Group is named its change controller.
  • A Historic file-format description, a media-type registration and LinkType assignments are different records of authority. None alone proves the provenance of a particular capture.

The proposed application/pcap registration is easy to mistake for a small naming update. It is not yet an assignment. The existing IANA record, application/vnd.tcpdump.pcap, dates from 2011 and names Guy Harris as its author and change controller. Revision 09 of the IETF working-group draft requests a new standards-tree type and names The Tcpdump Group as its proposed controller. Its security section points to the older record without saying whether the names will coexist or one will supersede the other.

That ambiguity was one of several questions in the Area Director’s August review. He also identified an error in the older draft’s nanosecond magic-number byte list; the September revision now shows the corrected sequences. The Datatracker nevertheless records his 23 September observation that no response to the review was visible and moves the document back to AD Evaluation::Revised I-D Needed. That is a process state, not a finding that the format is unsafe, that the revision was rejected, or that any media-type policy has been decided.

The document’s Historic intent is about the evolution path of the file format. PCAP v2 is constrained to one LINKTYPE per file, and its header makes simple concatenation awkward. The companion pcapng draft is designed for extension and multiple interfaces. Yet the PCAP draft explicitly allows newly registered LINKLAYER types inside old-format files. A separate LinkType draft proposes an IANA registry with expert review and initial entries drawn from the libpcap list. Neither companion draft is a published RFC merely because PCAP points to it.

What needs an answer is therefore a four-part crosswalk: which content-type name an archive or tool emits, which registration version authorizes it, who may change that registration, and which LinkType list a reader uses to interpret the bytes. An RFC label cannot silently settle those distinct questions. The older vendor type cannot by itself veto a new registration either. A short explicit disposition in the document and IANA record would let implementers preserve both compatibility and an accountable change history without treating “Historic” as “unusable.”

Sources