The MIME Multipart/Related Content-type
RFC 2112

Document Type RFC - Proposed Standard (March 1997; No errata)
Obsoleted by RFC 2387
Obsoletes RFC 1872
Last updated 2013-03-02
Stream IETF
Formats plain text pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2112 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        E. Levinson
Request for Comments: 2112                                   XIson, Inc.
Category: Standards Track                                     March 1997
Obsoletes: 1872

                The MIME Multipart/Related Content-type

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

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 objects 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, this document describes a
   single mechanism for such aggregate or compound objects.

   The Multipart/Related content-type addresses the MIME representation
   of compound objects.  The object is categorized by a "type"
   parameter.  Additional parameters are provided to indicate a specific
   starting body part or root and auxiliary information which may be
   required when unpacking or processing the object.

   Multipart/Related MIME entities may contain Content-Disposition
   headers that provide suggestions for the storage and display of a
   body part.  Multipart/Related processing takes precedence over
   Content-Disposition; the interaction between them is discussed in
   section 4.

   Responsibility for the display or processing of a Multipart/Related's
   constituent entities rests with the application that handles the
   compound object.

Levinson                    Standards Track                     [Page 1]
RFC 2112          MIME Multipart/Related Content-type         March 1997

2.  Multipart/Related Registration Information

   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:       Type, a media type/subtype.

   Optional parameters:       Start
                     Start-info

   Encoding considerations:   Multipart content-types cannot have
                              encodings.

   Security considerations:   Depends solely on the referenced type.

   Published specification:   RFC-REL (this document).

   Person & email address to contact for further information:
                     Edward Levinson
                     47 Clive Street
                     Metuchen, NJ 08840-1060
                     +1 908 494 1606
                     XIson@cnj.digex.net

3.  Intended usage

   The Multipart/Related media type is intended for compound objects
   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 content-type
   of the Multipart/Related object is specified by the type parameter.
   The "start" parameter, if given, points, via a content-ID, to the
   body part that contains the object root.  The default root is the
   first body part within the Multipart/Related body.

Levinson                    Standards Track                     [Page 2]
RFC 2112          MIME Multipart/Related Content-type         March 1997

   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, such links may be
   represented within a MIME message using content-IDs or the value of
   some other "Content-" headers.

3.1.  The Type Parameter

   The type parameter must be specified and its value is the MIME media
   type of the "root" body part.  It permits a MIME user agent to
   determine the content-type without reference to the enclosed body
   part.  If the value of the type parameter and the root body part's
   content-type differ then the User Agent's behavior is undefined.

3.2.  The Start Parameter

   The start parameter, if given, is the content-ID of the compound
   object's "root".  If not present the "root" is the first body part in
   the Multipart/Related entity.  The "root" is the element the
Show full document text