Message/External-Body Content-ID Access Type
A MIME access type that lets one message part point to another part of the same message instead of repeating its data.
Levinson, E. and J. Clark, "Message/External-Body Content-ID Access Type", RFC 1873, DOI 10.17487/RFC1873, December 1995, <https://www.rfc-editor.org/info/rfc1873>.
@misc{rfc1873,
series = {Request for Comments},
number = 1873,
howpublished = {RFC 1873},
publisher = {RFC Editor},
doi = {10.17487/RFC1873},
url = {https://www.rfc-editor.org/info/rfc1873},
author = {E. Levinson and J. Clark},
title = {{Message/External-Body Content-ID Access Type}},
pagetotal = 4,
year = 1995,
month = dec,
} RFC text
Contents
Network Working Group E. Levinson
Request for Comments: 1873 Accurate Information Systems, Inc.
Category: Experimental J. Clark
December 1995
Message/External-Body Content-ID Access Type
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. This memo does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Abstract
When using MIME [MIME] to encapsulate a structured object that
consist of many elements, for example an SGML [SGML] document, a
single element may occur several times. An encapsulation normally
maps each of the structured objects elements to a MIME entity. It is
useful to include elements that occur multiple time exactly once. To
accomplish that and to preserve the object structure it is desirable
to unambiguously refer to another body part of the same message.
The existing MIME Content-Type Message/External-Body access-types
allow a MIME entity (body-part) to refer to an object that is not in
the message by specifying how to access that object. The Content-ID
access method described in this document provides the capability to
refer to an object within the message.
1. Introduction
Consider a MIME multipart entity several of whose body parts contain
the same data (body) but different parameters or Content-* headers.
Representing those body parts without duplicating the data in each
one promotes efficient use of resources (bandwidth and storage
space). To achieve these benefits an access-type is defined that
permits one message part to refer to another one in the same message.
2. The Content-ID Access Type
2.1 Registration Information
MIME access-type name: content-id
Required parameters: none
Optional parameters: none
Published specification: this document
Person & email address
to contact for further
information: Ed Levinson <ELevinson@accurate.com>
Additional requirements:
The content-id header of the access-type=content-id MIME
entity must match (be identical to) exactly one content-id
in the same message, excluding other access-type=content-id
entities. Thus, the content-id access type can only occur
within a multipart message and can refer to another body
part anywhere in the same message.
A MIME User Agent (MUA) constructs the resultant MIME body
part as described below. We call the access-type=content-id
MIME entity the referring body part and the MIME body part
to which it refers, the one with the matching content-id,
the referenced body part. The MIME entity that results from
content-id access type consists of:
(a) the referenced body part's content-type header,
(b) the referring body part's headers except its content-type
header,
(c) any headers in the referenced body part not in the referring
one,
(d) the line separating the headers from the body, and
(e) the referenced body part's body.
2.2 Example Usage
The following example shows a message that consists of two identical
images.
MIME-Version: 1.0
Content-Type: Multipart/Mixed;
boundary=tiger-lily
--tiger-lily
Content-Type: image/jpeg
Content-ID: <950323.1552@XIson.com>
AAAcdb...
--tiger-lily
Content-type: Message/External-Body;
access-type=content-id
Content-ID: <950323.1552@XIson.com>
Content-Description:
This body part is duplicated by reference
--tiger-lily--
The equivalent MIME entity for the second body part is:
--tiger-lily
Content-Type: image/jpeg
Content-ID: <950323.1552@XIson.com>
Content-Description:
This body part is duplicated by reference
AAAcdb...
--tiger-lily
3. Security Considerations
The content-id access-type does not impact the security of messages
or systems. The referenced MIME entity may have security
implications.
4. References
[822] Crocker, D., "Standard for the Format of ARPA Internet
Text Messages", STD 11, RFC 822, UDEL, August 1982.
[SGML] ISO 8879:1988, Information processing -- Text and office
systems -- Standard Generalized Markup Language (SGML).
[MIME] Borenstein, N., and N. Freed, "MIME (Multipurpose
Internet Mail Extensions) Part One: Mechanisms for
Specifying and Describing the Format of Internet
Message Bodies", RFC 1521, Bellcore, Innosoft,
September 1993.
5. Authors' Addresses
Edward Levinson
Accurate Information Systems, Inc.
2 Industrial Way
Eatontown, NJ 07724-2265
USA
Phone: +1 908 389 5550
EMail: <ELevinson@Accurate.com>
James Clark
90 Clarendon Road
London W11 2HR
UK
EMail: <jjc@jclark.com>
AI ELI5
On this page
§1Why Refer Within a Message
When MIME is used to wrap a structured object with many elements, such as an SGML document, one element may occur several times. Each element normally maps to a MIME entity, but it is useful to include repeated elements exactly once while keeping the object structure.
Consider a multipart entity where several body parts contain the same data but different parameters or Content-* headers. Not duplicating the data in each saves bandwidth and storage space. The existing Message/External-Body type points to objects outside the message; this access type points to an object inside it.
If the same picture appears many times, send it once and let the other spots point to it.
§2The content-id Access Type
The access-type name is content-id, with no required or optional parameters. The Content-ID header of the referring part must match exactly one Content-ID in the same message, not counting other content-id access-type entities. So the type can only occur inside a multipart message, and it may refer to a body part anywhere in that message.
The mail user agent builds the result from five pieces: the referenced part's content-type header, the referring part's other headers, any headers of the referenced part that the referring part lacks, the blank line that ends the headers, and the referenced part's body.
The reader glues the note and the thing it points to together into one finished piece.
§3Example
The RFC shows a Multipart/Mixed message with two identical images. The first part is an image/jpeg with a Content-ID. The second is a Message/External-Body part with access-type=content-id and the same Content-ID, and no body of its own.
After the reader resolves it, the second part becomes an image/jpeg with the same data and the second part's own Content-Description, which reads that the body part is duplicated by reference.
The second picture is just a sticky note saying 'same as the first one', and the reader swaps in the real picture.
MIME-Version: 1.0
Content-Type: Multipart/Mixed;
boundary=tiger-lily
--tiger-lily
Content-Type: image/jpeg
Content-ID: <950323.1552@XIson.com>
AAAcdb...
--tiger-lily
Content-type: Message/External-Body;
access-type=content-id
Content-ID: <950323.1552@XIson.com>
Content-Description:
This body part is duplicated by reference
--tiger-lily--§4Security Notes
The RFC says the content-id access type does not affect the security of messages or systems. It adds that the referenced MIME entity may have security implications of its own.
The pointer itself is harmless, but what it points to still needs the usual care.