From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1873.txt | 227 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 227 insertions(+) create mode 100644 doc/rfc/rfc1873.txt (limited to 'doc/rfc/rfc1873.txt') diff --git a/doc/rfc/rfc1873.txt b/doc/rfc/rfc1873.txt new file mode 100644 index 0000000..8ed87d5 --- /dev/null +++ b/doc/rfc/rfc1873.txt @@ -0,0 +1,227 @@ + + + + + + +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. + + + + + + + + + + + + +Levinson & Clark Experimental [Page 1] + +RFC 1873 Access Type Content-ID December 1995 + + +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 + + 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. + + + + + + + + +Levinson & Clark Experimental [Page 2] + +RFC 1873 Access Type Content-ID December 1995 + + +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. + + + + + + + + + + + + +Levinson & Clark Experimental [Page 3] + +RFC 1873 Access Type Content-ID December 1995 + + +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: + + +James Clark +90 Clarendon Road +London W11 2HR +UK + +EMail: + + + + + + + + + + + + + + + + + + +Levinson & Clark Experimental [Page 4] + -- cgit v1.2.3