SGML: The MIME Multipart/Related Content-type
MIMESGML Working Group E. Levinson
Internet Draft: Multipart/Related ACCURATE Info. Sys.
<draft-ietf-mimesgml-related-01.txt> May 30, 1995
The MIME Multipart/Related Content-type
This draft document is being circulated for comment. Please
send your comments to the authors or to the ietf-822 mail
list <ietf-822@822@dimacs.rutgers.edu>. If consensus is
reached, this document may be submitted to the RFC editor as
a Proposed Standard protocol specification for use with
MIME.
Status of this Memo
This document is an Internet Draft; Internet Drafts are
working documents of the Internet Engineering Task Force
(IETF) its Areas, and Working Groups. Note that other
groups may also distribute working documents as Internet
Drafts.
Internet Drafts are draft documents valid for a maximum of
six months. They may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use
Internet Drafts as reference material or to cite them other
than as a "working draft" or "work in progress".
Please check the abstract listing in each Internet Draft
directory for the current status of this or any other
Internet Draft.
Abstract
The Multipart/Related content-type provides a common
mechanism for representing objects that are aggregates of
related MIME body parts. This document defines the
Multipart/Related content-type and provides examples of its
use.
1. Introduction
Several applications of MIME, including MIME-PEM, and MIME-
Macintosh and other proposals, require multiple body parts
that make sense only in the aggregate. The present approach
to these compound object has been to define specific
multipart subtypes for each new object. In keeping with the
MIME philosophy of having one mechanism to achieve the same
goal for different purposes, one single mechanism should be
defined for such aggregate or compound objects.
The Multipart/Related content-type addresses the MIME
representation of compound objects. Basically, two pieces of
information are required, the "root" or starting body
part(s), and an indication of the object type.
Levinson Expires December 31, 1995 [Page 1]
Internet Draft Multipart/Related
2. Definition
The following form is copied from RFC 1590, Appendix A.
To: IANA@isi.edu
Subject: Registration of new Media Type content-type/subtype
Media Type name: Multipart
Media subtype name: Related
Required parameters: None.
Optional parameters: Start, an ordered list of content-IDs.
Type, a media type/subtype
Encoding considerations: 1. Multipart content-types cannot have
encodings.
Security considerations: Depends solely on the referenced type
Published specification: This document
Person & email address to contact for further information:
Document authors
3. Intended usage
The Multipart/Related Content-Type is intended for compound
object consisting of several inter-related body parts. For
a Multipart/Related object, proper display cannot be
achieved by individually displaying the constituent body
parts. The actual content-type of the Multipart/Related
object is specified by the content-type of the "root" or
starting body parts. The "start" parameter, if given,
points, by content-id, to one or more body parts that
contain the object root. The default root is the first body
part within the Multipart/Related body. The content-type
header of the first of the start body part may also specify
additional object information.
The relationships among the body parts of a compound object
distinguishes it from other object types. These
relationships are often represented by links internal to the
object's components that reference the other components.
Within a single operating environment the links are often
file names, within a MIME message content-ids can serve the
same purpose. A companion piece [CID] discusses the use of
content-ids in such objects.
3.1. The Start Parameter
The start parameter, if given, lists the content-ID of the
Levinson Expires December 31, 1995 [Page 2]
Internet Draft Multipart/Related
compound object's "root". The root may consist of one or
more body parts, in which case the start parameter consists
of a comma separated list of content-IDs. In that case the
first listed body part specifies the object type.
3.2 The Type Parameter
The type parameter must be specified if the start parameter
is present. It permits a MIME user agent to determine the
content-type without reference to the enclosed body part.
Where the content-type of the object root and the one
indicated by the type parameter disagree, the object root is
authoritative. The MIME agent, however, may take action,
including suppressing the Multipart/Related body, based on
the indicated content-type.
3.3 Syntax
related-param = [ ";" "start" "=" msg-id *( "," msg-id ) ]
[ ";" "type" "=" type "/" subtype ]
; order independent
Note that the values of both parameters will usually require
quoting. Msg-id usually contains the special characters
"<", ">", "@", and perhaps others. If msg-id contains
quoted-strings, those quote marks must be escaped.
Similarly, the type parameter contains the special character
"/".
4. Examples
4.1 Application/X-FixedRecord
The X-FixedRecord content-type consists of two parts: an
octet-stream and a list of the lengths of each record. The
root, which lists the record lengths has one required
parameter, data-blocks, whose value is the content-id of one
or more octet-stream body parts. The body of X-FixedRecord
consists of a set of INTEGERs in ASCII format, one per line.
Each INTEGER gives the number of octets from the octet-
stream body part that constitute the next "record".
The example below, uses a single data block.
Content-Type: Multipart/Related; boundary=tiger-lily
start="<950120.1133@XIson.com>";
type="Application/X-FixedRecord"
--tiger-lily
Content-Type: Application/X-FixedRecord;
data-blocks="<950120.1133@XIson.com>"
Content-ID: <950120.1132@XIson.com>
Levinson Expires December 31, 1995 [Page 3]
Internet Draft Multipart/Related
25
10
34
10
25
21
26
10
--tiger-lily
Content-Type: Application/octet-stream
Content-Description: The fixed length records
Content-Transfer-Encoding: base64
Content-ID: <950120.1133@XIson.com>
T2xkIE1hY0RvbmFsZCBoYWQgYSBmYXJtCkUgSS
BFIEkgTwpBbmQgb24gaGlzIGZhcm0gaGUgaGFk
IHNvbWUgZHVja3MKRSBJIEUgSSBPCldpdGggYS
BxdWFjayBxdWFjayBoZXJlLAphIHF1YWNrIHF1
YWNrIHRoZXJlLApldmVyeSB3aGVyZSBhIHF1YW
NrIHF1YWNrCkUgSSBFIEkgTwo=
--tiger-lily--
4.2 Text/X-Okie
The Text/X-Okie is an invented markup language permitting
the inclusion of images with text. A feature of this
example is the inclusion of two additional body parts, both
picture. Tehy are referred to internally by the encapsulated
document via each picture's body part content-id. Usage of
"cid:", as in this example, may be useful for a variety of
compound objects. It is not, however, a part of this or the
Multipart/Related specification.
Content-Type: Multipart/Related; boundary=example;
start="<950118.1528@XIson.com>"
type="Text/x-Okie"
--example
Content-Type: Text/x-Okie; charset=iso-8859-1;
declaration="<950118.1530@XIson.com>"
Content-ID: <950118.1528@XIson.com>
Content-Description: Document
{doc}
This picture was taken by an automatic camera mounted ...
{image file=cid:<950118.1532@XIson.com>}
{para}
Now this is an enlargement of the area ...
{image file=cid:<950118:1648@XIson.com>}
{/doc}
--example
Content-Type: image/jpeg
Content-ID: <950118.1648@XIson.com>
Levinson Expires December 31, 1995 [Page 4]
Internet Draft Multipart/Related
Content-Transfer-Encoding: BASE64
Content-Description: Picture A
[encoded jpeg image]
--example
Content-Type: image/jpeg
Content-ID: <950118.1532@XIson.com>
Content-Transfer-Encoding: BASE64
Content-Description: Picture B
[encoded jpeg image]
--example--
5. User Agent Requirements
Existing MIME-capable mail user agents (MUAs) handle the
existing media types in a straigth forward manner. For
discrete media types (e.g. text, image, etc.) the body of
the entity can be directly passed to a display process.
Similarly the existing composite subtypes can be reduced to
handings one or more discrete types.
Multipart/Related entities require that all constituent body
parts be available to the display process before it is
invoked. The following sections discuss what information
the proccessing application, called the unpacker, requires.
It is possible that the unpacker will manipulate the
entities for display and then invoke another process. Okie,
above, is an example of this; its unpacker may need to parse
the document and substitute local file names for the
originator's file names. Other applications may just
require a table showing the correspondence between the local
file names and the originator's.
5.1 Data Requirments
MIME-capable mail user agents (MUAs) are required to provide
the unpacker:
(a) the bodies of the MIME entities, the entity Content-* headers,
(b) the parameters of the Multipart/Related Content-type header,
(c) the parameters of the first start entity's Content-type header, and
(d) the correspondence between each body's local file name, that body's
header data, and, if present, the body part's content-id.
5.2 Storing Multipart/Related Entities
The Multipart/Related media type will be used for objects that have
internal linkages between the body parts. When the objects are stored
the linkages may require processing by the unpacker.
Levinson Expires December 31, 1995 [Page 5]
Internet Draft Multipart/Related
5.3 Recursion
MIME is a recursive structure. Hence one must expect a
Multipart/Related entity to contain other Multipart/Related entities.
When a Multipart/Related entity is being processed for display or
storage, any enclosed Multipart/Related entities shall be processed as
though they were being stored.
5.5 Configuration Considerations
It is suggested that MUAs that use configuration mechanisms, see [CFG]
for an example, refer to Multipart/Related as Multipart/Related/<type>,
were <type> is the value of the underlying content-type.
MIME-capable mail user agents (MUAs) may suppress processing of
Multipart/Related body parts whose underlying content-type it cannot
display or process. (The underlying content-type is the content-type of
the start body part, or, if given, the value of the type parameter.)
Alternately, the MUA may treat the Multipart/Related media type as
Multipart/Mixed.
6. Security considerations
Security considerations relevant to Multipart/Related are identical to
those of the underlying content-type.
7. Acknowledgments
This proposal is the result of conversations the author has had with
many people. In particular, Harald A. Alvestrand and Ned Freed, pro-
vided both encouragement and guidance. The author, however, take full
responsibility for all errors contained in this document.
8. References
[822] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", August 1982, University of Delaware, RFC 822.
[CID] Levinson, E., "CID: The Content-ID Uniform Resource Loca-
tor", work in progress, ftp://ds.internic.net/internet-
drafts/draft-levinson-cid-00.txt.
[CFG] Borenstein, N., "A User Agent Configuration Mechanism For
Multimedia Mail Format Information", September 23, 1993, RFC
1524
[MIME] Borenstein, N. and Freed, N., "MIME (Multipurpose Internet
Mail Extensions): Mechanisms for Specifying and Describing
the Format of Internet Message Bodies", June 1992, RFC 1341.
9. Author's address
Edward Levinson
Levinson Expires December 31, 1995 [Page 6]
Internet Draft Multipart/Related
Accurate Information Systems, Inc.
2 Industrial Way
Eatontown, NJ 07724-2265
USA
+1 908 389 5550
<ELevinson@Accurate.com>
Levinson Expires December 31, 1995 [Page 7]