"Eric A. Hall" wrote:
http://www.exit109.com/~jeremy/news/binaries/ has an essay
The relevant part of that chain is below. Comments for consideration
should probably be sent directly to the author (jeremy(_at_)exit109(_dot_)com)
or
posted to news.software.nntp. I'm quite sure he would appreciate any help
from MIME wizards. Rants can of course go anywhere.
-**-
application/file-fragment
The MIME type application/file-fragment specifies that a MIME body
contains a fragment of a larger file. The segment must be contiguous. A
collection of application/file-fragment entities can be created by
splitting the original, raw datastream at whatever intervals are
appropriate, and encoding the result with some transfer-encoding in order
to include it in a MIME entity. The divisions must occur at least on byte
boundaries. It may be desirable to only create divisions on boundaries of
multiples of four bytes. (The datastream should be considered an
octet-stream, not a bit-stream.) The segments in a series need not all be
the same size.
For the purposes of this specification, the term series refers to a
sequence of posts, done all at once, containing fragments of the same
file. A complete series contains all of the data from the original file,
and an incomplete series contains only some of the data (as in the case of
a partial repost). A complete series should contain the data in sequence;
that is, the data in part number two should be that immediately after the
data in part number one.
Parameters
application/file-fragment defines the following parameters.
name
Specifies the name of the file. This must have the same value in all
messages in a series, and is required. (However, implementations should be
careful about blindly using the specified filename when saving data to
disk.)
offset
Specifies the starting point of this fragment, in bytes, within the
original (unencoded) data of which this fragment is part. Offsets are
zero-based (the first byte in the file is at offset zero). This parameter
is required.
length
The length, in bytes, of the unencoded data represented by this
fragment. This parameter is required.
number
Where this fragment falls in sequence, in this series of posts. This
parameter is required if the fragment is being posted as part of a series,
whether or not the series is complete with regard to the original file. If
a single fragment of a file is being posted, it need not be used. (Thus,
if not present, its value should be assumed to be 1.)
total
The total number of fragments in this series of posts. As with
number, this parameter is required unless this is the only fragment of the
file being posted. (Thus, if not present, its value should be assumed to
be 1.)
id
Semantically identical to a message-id, this is a unique identifier
for the series of posts. It must be the same in all posts comprising a
series. This parameter is required in any series, and optional if only a
single fragment is being posted. It can be used by a client to locate
other posts in a particular series, and can be used to distinguish between
multiple posts of the same file. It should not be the same as any
message-id of any post in a series. (The reason this parameter is required
is to allow automated searching for other posts in a series by clients.)
md5
Contains the MD5 checksum (as in Content-MD5) of the full,
reassembled, decoded, original file of which this fragment is a part. This
can be used by a client to verify the integrity of the final, decoded
file. It can also be used to locate different posts of the same file
(reposts) in order to fill in "gaps" in in the file, even if the reposts
were done with a different filename, and can be used to differentiate
between different files posted under the same filename. It must be the
same in all posts in a series, and is required (the reason it is required
is to allow automated searching for fragments of a desired file by
clients).
type
Specifies the MIME type of the full file. This parameter is
optional, and should only be included where appropriate (that is, if the
value will not provide any useful information to a client, as in the case
of application/octet-stream, it should not be specified). If it is not
present, the file should be treated as type application/octet-stream.
As an example of what such a header might look like, with all parameters
given (broken onto multiple lines for readability):
Content-Type: application/file-fragment; name=foo.pdf; offset=0;
length=500000; number=1; total=15; id="<ad438c$89ef(_at_)example(_dot_)com>";
md5=7c595c4ea2befbd6f9d0658506207438; type=application/pdf
In addition to the Content-Type header, each application/file-fragment
should have a Content-MD5 header which contains an MD5 checksum of the
(decoded) data contained within that fragment. This can be used to detect
corrupt fragments, so that a client can discard them and look for another
post containing the needed data. Content-MD5 is described in RFC 1864.
Since the checksum is taken from the original data, it should survive
recoding to a different transfer-encoding.
A description of the file can be included in the Content-Description
header (defined in RFC 2045). If it is used in a series (whether complete
or incomplete with regard to the original file), it must be present in the
first post in that series, and is optional in the other segments (and
would be redundant in them). This way, a client looking for a description
of the file need only check the headers of the first post in the series.
A Content-Disposition header, if present, should not contain the filename
of the original file; the header is meant to describe only the entity
within that one message, so it does not apply for that purpose.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/