Previous chapter

Chapter 4

Chapter 4

The Digiment MIME types

The Digiment MIME types

This chapter outlines the function and purpose of the different MIME types which make up a digiment. A specification of the actual types can be found in Appendix A on page 81.

4.1 What is MIME?

MIME stands for Multipurpose Internet Mail Extensions, which was defined by RFC1341, and later revised in RFC1521, and was originally developed to allow Internet email messages to contain images, sounds, applications and other data types besides plain text. In addition, it was designed to work around current limitations in Internet mail gateways. Existing Internet mail gateways have been designed to deal with messages which have been formatted according to the RFC822 email specification, which limits line length to 79 characters and the character set to 7-bits. These limitations prohibit the transfer of files which may include 8-bit characters or any arbitrary binary data.

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.

4.1.1 MIME types

All MIME objects have a "type/subtype" pair associated with them. This allows a MIME compliant agent to determine what format the object is in and take appropriate action. For example, if an object has a type which specifies that it is a TIFF image, the agent can either display the image itself, if it is capable, or it can pass the object to another program which it knows can display TIFF images. This system of assigning types to every object allows an agent to keep a table of default actions for each MIME type which it knows about. The action can be either to handle the type internally, or to call "helper" applications, which it knows can process objects of that type.

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       
                                                
----------------------------------------------

4.1.2 Subtypes and parameters

Each of these main MIME types can have an unlimited number of subtypes, which describe the specific type of object within the general class. Some example MIME type/subtype pairs are shown in Table 4.2 on page 35.

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           
                                                        
------------------------------------------------------

4.1.3 The multipart MIME type

The multipart MIME type is special in that it indicates that an object with this type actually contains multiple other objects, each of which have their own MIME type. The most commonly used subtype for multipart is multipart/mixed, which indicates multiple independent objects are contained within, intended to be viewed serially. Another type, multipart/alternative has similar semantics, but indicates that the individual objects are representations of the same data in alternative formats.

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.

4.2 MIME Headers

A MIME object consists of a set of headers which describe the contents of the object, followed by a blank line, followed by the contents of the object. Two headers in particular are used very often; Content-Type and Content-ID.

4.2.1 Content-Type

The way in which a MIME object specifies its type is with the header Content-Type:, followed by the MIME type/subtype pair. This should be the first line in the headers. A typical multipart object would be typed like this:

Content-Type:      multipart/mixed; boundary="=======digboundary====="
Every MIME object is required to have this header.

4.2.2 Content-IDs

Each MIME object can have an ID associated with it. This ID should be as world-unique as possible and can be used to refer to a particular MIME object. This is especially useful for caching and for multipart objects which want to refer to each other. The ID is specified by a line with the header Content-ID:, followed by the ID. Thus, a typical content ID would look like this:

Content-ID:      MIT-LCS//MIT/LCS/TR-341.bib

4.3 The multipart/digiment type

I define multipart/digiment to be the base MIME type for a digiment. When transferring a digiment, the type used should be multipart/digiment. The multipart digiment is syntactically equivalent to the multipart/mixed type, but with different semantics. The only type allowed within a multipart/digiment is application/digiment. The use of multipart/digiment instead of multipart/mixed is to differentiate a digiment from a random multipart message. This special subtype allows MIME agents to detect a multipart/digiment and pass the entire multipart object to a browser which understands digiments. If a digiment used a standard MIME multipart subtype, a MIME agent may extract the individual parts from the multipart/digiment, which are not useful by themselves. When referring to a "digiment", we are actually referring to the multipart/digiment object which contains all the other data objects; the whole is known as the digiment.

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.

4.4 The application/digiment type

The application/digiment type is the meat of the digiment. A digiment is made up of a collection of application/digiments which describe the available data formats for the digiment and the relationships among them. Each application/digiment consists of two MIME headers; a Content-Type: of application/digiment, and a Content-ID with a globally unique ID. These headers must always be present. Following these headers is a blank line and the body of the application/digiment. Thus, the beginning of an application/digiment would look like this:

