Penango, Inc.

5900 Wilshire Boulevard 21st Floor Los Angeles CA 90036 USA dev+ietf@seantek.com http://www.penango.com/

matthew@kerwin.net.au http://matthew.kerwin.net.au/

General Internet-Draft This document defines a new top-level media type to be known as “archive”, which defines a fundamental type of media with unique presentational, hardware, and processing aspects.

The purpose of this memo is to update and to include a new top-level media type to be known as “archive”. describes mechanisms for specifying and describing the format of Internet Message Bodies via media type/subtype pairs. “archive” defines a fundamental type of media with unique presentational, hardware, and processing aspects. Various subtypes of this top-level type are immediately anticipated, and will be covered under separate documents.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in .

The archive top-level media type identifies a container of one or more data objects and metadata about them. Archives are used to collect multiple data objects together into a single object for easier portability and storage. Archive formats can provide many optional services, including: compression encryption authentication backup and restoration filesystem imaging software packaging and distribution volume-splitting (archive split into multiple objects) block storage Formats and techniques that support one or more of these services already exist under separate registrations. For example, the Content-Encoding header can be used to signal compressed Internet message content. The distinguishing feature of the archive top-level type is that these services are integrated into the format itself, along with the inclusion of object-specific metadata. Formats contemplated under this top-level type are designed to concatenate multiple objects into a single data stream, along with names and other metadata. When an Internet-facing application handles content labeled with this type, it SHOULD treat the archive as a discrete data item. For example, an Internet mail user agent might display an archive-labeled type with an archive icon, possibly with a preview of the objects contained therein, as opposed to automatically extracting its contents.

Unrecognized subtypes of archive SHOULD be treated as “archive/file”. Like “application/octet-stream”, the purpose of the “archive/file” type is to provide default handling; it does not represent a particular archive format. Implementations SHOULD defer handling of unrecognized subtypes of archive to a robust general-purpose archive processing application, if such an application is available. If default archive handling is not supported, the archive MAY be treated as if it were “application/octet-stream”. Unless noted in the subtype registration, subtypes of archive MUST be assumed to contain binary data, implying the use of base64 content encoding for email and binary transfer for ftp and http.

The formal syntax for the subtypes of the archive top-level type SHOULD look like this: archive xxxxxxxx none TBD base64 encoding is recommended when transmitting archive/* documents through MIME electronic mail. see below TBD TBD The considerations of this document, plus any extra syntaxes not inconsistent with this document. (Include non-archive alias names, such as those in application.) Magic number(s): TBD File extension(s): TBD Macintosh file type code(s): TBD See for references to some of the expected subtypes. TBD TBD (COMMON will be the most common) TBD TBD TBD (Yes/No) (Any other information that the author deems interesting may be added below this line.) The optional parameters consist of starting conditions and variable values used as part of the subtypes.

Archive formats usually include parameteric meta-data within the format. Consequently, subtypes of archive SHOULD NOT specify the same information as parameters to the type. Some archive formats are very old, or are designed to be backwards-compatible with older formats, and as such might not have been designed with transport across the Internet in mind. For example, modern versions of the ZIP file format include support for the Universal Character Set , however the default encoding of filenames within a ZIP archive has always been Code Page 437 . Due to the historical nature of archives, and to support interoperability with older implementations, sometimes it is preferable to communicate the archive as-is, rather than updating it to a more modern or universal format. Implementations that are archive-type aware MUST support the following parameters for maximum compatibility. At the same time, new archive types SHOULD NOT rely on these parameters for disambiguation; new archive types SHOULD be designed in such a way that “universal” interoperability is achieved using information contained within the archive format itself. [[TODO: write this list]] Code Page – like charset but only applies to certain strings in the archive, when the archive format is ambiguous. Do not attempt to apply this parameter as one would apply charset to text/* Endianness? Time/Y2K representation issues? Anything else?

Several archive formats (notably RAR and ZIP) support split archives. A “split archive” can be stored in multiple files, or more generally, across multiple storage media. For example, the ZIP format supports two types of splits: “split archive” and “spanned archive”. A “split archive” is a standard ZIP archive split over multiple files using file extensions .z01, .z02, etc.; the final file in the sequence uses the .zip file extension. The “spanned archive” was designed for use on floppy disks with restrictive space limitations; all archive files have the same filename, and volume labels (presumably on floppy disks) are used to store sequence information. Neither sub-format is merely a naive division of the octet stream: each ZIP file is parseable in its own right, and contains its own offset values. The TAR format (or family of formats, including cpio and ustar) was originally designed for streaming to and from tape devices, so splitting is accomplished differently. [[TODO: Consider how to label this content. archive/zip^01? archive/zip; split=01? Something else? How shall 01 be associated with 02, 03, etc., when the Content-Disposition: ; filename=”” parameter is “presentation-information” and may be separated from the Content-Type header information?]]

As archives usually store objects in hierarchical structures similar to filesystems, archives can serve as virtual filesystems. Respondents have noted that the objects stored in an archive can be addressed by a fragment syntax that resembles a filesystem path. At the same time, archives can store objects in different ways (along with different types of metadata), suggesting that a common baseline with flexible extension points is more appropriate than a fixed universal syntax. [[TODO: This will be explored in future drafts. Note the similarities with this and the file: URI…]] [[TODO: consider how to provide a fragment for content in the archive. NB: most archives do NOT provide Content-Type/media type information! So /foo.html being an HTML file is just an assumption, and possibly a very wrong one at that. There is no IETF registry for file extensions.]]

[[TODO: discuss tar piped through bzip2, gzip, etc. as a distinct file format, rather than an application of the Content-Encoding: header. Suggest common suffix like archive/tar|bzip2, where | is some useful character but not + since + is for structured syntaxes.]]

Archives can store files, file metadata, and even entire filesystems; thus, security issues loom large because archives can contain just about anything. These concerns are magnified by the arbitrary transport of such data across the Internet. [[TODO: complete.]]

Innosoft International, Inc.

1050 East Garvey Avenue South West Covina CA 91790 US +1 818 919 3600 +1 818 919 3614 ned@innosoft.com

First Virtual Holdings

25 Washington Avenue Morristown NJ 07960 US +1 201 540 8967 +1 201 993 3032 nsb@nsb.fv.com

STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for (1) textual message bodies in character sets other than US-ASCII, (2) an extensible set of different formats for non-textual message bodies, (3) multi-part message bodies, and (4) textual header information in character sets other than US-ASCII. These documents are based on earlier work documented in RFC 934, STD 11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822. This initial document specifies the various headers used to describe the structure of MIME messages. The second document, RFC 2046, defines the general structure of the MIME media typing system and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final document, RFC 2049, describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography. These documents are revisions of RFCs 1521, 1522, and 1590, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions. Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Note that the force of these words is modified by the requirement level of the document in which they are used. This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. International Organization for Standardization Microsoft Developer Network

The following archive formats will be explored for registration as subtypes along with this effort: TAR ZIP, ACE, RAR, 7-Zip, StuffIt, FreeArc MSI, RPM, JAR, XPI, CAB, CRX, APK ISO, NRG, BIN/CUE, VMDK, WIM, PartImage, IMG/IMA/IMZ, DMG

Changes since -00 retool to use XML2RFC – lots of layout changes remove large sections of text, as suggested by Ned Freed and Dave Crocker replace “primary” with “top-level”, and “content-type” with “media type” throughout add reference to RFC 6838 (BCP 13) - Media Type Specifications and Registration Procedures lots of editorial changes