Network Working Group                                          C. Newman
Internet Draft: Metadata Content-Disposition Type               Innosoft
Document: draft-newman-mime-cdisp-metadata-01.txt              July 1998
                                                   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
     (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
     (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US
     West Coast).


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.


. 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



Newman                                                          [Page 1]

Internet Draft     Metadata Content-Disposition Type           July 1998


     use in RFCs to Indicate Requirement Levels" [KEYWORDS].


. 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."


. Amended Formal Syntax

     This amends the formal syntax [ABNF] for "disposition-type"
     [CDISP]:

         disposition-type =/ "metadata"


. Security Considerations

     This does not add additional security considerations beyond those
     which already apply to the Content-Disposition header field
     [CDISP].


. References

     [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
     ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd,
     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.





Newman                                                          [Page 2]

Internet Draft     Metadata Content-Disposition Type           July 1998


     [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.


. Author's Address

     Chris Newman
     Innosoft International, Inc.
     1050 Lakes Drive
     West Covina, CA 91790 USA

     Email: chris.newman@innosoft.com





























Newman                                                          [Page 3]