Content-Type:      application/digiment
Content-ID:      MIT-LCS//MIT/LCS/TR-341.map
start of application/digiment body
There 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.

4.4.1 Application/digiment headers

Each digiment-type has the same first two lines as a header. The first line must contain the tag Version:, followed by the version number. This document describes version 1.0 of each digiment-type. The only current legal version number is 1.0. Any future version may describe a different format and must be described in a separate document. The second line must contain the tag Digiment-type: followed by a legal digiment-type. The currently defined types are described below, as well as being listed in Table 4.1 on page 39. Thus, a correct part-list application/digiment would start like this (including the MIME headers):

Content-Type:      application/digiment
Content-ID:      MIT-LCS//MIT/LCS/TR-341.parts
Version:      1.0
Digiment-type:      part-list
The rest of the application/digiment body follows immediately afterwards, without any blank lines.

4.4.2 Summary of digiment-types

These types are designed to cover the common cases for digiment delivery. However, they are certainly not a complete set of all possibilities for capturing all the various types of data and relationships between types which may be delivered. Therefore, it is expected that this set will be expanded by future types to enhance the flexibility of delivery options and capture more data. The following table is a complete listing of the types defined in this document.

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                                 
                                                       
-----------------------------------------------------

4.4.3 The part-list type

The part-list type is the only required type of application/digiment in a digiment, and must be the first part in a digiment. This type contains a listing of each of the other application/digiments in the digiment, with their Digiment-type and Content-ID. In addition, types which contain data, such as a page-list or body-list, may also have the MIME type of the data included as a hint.

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.

4.4.4 The bibliography type

The bibliography type is meant to contain bibliographic and other meta-information about the document which is not otherwise found in the body of the document. This can include the authors, the title, date of publication, number of pages, the abstract, copyright notices, and other types of information about the document. The information is stored in the standard bibliographic format used by the CSTR project, which is defined by RFC1357 [4]. The bibliography type allows a digiment browser to extract this information easily from the digiment. The information can then be used to help display the digiment.

A sample bibliography type can be found in section A.2.3 on page 83.

4.4.5 The page-list type

The page-list type is the main digiment-type used for specifying page-based data. Page-based data refers to any data which is accessible a single page at a time. This type was originally intended for image based data, such as a document which has been scanned, but may be used for any data type which is available a page at a time. For example, a document may be available in Postscript form, which would be specified in a body-list. Normally, a client would have to download the entire Postscript file to view a single page. However, a server may be able to serve a single page of a Postscript version of a document at a time. The entire Postscript version could then be listed as a page-list and accessed a page at a time, permitting additional information to be assigned to each page and allowing finer control of the relationships between different versions. This also has the advantage of not requiring an entire body-list part to be transferred to view a single page, making for more effective use of bandwidth.

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.

4.4.6 The page-map type

The page-map type includes extra data about a specific page, and is used to relate different versions of the same page together. Multiple page-lists can share a single page-map; this is how multiple pages can indicate that they refer to the same virtual page. Page-maps are also used to describe the type of page, as well as provide the page number.

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.

4.4.7 The body-list type

The body-list type is similar to the page-list type, but it is used to specify data segments that contain multiple pages, or are not page based. For example, a Postscript version of a document would be placed in a body-list. However, sometimes a segment may contain only part of a document, such as a Postscript file for each chapter in a document. In this case, a body-list will contain an entry for each file which makes up the document.

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.

4.4.8 The preferred-order type

The preferred-order type is used to specify a preferred sequence of data objects for the browser to display. Although page-lists and body-lists can do this, they are limited to only specifying pages or segments which are in a specific format. By using a preferred-order type, a digiment can specify a sequence of objects which are listed in any page-list or body-list in the digiment. For example, a digiment can specify that a preferred viewing order is pages 1 through 5 from page-list A, pages 6 and 7 from page-list B, segment 3 from body-list C, and pages 8 through 45 from page-list A. Digiments may contain multiple preferred-order parts. Thus, another preferred-order may be identical to the previous one described, but use page-list C instead of page-list A.

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.

Next chapter