A MIME object is any collection of bits which is put together in a way which adheres to the MIME specification. Some MIME objects may contain other MIME objects nested inside. A MIME compliant agent is any program which can recognize MIME objects and perform appropriate actions on them, depending on the type of object it is.
There are currently seven MIME types registered. These are listed in Table 4.1 on page 34. The main types are intended to categorize most types of data. The application type is intended to hold subtypes which do not fit into the other classes, such as binary data or application specific data. The audio type is intended to contain any subtype which indicates audio data. The image type is intended for bitmapped image data of any type. The message type is used to indicate encapsulated messages of various types. The multipart type is a special type which allows multiple objects to be nested within it. The text type is used for data which is primarily textual. Finally, the video type is used for any time-varying-picture data, possibly with synchronized audio.
Table 4.1: Registered MIME types ---------------------------------------------- MIME Type Used for ---------------------------------------------- application Application specific data audio Audio based data image Bitmapped images message Encapsulated messages multipart An object which contains several other objects text Textual data video A time-varying-picture image ----------------------------------------------
By using the combination of a type/subtype pair, it is possible to characterize the type of data which an object contains. This specification can be further refined by the use of parameters. Parameters can be added to a type/subtype pair to specify options within that subtype. For example, a 300 DPI, 8 bit greyscale GIF image could be specified as "image/gif;dpi=300;bits=8", while a 600 DPI monochrome GIF image could be specified as "image/gif;dpi=600;bits=1".
Table 4.2: Some MIME type/subtype pairs ------------------------------------------------------ MIME type/subtype Meaning ------------------------------------------------------ image/gif Image in CompuServe GIF format image/tiff Image in TIFF format audio/basic Audio in ISDN 8-bit 8kH format text/plain Plain ASCII text application/postscript A Postscript document ------------------------------------------------------
It is possible to distinguish where one object in a multipart message ends and another begins because each object is preceded by a special encapsulation boundary, which is given as a parameter to the multipart object. The final object is then concluded by a closing boundary. The boundary string is specified by the required parameter "boundary" to the multipart object.
The encapsulation boundary consists of a blank line, followed by two hyphens, followed by the string given in the boundary parameter, followed by a newline. Every occurrence of this sequence in the multipart object denotes the beginning of a new sub-object. The MIME headers and body follow immediately after the encapsulation boundary. Any data which precedes the first encapsulation boundary is ignored.
The closing boundary consists of a blank line, followed by two hyphens, followed by the string given in the boundary parameter, followed by two hyphens, terminated with a newline. Any data which follows the closing boundary is ignored.
Boundary strings must be chosen so that they do not occur in the body of the multipart object. Algorithms should be used to choose a boundary string which ensures that this restriction is met. For a more thorough description of multipart and other MIME types, please refer to RFC1521.
Content-Type: multipart/mixed; boundary="=======digboundary====="Every MIME object is required to have this header.
Content-ID: MIT-LCS//MIT/LCS/TR-341.bib
A multipart/digiment consists of a number of application/digiment objects, which are defined in the following section. A minimal multipart/digiment consists of an application/digiment of type page-list, followed by one or more application/digiment parts of varying types. Any object which is not an application/digiment MIME type may be ignored.
Content-Type: application/digiment Content-ID: MIT-LCS//MIT/LCS/TR-341.map start of application/digiment bodyThere are multiple subtypes of application/digiments. Each application/digiment describes some data of the digiment, or a relationship among different data types. The specific type of the application/digiment is specified in the application/digiment headers.
Content-Type: application/digiment Content-ID: MIT-LCS//MIT/LCS/TR-341.parts Version: 1.0 Digiment-type: part-listThe rest of the application/digiment body follows immediately afterwards, without any blank lines.
Table 4.1: Application/digiment Digiment-types ----------------------------------------------------- Digiment-type: Description ----------------------------------------------------- part-list Listing of all the application/digi ments in this digiment bibliography Bibliographic material in RFC1357 format page-map A mapping from VSN to page # page-list A list of pages available in a cer tain format preferred-order A listing of pages or body-list parts in a particular order from various page-list or body-list parts body-list A file which contains multiple pages -----------------------------------------------------
The part-list type is used to describe the contents of the digiment. Each application/digiment which is part of the digiment must be listed in the part-list, or can be ignored. By parsing a part-list, a browser can quickly determine which parts contain data, such as page-lists, and which parts specify structure, such as page-maps. The browser can then build lists of the available page-lists, body-lists and preferred-order types.
A sample bibliography type can be found in section A.2.3 on page 83.
Each distinct data format should have its own page-list, even if it does not contain an entry for each page. For example, if a digiment contained pages 1-15 of a document in greyscale GIF, but also included a separate copy of page 12 in color GIF, the digiment would have two separate page-lists. One would contain a listing for each of the pages 1-15 available in greyscale, while the other would only have an entry for page 12, which is a color GIF. The relationship between pages which contain alternate forms of the same data is maintained in a separate part called a page-map.
The page-list type consists of the MIME type of the individual pages, an page-map, which is associate with the page-list, and a list of pages that are available in the specified data type. Each page is assumed to be in the same format, which is specified by the MIME type. Separate formats should be listed in separate page-lists. Each page-list is also associated with a page-map. Page-maps, which are described in section 4.4.6 on page 42, contain various meta-information about a specific page, as well as preserve relationships between pages which contain the same data, but are in different formats.
Each page has a single entry in the page-list. An entry consists of a Virtual Sequence Number, or VSN, a URL which can be used to access the page data, and a Page Description field. The VSN uniquely identifies a page within a given page-list, and is assumed to have some absolute ordering. That is, a page with a VSN less than a second page should be displayed before the page with the higher VSN and vice-versa. VSNs do not have to be sequential, but must have some absolute relative ordering. The URL field specifies a URL which can be resolved to retrieve the page data. A page-list can have a URL-stem: header, which will be prepended to the URL, so the URL field does not need to be a valid URL by itself; however, the combination of the URL-stem: field and the URL field must create a valid URL which can be resolved to access the page data. Finally, the Page Description field is used to label the specific version of the page. This field is free text and may contain most printable characters and punctuation characters. The page description field is displayed by the browser to label a button, to indicate which version of a page a user is looking at, and which others are available. By clicking on the different buttons, users can view different versions of the same page. For example, page 12 which is in greyscale format might have a page description label of "Standard image", while a color version of page 12 might have a label of "Color image", while an extremely low resolution version might have a label of "Quick preview".
A sample page-list type can be found in section A.2.4 on page 84.
A page-map consists of a mapping for each page in the page-map. Each page has a single entry in the page-map. The entry contains a VSN, a Page Type, and a Page Name. This VSN corresponds to the VSN for a specific page in every page-list which points to this page-map. For example, if page-list A pointed to page-map A', the page with VSN 12 in A would correspond to the map with VSN 12 in A'. In addition, if page-list B also pointed to page-map A', the page with VSN 12 in A would be considered an alternate version of the page with VSN 12 in B. It is permissible for multiple page-lists which all point to a single page-map to have VSN series that do not completely overlap, as long as those VSNs that do overlap refer to the same page in alternate formats and the VSNs that do not overlap refer to pages which are only available in certain formats. This allows flexibility in specifying relationships between pages in various formats, where all the pages may not be available in each format.
The Page Type field can hold one of five values; supporting, title page, unnumbered, an integer number, or unknown. This field can be used by the browser to determine what type of logical page this is. A value of supporting means that the page is not really part of the document, but is used in processing or contains calibration or miscellaneous information. These pages are not normally displayed or printed. A value of title page indicates that the given page is the first or title page for the given digiment. A value of unnumbered means that the page has no page number, while an integer number refers to the actual page number in the document. Finally, unknown indicates that there is no logical information about this page.
Finally, the Page Name field is simply displayed by the browser to indicate which page is currently being viewed. Normally this field will contain the page number, but it may contain "Title page", or a description of a processing control or calibration page.
A sample page-map type can be found in section A.2.5 on page 86.
The body-list type consists of the MIME type of the individual segments, and a list of segments which are available in the specified data type. Each segment is assumed to be in the same type, which is specified by the MIME type. Separate formats should be listed in separate body-lists.
Each data segment has a single entry in the body-list. An entry consists of a Virtual Sequence Number, or VSN, a URL which can be used to access the segment, and a Segment Description field. The VSN uniquely identifies a segment within a given body-list, and is assumed to have some absolute ordering. That is, a segment with a VSN less than a second segment should be displayed before the segment with the higher VSN and vice-versa. VSNs do not have to be sequential, but must have some absolute relative ordering. The URL field specifies a URL which can be resolved to retrieve the segment data. A body-list can have a URL-stem: header, which will be prepended to the URL, so the URL field does not need to be a valid URL by itself; however, the combination of the URL-stem: field and the URL field must create a valid URL which can be resolved to access the segment data. Finally, the Segment Description field is used to label the specific version of the segment. This field is free text and may contain most printable characters and punctuation characters. The segment description field is displayed by the browser to label a button, to indicate at which segment of a document a user is looking. For example, a segment may be named "Chapter 1" or "Chapters 4-7".
A sample body-list type can be found in section A.2.6 on page 88.
The preferred-order type consists of a listing of data objects, along with a Preference Description. Each object has a single entry in the preferred-order list. An entry consists of a Preferred Sequence Number, or PSN, a Content-ID, and a VSN. The PSN specifies the order in which the objects are to be displayed. The first object displayed is the object which corresponds to the lowest PSN, and objects are displayed in order of increasing PSNs. The Content-ID is the content-ID of either a part-list or body-list digiment part. The VSN specifies a specific page or segment from the part-list or body-list part. By using a VSN and Content-ID pair, it is possible to specify any object which is contained in a digiment. Thus, a preferred-order part can specify any arbitrary viewing order of objects contained within a digiment.
The preference description is a free text field which contains a short description of the preferred-order. This text is displayed by the browser to let the user choose which version of the digiment he wishes to view. For example, one preferred-order may have a preference description of "For use with color monitors", while another preferred-order may have a description of "Suitable for high resolution printers".
A sample preferred-order type can be found in section A.2.7 on page 89.