Network Working Group                                 D. Crocker
draft-crocker-wrap-02.txt            Brandenburg InternetWorking
                                                   June 23, 2002
Expiration <12/02>




          Wrapping MIME Objects:  Application/MIME

STATUS OF THIS MEMO

This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.

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

MIME is a general-purpose mechanism for labeling and
aggregating objects into complex hierarchies. Some MIME
objects are discrete objects.  If placed within another MIME
hierarchy, they need to appear as a leaf node in the
containing hierarchy, rather than seeming to be continuations
of that hierarchy.  This specification defines Content-type
Application/MIME to provide an encapsulation mechanism for
arbitrary MIME structures.  This facilitates their treatment
as a single unit, rather than causing them to be treated as
part of any containing MIME hierarchy.



INTRODUCTION

MIME is a general-purpose mechanism for labeling and
aggregating objects into complex hierarchies. Some MIME
objects are discrete objects.  If placed within another MIME
hierarchy, they need to appear as a leaf node in the
containing hierarchy, rather than seeming to be continuations
of that hierarchy.  One example of this requirement is to
provide some protection against the translations that email
gateways often make to MIME attachments.  Further some uses
of MIMEÆs aggregation mechanism, Content-type Multipart, can
lead to requirements for processing an entire aggregated
object as a single unit.  This is in contrast to Content-type
Multipart/Mixed, which specifies separate processing of
constituent components, and to which multipart sub-types
default if they are unknown to the processing software.

This specification defines Content-type Application/MIME to
provide an encapsulation mechanism for arbitrary MIME
structures.  This facilitates their treatment as a single
unit, rather than causing them to be treated as part of any
containing MIME hierarchy.  It is expected that
Application/MIME will be especially useful in getting data
past gateways.

The specification simply defines an object that contains MIME
data.  When the object is removed from its Content-type
Application/MIME wrapper, what remains is an entire MIME
object, beginning with a (new) Content-type header.



APPLICATION/MIME SPECIFICATION

MIME type name:               Application

MIME subtype name:            MIME

Required parameters:          <contained>

Optional parameters:          None

Encoding considerations:      May need BASE64 or QUOTED-
                              PRINTABLE transfer encoding, as
                              appropriate for the <contained>
                              data.  Careful use of QUOTED-
                              PRINTABLE will maintain clear
                              text as robust against gateway
                              processing yet still be
                              readable without special
                              processing.

                              NOTE:  items carried inside
                              this MIME object must be fully
                              conformant MIME structure and
                              data; this includes all of the
                              usual rules concerning network
                              standard canonical
                              representation.

Security considerations:      See separate section in this
                              document.

Published specification:      See detail, below.

Rationale:                    MIME objects can be discrete
                              entities; when attached to
                              another MIME object, the
                              attachment needs to be
                              represented as a leaf, rather
                              than a part of that hierarchy.
                              One use of this distinction is
                              for gateways and other
                              processing environments that
                              can alter and destroy MIME data
                              structure; the defined data
                              type will permit separate
                              handling of the structure
                              inside an object.  It also
                              permits passing an aggregate
                              object as a single entity,
                              through processors that would
                              otherwise separate the
                              components.

Contact-info:                 See Contact section, below.

Detail specific to MIME-based usage:

     This is a generic mechanism for encapsulating any MIME
     object structure.  The object is self-defining, since it
     begins with a MIME Content-Type header and is then
     processed (recursively).  The mechanism is intended for
     use when correct processing of the basic MIME structure
     is at risk, in effect allowing the MIME structure to be
     tunneled through such an environment.

     The Content-Type parameter comprises the type and sub-
     type tokens of the Content-Type header for the contained
     MIME component, i.e.,

     contained   =  c-t *(ô;ö *parameter)

     c-t         =  ôContent-Type=ô <"> type "/" subtype <">

     parameter   =  {as defined for MIME}

     where the type and subtype tokens are defined by the
     MIME [2] specification.  The value of the Content-Type
     parameter specifies the MIME Content-Type and subtype of
     the data structure contained inside the Application/MIME
     object.

     The <contained> parameters replicate all of the
     parameters which are present in the Content-Type
     specification header referenced by the Content-Type
     parameter.  That is, they replicate the contained
     objectÆs parameters, in their entirety.  This is done to
     facilitate dispatch of a particular type to a handler,
     without parsing the contained MIME structure.

          If the contained object is, itself
          Application/MIME, then none of the <contained>
          parameters of that contained object shall be
          included.

     (Using Application/MIME for doubly-wrapping MIME data
     may provide a necessary level of protection in some
     cases.)



