Network Working Group C. Newman Internet Draft: Metadata Content-Disposition Type Innosoft Document: draft-newman-mime-cdisp-metadata-00.txt November 1997 Expires in six months Metadata Content-Disposition Type 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 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." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Copyright Notice Copyright (C) The Internet Society 1997. All Rights Reserved. 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 contains metadata 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, ''metadata'', to address this situation. Newman [Page 1]
Internet Draft Metadata Content-Disposition Type November 1997 1. Conventions Used in this Document The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 2. The Metadata Disposition Type A body part can be designated "metadata" if it contains metadata for one or more other body parts in 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 a "metadata" 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 a "metadata" disposition type as it is usually useless by itself. In a multipart/security [MIME-SEC], the signature body part is usually useless without the text it signs and thus would usually have a disposition type of "metadata." 2. Amended Formal Syntax This amends the formal syntax [ABNF] for "disposition-type" [CDISP]: disposition-type =/ "metadata" 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", Work in progress: draft-ietf-drums-abnf-xx.txt Newman [Page 2]
Internet Draft Metadata Content-Disposition Type November 1997 [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. <ftp://ds.internic.net/rfc/rfc2183.txt> [MACMIME] Faltstrom P., Crocker, D., and E. Fair, "MIME Encapsulation of Macintosh Files - MacMIME", RFC 1740, KTH, Brandenburg Consulting, Apple Computer Inc., December 1994. <ftp://ds.internic.net/rfc/rfc1740.txt> [MIME-IMB] Freed, Borenstein, "Mulitpurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, Innosoft, First Virtual, November 1996. <ftp://ds.internic.net/rfc/rfc2045.txt> [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. <ftp://ds.internic.net/rfc/rfc1847.txt> 5. Full Copyright Statement Copyright (C) The Internet Society 1997. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Newman [Page 3]
Internet Draft Metadata Content-Disposition Type November 1997 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 6. Author's Address Chris Newman Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA Email: chris.newman@innosoft.com Newman [Page 4]