HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 10:28:19 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Wed, 24 Mar 1999 14:03:00 GMT ETag: "361cae-14be-36f8f094" Accept-Ranges: bytes Content-Length: 5310 Connection: close Content-Type: text/plain Network Working Group C. Newman Internet Draft: Ancillary Content-Disposition Type Innosoft Document: draft-newman-mime-cdisp-metadata-02.txt March 1999 Ancillary Content-Disposition Type Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The Content-Disposition [CDISP] header defines two disposition types: ``inline'' and ``attachment'' which can affect presentation of a MIME [MIME-IMB] body part. There have been a number of cases where one MIME body part is ancillary or contains meta-data for another MIME body part and is neither suitable for inline display by itself, nor is it useful if treated as an independent attachment and saved to a file by itself. If the recipient UA is not familiar with the specific media type, the user often is presented with a useless unrecognizable attachment. This memo proposes a third disposition type, ``ancillary'', to address this situation. 1. Conventions Used in this Document The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" Newman Expires September 1999 [Page 1] Internet Draft Ancillary Content-Disposition Type March 1999 in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 2. The Ancillary Disposition Type A body part can be designated "ancillary" if it is ancillary to the primary content of the containing multipart and is unlikely to be useful if saved to a file by itself or viewed independently. If an interpreting user agent sees an unknown media type with an "ancillary" disposition type, it SHOULD indicate in some way that the body part is unlikely to be useful to the user. For example, in a multipart/appledouble [MACMIME], the application/applefile body part SHOULD have an "ancillary" disposition type as it is usually useless by itself. In a multipart/security [MIME-SEC], the signature body part can be useless without the text it signs and thus might have a disposition type of "ancillary." If a client automatically attaches ancillary information to every message sent (e.g., a vcard [VCARD] or vendor proprietary information intended for special processing by a recipient running the same software), that information is a good candidate for this label. 2. Amended Formal Syntax This amends the formal syntax [ABNF] for "disposition-type" [CDISP]: disposition-type =/ "ancillary" 3. Security Considerations This does not add additional security considerations beyond those which already apply to the Content-Disposition header field [CDISP]. 4. References [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, November 1997. Newman Expires September 1999 [Page 2] Internet Draft Ancillary Content-Disposition Type March 1999 [CDISP] Troost, Dorner, Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, New Century Systems, Qualcomm Incorporated, University of Tennessee, August 1997. Draft Standard revision is a WORK-IN-PROGRESS. [MACMIME] Faltstrom P., Crocker, D., and E. Fair, "MIME Encapsulation of Macintosh Files - MacMIME", RFC 1740, KTH, Brandenburg Consulting, Apple Computer Inc., December 1994. [MIME-IMB] Freed, Borenstein, "Mulitpurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, Innosoft, First Virtual, November 1996. [MIME-SEC] Galvin, Murphy, Crocker, Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Trusted Information Systems, CyberCash, Innosoft International, October 1995. [VCARD] Dawson, F., Howes, T., "vCard MIME Directory Profile", RFC 2426, Lotus Development Corporation, September 1998. 5. Author's Address Chris Newman Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA Email: chris.newman@innosoft.com Newman Expires September 1999 [Page 3]