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]