Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter
RFC 3459

Document Type RFC - Proposed Standard (January 2003; No errata)
Updated by RFC 5621
Updates RFC 3204
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 3459 (Proposed Standard)
Telechat date
Responsible AD Ned Freed
IESG note announced 30-Jan-2003
Send notices to <jwn2@qualcomm.com>, <gparsons@nortelnetworks.com>
Network Working Group                                          E. Burger
Request for Comments: 3459                            SnowShore Networks
Updates: 3204                                               January 2003
Category: Standards Track

              Critical Content Multi-purpose Internet Mail
                      Extensions (MIME) Parameter

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This document describes the use of a mechanism for identifying body
   parts that a sender deems critical in a multi-part Internet mail
   message.  The mechanism described is a parameter to Content-
   Disposition, as described by RFC 3204.

   By knowing what parts of a message the sender deems critical, a
   content gateway can intelligently handle multi-part messages when
   providing gateway services to systems of lesser capability.  Critical
   content can help a content gateway to decide what parts to forward.
   It can indicate how hard a gateway should try to deliver a body part.
   It can help the gateway to pick body parts that are safe to silently
   delete when a system of lesser capability receives a message.  In
   addition, critical content can help the gateway chose the
   notification strategy for the receiving system.  Likewise, if the
   sender expects the destination to do some processing on a body part,
   critical content allows the sender to mark body parts that the
   receiver must process.

Burger                      Standards Track                     [Page 1]
RFC 3459           Critical Content of Internet Mail        January 2003

Table of Contents

   1.  Conventions used in this document..............................3
   2.  Introduction...................................................3
   3.  Handling Parameter.............................................4
       3.1. REQUIRED..................................................4
       3.2. OPTIONAL..................................................5
       3.3. Default Values............................................5
       3.4. Other Values..............................................5
   4.  Collected Syntax...............................................6
   5.  Notification...................................................6
       5.1. DSN vs. MDN Generation....................................7
       5.2. Summary...................................................7
   6.  Signed Content.................................................8
   7.  Encrypted Content..............................................9
   8.  Status Code...................................................10
   9.  Requirements for Critical Content.............................11
       9.1. Needs....................................................11
       9.2. Current Approaches.......................................12
   10. The Content Gateway...........................................13
       10.1. Integrated Content Gateway..............................14
       10.2. Disaggregated Delivery Network..........................14
   11. Backward Compatibility Considerations.........................15
   12. MIME Interactions.............................................15
       12.1. multipart/alternative...................................15
       12.2. multipart/related.......................................15
       12.3. message/rfc822..........................................15
       12.4. multipart/signed........................................16
       12.5. multipart/encrypted.....................................16
   13. Implementation Examples.......................................16
       13.1. Content Gateways........................................16
       13.2. Disaggregated Content Gateway...........................17
   14. OPES Considerations...........................................18
       14.1. Consideration (2.1): One-Party Consent..................18
       14.2. Consideration (2.2): IP-layer Communications............18
       14.3. Consideration (3.1): Notification - Sender..............18
       14.4. Consideration (3.2): Notification - Receiver............18
       14.5. Consideration (3.3): Non-Blocking.......................18
       14.6. Consideration (4.1): URI Resolution.....................18
       14.7. Consideration (4.2): Reference Validity.................19
       14.8. Consideration (4.3): Architecture Extensions............19
Show full document text