On Nov 3, 2010, at 9:50 PM, Glen Turner wrote: > 2. Subtype name (See Existing subtype names) > See also RFC 2046, and RFC 4288, sections 3 and 4.2. > Note: Registrations in the standards tree must be approved by the > IESG and must correspond to a formal publication by a recognized > standards body. > Vendor Tree - [vnd.tcpdump.org-libpcap]
I might be tempted to call it vnd.tcpdump.org-pcap - the file format is often referred to as just "pcap format", and code to read and write it other than libpcap exists (e.g. the code in Wireshark; you could also count WinPcap, although you could also argue that it's a port of libpcap, not a separate implementation). That would also match the name of the pcap-ng file format (for which there should also be a media type at some point). > 3. Required parameters > See RFC 2046 section 1, and RFC 4288, section 4.3 > [] > > > 4. Optional parameters > See RFC 2046 section 1, and RFC 4288, section 4.3 > [] Or "None", if necessary. I can't think offhand of any parameters that would be needed. > 7. Interoperability considerations > See RFC 4288, section 4.5 > [ > A network protocol capture is written in host byte order. The first > four bytes form a magic number. 0xa1b2c3d4 indicates that the reader > has the same byte order as the writer. 0xd4c3b2a1 indicates that the > reader has a different byte order from the writer and should swap > bytes as it reads. You should probably note that "should swap bytes" refers to the file header, the per-packet record headers, and, for a few link-layer types, the link-layer header; most data in the packet should not be byte-swapped based on the magic number. > The accuracy and resolution of the time stamp on each packet depends > upon the host and its operating system. > > The header contains major and minor version numbers to allow a reading > program to determine if it is compatible with the media. A reading > program is not compatible if it encounters a major version number > greater than it expects. > > Data link types are assigned by tcpdump.org and can be viewed in the > file pcap/bpf.h of the libpcap code. Actually, those are the data link types presented to applications by the pcap_datalink() API and used in the pcap_open_dead() API. The data link types in pcap files are the LINKTYPE_ values in the pcap-common.c file in the libpcap code. *Most* DLT_ types have the same numerical value as the corresponding LINKTYPE_ types, but there are some exceptions (for binary compatibility with applications using pcap_datalink() and pcap_open_dead() on some platforms - some platforms chose different numerical values for the same DLT_ #define). > The data link types DLT_USER0 to > DLT_USER15 are reserved for local use and thus are intentionally not > interoperable. > ] (Which would become LINKTYPE_USER0 through LINKTYPE_USER15.) > 8. Published specification > See RFC 4288, section 4.10 > [ > See "Libpcap File Format" at > <http://wiki.wireshark.org/Development/LibpcapFileFormat>. ...or the pcap-savefile man page in the libpcap source. > 10. Additional information > See RFC 4288, section 4.11 > * Magic number(s) > [0xa1b2c3d4, 0xd4c3b2a1] > > * File extension(s) > [.pcap, .cap, .dmp] > > * Macintosh File Type Code(s) > [] We don't have any. (And we probably never will; file type codes are obsolete, Uniform Type Identifiers are the way to go has the IETF gotten the memo yet? http://developer.apple.com/library/mac/#documentation/FileManagement/Conceptual/understanding_utis/understand_utis_intro/understand_utis_intro.html although we don't yet have a UTI for pcap files. At least two MIME type registrations: http://dev.w3.org/SVG/profiles/1.1F2/publish/mimereg.html http://www.w3.org/TR/2009/WD-MathML3-20090924/appendixb.html do include UTI codes, as well as Windows clipboard names.) > * Object Identifier(s) or OID(s) > (See RFC1494) > [] ...or "None". > Person to contact for further information > See RFC 4288, section 4.9 > * Name > [Guy Harris] > * E-mail > [...@____.___.___] > * Author/Change controller > [Guy Harris <g...@____.___.___>] Or should that be you, Michael? - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
