RFC 3459 on Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter
rfc-editor@rfc-editor.org Thu, 30 January 2003 18:39 UTC
Received: from ran.ietf.org (ran.ietf.org [10.27.6.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06298; Thu, 30 Jan 2003 13:39:22 -0500 (EST)
Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18eJW2-0000H2-00 for ietf-announce-list@ran.ietf.org; Thu, 30 Jan 2003 13:34:22 -0500
Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18eJVF-0000EN-00 for all-ietf@ran.ietf.org; Thu, 30 Jan 2003 13:33:33 -0500
Received: from gamma.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06093 for <all-ietf@ietf.org>; Thu, 30 Jan 2003 13:25:17 -0500 (EST)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0UISnD27203; Thu, 30 Jan 2003 10:28:49 -0800 (PST)
Message-Id: <200301301828.h0UISnD27203@gamma.isi.edu>
To: IETF-Announce:;
Subject: RFC 3459 on Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter
Cc: rfc-editor@rfc-editor.org, vpim@lists.neystadt.org
From: rfc-editor@rfc-editor.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Thu, 30 Jan 2003 10:28:49 -0800
Sender: owner-ietf-announce@ietf.org
Precedence: bulk
A new Request for Comments is now available in online RFC libraries. RFC 3459 Title: Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter Author(s): E. Burger Status: Standards Track Date: January 2003 Mailbox: e.burger@ieee.org Pages: 24 Characters: 54282 Updates: 3204 I-D Tag: draft-ietf-vpim-cc-08.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3459.txt 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. This document is a product of the Voice Profile for Internet Mail Working Group of the IETF. This is now a Proposed Standard Protocol. 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. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs.