Re: MIME type for libpcap (tcpdump -w)

[Guy Harris <guy () alum mit edu>]

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
>    [guy@____.___.___]
>  * Author/Change controller
>    [Guy Harris <guy@____.___.___>]

Or should that be you, Michael?

-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.