GATEWAY AND PASS-THROUGH PROCESSING

Software which manipulates an Application/MIME component must
do so ONLY when  processing can be done fully and correctly.
In the extreme, this may require full parsing of the
contained MIME structure and its parameters, prior to
deciding whether to take responsibility for the content.
Typically, however, review of the Application/MIME type and
<contained> parameters will suffice.

Any MIME-aware software that encounters an Application/MIME
component must leave the component in its existing form,
unless that software is able to fully and correctly process
ALL of the component contents AND such processing is
appropriate to the environment in which the software is
operating.

IMPORTANT NOTE:     Gateway implementers are specifically
                    and strongly cautioned against
                    modification of an Application/MIME
                    component.

The question of whether to unwrap content that is embedded in
an Application/MIME becomes very simple.  Application/MIME is
used to provide protection against mishandling by
intermediaries.  Hence, only end-system softwareûincluding
gateways and regular email user agentsûshould even consider
touching the content and then it should only do so when the
recipient has a basis for believing that the processing will
be correct.



SIMPLE USAGE IN MIME-BASED EMAIL

This section is intended as a simple example of the gist of
the formatting required to encapsulate MIME objects within
Internet mail, using Application/MIME:

To:
Subject:
From:
Date:
Mime-Version: 1.0
Content-Type: Application/MIME;
                 content-type=Multipart/signed;
                 protocol="application/somesigscheme";
                 boundary="//signatureboundary//"

Content-Type: Multipart/Signed;
                 boundary=//signatureboundary//;
                 protocol="application/somesigscheme"

--//signatureboundary//
Content-type:<<type of the user data>>

<<user data>>

--//signatureboundary//
Content-type:application/somesigscheme

<<signature control information>>

--//signatureboundary//--



DOUBLE-WRAPPED EXAMPLE

This section shows a contained object which is, itself, a
contained object, double-wrapped for extra protection against
decay:

To:
Subject:
From:
Date:
Mime-Version: 1.0
Content-Type: Application/MIME;
                 content-type=Multipart/signed;
                 protocol="application/somesigscheme";
                 boundary="//signatureboundary//"

Content-Type: Application/MIME;
                 content-type=Multipart/signed;
                 boundary="//signatureboundary//";
                 protocol="application/somesigscheme"

Content-Type: Multipart/Signed;
                 boundary=//signatureboundary//;
                 protocol="application/somesigscheme"

--//signatureboundary//
Content-type:<<type of the user data>>

<<user data>>

--//signatureboundary//
Content-type:application/somesigscheme

<<signature control information>>

--//signatureboundary//--



SECURITY CONSIDERATIONS

MIME content often includes sensitive data, so that
transmission often needs to attend to authentication, data
integrity, privacy, access control, and the like as
appropriate.

IMPORTANT NOTE:     The recursive processing required by
                    Application/MIME  requires use of
                    whatever security checks are applied to
                    newly received MIME data.

This specification does NOT, itself, provide any security-
related mechanisms.  As needed and appropriate, such
mechanisms MUST be added, either via Internet MIME-based
security services or any other services which are appropriate
to the user requirements.



ACKNOWLEDGMENTS

The idea for Application/MIME first developed out of
conversations with Einar Stefferud and Marshall Rose, in
trying to find a way for exchanging valid Internet Mail,
complete with RFC822 headers and MIME content, through
environments that provided no other Internet Mail technology
besides a gateway between the proprietary environment and the
Internet.  Additional benefits of this mechanism then
surfaced during discussions on the S/MIME development list.

A previous draft was co-authored by Laurence Lundblade and
Jamie Zewinskie.  They are not listed in the current draft
merely to protect the innocent.



CONTACT

David H. Crocker <dcrocker@brandenburg.com>
Brandenburg InternetWorking
675 Spruce Drive
Sunnyvale, CA 94086 USA
Phone:    +1.408.246.8253