Internet DRAFT - draft-levinson-multipart-related
draft-levinson-multipart-related
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 09:50:29 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Tue, 31 Jan 1995 23:00:00 GMT
ETag: "3240ec-325a-2f2ec0f0"
Accept-Ranges: bytes
Content-Length: 12890
Connection: close
Content-Type: text/plain
Network Working Group Harald Tveit Alvestrand
Internet Draft: Multipart/Related UNINETT
<draft-levinson-multipart-related-00.txt> Edward Levinson
ACCURATE Info. Sys.
January 31, 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 proposals for MIME-SGML, 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
Levinson and Alvestrand Expires July 31, 1995 [Page 1]
Internet Draft Multipart/Related
information are required, the "root" or starting body
part(s), and an indication of the object type.
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.
2. All body parts contained within this
media type must have Content-ID headers
and values.
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 part. The "start" parameter, if given,
points, by content-id, to the body part containing the
object root. The default object root is the first body part
within the Multipart/Related body. The root header also
specifies the additional object information required to
display the object.
The relationships between the body parts of a compound
object distinguishes it from other object types. Those
relationships are often represented by links internal to the
object's components that reference other components. Within
a single operating environment the links are often file
Levinson and Alvestrand Expires July 31, 1995 [Page 2]
Internet Draft Multipart/Related
names, within a MIME message content-ids can serve the same
purpose. MIME message composers are encouraged, as a
recommended practice, to use the content-id header for each
body part within the Multipart/Related body part. 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
compound object's "root". If the content-ID of several body
parts are listed, then the first body part referenced
specifies the object type.
3.2 The Type Parameter
The type parameter can be specified to indicate the
content-type of the Multipart/Related object. Using this
parameter permits a MIME agent to determine the content-type
without reference to the enclosed body part. The type
parameter is expected to be useful in those agents
processing the MIME message as a stream.
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
multipart-subtype = existing-subtypes / "related"
related-param = ( ";" "start" "=" msg-id )
/ ( ";" "type" "=" type "/" subtype )
Note that quotes are required if the type parameter value
has embedded blanks.
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.
Levinson and Alvestrand Expires July 31, 1995 [Page 3]
Internet Draft Multipart/Related
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>
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-sgml
The Text/X-sgml content-type has three parameters
declaration optional
catalog optional
style-sheet optional
Note, a MIME encapsulation of SGML is currently under
discussion. In this example the Multipart/Related type
parameter is omitted. Another feature of this example is
the inclusion of an additional body part, the picture. It is
referred to internally by the encapsulated document via
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 the Multipart/Related
specification.
Content-Type: Multipart/Related; boundary=example;
start=950118.1528@XIson.com
--example
Levinson and Alvestrand Expires July 31, 1995 [Page 4]
Internet Draft Multipart/Related
Content-Type: Text/x-sgml; charset=iso-8859-1;
declaration=<950118.1530@XIson.com>
Content-ID: <950118.1528@XIson.com>
Content-Description: Document
<!DOCTYPE doc PUBLIC "-//IETF ..." [
<!NOTATION jpeg SYSTEM "image/jpeg">
<!ENTITY picture SYSTEM "cid:950118.1532@XIson.com" NDATA jpeg>
] >
<doc>
whatever
</doc>
--example
Content-Type: Application/x-sgml; charset=iso-8859-1
Content-ID: <950118.1530@XIson.com>
Content-Description: An sgml declaration
<!SGML "ISO 8879-1986" ... >
--example
Content-Type: image/jpeg
Content-ID: <950118.1532@XIson.com>
Content-Transfer-Encoding: BASE64
Content-Description: Picture
[encoded jpeg image]
--example--
5. User Agent Requirements
MIME-capable mail user agents (MUAs) may suppress display of
Multipart/Related body parts whose underlying content-type
cannot be displayed. The underlying content-type is the
content-type of the first body part pointed to by the start
parameter. If the type parameter value is given, the MUA
may base its display decision on that value.
The MUA must make available to the process that displays the
underlying content-type the correspondence between the
content-ids of the constituent body parts and their storage
locations. Similarly, the value of the start parameter must
be available.
6. Security considerations
Security considerations relevant to Multipart/Related are
identical to those of the embedded content-type.
7. Acknowledgments
Acknowledgements are, as always, due to more people than can
be listed. However, the authors take full responsibility
for all errors contained in this document.
Levinson and Alvestrand Expires July 31, 1995 [Page 5]
Internet Draft Multipart/Related
8. References
[822] Crocker, D., Standard for the Format of ARPA Internet Text
Messages, August 1982, University of Delaware, RFC 822.
[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.
[SGML] ISO 8879:1988, Information processing -- Text and office
systems -- Standard Generalized Markup Language (SGML).
[CID] Levinson, E., CID: The Content-ID Uniform Resource Locator,
work in progress, ftp://ds.internic.net/internet-
drafts/draft-levinson-cid-00.txt.
9. Author's address
Edward Levinson
Accurate Information Systems, Inc.
2 Industrial Way
Eatontown, NJ 07724-2265
USA
+1 908 389 5550
<ELevinson@Accurate.com>
Harald T. Alvestrand
UNINETT
P.O.Box 6883 Elgeseter
N-7002 Trondheim
Norway
<Harald.T.Alvestrand@uninett.no>
Levinson and Alvestrand Expires July 31, 1995 [Page 6]
