(RFC 2045 and 2046 published November 1996, subtype last updated April November 1996)
The "octet-stream" subtype is used to indicate that a body contains
arbitrary binary data. The set of currently defined parameters is:
(1) TYPE -- the general type or category of binary data.
This is intended as information for the human recipient
rather than for any automatic processing.
(2) PADDING -- the number of bits of padding that were
appended to the bit-stream comprising the actual
contents to produce the enclosed 8bit byte-oriented
data. This is useful for enclosing a bit-stream in a
body when the total number of bits is not a multiple of
8.
Both of these parameters are optional.
An additional parameter, "CONVERSIONS", was defined in RFC 1341 but
has since been removed. RFC 1341 also defined the use of a "NAME"
parameter which gave a suggested file name to be used if the data
were to be written to a file. This has been deprecated in
anticipation of a separate Content-Disposition header field, to be
defined in a subsequent RFC.
The recommended action for an implementation that receives an
"application/octet-stream" entity is to simply offer to put the data
in a file, with any Content-Transfer-Encoding undone, or perhaps to
use it as input to a user-specified process.
To reduce the danger of transmitting rogue programs, it is strongly
recommended that implementations NOT implement a path-search
mechanism whereby an arbitrary program named in the Content-Type
parameter (e.g., an "interpreter=" parameter) is found and executed
using the message body as input.