reference on critical content

14 files changed, 8772 insertions, 0 deletions

diff --git a/Documentation/en/I-D/draft-burger-vpim-cc-00.txt b/Documentation/en/I-D/draft-burger-vpim-cc-00.txt
new file mode 100644
index 00000000..d7480692
--- /dev/null
+++ b/Documentation/en/I-D/draft-burger-vpim-cc-00.txt
@@ -0,0 +1,543 @@
+
+
+Network Working Group                                           E. Burger
+Internet Draft                                   Centigram Communications
+Document: draft-burger-vpim-cc-00.txt                          E. Candell
+Category: Standards Track                        Comverse Network Systems
+Expires in six Months                                        June 6, 2000
+
+
+                   Critical Content of Internet Mail
+
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026 [1].
+
+   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."
+
+   One can access the list of current Internet-Drafts at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+
+   One can access the list of Internet-Draft Shadow Directories at
+   http://www.ietf.org/shadow.html.
+
+
+
+1.
+  Abstract
+
+   This document describes a mechanism for identifying the critical
+   content body parts of a multi-part Internet mail message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                           Expires 12/6/00                    [Page 1]
+
+                  Critical Content of Internet Mail          June 2000
+
+
+
+Table of Contents
+
+1.ABSTRACT ...........................................................1
+2.CONVENTIONS USED IN THIS DOCUMENT ..................................2
+3.INTRODUCTION .......................................................2
+
+4.CONTENT-NOTIFICATION ENTITY ........................................5
+4.1. NOTIFY ..........................................................5
+4.2. PARTIAL .........................................................5
+4.3. IGNORE ..........................................................6
+4.4. Other Values ....................................................6
+4.5. Notification Precedence .........................................6
+5.BACKWARD COMPATIBILITY CONSIDERATIONS ..............................6
+6.SECURITY CONSIDERATIONS ............................................7
+
+7.COLLECTED SYNTAX ...................................................7
+8.REFERENCES .........................................................7
+9.ACKNOWLEDGMENTS ....................................................8
+10. AUTHOR'S ADDRESSES ...............................................8
+
+
+2.
+  Conventions used in this document
+
+   This document refers generically to the sender of a message in the
+   masculine (he/him/his) and the recipient of the message in the
+   feminine (she/her/hers).  This convention is purely for convenience
+   and makes no assumption about the gender of a message sender or
+   recipient.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
+   this document are to be interpreted as described in RFC-2119 [2].
+
+   FORMATTING NOTE: Notes, such at this one, provide additional
+   nonessential information that the reader may skip without missing
+   anything essential.  The primary purpose of these non-essential
+   notes is to convey information about the rationale of this document,
+   or to place this document in the proper historical or evolutionary
+   context.  Readers whose sole purpose is to construct a conformant
+   implementation may skip such information.  However, it may be of use
+   to those who wish to understand why we made certain design choices.
+
+
+3.
+  Introduction
+
+   This document describes the Critical Content identification for
+   multi-part Internet mail.
+
+   The need for a critical content identification mechanism comes about
+   because of the internetworking of Internet mail systems with legacy
+   messaging systems that do not fulfil all of the semantics of
+   Internet mail.  Such legacy systems have a limited ability to render
+
+Burger and Candell         Expires 12/6/00                    [Page 2]
+
+                  Critical Content of Internet Mail          June 2000
+
+
+
+   all parts of a given message.  This document will use the case of an
+   Internet mail system exchanging electronic messages with a legacy
+   voice messaging system for illustrative purposes.
+
+   Electronic mail has historically been text-centric.  Extensions such
+   as MIME [3] enable the desktop to send and receive multi-part,
+   multimedia messages.  Popular multimedia data types include binary
+   word processing documents, binary business presentation graphics,
+   voice, and video.
+
+   Voice mail has historically been audio-centric.  Many voice
+   messaging systems only render voice.  Extensions such as fax enable
+   the voice mail system to send and receive fax images as well as
+   create multi-part voice and fax messages.  A few voice mail systems
+   can render text using text-to-speech or text-to-fax technology.
+   Although theoretically possible, none can today render video.
+
+   An important aspect of the interchange between voice messaging
+   services and desktop e-mail client applications is that the
+   rendering capability of the voice messaging platform is often much
+   less than the rendering capability of a desktop e-mail client.  In
+   the e-mail case, the sender has the expectation that the recipient
+   receives all components of a multimedia message.  This is so even if
+   the recipient cannot render all body parts.  In most cases, the
+   recipient can either find the appropriate rendering tool or tell the
+   sender that she cannot read the particular attachment.
+
+   This is an important issue.  By definition, a MIME-enabled user
+   agent, conforming to [4] will present or make available all of the
+   body parts to the recipient.  However, a voice mail system may not
+   be capable of storing non-voice objects.  Moreover, the voice mail
+   system may not be capable of notifying the recipient that there were
+   undeliverable message parts.
+
+   The inability of the receiving system to render a body part is
+   usually a permanent failure.  Retransmission of the message will not
+   improve the likelihood of a future successful delivery.  Contrast
+   this to the case with normal data delivery.  Traditional message
+   failures, such as a garbled message or disabled link will benefit
+   from retransmission.
+
+   This situation is fundamentally different from normal Internet mail.
+   In the Internet mail case, either the system delivered the message,
+   or it didn't.  There is no concept of a system partially delivering
+   a message.
+
+   In addition, the sender would not mind if the system did not deliver
+   non-critical parts of a message.  In fact, the sender's user agent
+   may be silently adding body parts to a message unbeknownst to the
+   sender.  For example, take Microsoft Outlook as a user agent.
+   Outlook often will attach a TNEF section or other body parts. If the
+
+
+Burger and Candell         Expires 12/6/00                    [Page 3]
+
+                  Critical Content of Internet Mail          June 2000
+
+
+
+   receiving system rejected the message because it could not render
+   TNEF, the sender would be understandably confused and upset.
+
+   Thus, there is a need for a method of indicating to a Mail Transfer
+   Agent (MTA) or User Agent (UA) that the sender considers parts of a
+   message to be critical.  From the sender's perspective, he would not
+   consider the message delivered if the system did not deliver the
+   critical parts.
+
+   One method of indicating critical content of a message is to define
+   a profile.  The profile defines discard rules based on knowledge of
+   the user population for silently deleting body parts.  Citing the
+   example above, a voice profile can easily declare that MTAs or UAs
+   can silently delete TNEF data and yet consider the message
+   successfully delivered.  This is, in fact, the approach originally
+   proposed for VPIMv3 [5].
+
+   Since one aspect of the issue is deciding when to notify the sender
+   that the system cannot deliver part of a message, one could use a
+   partial non-delivery notification mechanism [6] to indicate a
+   problem with delivering a given body part.  However, this requires
+   the user request a MDN.  Moreover, the sender will receive PNDN
+   failures for objects the sender may not be aware he is sending.  An
+   example would be the TNEF part.
+
+   Summarizing the needs, we need a mechanism that will let the sender
+   or sender's UA mark body parts he considers critical to the message
+   that the system must deliver.  The mechanism MUST NOT burden the
+   sender with failure notifications for non-critical body parts.  The
+   mechanism MUST conform to the general notification status request
+   mechanism for positive or negative notification.  When requested,
+   the mechanism MUST indicate to the sender when a receiving system
+   cannot deliver a critical body part.
+
+   In short, we need a method of indicating what sort of delivery
+   notification the sender requires on a per-body part basis.
+
+   This document describes a Critical Content marking mechanism that
+   satisfies these needs.  Following the format for Internet message
+   bodies [3], this document introduces the Content-Notification body
+   part header.  Values for this header are NOTIFY, PARTIAL, or IGNORE.
+   The receiving MTA or UA will generate a DSN or PNDN if it receives a
+   request for notification and the (non-)delivery status of the parts
+   marked NOTIFY meet the criteria for notification.  Likewise, the
+   receiving UA will generate a MDN or MNDN if it receives a request
+   for notification and the (non-)delivery status of the parts marked
+   NOTIFY meet the criteria for notification.
+
+   <<<EDITOR'S NOTE: We don't have an ID for MNDN yet, but it will look
+   like PNDN.  Stay tuned.>>>
+
+
+
+Burger and Candell         Expires 12/6/00                    [Page 4]
+
+                  Critical Content of Internet Mail          June 2000
+
+
+
+
+4.
+  Content-Notification Entity
+
+   The Content-Notification field is a MIME body part header inserted
+   by the sending UA to indicate to the receiving MTA or UA whether to
+   consider this body part when generating a (non-)delivery message.
+   If the value of the field is IGNORE, the receiving MTA or UA MUST
+   NOT generate a notification.  If the value of the field is NOTIFY,
+   the receiving MTA or UA MUST generate a notification, based on the
+   normal notification request mechanisms.  Normal notification request
+   mechanisms include the SMTP RCPT NOTIFY command [7] and the
+   Disposition-Notification-To header [8].
+
+   The terms "entity" and "body part" have the meanings defined in [3].
+
+   The next sections examine the actions taken by an MTA or UA given
+   the different values of Content-Notification.
+
+   NOTE: This implies that the MTA must examine the entire message on
+   receipt to determine whether it needs to generate a notification.
+   However, the MTA need not examine the message if it knows it can
+   store and forward all media types.  Said differently, an Internet e-
+   mail MTA can, by default, handle any arbitrary MIME-encapsulated
+   type.  Some voice mail systems, on the other hand, cannot even store
+   binary attachments, such as application/ms-word.  The voice mail
+   MTA, in this example, would be scanning for non-renderable body
+   parts anyway.
+
+  4.1. NOTIFY
+
+   "Content-Notification: NOTIFY" signifies that this body part is
+   critical to the sender.  The sender wishes to receive notification
+   reports for this body part.
+
+   If the receiving system cannot render or store a body part marked
+   NOTIFY, then the entire message has failed.  In this case, the
+   receiving system MUST take the appropriate failure action.
+
+   NOTE: We say "appropriate action", because the sender may have
+   suppressed all notifications.  In this case, the appropriate action
+   is to simply discard the message.
+
+  4.2. PARTIAL
+
+   "Content-Notification: PARTIAL" signifies that the sender wishes to
+   receive notification reports for this body part.
+
+   If the receiving system cannot render or store a body part marked
+   PARTIAL, the receiving system MUST take the appropriate failure
+   action.  It is important to note that if the system is successful in
+   delivering other critical body parts, then the message delivery is
+
+
+Burger and Candell         Expires 12/6/00                    [Page 5]
+
+                  Critical Content of Internet Mail          June 2000
+
+
+
+   successful.  In this situation, the receiving system MUST return a
+   partial non-delivery notification [6].
+
+  4.3. IGNORE
+
+   "Content-Notification: IGNORE" signifies that the sender does not
+   care about notification reports for this body part.
+
+   If the receiving system cannot render or store a body part marked
+   IGNORE, the receiving system may silently delete the body part.  The
+   receiving system MUST NOT return a delivery failure, unless parts
+   marked PARTIAL or NOTIFY have also failed.
+
+  4.4. Other Values
+
+   The receiving system MUST treat unrecognized values as PARTIAL.
+   This is to provide backward compatibility with future uses of the
+   Content-Notification entity.
+
+   <<<ALTERNATIVES:
+
+   IGNORE: If I don't recognize something, ignore it!
+
+   NOTIFY: Future values are more likely to involve some sort of
+   notification, rather than non-notification.  However, if the
+   notifications are more sophisticated than NOTIFY, senders may be
+   miffed they didn't get the processing they expected.
+
+   Reject the Message: This would be too extreme!  Yes, it would weed
+   out non-conformant sending UAs, but this would really piss off
+   users.
+
+
+   So far, we have one vote for IGNORE, as that would be compatible
+   with VPIMv2.
+   We have one vote for PARTIAL, as that would provide forward-
+   compatibility with future uses of Content-Notification.
+   We expect this to be a point of discussion on the list.
+
+   End of ALTERNATIVES>>>
+
+  4.5. Notification Precedence
+
+   <<<We'll fill-in this in the next draft.>>>
+
+
+5.
+  Backward Compatibility Considerations
+
+   If there are no Content-Notification entities in the message, the
+   default value for Content-Notification is NOTIFY.  The standard
+   notification mechanisms work for sending user agents (UA) that do
+
+
+Burger and Candell         Expires 12/6/00                    [Page 6]
+
+                  Critical Content of Internet Mail          June 2000
+
+
+
+   not know about the content notification entity.  All body parts are
+   critical, because they have the default marking of NOTIFY.
+
+   If there is at least one Content-Notification entity in the message,
+   the default value for unspecified body parts is IGNORE.  The
+   philosophy is that UAs, especially manually constructed messages,
+   will explicitly mark the critical body parts.
+
+   NOTE: We could choose the default value for Content-Notification to
+   be IGNORE.  This would make VPIMv2 automatically compliant with this
+   document, as VPIMv2 has provision to silently delete undeliverable
+   parts.  However, VPIMv2 systems should not be receiving arbitrary e-
+   mail from the Internet.  If they do, they should be compliant with
+   this series of documents.  By defaulting to NOTIFY, this draft is
+   compliant with the rest of the Internet infrastructure.
+
+
+
+6.
+  Security Considerations
+
+   We anticipate no new security issues beyond those already addressed
+   by the notification RFCs.
+
+
+7.
+  Collected Syntax
+
+   The format of the collected syntax is in accordance with the ABNF of
+   [9].  Note that per RFC 2045, none of the strings are case
+   sensitive.
+
+
+        "Content-Notification" ":" notification-type CRLF
+
+        notification-type = "NOTIFY" / "PARTIAL" / "IGNORE"
+
+
+
+8.
+  References
+
+
+   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+      9, RFC 2026, October 1996.
+
+   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+      Levels", BCP 14, RFC 2119, March 1997.
+
+   3  Freed, N. and Borenstein, N., "Multipurpose Internet Mail
+      Extensions (MIME) Part One: Format of Internet Message Bodies",
+      RFC 2045, Innosoft and First Virtual, November 1996.
+
+
+
+
+Burger and Candell         Expires 12/6/00                    [Page 7]
+
+                  Critical Content of Internet Mail          June 2000
+
+
+
+
+   4  Freed, N. and Borenstein, N., "Multipurpose Internet Mail
+      Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft and
+      First Virtual, November 1996.
+
+   5  Vaudreuil, G. and Parsons, G., "Voice Profile for Internet Mail -
+      version 3", <draft-ema-vpimv3-00.txt>, Work in Progress, expired.
+
+   6  Burger, E., "Partial Non-Delivery Notification", Work in
+      Progress, draft-ema-burger-pndn-01.txt, March 2000.
+
+   7  Moore, K., "SMTP Service Extension for Delivery Status
+      Notifications", RFC 1981, University of Tennessee, January 1996.
+
+   8  Fajman, R., "An Extensible Message Format for Message Disposition
+      Notifications", RFC 2298, National Institutes of Health, March
+      1998.
+
+   9  Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
+      Specifications: ABNF", RFC 2234, Internet Mail Consortium and
+      Demon Internet Ltd., November 1997.
+
+
+
+
+9.
+  Acknowledgments
+
+   Coming soon!
+
+
+10.
+   Author's Addresses
+
+   Eric Burger
+   Centigram Communications Corporation
+   Maryland Technology Center
+   1375 Piccard Dr., MS 150I
+   Rockville, MD  20850-4311
+   USA
+
+   Phone: +1 301/212-3320
+   Email: e.burger@ieee.org
+
+
+   Emily Candell
+   Comverse Network Systems
+   200 Quannapowitt Pkwy.
+   Wakefield, MA  01880
+   USA
+
+   Phone: +1 781/213-2324
+   Email: emily@comversens.com
+
+
+Burger and Candell         Expires 12/6/00                    [Page 8]
+
+                  Critical Content of Internet Mail          June 2000
+
+
+
+
+Full Copyright Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances
+   of licenses to be made available, or the result of an attempt made
+   to obtain a general license or permission for the use of such
+   proprietary rights by implementers or users of this specification
+   can be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+   Copyright (C) 2000 The Internet Society.  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph
+   are included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the  purpose of
+
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+Burger and Candell         Expires 12/6/00                    [Page 9]
+
+
+
diff --git a/Documentation/en/I-D/draft-burger-vpim-cc-01.txt b/Documentation/en/I-D/draft-burger-vpim-cc-01.txt
new file mode 100644
index 00000000..f7c638c3
--- /dev/null
+++ b/Documentation/en/I-D/draft-burger-vpim-cc-01.txt
@@ -0,0 +1,10 @@
+

+This document has been replaced by draft-ietf-vpim-cc-00.txt.

+For more information or a copy of the document, contact the author directly.

+

+Draft Author(s):

+

+E. Burger: e.burger@ieee.org                                                       

+E. Candell: emily@comversens.com                                                    

+

+

diff --git a/Documentation/en/I-D/draft-ietf-vpim-cc-00.txt b/Documentation/en/I-D/draft-ietf-vpim-cc-00.txt
new file mode 100644
index 00000000..8a2d8438
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-vpim-cc-00.txt
@@ -0,0 +1,628 @@
+
+
+Network Working Group                                           E. Burger
+Internet Draft                                   Centigram Communications
+Document: draft-ietf-vpim-cc-00.txt                            E. Candell
+Obsoletes: draft-burger-vpim-cc-00.txt           Comverse Network Systems
+Category: Standards Track                                   July 14, 2000
+Expires in six Months
+
+
+                   Critical Content of Internet Mail
+
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026 [1].
+
+   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."
+
+   One can access the list of current Internet-Drafts at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+
+   One can access the list of Internet-Draft Shadow Directories at
+   http://www.ietf.org/shadow.html.
+
+
+
+1.   Abstract
+
+   This document describes a mechanism for identifying the body parts
+   that the sender deems critical in a multi-part Internet mail
+   message.
+
+   By knowing what parts of a message the sender deems critical, a MTA
+   or UA can intelligently handle multi-part messages.  Applications of
+   critical content include, but are not limited to, the following
+   applications.  Critical content can help a smart gateway decide what
+   parts to forward.  It can indicate how hard a gateway should try to
+   deliver a body part.  It can help an MTA to select body parts to
+   silently delete when a system of lesser capability receives a
+   message.  In addition, critical content can help indicate the
+   notification strategy of the receiving system.
+
+
+
+
+
+
+                           Expires 1/14/01                    [Page 1]
+                  Critical Content of Internet Mail          July 2000
+
+
+Table of Contents
+
+1.  ABSTRACT .........................................................1
+2.  CONVENTIONS USED IN THIS DOCUMENT ................................2
+3.  INTRODUCTION .....................................................2
+
+4.  CONTENT-CRITICALITY ENTITY .......................................5
+4.1.  CRITICAL .......................................................6
+4.2.  IMPORTANT ......................................................6
+4.3.  IGNORE .........................................................6
+4.4.  Other Values ...................................................7
+4.5.  Criticality Precedence .........................................7
+4.6.  Summary ........................................................7
+5.  BACKWARD COMPATIBILITY CONSIDERATIONS ............................8
+
+6.  SECURITY CONSIDERATIONS ..........................................9
+7.  COLLECTED SYNTAX .................................................9
+8.  REFERENCES .......................................................9
+9.  ACKNOWLEDGMENTS .................................................10
+10. AUTHOR'S ADDRESSES ..............................................10
+
+
+2.   Conventions used in this document
+
+   This document refers generically to the sender of a message in the
+   masculine (he/him/his) and the recipient of the message in the
+   feminine (she/her/hers).  This convention is purely for convenience
+   and makes no assumption about the gender of a message sender or
+   recipient.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
+   this document are to be interpreted as described in RFC-2119 [2].
+
+   FORMATTING NOTE: Notes, such at this one, provide additional
+   nonessential information that the reader may skip without missing
+   anything essential.  The primary purpose of these non-essential
+   notes is to convey information about the rationale of this document,
+   or to place this document in the proper historical or evolutionary
+   context.  Readers whose sole purpose is to construct a conformant
+   implementation may skip such information.  However, it may be of use
+   to those who wish to understand why we made certain design choices.
+
+
+3.   Introduction
+
+   This document describes the Critical Content identification for
+   multi-part Internet mail.
+
+   The need for a critical content identification mechanism comes about
+   because of the internetworking of Internet mail systems with legacy
+
+
+Burger and Candell         Expires 1/14/01                    [Page 2]
+                  Critical Content of Internet Mail          July 2000
+
+
+   messaging systems that do not fulfil all of the semantics of
+   Internet mail.  Such legacy systems have a limited ability to render
+   all parts of a given message.  This document will use the case of an
+   Internet mail system exchanging electronic messages with a legacy
+   voice messaging system for illustrative purposes.
+
+   Electronic mail has historically been text-centric.  Extensions such
+   as MIME [3] enable the desktop to send and receive multi-part,
+   multimedia messages.  Popular multimedia data types include binary
+   word processing documents, binary business presentation graphics,
+   voice, and video.
+
+   Voice mail has historically been audio-centric.  Many voice
+   messaging systems only render voice.  Extensions such as fax enable
+   the voice mail system to send and receive fax images as well as
+   create multi-part voice and fax messages.  A few voice mail systems
+   can render text using text-to-speech or text-to-fax technology.
+   Although theoretically possible, none can today render video.
+
+   An important aspect of the interchange between voice messaging
+   services and desktop e-mail client applications is that the
+   rendering capability of the voice messaging platform is often much
+   less than the rendering capability of a desktop e-mail client.  In
+   the e-mail case, the sender has the expectation that the recipient
+   receives all components of a multimedia message.  This is so even if
+   the recipient cannot render all body parts.  In most cases, the
+   recipient can either find the appropriate rendering tool or tell the
+   sender that she cannot read the particular attachment.
+
+   This is an important issue.  By definition, a MIME-enabled user
+   agent, conforming to [4] will present or make available all of the
+   body parts to the recipient.  However, a voice mail system may not
+   be capable of storing non-voice objects.  Moreover, the voice mail
+   system may not be capable of notifying the recipient that there were
+   undeliverable message parts.
+
+   The inability of the receiving system to render a body part is
+   usually a permanent failure.  Retransmission of the message will not
+   improve the likelihood of a future successful delivery.  Contrast
+   this to the case with normal data delivery.  Traditional message
+   failures, such as a garbled message or disabled link will benefit
+   from retransmission.
+
+   This situation is fundamentally different from normal Internet mail.
+   In the Internet mail case, either the system delivered the message,
+   or it didn't.  There is no concept of a system partially delivering
+   a message.
+
+   In addition, the sender would not mind if the system did not deliver
+   non-critical parts of a message.  In fact, the sender's user agent
+   may be silently adding body parts to a message unbeknownst to the
+   sender.  For example, take Microsoft Outlook as a user agent.
+
+Burger and Candell         Expires 1/14/01                    [Page 3]
+                  Critical Content of Internet Mail          July 2000
+
+
+   Outlook often will attach a TNEF section or other body parts. If the
+   receiving system rejected the message because it could not render
+   TNEF, the sender would be understandably confused and upset.
+
+   Thus, there is a need for a method of indicating to a Mail Transfer
+   Agent (MTA) or User Agent (UA) that the sender considers parts of a
+   message to be critical.  From the sender's perspective, he would not
+   consider the message delivered if the system did not deliver the
+   critical parts.
+
+   One method of indicating critical content of a message is to define
+   a profile.  The profile defines discard rules based on knowledge of
+   the user population for silently deleting body parts.  Citing the
+   example above, a voice profile can easily declare that MTAs or UAs
+   can silently delete TNEF data and yet consider the message
+   successfully delivered.  This is, in fact, the approach originally
+   proposed for VPIMv3 [5].
+
+   Since one aspect of the issue is deciding when to notify the sender
+   that the system cannot deliver part of a message, one could use a
+   partial non-delivery notification mechanism [6] to indicate a
+   problem with delivering a given body part.  However, this requires
+   the user request a MDN.  Moreover, the sender will receive PNDN
+   failures for objects the sender may not be aware he is sending.  An
+   example would be the TNEF part.
+
+   Summarizing the needs, we need a mechanism that will let the sender
+   or sender's UA mark body parts he considers critical to the message
+   that the system must deliver.  The mechanism MUST NOT burden the
+   sender with failure notifications for non-critical body parts.  The
+   mechanism MUST conform to the general notification status request
+   mechanism for positive or negative notification.  When requested,
+   the mechanism MUST indicate to the sender when a receiving system
+   cannot deliver a critical body part.
+
+   In short, we need a method of letting the sender indicate what body-
+   parts he considers to be critical.
+
+   This document describes a Critical Content marking mechanism that
+   satisfies these needs.  Following the format for Internet message
+   bodies [3], this document introduces the Content-Criticality body
+   part header.  Values for this header are CRITICAL, NOTIFY, or
+   IGNORE.  The receiving MTA or UA will generate a DSN or PNDN at
+   delivery time if it receives a request for notification and the
+   (non-)delivery status of the parts marked NOTIFY meet the criteria
+   for notification.  Likewise, the receiving UA will generate a MDN or
+   PMDN at reading time if it receives a request for notification and
+   the (non-)delivery status of the parts marked CRITICAL meet the
+   criteria for notification.
+
+
+
+
+Burger and Candell         Expires 1/14/01                    [Page 4]
+                  Critical Content of Internet Mail          July 2000
+
+
+   NOTE: A straight-forward alternative implementation method for
+   marking a body part critical is to use a content-disposition
+   parameter called "criticality".
+
+   <<<EDITOR'S NOTE: Let's discuss the merits of content-disposition on
+   the list.  It's trivial to rework this ID; only the Entity changes.
+   That is, rather than having a 'Content-Criticality: Foo' part header
+   (entity), we have a 'content-disposition: ... ; criticality="Foo"'
+   parameter.  Everything else in the document stands (the parameter
+   names and actions).
+
+   I at first proposed content-disposition; Ned feels strongly about
+   it; Keith likes it.  Emily felt strongly that the indicator
+   shouldn't be content-disposition, but rather its own entity.  I
+   can't remember all the reasons, but they were enough for me to go
+   down the entity, rather than parameter path.
+
+   Comments?>>>
+
+   <<<EDITOR'S NOTE: We don't have an ID for PMDN yet, but it will look
+   like PNDN.  Stay tuned.>>>
+
+
+
+4.   Content-Criticality Entity
+
+   The Content-Criticality field is a MIME body part header inserted by
+   the sending UA to indicate to the receiving MTA or UA whether to
+   consider this body part critical.
+
+   A CRITICAL body part is one the sender requires the receiving system
+   to deliver for him to consider the message delivered.
+
+   An IMPORTANT body part is one the sender doesn't consider critical
+   to the delivery of the message.  However, the sender may be
+   interested in knowing if the receiving system delivered the body
+   part.
+
+   An IGNORE body part is one the sender doesn't care about whether the
+   receiving system delivers it or not.  The receiving system can
+   silently delete such body parts if the receiving system cannot
+   deliver the part.
+
+   The terms "entity" and "body part" have the meanings defined in [3].
+
+   One obvious application of critical content is generating a
+   (non-)delivery message.  If the value of the field is IGNORE, the
+   receiving MTA or UA MUST NOT generate a notification.  If the value
+   of the field is CRTITICAL, the receiving MTA or UA will generate a
+   notification, based on the normal notification request mechanisms.
+   Normal notification request mechanisms include the SMTP RCPT NOTIFY
+   command [7] and the Disposition-Notification-To header [8].
+
+Burger and Candell         Expires 1/14/01                    [Page 5]
+                  Critical Content of Internet Mail          July 2000
+
+
+
+   For example, if the sending system requests notification, and a
+   CRITICAL part fails, the receiving system will generate a NDN for
+   the whole message.  Conversely, if only an IGNORE part fails, the
+   receiving system will not generate a NDN.
+
+   The next sections examine the actions taken by an MTA or UA given
+   the different values of Content-Criticality.
+
+   NOTE: This implies that the MTA must examine the entire message on
+   receipt to determine whether it needs to generate a notification.
+   However, the MTA need not examine the message if it knows it can
+   store and forward all media types.  Said differently, an Internet e-
+   mail MTA can, by default, handle any arbitrary MIME-encapsulated
+   type.  Some voice mail systems, on the other hand, cannot store
+   binary attachments at all, such as application/ms-word.  The voice
+   mail MTA, in this example, would be scanning for non-renderable body
+   parts in any event.
+
+  4.1. CRITICAL
+
+   "Content-Criticality: CRITICAL" signifies that this body part is
+   critical to the sender.
+
+   If the receiving system cannot render or store a body part marked
+   CRITICAL, then the entire message has failed.  In this case, the
+   receiving system MUST take the appropriate failure action.
+
+   NOTE: We say "appropriate action", because the sender may have
+   suppressed all notifications.  In this case, the appropriate action
+   is to simply discard the message.
+
+  4.2. IMPORTANT
+
+   "Content-Criticality: IMPORTANT" signifies that the sender wishes to
+   receive notification reports for this body part.  Failure of such a
+   body part does not result in the failure of the message as a whole,
+   as happens with CRITICAL body parts.  However, the receiving system
+   MUST perform the appropriate body-part failure action.
+
+   If the receiving system cannot render or store a body part marked
+   IMPORTANT, the receiving system MUST take the appropriate failure
+   action.  It is important to note that if the system is successful in
+   delivering other critical body parts, then the message delivery is
+   successful.  In this situation, the receiving system MUST return a
+   partial non-delivery notification [6].
+
+  4.3. IGNORE
+
+   "Content-Criticality: IGNORE" signifies that the sender does not
+   care about notification reports for this body part.
+
+
+Burger and Candell         Expires 1/14/01                    [Page 6]
+                  Critical Content of Internet Mail          July 2000
+
+
+   If the receiving system cannot render or store a body part marked
+   IGNORE, the receiving system may silently delete the body part.  The
+   receiving system MUST NOT return a delivery failure, unless parts
+   marked IMPORTANT or CRITICAL have also failed.
+
+  4.4. Other Values
+
+   The receiving system MUST treat unrecognized values as IMPORTANT.
+   This is to provide backward compatibility with future uses of the
+   Content-Criticality entity.
+
+   <<<ALTERNATIVES:
+
+   IGNORE: If I don't recognize something, ignore it!
+
+   CRITICAL: Future values are more likely to involve some sort of
+   notification, rather than non-notification.  However, if the
+   notifications are more sophisticated than CRITICAL, senders may be
+   miffed they didn't get the processing they expected.
+
+   Reject the Message: This would be too extreme!  Yes, it would weed
+   out non-conformant sending UAs, but this would really piss off
+   users.
+
+
+   So far, we have one vote for IGNORE, as that would be compatible
+   with VPIMv2.
+   We have one vote for IMPORTANT, as that would provide forward-
+   compatibility with future uses of Content-Criticality.
+   We expect this to be a point of discussion on the list.
+
+   End of ALTERNATIVES>>>
+
+  4.5. Criticality Precedence
+
+   <<<We'll fill-in this in the next draft.>>>
+
+  4.6. Summary
+
+   The following table summarizes the actions expected of a conforming
+   MTA or UA.
+
+
+
+
+
+
+
+
+
+
+
+
+Burger and Candell         Expires 1/14/01                    [Page 7]
+                  Critical Content of Internet Mail          July 2000
+
+
+                            +--------------------------------------+
+                            |    Sending UA Has Marked Body Part   |
+                            |-------------+-------------+----------|
+                            |  CRITICAL   |  IMPORTANT  |  IGNORE  |
+       +--------------------+-------------+-------------+----------+
+       | Body Part is       | Appropriate | Appropriate |          |
+       | Deliverable/read   |   Action    |   Action    |  ignore  |
+       +--------------------+-------------+-------------+----------+
+       | Body Part is       | Fail Entire | Appropriate |          |
+       | Undeliverable /    |   Message   |   Action    |  ignore  |
+       |  Unreadable        |             |             |          |
+       +--------------------+--------------------------------------+
+
+   The distinction between deliverable/read is as follows.  A MTA can
+   determine if a body part is deliverable.  Sample actions a MTA can
+   take are generating a NDN or DSN.  An UA can determine if a body
+   part is readable.  A sample action an UA can take is generating a
+   MDN.
+
+   The "Appropriate Action" is the action the MTA or UA would take
+   given the context of execution.  For example, if a sender requests
+   return receipt and the receiver reads a CRITICAL body part, the
+   receiving UA must generate the appropriate MDN (following the rules
+   for MDN).
+
+   "Ignore" means the MTA or UA MUST ignore the operation on the body
+   part.  The MTA or UA MUST treat the message as if the body part was
+   not present in the message.
+
+
+5.   Backward Compatibility Considerations
+
+   If there are no Content-Criticality entities in the message, the
+   default value for Content-Criticality is CRITICAL.  The standard
+   notification mechanisms work for sending user agents (UA) that do
+   not know about the content notification entity.  All body parts are
+   critical, because they have the default marking of CRITICAL.
+
+   If there is at least one Content-Criticality entity in the message,
+   the default value for unspecified body parts is IGNORE.  The
+   philosophy is that UAs, especially manually constructed messages,
+   will explicitly mark the critical body parts.
+
+   NOTE: We could choose the default value for Content-Criticality to
+   be IGNORE.  This would make VPIMv2 automatically compliant with this
+   document, as VPIMv2 has provision to silently delete undeliverable
+   parts.  However, VPIMv2 systems should not be receiving arbitrary e-
+   mail from the Internet.  If they do, they should be compliant with
+   this series of documents.  By defaulting to CRITICAL, this draft is
+   compliant with the rest of the Internet infrastructure.
+
+
+
+Burger and Candell         Expires 1/14/01                    [Page 8]
+                  Critical Content of Internet Mail          July 2000
+
+
+   NOTE: Some VPIMv2 implementations can receive arbitrary e-mail from
+   the Internet.  However, these systems are really acting in the
+   capacity of an Internet Voice Mail system.  In this case, one would
+   expect the implementation to provide Internet Voice Mail semantics
+   to Internet Voice Mail messages.
+
+
+6.   Security Considerations
+
+   Receiving systems and users should not place any authentication
+   value on the Content-Criticality entity.  Just because a message has
+   a particular Content-Criticality value doesn't mean that the message
+   really originated at a given type of system.
+
+
+7.   Collected Syntax
+
+   The format of the collected syntax is in accordance with the ABNF of
+   [9].  Note that per RFC 2045, none of the strings are case
+   sensitive.
+
+
+        "Content-Criticality" ":" notification-type CRLF
+
+        notification-type = "CRITICAL" / "IMPORTANT" / "IGNORE"
+
+
+
+8.   References
+
+
+   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+      9, RFC 2026, October 1996.
+
+   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+      Levels", BCP 14, RFC 2119, March 1997.
+
+   3  Freed, N. and Borenstein, N., "Multipurpose Internet Mail
+      Extensions (MIME) Part One: Format of Internet Message Bodies",
+      RFC 2045, Innosoft and First Virtual, November 1996.
+
+   4  Freed, N. and Borenstein, N., "Multipurpose Internet Mail
+      Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft and
+      First Virtual, November 1996.
+
+   5  Vaudreuil, G. and Parsons, G., "Voice Profile for Internet Mail -
+      version 3", <draft-ema-vpimv3-00.txt>, Work in Progress, expired.
+
+   6  Burger, E., "Partial Non-Delivery Notification", Work in
+      Progress, draft-ema-burger-pndn-01.txt, March 2000.
+
+
+
+Burger and Candell         Expires 1/14/01                    [Page 9]
+                  Critical Content of Internet Mail          July 2000
+
+
+
+   7  Moore, K., "SMTP Service Extension for Delivery Status
+      Notifications", RFC 1981, University of Tennessee, January 1996.
+
+   8  Fajman, R., "An Extensible Message Format for Message Disposition
+      Notifications", RFC 2298, National Institutes of Health, March
+      1998.
+
+   9  Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
+      Specifications: ABNF", RFC 2234, Internet Mail Consortium and
+      Demon Internet Ltd., November 1997.
+
+
+
+
+9.   Acknowledgments
+
+   We'd like to thank Ned Freed for pointing out that this mechanism
+   was about criticality, not notification per se.  That insight made
+   the concept and descriptions infinitely more straight forward.  If
+   it's still confusing, it's our fault!
+
+   We'd also like to thank Keith Moore for helping us tighten-up our
+   explanations.
+
+
+10.    Author's Addresses
+
+   Eric Burger
+   Centigram Communications Corporation
+   Maryland Technology Center
+   1375 Piccard Dr., MS 150I
+   Rockville, MD  20850-4311
+   USA
+
+   Phone: +1 301/212-3320
+   Email: e.burger@ieee.org
+
+
+   Emily Candell
+   Comverse Network Systems
+   200 Quannapowitt Pkwy.
+   Wakefield, MA  01880
+   USA
+
+   Phone: +1 781/213-2324
+   Email: emily@comversens.com
+
+
+
+
+
+
+Burger and Candell         Expires 1/14/01                   [Page 10]
+                  Critical Content of Internet Mail          July 2000
+
+
+Full Copyright Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances
+   of licenses to be made available, or the result of an attempt made
+   to obtain a general license or permission for the use of such
+   proprietary rights by implementers or users of this specification
+   can be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+   Copyright (C) 2000 The Internet Society.  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph
+   are included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the  purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+Burger and Candell         Expires 1/14/01                   [Page 11]
+
\ No newline at end of file
diff --git a/Documentation/en/I-D/draft-ietf-vpim-cc-01.txt b/Documentation/en/I-D/draft-ietf-vpim-cc-01.txt
new file mode 100644
index 00000000..31c4680b
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-vpim-cc-01.txt
@@ -0,0 +1,627 @@
+
+Network Working Group                                           E. Burger
+Internet Draft                                         SnowShore Networks
+Document: draft-ietf-vpim-cc-01.txt                            E. Candell
+Category: Standards Track                        Comverse Network Systems
+Expires February 2001                                    October 18, 2000
+ 
+ 
+                   Critical Content of Internet Mail 
+ 
+ 
+Status of this Memo 
+ 
+   This document is an Internet-Draft and is in full conformance with 
+   all provisions of Section 10 of RFC2026 [1].  
+    
+   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." 
+    
+   One can access the list of current Internet-Drafts at 
+   http://www.ietf.org/ietf/1id-abstracts.txt 
+    
+   One can access the list of Internet-Draft Shadow Directories at 
+   http://www.ietf.org/shadow.html. 
+    
+    
+    
+1.   Abstract 
+    
+   This document describes a mechanism for identifying the body parts 
+   that the sender deems critical in a multi-part Internet mail 
+   message. 
+    
+   By knowing what parts of a message the sender deems critical, a MTA 
+   or UA can intelligently handle multi-part messages when gatewaying 
+   (MTA) or presenting (UA) to systems of lesser capability. Critical 
+   content can help a smart gateway decide what parts to forward.  It 
+   can indicate how hard a gateway should try to deliver a body part.  
+   It can help an MTA to select body parts to silently delete when a 
+   system of lesser capability receives a message.  In addition, 
+   critical content can help indicate the notification strategy of the 
+   receiving system. 
+    
+
+
+
+
+
+ 
+                           Expires 4/18/01                    [Page 1] 
+                  Critical Content of Internet Mail       October 2000 
+ 
+ 
+Table of Contents 
+    
+1.  ABSTRACT .........................................................1 
+2.  CONVENTIONS USED IN THIS DOCUMENT ................................2 
+3.  INTRODUCTION .....................................................2 
+4.  CONTENT-CRITICALITY ENTITY .......................................5 
+
+4.1.  CRITICAL .......................................................6 
+4.2.  IGNORE .........................................................6 
+4.3.  Other Values ...................................................6 
+4.4.  Summary ........................................................6 
+5.  BACKWARD COMPATIBILITY CONSIDERATIONS ............................7 
+6.  MIME INTERACTIONS ................................................8 
+6.1.  multipart/alternative ..........................................8 
+6.2.  multipart/related ..............................................8 
+
+6.3.  message/rfc822 .................................................8 
+7.  SECURITY CONSIDERATIONS ..........................................8 
+8.  COLLECTED SYNTAX .................................................9 
+9.  REFERENCES .......................................................9 
+10. ACKNOWLEDGMENTS .................................................10 
+11. AUTHOR'S ADDRESSES ..............................................10 
+    
+    
+2.   Conventions used in this document 
+    
+   This document refers generically to the sender of a message in the 
+   masculine (he/him/his) and the recipient of the message in the 
+   feminine (she/her/hers).  This convention is purely for convenience 
+   and makes no assumption about the gender of a message sender or 
+   recipient. 
+    
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
+   this document are to be interpreted as described in RFC-2119 [2]. 
+    
+   FORMATTING NOTE: Notes, such at this one, provide additional 
+   nonessential information that the reader may skip without missing 
+   anything essential.  The primary purpose of these non-essential 
+   notes is to convey information about the rationale of this document, 
+   or to place this document in the proper historical or evolutionary 
+   context.  Readers whose sole purpose is to construct a conformant 
+   implementation may skip such information.  However, it may be of use 
+   to those who wish to understand why we made certain design choices. 
+    
+    
+3.   Introduction 
+    
+   This document describes the Critical Content identification for 
+   multi-part Internet mail. 
+    
+
+  
+Burger and Candell         Expires 4/18/01                    [Page 2] 
+                  Critical Content of Internet Mail       October 2000 
+ 
+ 
+   The need for a critical content identification mechanism comes about 
+   because of the internetworking of Internet mail systems with legacy 
+   messaging systems that do not fulfil all of the semantics of 
+   Internet mail.  Such legacy systems have a limited ability to render 
+   all parts of a given message.  This document will use the case of an 
+   Internet mail system exchanging electronic messages with a legacy 
+   voice messaging system for illustrative purposes. 
+    
+   Electronic mail has historically been text-centric.  Extensions such 
+   as MIME [3] enable the desktop to send and receive multi-part, 
+   multimedia messages.  Popular multimedia data types include binary 
+   word processing documents, binary business presentation graphics, 
+   voice, and video. 
+    
+   Voice mail has historically been audio-centric.  Many voice 
+   messaging systems only render voice.  Extensions such as fax enable 
+   the voice mail system to send and receive fax images as well as 
+   create multi-part voice and fax messages.  A few voice mail systems 
+   can render text using text-to-speech or text-to-fax technology.  
+   Although theoretically possible, none can today render video. 
+    
+   An important aspect of the interchange between voice messaging 
+   services and desktop e-mail client applications is that the 
+   rendering capability of the voice messaging platform is often much 
+   less than the rendering capability of a desktop e-mail client.  In 
+   the e-mail case, the sender has the expectation that the recipient 
+   receives all components of a multimedia message.  This is so even if 
+   the recipient cannot render all body parts.  In most cases, the 
+   recipient can either find the appropriate rendering tool or tell the 
+   sender that she cannot read the particular attachment. 
+    
+   This is an important issue.  By definition, a MIME-enabled user 
+   agent, conforming to [4] will present or make available all of the 
+   body parts to the recipient.  However, a voice mail system may not 
+   be capable of storing non-voice objects.  Moreover, the voice mail 
+   system may not be capable of notifying the recipient that there were 
+   undeliverable message parts. 
+    
+   The inability of the receiving system to render a body part is 
+   usually a permanent failure.  Retransmission of the message will not 
+   improve the likelihood of a future successful delivery.  Contrast 
+   this to the case with normal data delivery.  Traditional message 
+   failures, such as a garbled message or disabled link will benefit 
+   from retransmission. 
+    
+   This situation is fundamentally different from normal Internet mail.  
+   In the Internet mail case, either the system delivered the message, 
+   or it didn't.  There is no concept of a system partially delivering 
+   a message. 
+    
+   In addition, the sender would not mind if the system did not deliver 
+   non-critical parts of a message.  In fact, the sender's user agent 
+  
+Burger and Candell         Expires 4/18/01                    [Page 3] 
+                  Critical Content of Internet Mail       October 2000 
+ 
+ 
+   may be silently adding body parts to a message unbeknownst to the 
+   sender.  For example, take Microsoft Outlook as a user agent.  
+   Outlook often will attach a TNEF section or other body parts. If the 
+   receiving system rejected the message because it could not render 
+   TNEF, the sender would be understandably confused and upset. 
+    
+   Thus, there is a need for a method of indicating to a Mail Transfer 
+   Agent (MTA) or User Agent (UA) that the sender considers parts of a 
+   message to be critical.  From the sender's perspective, he would not 
+   consider the message delivered if the system did not deliver the 
+   critical parts. 
+    
+   One method of indicating critical content of a message is to define 
+   a profile.  The profile defines discard rules based on knowledge of 
+   the user population for silently deleting body parts.  Citing the 
+   example above, a voice profile can easily declare that MTAs or UAs 
+   can silently delete TNEF data and yet consider the message 
+   successfully delivered.  This is, in fact, the approach taken by 
+   VPIMv2 [5]. 
+    
+   Since one aspect of the issue is deciding when to notify the sender 
+   that the system cannot deliver part of a message, one could use a 
+   partial non-delivery notification mechanism [6] to indicate a 
+   problem with delivering a given body part.  However, this requires 
+   the user request a MDN.  Moreover, the sender will receive PNDN 
+   failures for objects the sender may not be aware he is sending.  An 
+   example would be the TNEF part. 
+    
+   Summarizing the needs, we need a mechanism that will let the sender 
+   or sender's UA mark body parts he considers critical to the message 
+   that the system must deliver.  The mechanism MUST NOT burden the 
+   sender with failure notifications for non-critical body parts.  The 
+   mechanism MUST conform to the general notification status request 
+   mechanism for positive or negative notification.  When requested, 
+   the mechanism MUST indicate to the sender when a receiving system 
+   cannot deliver a critical body part. 
+    
+   In short, we need a method of letting the sender indicate what body-
+   parts he considers to be critical. 
+    
+   This document describes a Critical Content marking mechanism that 
+   satisfies these needs.  Following the format for Internet message 
+   bodies [3], this document introduces the Content-Criticality body 
+   part header.  Values for this header are CRITICAL, NOTIFY, or 
+   IGNORE.  The receiving MTA or UA will generate a DSN or MDN at 
+   delivery time or reading time if it receives a request for 
+   notification and the (non-)delivery status of the parts marked 
+   NOTIFY meet the criteria for notification.   
+    
+   NOTE: A straight-forward alternative implementation method for 
+   marking a body part critical is to use a content-disposition 
+   parameter called "criticality". 
+  
+Burger and Candell         Expires 4/18/01                    [Page 4] 
+                  Critical Content of Internet Mail       October 2000 
+ 
+ 
+    
+   NOTE: We could have made the critical content indicator a parameter 
+   to content-disposition.  This has the benefit of being very easy for 
+   IMAP servers to implement.  In particular, IMAP servers 
+   automatically present the content-disposition entity when a UA 
+   requests information on a message.  On the other hand, the UA must 
+   explicitly request the presence and value of different entities, 
+   such as content-criticality.  However, implementing the critical 
+   content indicator as a parameter to content-disposition overloads 
+   the meaning of the entity.  Moreover, IMAP servers can present, in 
+   the future, content-criticality by default.  Lastly, most UA's that 
+   have interest in content-criticality will explicitly request the 
+   header in any event. 
+    
+    
+4.   Content-Criticality Entity 
+    
+   The Content-Criticality field is a MIME body part header inserted by 
+   the sending UA to indicate to the receiving MTA or UA whether to 
+   consider this body part critical. 
+    
+   A CRITICAL body part is one the sender requires the receiving system 
+   to deliver for him to consider the message delivered. 
+    
+   An IGNORE body part is one the sender doesn't care whether the 
+   receiving system delivers it or not.  The receiving system can 
+   silently delete such body parts if the receiving system cannot 
+   deliver the part. 
+    
+   The terms "entity" and "body part" have the meanings defined in [3]. 
+    
+   One obvious application of critical content is generating a 
+   (non-)delivery message.  If the value of the field is IGNORE, the 
+   receiving MTA or UA MUST NOT generate a notification.  If the value 
+   of the field is CRTITICAL, the receiving MTA or UA will generate a 
+   notification, based on the normal notification request mechanisms.  
+   Normal notification request mechanisms include the SMTP RCPT NOTIFY 
+   command [7] and the Disposition-Notification-To header [8]. 
+    
+   For example, if the sending system requests a notification, and a 
+   CRITICAL part fails, the receiving system will generate a NDN for 
+   the whole message.  Conversely, if only an IGNORE part fails, the 
+   receiving system will not generate a NDN.  
+    
+   The next sections examine the actions taken by an MTA or UA given 
+   the different values of Content-Criticality. 
+    
+   NOTE: This implies that the MTA must examine the entire message on 
+   receipt to determine whether it needs to generate a notification.  
+   However, the MTA need not examine the message if it knows it can 
+   store and forward all media types.  Said differently, an Internet e-
+   mail MTA can, by default, handle any arbitrary MIME-encapsulated 
+  
+Burger and Candell         Expires 4/18/01                    [Page 5] 
+                  Critical Content of Internet Mail       October 2000 
+ 
+ 
+   type.  Some voice mail systems, on the other hand, cannot store 
+   binary attachments at all, such as application/ms-word.  The voice 
+   mail MTA, in this example, would be scanning for non-renderable body 
+   parts in any event.  
+    
+  4.1. CRITICAL 
+    
+   "Content-Criticality: CRITICAL" signifies that this body part is 
+   critical to the sender. 
+    
+   If the receiving system cannot render or store a body part marked 
+   CRITICAL, then the entire message has failed.  In this case, the 
+   receiving system MUST take the appropriate failure action. 
+    
+   NOTE: We say "appropriate action", because the sender may have 
+   suppressed all notifications.  In this case, the appropriate action 
+   is to simply discard the message. 
+    
+  4.2. IGNORE 
+    
+   "Content-Criticality: IGNORE" signifies that the sender does not 
+   care about notification reports for this body part. 
+    
+   If the receiving system cannot render or store a body part marked 
+   IGNORE, the receiving system may silently delete the body part.  The 
+   receiving system MUST NOT return a delivery failure, unless parts 
+   marked IMPORTANT or CRITICAL have also failed. 
+    
+  4.3. Other Values 
+    
+   The receiving system MUST treat unrecognized values as CRITICAL.  
+   This is to provide backward compatibility with future uses of the 
+   Content-Criticality entity. 
+    
+   The most likely new value is IMPORTANT.  An IMPORTANT body part is 
+   something the sender wants the receiver to get, but would not want 
+   the message rejected outright if the IMPORTANT body part fails.  A 
+   receiving system that does not understand IMPORTANT MUST take the 
+   default value of CRITICAL.  In this case, the MTA or UA MUST take 
+   the conservative action of rejecting the message. 
+     
+  4.4. Summary 
+    
+   The following table summarizes the actions expected of a conforming 
+   MTA or UA. 
+    
+
+
+
+
+
+
+  
+Burger and Candell         Expires 4/18/01                    [Page 6] 
+                  Critical Content of Internet Mail       October 2000 
+ 
+ 
+                            +--------------------------------------+ 
+                            |    Sending UA Has Marked Body Part   | 
+                            |---------------------+----------------| 
+                            |      CRITICAL       |     IGNORE     | 
+       +--------------------+---------------------+----------------+ 
+       | Body Part is       |                     |                | 
+       | Deliverable/read   | Appropriate Action  |     ignore     | 
+       +--------------------+---------------------+----------------+ 
+       | Body Part is       |                     |                | 
+       | Undeliverable /    |                     |                | 
+       |  Unreadable        | Fail Entire Message |     ignore     | 
+       +--------------------+--------------------------------------+ 
+    
+   The distinction between deliverable/read is as follows.  A MTA can 
+   determine if a body part is deliverable.  Sample actions a MTA can 
+   take are generating a NDN or DSN.  An UA can determine if a body 
+   part is readable.  A sample action an UA can take is generating a 
+   MDN. 
+    
+   The "Appropriate Action" is the action the MTA or UA would take 
+   given the context of execution.  For example, if a sender requests 
+   return receipt and the receiver reads a CRITICAL body part, the 
+   receiving UA must generate the appropriate MDN (following the rules 
+   for MDN). 
+    
+   "Ignore" means the MTA or UA MUST ignore the operation on the body 
+   part.  The MTA or UA MUST treat the message as if the body part was 
+   not present in the message. 
+    
+    
+5.   Backward Compatibility Considerations 
+    
+   If there are no Content-Criticality entities in the message, the 
+   default value for Content-Criticality is CRITICAL.  The standard 
+   notification mechanisms work for sending user agents (UA) that do 
+   not know about the content notification entity.  All body parts are 
+   critical, because they have the default marking of CRITICAL. 
+    
+   If there is at least one Content-Criticality entity in the message, 
+   the default value for unspecified body parts is IGNORE.  The 
+   philosophy is that UAs, especially manually constructed messages, 
+   will explicitly mark the critical body parts. 
+    
+   NOTE: We could choose the default value for Content-Criticality to 
+   be IGNORE.  This would make VPIMv2 automatically compliant with this 
+   document, as VPIMv2 has provision to silently delete undeliverable 
+   parts.  However, VPIMv2 systems should not be receiving arbitrary e-
+   mail from the Internet.  If they do, they should be compliant with 
+   this series of documents.  By defaulting to CRITICAL, this draft is 
+   compliant with the rest of the Internet infrastructure. 
+    
+
+  
+Burger and Candell         Expires 4/18/01                    [Page 7] 
+                  Critical Content of Internet Mail       October 2000 
+ 
+ 
+   NOTE: Some VPIMv2 implementations can receive arbitrary e-mail from 
+   the Internet.  However, these systems are really acting in the 
+   capacity of an Internet Voice Mail system.  In this case, one would 
+   expect the implementation to provide Internet Voice Mail semantics 
+   to Internet Voice Mail messages. 
+    
+ 
+6.   MIME Interactions 
+    
+  6.1. multipart/alternative 
+    
+   Content-Criticality is only in effect for the selected alternative.  
+   If the selected alternative has the critical content indicator, then 
+   the entire alternative takes on the criticality indicated.  That is, 
+   if the alternative selected has Content-Criticality: IGNORE, then 
+   the receiving system MUST NOT generate any delivery notifications 
+   (MDN, NDN, return-receipt, etc.). 
+    
+   It is unlikely for a selected alternative to fail, as the receiving 
+   UA presumably picks the alternative specifically because it can 
+   render it.  
+    
+   If the selected alternative is a message/rfc822 that encloses a 
+   multipart MIME message or the selected alternative is itself a 
+   multipart MIME type, the individual top-level body parts follow the 
+   Content-Criticality mechanism described in this document. 
+    
+  6.2. multipart/related 
+    
+   Content-Criticality fits in rather well with the multipart/related 
+   construction.  For example, consider a multipart/related message 
+   consisting of a Macintosh data fork and a Macintosh resource fork.  
+   For a Microsoft Word document, the data fork is likely to be 
+   critical.  The receiving system can safely ignore the resource fork. 
+    
+  6.3. message/rfc822 
+    
+   Content-Criticality only affects the outermost level of the message 
+   or, in the case of multipart/alternative, the outermost level of the 
+   selected alternative.  Specifically, the receiving system ignores 
+   Content-Criticality indicators in embedded body parts.  This avoids 
+   the situation of a forwarded message triggering or suppressing 
+   undesired or desired reporting. 
+    
+7.   Security Considerations 
+ 
+   Receiving systems and users should not place any authentication 
+   value on the Content-Criticality entity.  Just because a message has 
+   a particular Content-Criticality value doesn't mean that the message 
+   really originated at a given type of system. 
+    
+    
+  
+Burger and Candell         Expires 4/18/01                    [Page 8] 
+                  Critical Content of Internet Mail       October 2000 
+ 
+ 
+8.   Collected Syntax 
+    
+   The format of the collected syntax is in accordance with the ABNF of 
+   [9].  Note that per RFC 2045, none of the strings are case 
+   sensitive. 
+    
+    
+        "Content-Criticality" ":" notification-type CRLF 
+    
+        notification-type = "CRITICAL" / "IGNORE" 
+    
+    
+ 
+9.   References 
+    
+ 
+   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
+      9, RFC 2026, October 1996. 
+    
+   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
+      Levels", BCP 14, RFC 2119, March 1997. 
+    
+   3  Freed, N. and Borenstein, N., "Multipurpose Internet Mail 
+      Extensions (MIME) Part One: Format of Internet Message Bodies", 
+      RFC 2045, Innosoft and First Virtual, November 1996. 
+    
+   4  Freed, N. and Borenstein, N., "Multipurpose Internet Mail 
+      Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft and 
+      First Virtual, November 1996. 
+    
+   5  Vaudreuil, G. and Parsons, G., "Voice Profile for Internet Mail -         
+      version 2", RFC 2321, Lucent Technologies and Nortel Networks, 
+      September 1998. 
+    
+   6  Burger, E., "Partial Non-Delivery Notification", Work in 
+      Progress, draft-ema-burger-pndn-01.txt, March 2000. 
+    
+   7  Moore, K., "SMTP Service Extension for Delivery Status 
+      Notifications", RFC 1981, University of Tennessee, January 1996. 
+    
+   8  Fajman, R., "An Extensible Message Format for Message Disposition 
+      Notifications", RFC 2298, National Institutes of Health, March 
+      1998. 
+    
+   9  Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 
+      Specifications: ABNF", RFC 2234, Internet Mail Consortium and 
+      Demon Internet Ltd., November 1997. 
+    
+    
+    
+    
+
+  
+Burger and Candell         Expires 4/18/01                    [Page 9] 
+                  Critical Content of Internet Mail       October 2000 
+ 
+ 
+10.    Acknowledgments 
+    
+   We'd like to thank Ned Freed for pointing out that this mechanism 
+   was about criticality, not notification per se.  That insight made 
+   the concept and descriptions infinitely more straight forward.  If 
+   it's still confusing, it's our fault! 
+    
+   We'd also like to thank Keith Moore for helping us tighten-up our 
+   explanations. 
+    
+   Dropping the IMPORTANT critical content type took away one of the 
+   reasons for partial non-delivery notification.  That makes Jutta 
+   Degener very happy! 
+    
+    
+11.    Author's Addresses 
+    
+   Eric Burger 
+   SnowShore Networks 
+   c/o CRV 
+   1000 Winter St. 
+   Waltham, MA  02451 
+   USA 
+    
+   Phone: +1 703/304-3883 
+   Email: e.burger@ieee.org 
+    
+    
+   Emily Candell 
+   Comverse Network Systems 
+   200 Quannapowitt Pkwy. 
+   Wakefield, MA  01880 
+   USA 
+    
+   Phone: +1 781/213-2324 
+   Email: emily@comversens.com 
+    
+    
+Full Copyright Statement                         
+
+   The IETF takes no position regarding the validity or scope of any 
+   intellectual property or other rights that might be claimed to  
+   pertain to the implementation or use of the technology described in 
+   this document or the extent to which any license under such rights 
+   might or might not be available; neither does it represent that it 
+   has made any effort to identify any such rights.  Information on the 
+   IETF's procedures with respect to rights in standards-track and 
+   standards-related documentation can be found in BCP-11.  Copies of 
+   claims of rights made available for publication and any assurances 
+   of licenses to be made available, or the result of an attempt made 
+   to obtain a general license or permission for the use of such 
+
+  
+Burger and Candell         Expires 4/18/01                   [Page 10] 
+                  Critical Content of Internet Mail       October 2000 
+ 
+ 
+   proprietary rights by implementers or users of this specification 
+   can be obtained from the IETF Secretariat. 
+    
+   The IETF invites any interested party to bring to its attention any 
+   copyrights, patents or patent applications, or other proprietary 
+   rights which may cover technology that may be required to practice 
+   this standard.  Please address the information to the IETF Executive 
+   Director. 
+    
+   Copyright (C) 2000 The Internet Society.  All Rights Reserved. 
+    
+   This document and translations of it may be copied and furnished to 
+   others, and derivative works that comment on or otherwise explain it 
+   or assist in its implementation may be prepared, copied, published 
+   and distributed, in whole or in part, without restriction of any 
+   kind, provided that the above copyright notice and this paragraph 
+   are included on all such copies and derivative works.  However, this 
+   document itself may not be modified in any way, such as by removing 
+   the copyright notice or references to the Internet Society or other 
+   Internet organizations, except as needed for the  purpose of 
+   developing Internet standards in which case the procedures for 
+   copyrights defined in the Internet Standards process must be 
+   followed, or as required to translate it into languages other than 
+   English. 
+    
+   The limited permissions granted above are perpetual and will not be 
+   revoked by the Internet Society or its successors or assigns. 
+    
+   This document and the information contained herein is provided on an 
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Burger and Candell         Expires 4/18/01                   [Page 11] 
+
\ No newline at end of file
diff --git a/Documentation/en/I-D/draft-ietf-vpim-cc-02.txt b/Documentation/en/I-D/draft-ietf-vpim-cc-02.txt
new file mode 100644
index 00000000..36a0cbe4
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-vpim-cc-02.txt
@@ -0,0 +1,783 @@
+
+Network Working Group                                           E. Burger
+Internet Draft                                         SnowShore Networks
+Document: draft-ietf-vpim-cc-02.txt                            E. Candell
+Category: Standards Track                        Comverse Network Systems
+Expires May 2001                                        November 24, 2000
+ 
+ 
+                   Critical Content of Internet Mail 
+ 
+ 
+Status of this Memo 
+ 
+   This document is an Internet-Draft and is in full conformance with 
+   all provisions of Section 10 of RFC2026 [1].  
+    
+   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." 
+    
+   One can access the list of current Internet-Drafts at 
+   http://www.ietf.org/ietf/1id-abstracts.txt 
+    
+   One can access the list of Internet-Draft Shadow Directories at 
+   http://www.ietf.org/shadow.html. 
+    
+   This document is a work product of the IETF Voice Profile for 
+   Internet Mail (vpim) Work Group.  The URL for the VPIM website is 
+   <http://www.vpim.org>. 
+    
+    
+1. Abstract 
+    
+   This document describes a mechanism for identifying the body parts 
+   that the sender deems critical in a multi-part Internet mail 
+   message. 
+    
+   By knowing what parts of a message the sender deems critical, a MTA 
+   or UA can intelligently handle multi-part messages when gatewaying 
+   (MTA) or presenting (UA) to systems of lesser capability. Critical 
+   content can help a smart gateway decide what parts to forward.  It 
+   can indicate how hard a gateway should try to deliver a body part.  
+   It can help an MTA to select body parts to silently delete when a 
+   system of lesser capability receives a message.  In addition, 
+   critical content can help indicate the notification strategy of the 
+   receiving system. 
+    
+
+
+ 
+                           Expires 5/24/01                    [Page 1] 
+                  Critical Content of Internet Mail      November 2000   
+ 
+Table of Contents 
+    
+1.  ABSTRACT .........................................................1 
+2.  CONVENTIONS USED IN THIS DOCUMENT ................................2 
+3.  INTRODUCTION .....................................................3 
+4.  CONTENT-CRITICALITY ENTITY .......................................5 
+4.1.  CRITICAL .......................................................6 
+4.2.  IGNORE .........................................................6 
+4.3.  Other Values ...................................................6 
+4.4.  Summary ........................................................7 
+5.  STATUS CODE ......................................................7 
+6.  BACKWARD COMPATIBILITY CONSIDERATIONS ............................8 
+7.  MIME INTERACTIONS ................................................8 
+7.1.  multipart/alternative ..........................................8 
+7.2.  multipart/related ..............................................9 
+7.3.  message/rfc822 .................................................9 
+8.  IMPLEMENTATION EXAMPLES ..........................................9 
+8.1.  Content Gateways ...............................................9 
+8.2.  Non-Traditional UA ............................................10 
+9.  SECURITY CONSIDERATIONS .........................................11 
+10. COLLECTED SYNTAX ................................................11 
+11. REFERENCES ......................................................11 
+12. ACKNOWLEDGMENTS .................................................12 
+13. AUTHOR'S ADDRESSES ..............................................13 
+    
+    
+2. Conventions used in this document 
+    
+   This document refers generically to the sender of a message in the 
+   masculine (he/him/his) and the recipient of the message in the 
+   feminine (she/her/hers).  This convention is purely for convenience 
+   and makes no assumption about the gender of a message sender or 
+   recipient. 
+    
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
+   this document are to be interpreted as described in RFC-2119 [2]. 
+    
+   FORMATTING NOTE: Notes, such at this one, provide additional 
+   nonessential information that the reader may skip without missing 
+   anything essential.  The primary purpose of these non-essential 
+   notes is to convey information about the rationale of this document, 
+   or to place this document in the proper historical or evolutionary 
+   context.  Readers whose sole purpose is to construct a conformant 
+   implementation may skip such information.  However, it may be of use 
+   to those who wish to understand why we made certain design choices. 
+    
+    
+
+  
+Burger and Candell         Expires 5/24/01                    [Page 2] 
+                  Critical Content of Internet Mail      November 2000   
+ 
+3. Introduction 
+    
+   This document describes the Critical Content identification for 
+   multi-part Internet mail. 
+    
+   The need for a critical content identification mechanism comes about 
+   because of the internetworking of Internet mail systems with legacy 
+   messaging systems that do not fulfil all of the semantics of 
+   Internet mail.  Such legacy systems have a limited ability to render 
+   all parts of a given message.  This document will use the case of an 
+   Internet mail system exchanging electronic messages with a legacy 
+   voice messaging system for illustrative purposes. 
+    
+   Electronic mail has historically been text-centric.  Extensions such 
+   as MIME [3] enable the desktop to send and receive multi-part, 
+   multimedia messages.  Popular multimedia data types include binary 
+   word processing documents, binary business presentation graphics, 
+   voice, and video. 
+    
+   Voice mail has historically been audio-centric.  Many voice-
+   messaging systems only render voice.  Extensions such as fax enable 
+   the voice mail system to send and receive fax images as well as 
+   create multi-part voice and fax messages.  A few voice mail systems 
+   can render text using text-to-speech or text-to-fax technology.  
+   Although theoretically possible, none can today render video. 
+    
+   An important aspect of the interchange between voice messaging 
+   services and desktop e-mail client applications is that the 
+   rendering capability of the voice-messaging platform is often much 
+   less than the rendering capability of a desktop e-mail client.  In 
+   the e-mail case, the sender has the expectation that the recipient 
+   receives all components of a multimedia message.  This is so even if 
+   the recipient cannot render all body parts.  In most cases, the 
+   recipient can either find the appropriate rendering tool or tell the 
+   sender that she cannot read the particular attachment. 
+    
+   This is an important issue.  By definition, a MIME-enabled user 
+   agent, conforming to [4] will present or make available all of the 
+   body parts to the recipient.  However, a voice mail system may not 
+   be capable of storing non-voice objects.  Moreover, the voice mail 
+   system may not be capable of notifying the recipient that there were 
+   undeliverable message parts. 
+    
+   The inability of the receiving system to render a body part is 
+   usually a permanent failure.  Retransmission of the message will not 
+   improve the likelihood of a future successful delivery.  Contrast 
+   this to the case with normal data delivery.  Traditional message 
+   failures, such as a garbled message or disabled link will benefit 
+   from retransmission. 
+    
+   This situation is fundamentally different from normal Internet mail.  
+   In the Internet mail case, either the system delivered the message, 
+  
+Burger and Candell         Expires 5/24/01                    [Page 3] 
+                  Critical Content of Internet Mail      November 2000   
+ 
+   or it didn't.  There is no concept of a system partially delivering 
+   a message. 
+    
+   In addition, the sender would not mind if the system did not deliver 
+   non-critical parts of a message.  In fact, the sender's user agent 
+   may be silently adding body parts to a message unbeknownst to the 
+   sender.  For example, take Microsoft Outlook as a user agent.  
+   Outlook often will attach a TNEF section or other body parts. If the 
+   receiving system rejected the message because it could not render 
+   TNEF, the sender would be understandably confused and upset. 
+    
+   Thus, there is a need for a method of indicating to a Mail Transfer 
+   Agent (MTA) or User Agent (UA) that the sender considers parts of a 
+   message to be critical.  From the sender's perspective, he would not 
+   consider the message delivered if the system did not deliver the 
+   critical parts. 
+    
+   One method of indicating critical content of a message is to define 
+   a profile.  The profile defines discard rules based on knowledge of 
+   the user population for silently deleting body parts.  Citing the 
+   example above, a voice profile can easily declare that MTAs or UAs 
+   can silently delete TNEF data and yet consider the message 
+   successfully delivered.  This is, in fact, the approach taken by 
+   VPIMv2 [5]. 
+    
+   Since one aspect of the issue is deciding when to notify the sender 
+   that the system cannot deliver part of a message, one could use a 
+   partial non-delivery notification mechanism [6] to indicate a 
+   problem with delivering a given body part.  However, this requires 
+   the user request a MDN.  Moreover, the sender will receive PNDN 
+   failures for objects the sender may not be aware he is sending.  An 
+   example would be the TNEF part. 
+    
+   Summarizing the needs, we need a mechanism that will let the sender 
+   or sender's UA mark body parts he considers critical to the message 
+   that the system must deliver.  The mechanism MUST NOT burden the 
+   sender with failure notifications for non-critical body parts.  The 
+   mechanism MUST conform to the general notification status request 
+   mechanism for positive or negative notification.  When requested, 
+   the mechanism MUST indicate to the sender when a receiving system 
+   cannot deliver a critical body part. 
+    
+   In short, we need a method of letting the sender indicate what body-
+   parts he considers to be critical. 
+    
+   This document describes a Critical Content marking mechanism that 
+   satisfies these needs.  Following the format for Internet message 
+   bodies [3], this document introduces the Content-Criticality body 
+   part header.  Values for this header are CRITICAL, NOTIFY, or 
+   IGNORE.  The receiving MTA or UA will generate a delivery status 
+   notification (DSN) [7] or Message Disposition Notification (MDN) [8] 
+   at delivery time or reading time if it receives a request for 
+  
+Burger and Candell         Expires 5/24/01                    [Page 4] 
+                  Critical Content of Internet Mail      November 2000   
+ 
+   notification and the (non-)delivery status of the parts marked 
+   NOTIFY meet the criteria for notification.   
+    
+   NOTE: A straightforward alternative implementation method for 
+   marking a body part critical is to use a content-disposition 
+   parameter called "criticality". 
+    
+   NOTE: We could have made the critical content indicator a parameter 
+   to content-disposition.  This has the benefit of being very easy for 
+   IMAP servers to implement.  In particular, IMAP servers 
+   automatically present the content-disposition entity when a UA 
+   requests information on a message.  On the other hand, the UA must 
+   explicitly request the presence and value of different entities, 
+   such as content-criticality.  However, implementing the critical 
+   content indicator as a parameter to content-disposition overloads 
+   the meaning of the entity.  Moreover, IMAP servers can present, in 
+   the future, content-criticality by default.  Lastly, most UA's that 
+   have interest in content-criticality will explicitly request the 
+   header in any event. 
+    
+    
+4. Content-Criticality Entity 
+    
+   The Content-Criticality field is a MIME body part header inserted by 
+   the sending UA to indicate to the receiving MTA or UA whether to 
+   consider this body part critical. 
+    
+   A CRITICAL body part is one the sender requires the receiving system 
+   to deliver for him to consider the message delivered. 
+    
+   An IGNORE body part is one the sender doesn't care whether the 
+   receiving system delivers it or not.  The receiving system can 
+   silently delete such body parts if the receiving system cannot 
+   deliver the part. 
+    
+   The terms "entity" and "body part" have the meanings defined in [3]. 
+    
+   One obvious application of critical content is generating a 
+   (non-)delivery message.  If the value of the field is IGNORE, the 
+   receiving MTA or UA MUST NOT generate a notification.  If the value 
+   of the field is CRTITICAL, the receiving MTA or UA will generate a 
+   notification, based on the normal notification request mechanisms.  
+   Normal notification request mechanisms include the SMTP RCPT NOTIFY 
+   command [9] and the Disposition-Notification-To header [8]. 
+    
+   For example, if the sending system requests a notification, and a 
+   CRITICAL part fails, the receiving system will generate a NDN for 
+   the whole message.  Conversely, if only an IGNORE part fails, the 
+   receiving system will not generate a NDN.  
+    
+   The next sections examine the actions taken by an MTA or UA given 
+   the different values of Content-Criticality. 
+  
+Burger and Candell         Expires 5/24/01                    [Page 5] 
+                  Critical Content of Internet Mail      November 2000   
+ 
+    
+   NOTE: This implies that the MTA must examine the entire message on 
+   receipt to determine whether it needs to generate a notification.  
+   However, the MTA need not examine the message if it knows it can 
+   store and forward all media types.  Said differently, Internet e-
+   mail MTA can, by default, handle any arbitrary MIME-encapsulated 
+   type.  Some voice mail systems, on the other hand, cannot store 
+   binary attachments at all, such as application/ms-word.  The voice 
+   mail MTA, in this example, would be scanning for non-renderable body 
+   parts in any event.  
+    
+  4.1. CRITICAL 
+    
+   "Content-Criticality: CRITICAL" signifies that this body part is 
+   critical to the sender. 
+    
+   If the receiving system cannot render or store a body part marked 
+   CRITICAL, then the entire message has failed.  In this case, the 
+   receiving system MUST take the appropriate failure action. 
+    
+   NOTE: We say "appropriate action", because the sender may have 
+   suppressed all notifications.  In this case, the appropriate action 
+   is to simply discard the message. 
+    
+  4.2. IGNORE 
+    
+   "Content-Criticality: IGNORE" signifies that the sender does not 
+   care about notification reports for this body part. 
+    
+   If the receiving system cannot render or store a body part marked 
+   IGNORE, the receiving system may silently delete the body part.  The 
+   receiving system MUST NOT return a delivery failure, unless parts 
+   marked IMPORTANT or CRITICAL have also failed. 
+    
+  4.3. Other Values 
+    
+   The receiving system MUST treat unrecognized values as CRITICAL.  
+   This is to provide backward compatibility with future uses of the 
+   Content-Criticality entity. 
+    
+   The most likely new value is IMPORTANT.  An IMPORTANT body part is 
+   something the sender wants the receiver to get, but would not want 
+   the message rejected outright if the IMPORTANT body part fails.  A 
+   receiving system that does not understand IMPORTANT MUST take the 
+   default value of CRITICAL.  In this case, the MTA or UA MUST take 
+   the conservative action of rejecting the message. 
+     
+
+
+
+
+
+  
+Burger and Candell         Expires 5/24/01                    [Page 6] 
+                  Critical Content of Internet Mail      November 2000   
+ 
+  4.4. Summary 
+    
+   The following table summarizes the actions expected of a conforming 
+   MTA or UA. 
+    
+   NOTE: This section is normative: it suggests what to put into the 
+   DSN or MDN.  
+                            +--------------------------------------+ 
+                            |    Sending UA Has Marked Body Part   | 
+                            |---------------------+----------------| 
+                            |      CRITICAL       |     IGNORE     | 
+       +--------------------+---------------------+----------------+ 
+       | Body Part is       |                     |                | 
+       | Deliverable/read   | Appropriate Action  |     ignore     | 
+       +--------------------+---------------------+----------------+ 
+       | Body Part is       |                     |                | 
+       | Undeliverable /    |                     |                | 
+       |  Unreadable        | Fail Entire Message |     ignore     | 
+       +--------------------+--------------------------------------+ 
+    
+   The distinction between deliverable/read is as follows.  A MTA can 
+   determine if a body part is deliverable.  If the body part is not 
+   deliverable and is critical, the MTA could generate a DSN.  An 
+   example of such a MTA is a content-converting gateway. 
+    
+   An UA can determine if a body part is readable.  If the body part is 
+   not readable and is critical the UA could generate a MDN.  
+    
+   The "Appropriate Action" is the action the MTA or UA would take 
+   given the context of execution.  For example, if a sender requests 
+   return receipt and the receiver reads a CRITICAL body part, the 
+   receiving UA must generate the appropriate MDN (following the rules 
+   for MDN).  Likewise, if the MTA or UA cannot deliver the body part 
+   and the body part is critical, the MTA or UA MUST generate the 
+   appropriate DSN or MDN.  
+    
+   "Ignore" means the MTA or UA MUST ignore the operation on the body 
+   part.  The MTA or UA MUST treat the message as if the body part was 
+   not present in the message. 
+    
+    
+5. Status Code 
+    
+   The critical content indication, in itself, does not guarantee any 
+   notification.  Notification follows the rules described in [7] and 
+   [8]. 
+    
+   NOTE: The content of actual DSNs or MDNs are beyond the scope of 
+   this document.  This document only specifies how to mark a critical 
+   body part.  On the other hand, we do envision sensible DSN and MDN 
+   contents.  For example, DSNs should include the appropriate failure 
+
+  
+Burger and Candell         Expires 5/24/01                    [Page 7] 
+                  Critical Content of Internet Mail      November 2000   
+ 
+   code as enumerated in [10].  Likewise, MDNs should include the 
+   failure code in the MDN "Failure:" field. 
+    
+   If the receiving system is to generate a notification based on its 
+   inability to render or store the media type, the notification MUST 
+   include the status code 5.6.1, "Media not supported", from [10]. 
+ 
+    
+    
+6. Backward Compatibility Considerations 
+    
+   If there are no Content-Criticality entities in the message, the 
+   default value for Content-Criticality is CRITICAL.  The standard 
+   notification mechanisms work for sending user agents (UA) that do 
+   not know about the content notification entity.  All body parts are 
+   critical, because they have the default marking of CRITICAL. 
+    
+   If there is at least one Content-Criticality entity in the message, 
+   the default value for unspecified body parts is IGNORE.  The 
+   philosophy is that UAs, especially manually constructed messages, 
+   will explicitly mark the critical body parts. 
+    
+   NOTE: We could choose the default value for Content-Criticality to 
+   be IGNORE.  This would make VPIMv2 automatically compliant with this 
+   document, as VPIMv2 has provision to silently delete undeliverable 
+   parts.  However, VPIMv2 systems should not be receiving arbitrary e-
+   mail from the Internet.  If they do, they should be compliant with 
+   this series of documents.  By defaulting to CRITICAL, this draft is 
+   compliant with the rest of the Internet infrastructure. 
+    
+   NOTE: Some VPIMv2 implementations can receive arbitrary e-mail from 
+   the Internet.  However, these systems are really acting in the 
+   capacity of an Internet Voice Mail system.  In this case, one would 
+   expect the implementation to provide Internet Voice Mail semantics 
+   to Internet Voice Mail messages. 
+    
+ 
+7. MIME Interactions 
+    
+  7.1. multipart/alternative 
+    
+   Content-Criticality is only in effect for the selected alternative.  
+   If the selected alternative has the critical content indicator, then 
+   the entire alternative takes on the criticality indicated.  That is, 
+   if the alternative selected has Content-Criticality: IGNORE, then 
+   the receiving system MUST NOT generate any delivery notifications 
+   (MDN, NDN, return-receipt, etc.). 
+    
+   It is unlikely for a selected alternative to fail, as the receiving 
+   UA presumably picks the alternative specifically because it can 
+   render it.  
+    
+  
+Burger and Candell         Expires 5/24/01                    [Page 8] 
+                  Critical Content of Internet Mail      November 2000   
+ 
+   If the selected alternative is a message/rfc822 that encloses a 
+   multipart MIME message or the selected alternative is itself a 
+   multipart MIME type, the individual top-level body parts follow the 
+   Content-Criticality mechanism described in this document. 
+    
+  7.2. multipart/related 
+    
+   Content-Criticality fits in rather well with the multipart/related 
+   construction.  For example, consider a multipart/related message 
+   consisting of a Macintosh data fork and a Macintosh resource fork.  
+   For a Microsoft Word document, the data fork is likely to be 
+   critical.  The receiving system can safely ignore the resource fork. 
+    
+  7.3. message/rfc822 
+    
+   Content-Criticality only affects the outermost level of the message 
+   or, in the case of multipart/alternative, the outermost level of the 
+   selected alternative.  Specifically, the receiving system ignores 
+   Content-Criticality indicators in embedded body parts.  This avoids 
+   the situation of a forwarded message triggering or suppressing 
+   undesired or desired reporting. 
+    
+    
+8. Implementation Examples 
+    
+   This section is not a normative part of the definition of Content-
+   Criticality.  However, we hope it helps implementers to understand 
+   the mechanics of the Content-Criticality mechanism. 
+    
+   We will examine two cases.  They are how a content gateway processes 
+   a message and how a UA processes a message. 
+    
+  8.1. Content Gateways 
+    
+   Content gateways examine the contents of a message from a first 
+   network before the gateway forwards the message to a second network.  
+   For the purposes of this example, we assume the second network has 
+   less capability than the first network.  In particular, we expect 
+   there will be certain message body types that the gateway cannot 
+   pass onto the second network. 
+    
+   Consider a gateway between the Internet and a text-only short 
+   message service.  A message comes through the gateway containing a 
+   text part and a tnef part.  The sender marks the text part CRITICAL.  
+   The gateway, knowing the capability of the short message service, 
+   silently deletes the non-critical, tnef part, passing the critical 
+   content to the shore message service network.  Any subsequent 
+   notifications, such as failure notices or delivery notices, follow 
+   the normal rules for notification. 
+    
+   Note the gateway, by silently deleting non-critical content, may 
+   affect proprietary message correlation schemes.  One can envision 
+  
+Burger and Candell         Expires 5/24/01                    [Page 9] 
+                  Critical Content of Internet Mail      November 2000   
+ 
+   the sending UA inserting a body part for tracking purposes.  By 
+   deleting non-critical content, the content gateway will break such a 
+   scheme.  If a sending UA understands how to mark critical content, 
+   it should use Internet standard mechanisms for tracking messages, 
+   such as Message-ID [11]. 
+    
+   What if no body parts have critical content indicators?  In this 
+   case, the entire message is critical.  Thus, when the gateway sees 
+   the tnef part, it will reject the entire message, generating a DSN 
+   with a status code 5.6.1, "Media not supported". 
+    
+   Likewise, consider a three part message with a text annotation (part 
+   1) to a voice message (part 2) with a vCard [12] (part 3).  The 
+   sender marks the first two parts CRITICAL.  Now, let us assume the 
+   receiving MTA (gateway) is a voice mail only system, without even 
+   the capability to store text.  In this case, the gateway (receiving 
+   MTA) will reject the message, generating a DSN with a status code 
+   5.6.1, "Media not supported". 
+ 
+  8.2. Non-Traditional UA 
+    
+   For this example, we will examine the processing of a three-part 
+   message.  The first part is a text annotation of the second part, an 
+   audio message.  The third part is the sender's vCard.  The sender 
+   marks the first and second parts CRITICAL.  In addition, the sender 
+   marks the message for read receipt. 
+    
+   For the purposes of example, the telephone user interface (TUI) does 
+   not perform text-to-speech conversion.  A TUI is a mail user agent 
+   (UA) that uses DTMF touch-tone digits for input and audio for output 
+   (display). 
+    
+   The TUI is unable to render the first part of the message, the text 
+   part.  In addition, it is unable to render the third part of the 
+   message, the vCard part.  Since the sender did not mark the third 
+   part of the message CRITICAL, the system ignores the failure of the 
+   TUI to render the third part of the message.  However, since the 
+   sender did mark the first part CRITICAL, and the TUI is unable to 
+   render text, the message fails. 
+    
+   What happens next is implementation dependent.  If the TUI is part 
+   of a unified messaging system, a reasonable action is to hold the 
+   message for the user.  The user can access the message at a later 
+   time from a terminal that can render all of the critical body parts.  
+   It would be reasonable for the TUI to notify the user about the 
+   message. 
+    
+   If the TUI is part of a voice messaging system, or if the user does 
+   not subscribe to a text-to-speech service, a reasonable action is 
+   for the TUI to return a MDN with the disposition "failed" and the 
+   failure modifier "5.6.1 (Media not supported)". 
+    
+  
+Burger and Candell         Expires 5/24/01                   [Page 10] 
+                  Critical Content of Internet Mail      November 2000   
+ 
+    
+9. Security Considerations 
+ 
+   Receiving systems and users should not place any authentication 
+   value on the Content-Criticality entity.  Just because a message has 
+   a particular Content-Criticality value doesn't mean that the message 
+   really originated at a given type of system. 
+    
+    
+10. Collected Syntax 
+    
+   The format of the collected syntax is in accordance with the ABNF of 
+   [13].  Note that per RFC 2045, none of the strings are case 
+   sensitive. 
+    
+    
+        "Content-Criticality" ":" notification-type CRLF 
+    
+        notification-type = "CRITICAL" / "IGNORE" 
+    
+    
+ 
+11. References 
+    
+ 
+   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
+      9, RFC 2026, October 1996. 
+    
+   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
+      Levels", BCP 14, RFC 2119, March 1997. 
+    
+   3  Freed, N. and Borenstein, N., "Multipurpose Internet Mail 
+      Extensions (MIME) Part One: Format of Internet Message Bodies", 
+      RFC 2045, Innosoft and First Virtual, November 1996. 
+    
+   4  Freed, N. and Borenstein, N., "Multipurpose Internet Mail 
+      Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft and 
+      First Virtual, November 1996. 
+    
+   5  Vaudreuil, G. and Parsons, G., "Voice Profile for Internet Mail - 
+      version 2", RFC 2321, Lucent Technologies and Nortel Networks, 
+      September 1998. 
+    
+   6  Burger, E., "Partial Non-Delivery Notification", Work in 
+      Progress, draft-ema-burger-pndn-01.txt, March 2000. 
+    
+   7  Moore, K. and Vaudreuil, G., "An Extensible Message Format for 
+      Delivery Status Notifications", RFC 1894, University of Tennessee 
+      and Octel Network Services, January 1996. 
+     
+
+
+  
+Burger and Candell         Expires 5/24/01                   [Page 11] 
+                  Critical Content of Internet Mail      November 2000   
+ 
+ 
+   8  Fajman, R., "An Extensible Message Format for Message Disposition 
+      Notifications", RFC 2298, National Institutes of Health, March 
+      1998. 
+    
+   9  Moore, K., "SMTP Service Extension for Delivery Status 
+      Notifications", RFC 1981, University of Tennessee, January 1996. 
+    
+   10 Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, 
+      Octel Network Services, January 1996. 
+    
+   11 Crocker, D., "Standard for the Format of ARPA Internet Text 
+      Messages", RFC 822, University of Delaware, August 1982. 
+    
+   12 Dawson, F. and Howes, T., "vCard MIME Directory Profile", RFC 
+      2426, Lotus Development Corporation and Netscape Communications, 
+      September 1998. 
+    
+   13 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 
+      Specifications: ABNF", RFC 2234, Internet Mail Consortium and 
+      Demon Internet Ltd., November 1997. 
+    
+    
+    
+    
+12. Acknowledgments 
+    
+   We'd like to thank Ned Freed for pointing out that this mechanism 
+   was about criticality, not notification per se.  That insight made 
+   the concept and descriptions infinitely more straightforward.  If 
+   it's still confusing, it's our fault! 
+    
+   We'd also like to thank Keith Moore for helping us tighten-up our 
+   explanations. 
+    
+   Dropping the IMPORTANT critical content type took away one of the 
+   reasons for partial non-delivery notification.  That makes Jutta 
+   Degener very happy! 
+    
+   Harald Alvestrand and Chris Newman suggested we add implementation 
+   examples, which we did. 
+    
+    
+
+
+
+
+
+
+
+
+
+  
+Burger and Candell         Expires 5/24/01                   [Page 12] 
+                  Critical Content of Internet Mail      November 2000   
+ 
+13. Author's Addresses 
+    
+   Eric Burger 
+   SnowShore Networks 
+   c/o CRV 
+   1000 Winter St. 
+   Waltham, MA  02451 
+   USA 
+    
+   Phone: +1 703/304-3883 
+   Email: e.burger@ieee.org 
+    
+    
+   Emily Candell 
+   Comverse Network Systems 
+   200 Quannapowitt Pkwy. 
+   Wakefield, MA  01880 
+   USA 
+    
+   Phone: +1 781/213-2324 
+   Email: emily@comversens.com 
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Burger and Candell         Expires 5/24/01                   [Page 13] 
+                  Critical Content of Internet Mail      November 2000   
+ 
+ 
+Full Copyright Statement 
+
+   The IETF takes no position regarding the validity or scope of any 
+   intellectual property or other rights that might be claimed to  
+   pertain to the implementation or use of the technology described in 
+   this document or the extent to which any license under such rights 
+   might or might not be available; neither does it represent that it 
+   has made any effort to identify any such rights.  Information on the 
+   IETF's procedures with respect to rights in standards-track and 
+   standards-related documentation can be found in BCP-11.  Copies of 
+   claims of rights made available for publication and any assurances 
+   of licenses to be made available, or the result of an attempt made 
+   to obtain a general license or permission for the use of such 
+   proprietary rights by implementers or users of this specification 
+   can be obtained from the IETF Secretariat. 
+    
+   The IETF invites any interested party to bring to its attention any 
+   copyrights, patents or patent applications, or other proprietary 
+   rights that may cover technology that may be required to practice 
+   this standard.  Please address the information to the IETF Executive 
+   Director. 
+    
+   Copyright (C) 2000 The Internet Society.  All Rights Reserved. 
+    
+   This document and translations of it may be copied and furnished to 
+   others, and derivative works that comment on or otherwise explain it 
+   or assist in its implementation may be prepared, copied, published 
+   and distributed, in whole or in part, without restriction of any 
+   kind, provided that the above copyright notice and this paragraph 
+   are included on all such copies and derivative works.  However, this 
+   document itself may not be modified in any way, such as by removing 
+   the copyright notice or references to the Internet Society or other 
+   Internet organizations, except as needed for the  purpose of 
+   developing Internet standards in which case the procedures for 
+   copyrights defined in the Internet Standards process must be 
+   followed, or as required to translate it into languages other than 
+   English. 
+    
+   The limited permissions granted above are perpetual and will not be 
+   revoked by the Internet Society or its successors or assigns. 
+    
+   This document and the information contained herein is provided on an 
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
+
+
+
+
+
+  
+Burger and Candell         Expires 5/24/01                   [Page 14] 
+
diff --git a/Documentation/en/I-D/draft-ietf-vpim-cc-03.txt b/Documentation/en/I-D/draft-ietf-vpim-cc-03.txt
new file mode 100644
index 00000000..d6a549d7
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-vpim-cc-03.txt
@@ -0,0 +1,894 @@
+
+Network Working Group                                           E. Burger
+Internet Draft                                         SnowShore Networks
+Document: draft-ietf-vpim-cc-03.txt                            E. Candell
+Category: Standards Track                        Comverse Network Systems
+Expires September 2001                                      March 2, 2001
+ 
+ 
+                   Critical Content of Internet Mail 
+ 
+ 
+Status of this Memo 
+ 
+   This document is an Internet-Draft and is in full conformance with 
+   all provisions of Section 10 of RFC 2026 [1].  
+    
+   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." 
+    
+   One can access the list of current Internet-Drafts at 
+   http://www.ietf.org/ietf/1id-abstracts.txt 
+    
+   One can access the list of Internet-Draft Shadow Directories at 
+   http://www.ietf.org/shadow.html. 
+    
+   This document is a work product of the IETF Voice Profile for 
+   Internet Mail (VPIM) Work Group.  The URL for the VPIM website is 
+   <http://www.vpim.org>. 
+    
+    
+1. Abstract 
+    
+   This document describes a mechanism for identifying the body parts 
+   that the sender deems critical in a multi-part Internet mail 
+   message. 
+    
+   By knowing what parts of a message the sender deems critical, a 
+   content gateway can intelligently handle multi-part messages when 
+   gatewaying 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 of the receiving system. 
+
+
+
+ 
+                            Expires 9/2/01                    [Page 1] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+Table of Contents 
+    
+1.  Abstract .........................................................1 
+2.  Conventions used in this document ................................2 
+3.  Introduction .....................................................3 
+4.  Content-Criticality Entity .......................................3 
+4.1.  CRITICAL .......................................................4 
+4.2.  IGNORE .........................................................4 
+4.3.  Default Values .................................................4 
+4.4.  Other Values ...................................................5 
+4.5.  DSN vs MDN Generation ..........................................5 
+4.6.  Summary ........................................................5 
+5.  Status Code ......................................................6 
+6.  Requirements for Critical Content ................................6 
+6.1.  Needs ..........................................................6 
+6.2.  Current Approaches .............................................8 
+6.3.  Critical-Content Entity ........................................8 
+7.  The Content Gateway ..............................................9 
+7.1.  Integrated Content Gateway .....................................9 
+7.2.  Disaggregated Delivery Network .................................9 
+8.  Backward Compatibility Considerations ...........................10 
+9.  MIME Interactions ...............................................10 
+9.1.  multipart/alternative .........................................10 
+9.2.  multipart/related .............................................10 
+9.3.  message/rfc822 ................................................11 
+10. Implementation Examples .........................................11 
+10.1. Content Gateways ..............................................11 
+10.2. Disaggregated Content Gateway .................................12 
+11. Security Considerations .........................................12 
+12. Collected Syntax ................................................13 
+13. References ......................................................13 
+14. Acknowledgments .................................................14 
+15. Author's Addresses ..............................................15 
+    
+    
+2. Conventions used in this document 
+    
+   This document refers generically to the sender of a message in the 
+   masculine (he/him/his) and the recipient of the message in the 
+   feminine (she/her/hers).  This convention is purely for convenience 
+   and makes no assumption about the gender of a message sender or 
+   recipient. 
+    
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
+   this document are to be interpreted as described in RFC 2119 [2]. 
+    
+
+  
+Burger and Candell          Expires 9/2/01                    [Page 2] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+   NOTE: Notes, such at this one, provide additional nonessential 
+   information that the reader may skip without missing anything 
+   essential.  The primary purpose of these non-essential notes is to 
+   convey information about the rationale of this document, or to place 
+   this document in the proper historical or evolutionary context.  
+   Readers whose sole purpose is to construct a conformant 
+   implementation may skip such information.  However, it may be of use 
+   to those who wish to understand why we made certain design choices. 
+    
+    
+3. Introduction 
+ 
+   The specification of Critical Content is small and compact.  For the 
+   benefit of developers, the specification comes first, the rationale 
+   after. 
+    
+   The content gateway issues notifications to the sender if the 
+   receiving user agent cannot deliver a critical part of the message.  
+   Conversely, the content gateway silently deletes parts of the 
+   message that the receiving user agent cannot receive. 
+    
+   One concept that an implementer must understand is the content 
+   gateway.  Section 7 describes the content gateway.  In brief, a 
+   content gateway has knowledge of the receiving system's 
+   capabilities.  The content gateway passes messages the receiving 
+   system can render or store.  The content gateway can modify a 
+   message, for example by deleting unrenderable or storable body 
+   parts, for delivery to the receiving system.  Finally, the content 
+   gateway can reject a message that the receiving system cannot 
+   handle. 
+    
+4. Content-Criticality Entity 
+    
+   The Content-Criticality field is a MIME body part header inserted by 
+   the sending UA to indicate to the content gateway whether to 
+   consider the marked body part critical. 
+    
+   A CRITICAL body part is one the sender requires the receiving system 
+   to deliver for him to consider the message delivered. 
+    
+   An IGNORE body part is one the sender doesn't care whether the 
+   receiving system delivers it or not.  A content gateway can silently 
+   delete such body parts if the receiving system cannot deliver the 
+   part. 
+    
+   The terms "entity" and "body part" have the meanings defined in [7]. 
+    
+   One obvious application of critical content is generating a 
+   (non-)delivery message.  If the value of the field is IGNORE, the 
+   content gateway MUST NOT generate a notification.  If the value of 
+   the field is CRTITICAL, the content gateway MAY generate a 
+   notification, based on the normal notification request mechanisms.  
+  
+Burger and Candell          Expires 9/2/01                    [Page 3] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+   Normal notification request mechanisms include the SMTP RCPT NOTIFY 
+   command [3] and the Disposition-Notification-To header [5]. 
+    
+   For example, if the sending system requests a notification, and a 
+   CRITICAL part fails, the content gateway will generate a NDN for the 
+   whole message.  Conversely, if the gateway cannot pass on a body 
+   part marked IGNORE, the gateway will not generate a NDN.  
+    
+   The next sections examine the actions taken by the content gateway, 
+   given the different values of Content-Criticality. 
+    
+   NOTE: This implies that the content gateway must examine the entire 
+   message to determine whether it needs to generate a notification.  
+   However, the content gateway need not examine the message if it 
+   knows it can store and forward all media types.  Said differently, 
+   Internet e-mail MTAs or gateways can, by default, handle any 
+   arbitrary MIME-encapsulated type.  Some voice mail systems, on the 
+   other hand, cannot store binary attachments at all, such as 
+   application/ms-word.  The voice mail content gateway, in this 
+   example, would be scanning for non-renderable body parts in any 
+   event.  
+    
+4.1. CRITICAL 
+    
+   "Content-Criticality: CRITICAL" signifies that this body part is 
+   critical to the sender. 
+    
+   If the content gateway cannot pass a body part marked CRITICAL, then 
+   the entire message has failed.  In this case, the content gateway 
+   MUST take the appropriate failure action. 
+    
+   NOTE: We say "appropriate action", because the sender may have 
+   suppressed all notifications.  In this case, the appropriate action 
+   is to silently discard the message. 
+    
+4.2. IGNORE 
+    
+   "Content-Criticality: IGNORE" signifies that the sender does not 
+   care about notification reports for this body part. 
+    
+   If the content gateway cannot pass a body part marked IGNORE, the 
+   receiving system may silently delete the body part.  The receiving 
+   system MUST NOT return a delivery failure, unless parts marked 
+   IMPORTANT or CRITICAL have also failed. 
+    
+4.3. Default Values 
+    
+   The default value for Content-Criticality for a given body part is 
+   CRITICAL.  This enables the existing notification mechanisms to work 
+   for user agents that do not know about the content notification 
+   entity.  All body parts are critical, because they have the default 
+   marking of CRITICAL. 
+  
+Burger and Candell          Expires 9/2/01                    [Page 4] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+    
+   NOTE: Remember that critical content processing is a function of the 
+   content gateway, and not the MTA or UA.  In practice, the entity 
+   performing content gateway processing is the receiving UA.  However, 
+   it is acting as a content gateway.  Thus the default action for any 
+   MIME-compliant user agent to ignore unrecognized MIME entities 
+   ensures that this mechanism is compatible with the Internet 
+   architecture. 
+    
+   NOTE: Some VPIMv2 implementations can receive arbitrary e-mail from 
+   the Internet.  However, these systems are really acting in the 
+   capacity of an Internet Voice Mail system.  In this case, one would 
+   expect the implementation to provide Internet Voice Mail semantics 
+   to Internet Voice Mail messages. 
+    
+    
+    
+4.4. Other Values 
+    
+   The content gateway MUST treat unrecognized values as CRITICAL.  
+   This is to provide backward compatibility with future uses of the 
+   Content-Criticality entity. 
+    
+   The most likely new value is IMPORTANT.  An IMPORTANT body part is 
+   something the sender wants the receiver to get, but would not want 
+   the message rejected outright if the IMPORTANT body part fails.  A 
+   content gateway that does not understand IMPORTANT MUST take the 
+   default value of CRITICAL.  This is because the content gateway has 
+   to take the conservative action of rejecting the message. 
+     
+4.5. DSN vs MDN Generation 
+    
+   The content gateway generates a delivery status notification (DSN) 
+   [4] if it operates as a gateway.  The content gateway generates a 
+   Message Disposition Notification (MDN) [5] if it operates as a user 
+   agent.  Section 7 describes the operating modes of a content 
+   gateway.  In short, if there is a MTA that "delivers" the message to 
+   the content gateway for processing, the MTA takes responsibility for 
+   DSN processing.  In this case, the only option available to the 
+   content gateway is to generate MDNs.  If the content gateway 
+   operates as a MTA, then it generates DSNs.  DSN generation is the 
+   preferred option. 
+    
+    
+4.6. Summary 
+    
+   The following table summarizes the actions expected of a conforming 
+   content gateway. 
+    
+   NOTE: This section is normative: it suggests what to put into the 
+   DSN or MDN.  
+
+  
+Burger and Candell          Expires 9/2/01                    [Page 5] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+                            +--------------------------------------+ 
+                            |    Sending UA Has Marked Body Part   | 
+                            |---------------------+----------------| 
+                            |      CRITICAL       |     IGNORE     | 
+       +--------------------+---------------------+----------------+ 
+       | Body Part is       |                     |                | 
+       | Deliverable        | Appropriate Action  |     ignore     | 
+       +--------------------+---------------------+----------------+ 
+       | Body Part is       |                     |                | 
+       | Undeliverable      | Fail Entire Message |     ignore     | 
+       +--------------------+--------------------------------------+ 
+    
+    
+   The "Appropriate Action" is the action the content gateway would 
+   take given the context of execution.  For example, if a sender 
+   requests return receipt and the receiver reads a CRITICAL body part, 
+   the receiving UA must generate the appropriate MDN (following the 
+   rules for MDN).  Likewise, if the content gateway cannot deliver the 
+   body part and the body part is critical, the content gateway 
+   generates the appropriate DSN or MDN.  
+    
+   "Ignore" means the content gateway ignores the disposition of the 
+   body part.  The content gateway treats the message as if the body 
+   part was not present in the message. 
+    
+    
+5. Status Code 
+    
+   The critical content indication, in itself, does not guarantee any 
+   notification.  Notification follows the rules described in [4] and 
+   [5]. 
+    
+   NOTE: The content of actual DSNs or MDNs are beyond the scope of 
+   this document.  This document only specifies how to mark a critical 
+   body part.  On the other hand, we do envision sensible DSN and MDN 
+   contents.  For example, DSNs should include the appropriate failure 
+   code as enumerated in [6].  Likewise, MDNs should include the 
+   failure code in the MDN "Failure:" field. 
+    
+   If the receiving system is to generate a notification based on its 
+   inability to render or store the media type, the notification MUST 
+   include the status code 5.6.1, "Media not supported", from [6]. 
+    
+    
+6. Requirements for Critical Content 
+    
+6.1. Needs 
+    
+   The need for a critical content identification mechanism comes about 
+   because of the internetworking of Internet mail systems with 
+   messaging systems that do not fulfill all of the semantics of 
+   Internet mail.  Such legacy systems have a limited ability to render 
+  
+Burger and Candell          Expires 9/2/01                    [Page 6] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+   or store all parts of a given message.  This document will use the 
+   case of an Internet mail system exchanging electronic messages with 
+   a legacy voice messaging system for illustrative purposes. 
+    
+   Electronic mail has historically been text-centric.  Extensions such 
+   as MIME [7] enable the user agents to send and receive multi-part, 
+   multimedia messages.  Popular multimedia data types include binary 
+   word processing documents, binary business presentation graphics, 
+   voice, and video. 
+    
+   Voice mail has historically been audio-centric.  Many voice-
+   messaging systems only render voice.  Extensions such as fax enable 
+   the voice mail system to send and receive fax images as well as 
+   create multi-part voice and fax messages.  A few voice mail systems 
+   can render text using text-to-speech or text-to-fax technology.  
+   Although theoretically possible, none can today render video. 
+    
+   An important aspect of the interchange between voice messaging 
+   services and desktop e-mail client applications is that the 
+   rendering capability of the voice-messaging platform is often much 
+   less than the rendering capability of a desktop e-mail client.  In 
+   the e-mail case, the sender has the expectation that the recipient 
+   receives all components of a multimedia message.  This is so even if 
+   the recipient cannot render all body parts.  In most cases, the 
+   recipient can either find the appropriate rendering tool or tell the 
+   sender that she cannot read the particular attachment. 
+    
+   This is an important issue.  By definition, a MIME-enabled user 
+   agent, conforming to [8], will present or make available all of the 
+   body parts to the recipient.  However, a voice mail system may not 
+   be capable of storing non-voice objects.  Moreover, the voice mail 
+   system may not be capable of notifying the recipient that there were 
+   undeliverable message parts. 
+    
+   The inability of the receiving system to render a body part is 
+   usually a permanent failure.  Retransmission of the message will not 
+   improve the likelihood of a future successful delivery.  Contrast 
+   this with the case with normal data delivery.  Traditional message 
+   failures, such as a garbled message or disabled link will benefit 
+   from retransmission. 
+    
+   This situation is fundamentally different from normal Internet mail.  
+   In the Internet mail case, either the system delivered the message, 
+   or it didn't.  There is no concept of a system partially delivering 
+   a message. 
+ 
+   In addition, there are many situations where the sender would not 
+   mind if the system did not deliver non-critical parts of a message.  
+   For example, the sender's user agent may add body parts to a message 
+   unbeknownst to the sender.  If the receiving system rejected the 
+   message because it could not render a hidden body part, the sender 
+   would be understandably confused and upset. 
+  
+Burger and Candell          Expires 9/2/01                    [Page 7] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+    
+   Thus, there is a need for a method of indicating to a Mail Transfer 
+   Agent (MTA) or User Agent (UA) that the sender considers parts of a 
+   message to be critical.  From the sender's perspective, he would not 
+   consider the message delivered if the system did not deliver the 
+   critical parts. 
+    
+6.2. Current Approaches 
+    
+   One method of indicating critical content of a message is to define 
+   a profile.  The profile defines rules for silently deleting mail 
+   body parts based on knowledge of the UA capabilities.  Citing the 
+   example above, a voice profile can easily declare that MTAs or UAs 
+   can silently delete TNEF data and yet consider the message 
+   successfully delivered.  This is, in fact, the approach taken by 
+   VPIMv2 [9]. 
+    
+   Since one aspect of the issue is deciding when to notify the sender 
+   that the system cannot deliver part of a message, one could use a 
+   partial non-delivery notification mechanism to indicate a problem 
+   with delivering a given body part.  However, this requires the user 
+   request a MDN. 
+    
+   A straightforward alternative implementation method for marking a 
+   body part critical is to use a content-disposition parameter called 
+   "criticality".  This would have the benefit of being very easy for 
+   IMAP servers to implement.  In particular, IMAP servers 
+   automatically present the content-disposition entity when a client 
+   requests information on a message.  On the other hand, the client 
+   must explicitly request the presence and value of different 
+   entities, such as content-criticality.  However, implementing the 
+   critical content indicator as a parameter to content-disposition 
+   overloads the meaning of the entity.  Moreover, IMAP servers can 
+   present, in the future, content-criticality by default.  Lastly, 
+   most clients that have interest in content-criticality will 
+   explicitly request the header in any event. 
+    
+   In short, we need a way of letting the sender indicate what body-
+   parts he considers to be critical.  The mechanism must not burden 
+   the sender with failure notifications for non-critical body parts.  
+   The mechanism must conform to the general notification status 
+   request mechanism for positive or negative notification.  When 
+   requested, the mechanism must indicate to the sender when a 
+   receiving system cannot deliver a critical body part. 
+    
+    
+6.3. Critical-Content Entity 
+    
+   The Critical Content marking mechanism satisfies these needs.  
+   Following the format for Internet message bodies [7], this document 
+   introduces the Content-Criticality body part header.  Values for 
+   this header are CRITICAL or IGNORE. 
+  
+Burger and Candell          Expires 9/2/01                    [Page 8] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+    
+7. The Content Gateway 
+    
+   In this section, we use the definition of [10] for the term 
+   "gateway." 
+    
+   A content gateway is a gateway that connects a first network to a 
+   second network.  The second network often has lesser capability than 
+   the first network.  The canonical topology follows.  The "[MTA]" 
+   signifies an optional component. 
+    
+                             +---------+ 
+   +---------+     +-----+   |         |     +-------+   +-----------+ 
+   | Sending |=...=|[MTA]|===| Content |=...=| [MTA] |===| Receiving | 
+   |   UA    |     +-----+   | Gateway |     +-------+   |    UA     | 
+   +---------+               |         |                 +-----------+ 
+                             +---------+ 
+          First Network                         Second Network 
+    
+    
+   The content gateway can be the last hop before the receiving MTA.  
+   The content gateway can be between networks, and thus not the last 
+   hop before the receiving MTA.  The content gateway can be the first 
+   MTA the sending UA contacts.  Finally, the content gateway can be an 
+   integrated component of the receiving MTA. 
+    
+    
+7.1. Integrated Content Gateway 
+    
+   In this situation, the receiving user agent is integrated with the 
+   content gateway. The integrated content gateway knows the 
+   capabilities of the user agent.  The topology is as follows. 
+    
+                             +---------------------+ 
+   +---------+     +-----+   |         :           | 
+   | Sending |=...=|[MTA]|===| Content : Receiving | 
+   |   UA    |     +-----+   | Gateway :    UA     | 
+   +---------+               |         :           | 
+                             +---------------------+ 
+          First Network           Second Network 
+    
+    
+7.2. Disaggregated Delivery Network 
+    
+   A degenerate case, although one that does occur, is where the 
+   content gateway sits behind the final MTA.  This happens when one 
+   implements the content gateway as a post-processing step to a normal 
+   delivery.  For example, one could configure a mail handling system 
+   to deliver the message to a queue or directory, where the content 
+   gateway process picks up the message.  If there were any directives 
+   for DSN processing, the delivering MTA would execute them.  For 
+   example, the message could have requested notification on successful 
+  
+Burger and Candell          Expires 9/2/01                    [Page 9] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+   delivery.  The delivering MTA, having delivered the message to the 
+   queue, would consider the message delivered and thus notify the 
+   sender of such.  However, the content gateway process could then 
+   discover that the receiving UA cannot render the message.  In this 
+   case, the content gateway generates a NDN, as it is the only option 
+   available. 
+    
+                           Delivered 
+                               |      +---------+ 
+   +---------+     +-----+     v      |         |     +-----------+ 
+   | Sending |=...=| MTA |--> File -->| Content |=...=| Receiving | 
+   |   UA    |     +-----+            | Gateway |     |    UA     | 
+   +---------+                        |         |     +-----------+ 
+                                      +---------+ 
+          First Network              Second Network 
+    
+    
+    
+8. Backward Compatibility Considerations 
+    
+   DSN requires ESMTP.  If MTAs in the path from the sending UA to the 
+   receiving UA do not support ESMTP, then that MTA will reject the DSN 
+   request.  In addition, the message will default to notification on 
+   delay or failure.  While not ideal, the sender will know that DSN is 
+   not available, and that critical content that fails will get 
+   notification. 
+    
+ 
+9. MIME Interactions 
+    
+9.1. multipart/alternative 
+    
+   Content-Criticality is only in effect for the selected alternative.  
+   If the selected alternative has the critical content indicator, then 
+   the entire alternative takes on the criticality indicated.  That is, 
+   if the alternative selected has Content-Criticality: IGNORE, then 
+   the content gateway MUST NOT generate any delivery notifications. 
+    
+   It is unlikely for a selected alternative to fail, as the content 
+   gateway presumably picks the alternative specifically because it can 
+   render it.  
+    
+   If the selected alternative is a message/rfc822 that encloses a 
+   multipart MIME message or the selected alternative is itself a 
+   multipart MIME type, the individual top-level body parts follow the 
+   Content-Criticality mechanism described in this document. 
+    
+9.2. multipart/related 
+    
+   Content-Criticality fits in rather well with the multipart/related 
+   construction.  For example, consider a multipart/related message 
+   consisting of a Macintosh data fork and a Macintosh resource fork.  
+  
+Burger and Candell          Expires 9/2/01                   [Page 10] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+   For a Microsoft Word document, the data fork is likely to be 
+   critical.  The receiving system can safely ignore the resource fork. 
+    
+9.3. message/rfc822 
+    
+   Content-Criticality only affects the outermost level of the message 
+   or, in the case of multipart/alternative, the outermost level of the 
+   selected alternative.  Specifically, the receiving system ignores 
+   Content-Criticality indicators in embedded body parts.  This avoids 
+   the situation of a forwarded message triggering or suppressing 
+   undesired reporting. 
+    
+    
+10. Implementation Examples 
+    
+   This section is not a normative part of the definition of Content-
+   Criticality.  However, we hope it helps implementers to understand 
+   the mechanics of the Content-Criticality mechanism. 
+    
+   We will examine two cases.  They are how a content gateway processes 
+   a message and how a disaggregated content gateway processes a 
+   message. 
+    
+10.1. Content Gateways 
+    
+   Content gateways examine the contents of a message from a first 
+   network before the gateway forwards the message to a second network.  
+   For the purposes of this example, we assume the second network has 
+   less capability than the first network.  In particular, we expect 
+   there will be certain message body types that the gateway cannot 
+   pass onto the second network. 
+    
+   Consider a gateway between the Internet and a text-only short 
+   message service.  A message comes through the gateway containing a 
+   text part and a tnef part.  The sender marks the text part CRITICAL.  
+   The gateway, knowing the capability of the short message service, 
+   silently deletes the non-critical, tnef part, passing the critical 
+   content to the short message service network.  Any subsequent 
+   notifications, such as failure notices or delivery notices, follow 
+   the normal rules for notification. 
+    
+   Note the gateway, by silently deleting non-critical content, may 
+   affect proprietary message correlation schemes.  One can envision 
+   the sending UA inserting a body part for tracking purposes.  By 
+   deleting non-critical content, the content gateway will break such a 
+   scheme.  If a sending UA understands how to mark critical content, 
+   it should use Internet standard mechanisms for tracking messages, 
+   such as Message-ID [11]. 
+    
+   What if no body parts have critical content indicators?  In this 
+   case, the entire message is critical.  Thus, when the gateway sees 
+
+  
+Burger and Candell          Expires 9/2/01                   [Page 11] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+   the tnef part, it will reject the entire message, generating a DSN 
+   with a status code 5.6.1, "Media not supported". 
+    
+   Likewise, consider a three part message with a text annotation (part 
+   1) to a voice message (part 2) with a vCard [12] (part 3).  The 
+   sender marks the first two parts CRITICAL.  Now, let us assume the 
+   receiving MTA (gateway) is a voice mail only system, without even 
+   the capability to store text.  In this case, the gateway, acting as 
+   the receiving MTA, will reject the message, generating a DSN with 
+   the status code 5.6.1, "Media not supported". 
+ 
+10.2. Disaggregated Content Gateway 
+    
+   For this example, we will examine the processing of a three-part 
+   message.  The first part is a text annotation of the second part, an 
+   audio message.  The third part is the sender's vCard.  The sender 
+   marks the first and second parts CRITICAL.  In addition, the sender 
+   marks the message for read receipt. 
+    
+   For the purposes of example, the telephone user interface (TUI) does 
+   not perform text-to-speech conversion.  A TUI is a mail user agent 
+   (UA) that uses DTMF touch-tone digits for input and audio for output 
+   (display). 
+    
+   The TUI is unable to render the first part of the message, the text 
+   part.  In addition, it is unable to render the third part of the 
+   message, the vCard part.  Since the sender did not mark the third 
+   part of the message CRITICAL, the system ignores the failure of the 
+   TUI to render the third part of the message.  However, since the 
+   sender did mark the first part CRITICAL, and the TUI is unable to 
+   render text, the message fails. 
+    
+   What happens next is implementation dependent.  If the TUI is part 
+   of a unified messaging system, a reasonable action is to hold the 
+   message for the user.  The user can access the message at a later 
+   time from a terminal that can render all of the critical body parts.  
+   It would be reasonable for the TUI to notify the user about the 
+   message. 
+    
+   If the TUI is part of a voice messaging system, or if the user does 
+   not subscribe to a text-to-speech service, a reasonable action is 
+   for the TUI to return a MDN with the disposition "failed" and the 
+   failure modifier "5.6.1 (Media not supported)". 
+    
+    
+11. Security Considerations 
+ 
+   Receiving systems and users should not place any authentication 
+   value on the Content-Criticality entity.  Just because a message has 
+   a particular Content-Criticality value doesn't mean that the message 
+   really originated at a given type of system. 
+    
+  
+Burger and Candell          Expires 9/2/01                   [Page 12] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+    
+12. IANA Considerations 
+    
+   None. 
+    
+    
+13. Collected Syntax 
+    
+   The format of the collected syntax is in accordance with the ABNF of 
+   [13].  Note that per RFC 2045, none of the strings are case 
+   sensitive. 
+    
+    
+        "Content-Criticality" ":" notification-type CRLF 
+    
+        notification-type = "CRITICAL" / "IGNORE" 
+    
+    
+ 
+14. References 
+    
+ 
+   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
+      9, RFC 2026, October 1996. 
+    
+   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
+      Levels", BCP 14, RFC 2119, March 1997. 
+    
+   3  Moore, K., "SMTP Service Extension for Delivery Status 
+      Notifications", RFC 1981, University of Tennessee, January 1996. 
+    
+   4  Moore, K. and Vaudreuil, G., "An Extensible Message Format for 
+      Delivery Status Notifications", RFC 1894, University of Tennessee 
+      and Octel Network Services, January 1996. 
+     
+   5  Fajman, R., "An Extensible Message Format for Message Disposition 
+      Notifications", RFC 2298, National Institutes of Health, March 
+      1998. 
+    
+   6  Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, 
+      Octel Network Services, January 1996. 
+    
+   7  Freed, N. and Borenstein, N., "Multipurpose Internet Mail 
+      Extensions (MIME) Part One: Format of Internet Message Bodies", 
+      RFC 2045, Innosoft and First Virtual, November 1996. 
+    
+   8  Freed, N. and Borenstein, N., "Multipurpose Internet Mail 
+      Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft and 
+      First Virtual, November 1996. 
+    
+
+
+  
+Burger and Candell          Expires 9/2/01                   [Page 13] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+ 
+   9  Vaudreuil, G. and Parsons, G., "Voice Profile for Internet Mail - 
+      version 2", RFC 2421, Lucent Technologies and Nortel Networks, 
+      September 1998. 
+    
+   10 Kille, S. "MIXER (Mime Internet X.400 Enhanced Relay): Mapping 
+      between X.400 and RFC 822/MIME", RFC 2156, Isode, January 1998. 
+    
+   11 Crocker, D., "Standard for the Format of ARPA Internet Text 
+      Messages", RFC 822, University of Delaware, August 1982. 
+    
+   12 Dawson, F. and Howes, T., "vCard MIME Directory Profile", RFC 
+      2426, Lotus Development Corporation and Netscape Communications, 
+      September 1998. 
+    
+   13 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 
+      Specifications: ABNF", RFC 2234, Internet Mail Consortium and 
+      Demon Internet Ltd., November 1997. 
+    
+    
+    
+    
+15. Acknowledgments 
+    
+   We'd like to thank Ned Freed for pointing out that this mechanism 
+   was about criticality, not notification per se.  That insight made 
+   the concept and descriptions infinitely more straightforward.  If 
+   it's still confusing, it's our fault! 
+    
+   We'd also like to thank Keith Moore for helping us tighten-up our 
+   explanations. 
+    
+   Dropping the IMPORTANT critical content type took away one of the 
+   reasons for partial non-delivery notification.  That makes Jutta 
+   Degener very happy! 
+    
+   Harald Alvestrand and Chris Newman suggested we add implementation 
+   examples, which we did. 
+    
+   Greg asked the key question that let us realize that critical 
+   content processing was a gateway, and not a MTA or UA function. 
+    
+    
+
+
+
+
+
+
+
+
+
+  
+Burger and Candell          Expires 9/2/01                   [Page 14] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+16. Author's Addresses 
+    
+   Eric Burger 
+   SnowShore Networks, Inc. 
+   285 Billerica Rd. 
+   Chelmsford, MA  01824-4120 
+   USA 
+    
+   Phone: +1 978 367 8403 
+   Fax:   +1 603 457 5944 
+   Email: e.burger@ieee.org 
+    
+    
+   Emily Candell 
+   Comverse Network Systems 
+   200 Quannapowitt Pkwy. 
+   Wakefield, MA  01880 
+   USA 
+    
+   Phone: +1 781 213 2324 
+   Email: emily@comversens.com 
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Burger and Candell          Expires 9/2/01                   [Page 15] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+ 
+Full Copyright Statement 
+
+   The IETF takes no position regarding the validity or scope of any 
+   intellectual property or other rights that might be claimed to  
+   pertain to the implementation or use of the technology described in 
+   this document or the extent to which any license under such rights 
+   might or might not be available; neither does it represent that it 
+   has made any effort to identify any such rights.  Information on the 
+   IETF's procedures with respect to rights in standards-track and 
+   standards-related documentation can be found in BCP-11.  Copies of 
+   claims of rights made available for publication and any assurances 
+   of licenses to be made available, or the result of an attempt made 
+   to obtain a general license or permission for the use of such 
+   proprietary rights by implementers or users of this specification 
+   can be obtained from the IETF Secretariat. 
+    
+   The IETF invites any interested party to bring to its attention any 
+   copyrights, patents or patent applications, or other proprietary 
+   rights that may cover technology that may be required to practice 
+   this standard.  Please address the information to the IETF Executive 
+   Director. 
+    
+   Copyright (C) 2000, 2001 The Internet Society.  All Rights Reserved. 
+    
+   This document and translations of it may be copied and furnished to 
+   others, and derivative works that comment on or otherwise explain it 
+   or assist in its implementation may be prepared, copied, published 
+   and distributed, in whole or in part, without restriction of any 
+   kind, provided that the above copyright notice and this paragraph 
+   are included on all such copies and derivative works.  However, this 
+   document itself may not be modified in any way, such as by removing 
+   the copyright notice or references to the Internet Society or other 
+   Internet organizations, except as needed for the  purpose of 
+   developing Internet standards in which case the procedures for 
+   copyrights defined in the Internet Standards process must be 
+   followed, or as required to translate it into languages other than 
+   English. 
+    
+   The limited permissions granted above are perpetual and will not be 
+   revoked by the Internet Society or its successors or assigns. 
+    
+   This document and the information contained herein is provided on an 
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
+
+
+
+
+
+  
+Burger and Candell          Expires 9/2/01                   [Page 16] 
+
diff --git a/Documentation/en/I-D/draft-ietf-vpim-cc-04.txt b/Documentation/en/I-D/draft-ietf-vpim-cc-04.txt
new file mode 100644
index 00000000..0a5be272
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-vpim-cc-04.txt
@@ -0,0 +1,901 @@
+
+
+Network Working Group                                           E. Burger 
+Internet Draft                                         SnowShore Networks 
+Document: draft-ietf-vpim-cc-04.txt                                       
+Category: Standards Track                                                 
+Expires September 2001                                     March 30, 2001 
+ 
+ 
+                   Critical Content of Internet Mail 
+ 
+ 
+Status of this Memo 
+ 
+   This document is an Internet-Draft and is in full conformance with 
+   all provisions of Section 10 of RFC 2026 [1].  
+    
+   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." 
+    
+   One can access the list of current Internet-Drafts at 
+   http://www.ietf.org/ietf/1id-abstracts.txt 
+    
+   One can access the list of Internet-Draft Shadow Directories at 
+   http://www.ietf.org/shadow.html. 
+    
+   This document is a work product of the IETF Voice Profile for 
+   Internet Mail (VPIM) Work Group. 
+    
+    
+1. Abstract 
+    
+   This document describes a mechanism for identifying body parts that 
+   a sender deems critical in a multi-part Internet mail message [10].  
+   The mechanism described is a parameter to Content-Disposition. 
+    
+   By knowing what parts of a message the sender deems critical, a 
+   content gateway can intelligently handle multi-part messages when 
+   gatewaying 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. 
+ 
+                           Expires 9/30/01                   [Page 1] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+Table of Contents 
+    
+1. Abstract...........................................................1 
+2. Conventions used in this document..................................2 
+3. Introduction.......................................................3 
+4. Criticality Parameter..............................................3 
+4.1. CRITICAL.........................................................3 
+4.2. IGNORE...........................................................4 
+4.3. Default Values...................................................4 
+4.4. Other Values.....................................................4 
+5. Collected Syntax...................................................5 
+6. Notification.......................................................5 
+6.1. DSN vs MDN Generation............................................5 
+6.2. Summary..........................................................6 
+7. Status Code........................................................6 
+8. Requirements for Critical Content..................................7 
+8.1. Needs............................................................7 
+8.2. Current Approaches...............................................8 
+8.3. Criticality Parameter............................................9 
+9. The Content Gateway................................................9 
+9.1. Integrated Content Gateway.......................................9 
+9.2. Disaggregated Delivery Network..................................10 
+10. Backward Compatibility Considerations............................10 
+11. MIME Interactions................................................10 
+11.1. multipart/alternative..........................................10 
+11.2. multipart/related..............................................11 
+11.3. message/rfc822.................................................11 
+12. Implementation Examples..........................................11 
+12.1. Content Gateways...............................................11 
+12.2. Disaggregated Content Gateway..................................12 
+13. Security Considerations..........................................13 
+14. IANA Considerations..............................................13 
+15. References.......................................................13 
+16. Acknowledgments..................................................15 
+17. Author's Address.................................................15 
+    
+    
+2. Conventions used in this document 
+    
+   This document refers generically to the sender of a message in the 
+   masculine (he/him/his) and the recipient of the message in the 
+   feminine (she/her/hers).  This convention is purely for convenience 
+   and makes no assumption about the gender of a message sender or 
+   recipient. 
+    
+  
+Burger                     Expires 9/30/01                   [Page 2] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
+   this document are to be interpreted as described in RFC 2119 [2]. 
+    
+   NOTE: Notes, such at this one, provide additional nonessential 
+   information that the reader may skip without missing anything 
+   essential.  The primary purpose of these non-essential notes is to 
+   convey information about the rationale of this document, or to place 
+   this document in the proper historical or evolutionary context.  
+   Readers whose sole purpose is to construct a conformant 
+   implementation may skip such information.  However, it may be of use 
+   to those who wish to understand why we made certain design choices. 
+    
+    
+3. Introduction 
+ 
+   The specification of Critical Content is small and compact.  For the 
+   benefit of developers, the specification comes first, the rationale 
+   after. 
+    
+   One concept that an implementer must understand is the content 
+   gateway.  Section 7 describes the content gateway.  In brief, a 
+   content gateway has knowledge of the receiving system's 
+   capabilities.  The content gateway passes messages the receiving 
+   system can render or store.  The content gateway can modify a 
+   message, for example by deleting unrenderable or storable body 
+   parts, for delivery to the receiving system.  Finally, the content 
+   gateway can reject a message that the receiving system cannot 
+   handle. 
+    
+4. Criticality Parameter 
+    
+   The Criticality parameter is a Content-Disposition [3] parameter 
+   inserted by the sending UA to indicate to the content gateway 
+   whether to consider the marked body part critical. 
+    
+   A CRITICAL body part is one the sender requires the receiving system 
+   to deliver for him to consider the message delivered. 
+    
+   An IGNORE body part is one the sender doesn't care whether the 
+   receiving system delivers it or not.  A content gateway can silently 
+   delete such body parts if the receiving system cannot deliver the 
+   part. 
+    
+   The terms "entity" and "body part" have the meanings defined in 
+   [10]. 
+    
+4.1. CRITICAL 
+    
+   "Criticality=CRITICAL" signifies that this body part is critical to 
+   the sender. 
+    
+  
+Burger                     Expires 9/30/01                   [Page 3] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+   If the content gateway cannot pass a body part marked CRITICAL, then 
+   the entire message has failed.  In this case, the content gateway 
+   MUST take the appropriate failure action. 
+    
+   NOTE: We say "appropriate action", because the sender may have 
+   suppressed all notifications.  In this case, the appropriate action 
+   is to silently discard the message. 
+    
+4.2. IGNORE 
+    
+   "Criticality=IGNORE" signifies that the sender does not care about 
+   notification reports for this body part. 
+    
+   If the content gateway cannot pass a body part marked IGNORE, the 
+   receiving system may silently delete the body part.  The receiving 
+   system MUST NOT return a delivery failure, unless parts marked 
+   IMPORTANT or CRITICAL have also failed. 
+    
+4.3. Default Values 
+    
+   The default value for Criticality for a given body part is CRITICAL.  
+   This enables the existing notification mechanisms to work for user 
+   agents that do not know about the content notification entity.  All 
+   body parts are critical, because they have the default marking of 
+   CRITICAL. 
+    
+   NOTE: Remember that critical content processing is a function of the 
+   content gateway, and not the MTA or UA.  Often, the entity 
+   performing content gateway processing is the receiving UA.  However, 
+   it is acting as a content gateway.  Thus the default action for any 
+   Content-Disposition [3]-compliant user agent to ignore unrecognized 
+   disposition parameters ensures that this mechanism is compatible 
+   with the Internet architecture. 
+    
+   NOTE: Some VPIMv2 implementations can receive arbitrary e-mail from 
+   the Internet.  However, these systems are really acting in the 
+   capacity of an Internet Voice Mail system.  In this case, one would 
+   expect the implementation to provide Internet Voice Mail semantics 
+   to Internet Voice Mail messages. 
+    
+    
+    
+4.4. Other Values 
+    
+   The content gateway MUST treat unrecognized values as CRITICAL.  
+   This is to provide backward compatibility with future uses of the 
+   Content-Criticality entity. 
+    
+   NOTE: A possible new value is IMPORTANT.  An IMPORTANT body part is 
+   something the sender wants the receiver to get, but would not want 
+   the message rejected outright if the IMPORTANT body part fails, but 
+   they do want notification of the failure.  However, as no 
+  
+Burger                     Expires 9/30/01                   [Page 4] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+   implementations do IMPORTANT, it is not important to this version of 
+   this document. 
+    
+    
+5. Collected Syntax 
+    
+   The format of the collected syntax is in accordance with the ABNF of 
+   [5].  Note that per RFC 2183 [3], the CRITICALITY Content-
+   Disposition parameter is not case sensitive.  In addition, the 
+   notification-type is not case sensitive. 
+    
+        "criticality" "=" notification-type CRLF 
+    
+        notification-type = "CRITICAL" / "IGNORE" 
+    
+    
+ 
+6. Notification 
+    
+   One obvious application of critical content is generating a 
+   (non-)delivery notification.  If the value of the field is IGNORE, 
+   the content gateway MUST NOT generate a notification.  If the value 
+   of the field is CRTITICAL, the content gateway MAY generate a 
+   notification, based on the normal notification request mechanisms.  
+   Normal notification request mechanisms include the SMTP RCPT NOTIFY 
+   command [6] and the Disposition-Notification-To header [8]. 
+    
+   If the sending system requests a notification, and a CRITICAL part 
+   fails, the content gateway will generate a notification for the 
+   whole message.  Conversely, if the gateway cannot pass on a body 
+   part marked IGNORE, the gateway will not generate a notification.  
+    
+   NOTE: This implies that the content gateway must examine the entire 
+   message to determine whether it needs to generate a notification.  
+   However, the content gateway need not examine the message if it 
+   knows it can store and forward all media types.  Said differently, 
+   Internet e-mail MTAs or gateways can, by default, handle any 
+   arbitrary MIME-encapsulated type.  Some voice mail systems, on the 
+   other hand, cannot store binary attachments at all, such as 
+   application/ms-word.  The voice mail content gateway, in this 
+   example, would be scanning for non-renderable body parts in any 
+   event.  
+     
+6.1. DSN vs MDN Generation 
+    
+   The content gateway generates a delivery status notification (DSN) 
+   [7] if it operates as a gateway.  The content gateway generates a 
+   Message Disposition Notification (MDN) [8] if it operates as a user 
+   agent.  Section 7 describes the operating modes of a content 
+   gateway.  In short, if there is a MTA that "delivers" the message to 
+   the content gateway for processing, the MTA takes responsibility for 
+   DSN processing.  In this case, the only option available to the 
+  
+Burger                     Expires 9/30/01                   [Page 5] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+   content gateway is to generate MDNs.  If the content gateway 
+   operates as a MTA, then it generates DSNs.  DSN generation is the 
+   preferred option. 
+    
+    
+6.2. Summary 
+    
+   The following table summarizes the actions expected of a conforming 
+   content gateway. 
+    
+   NOTE: This section is normative: it suggests what to put into the 
+   DSN or MDN.  
+                            +--------------------------------------+ 
+                            |    Sending UA Has Marked Body Part   | 
+                            |---------------------+----------------| 
+                            |      CRITICAL       |     IGNORE     | 
+       +--------------------+---------------------+----------------+ 
+       | Body Part is       |                     |                | 
+       | Deliverable        | Appropriate Action  |     ignore     | 
+       +--------------------+---------------------+----------------+ 
+       | Body Part is       |                     |                | 
+       | Undeliverable      | Fail Entire Message |     ignore     | 
+       +--------------------+--------------------------------------+ 
+    
+    
+   The "Appropriate Action" is the action the content gateway would 
+   take given the context of execution.  For example, if a sender 
+   requests return receipt and the receiver reads a CRITICAL body part, 
+   the receiving UA must generate the appropriate MDN (following the 
+   rules for MDN).  Likewise, if the content gateway cannot deliver the 
+   body part and the body part is critical, the content gateway 
+   generates the appropriate DSN or MDN.  
+    
+   "Ignore" means the content gateway ignores the disposition of the 
+   body part.  The content gateway treats the message as if the body 
+   part was not present in the message. 
+    
+    
+7. Status Code 
+    
+   The critical content indication, in itself, does not guarantee any 
+   notification.  Notification follows the rules described in [7] and 
+   [8]. 
+    
+   NOTE: The content of actual DSNs or MDNs are beyond the scope of 
+   this document.  This document only specifies how to mark a critical 
+   body part.  On the other hand, we do envision sensible DSN and MDN 
+   contents.  For example, DSNs should include the appropriate failure 
+   code as enumerated in [9].  Likewise, MDNs should include the 
+   failure code in the MDN "Failure:" field. 
+    
+  
+Burger                     Expires 9/30/01                   [Page 6] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+   If the receiving system is to generate a notification based on its 
+   inability to render or store the media type, the notification should 
+   use the status code 5.6.1, "Media not supported", from [9]. 
+    
+    
+8. Requirements for Critical Content 
+    
+8.1. Needs 
+    
+   The need for a critical content identification mechanism comes about 
+   because of the internetworking of Internet mail systems with 
+   messaging systems that do not fulfill all of the semantics of 
+   Internet mail.  Such legacy systems have a limited ability to render 
+   or store all parts of a given message.  This document will use the 
+   case of an Internet mail system exchanging electronic messages with 
+   a legacy voice messaging system for illustrative purposes. 
+    
+   Electronic mail has historically been text-centric.  Extensions such 
+   as MIME [10] enable the user agents to send and receive multi-part, 
+   multimedia messages.  Popular multimedia data types include binary 
+   word processing documents, binary business presentation graphics, 
+   voice, and video. 
+    
+   Voice mail has historically been audio-centric.  Many voice-
+   messaging systems only render voice.  Extensions such as fax enable 
+   the voice mail system to send and receive fax images as well as 
+   create multi-part voice and fax messages.  A few voice mail systems 
+   can render text using text-to-speech or text-to-fax technology.  
+   Although theoretically possible, none can today render video. 
+    
+   An important aspect of the interchange between voice messaging 
+   services and desktop e-mail client applications is that the 
+   rendering capability of the voice-messaging platform is often much 
+   less than the rendering capability of a desktop e-mail client.  In 
+   the e-mail case, the sender has the expectation that the recipient 
+   receives all components of a multimedia message.  This is so even if 
+   the recipient cannot render all body parts.  In most cases, the 
+   recipient can either find the appropriate rendering tool or tell the 
+   sender that she cannot read the particular attachment. 
+    
+   This is an important issue.  By definition, a MIME-enabled user 
+   agent, conforming to [11], will present or make available all of the 
+   body parts to the recipient.  However, a voice mail system may not 
+   be capable of storing non-voice objects.  Moreover, the voice mail 
+   system may not be capable of notifying the recipient that there were 
+   undeliverable message parts. 
+    
+   The inability of the receiving system to render a body part is 
+   usually a permanent failure.  Retransmission of the message will not 
+   improve the likelihood of a future successful delivery.  Contrast 
+   this with the case with normal data delivery.  Traditional message 
+  
+Burger                     Expires 9/30/01                   [Page 7] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+   failures, such as a garbled message or disabled link will benefit 
+   from retransmission. 
+    
+   This situation is fundamentally different from normal Internet mail.  
+   In the Internet mail case, either the system delivered the message, 
+   or it didn't.  There is no concept of a system partially delivering 
+   a message. 
+ 
+   In addition, there are many situations where the sender would not 
+   mind if the system did not deliver non-critical parts of a message.  
+   For example, the sender's user agent may add body parts to a message 
+   unbeknownst to the sender.  If the receiving system rejected the 
+   message because it could not render a hidden body part, the sender 
+   would be understandably confused and upset. 
+    
+   Thus, there is a need for a method of indicating to a Mail Transfer 
+   Agent (MTA) or User Agent (UA) that the sender considers parts of a 
+   message to be critical.  From the sender's perspective, he would not 
+   consider the message delivered if the system did not deliver the 
+   critical parts. 
+    
+8.2. Current Approaches 
+    
+   One method of indicating critical content of a message is to define 
+   a profile.  The profile defines rules for silently deleting mail 
+   body parts based on knowledge of the UA capabilities.  Citing the 
+   example above, a voice profile can easily declare that MTAs or UAs 
+   can silently delete TNEF data and yet consider the message 
+   successfully delivered.  This is, in fact, the approach taken by 
+   VPIMv2 [12]. 
+    
+   Since one aspect of the issue is deciding when to notify the sender 
+   that the system cannot deliver part of a message, one could use a 
+   partial non-delivery notification mechanism to indicate a problem 
+   with delivering a given body part.  However, this requires the user 
+   request a delivery notification.  In addition, the sender may not be 
+   aware of parts added by the sending user agent.  In this case, a 
+   failure notice would mystify the sender. 
+    
+   A straightforward alternative implementation method for marking a 
+   body part critical is to use a Critical-Content MIME entity.  This 
+   has the benefit that criticality is meta information for the body 
+   part.  However, IMAP servers in particular would need to either put 
+   Critical-Content into the BODYSTRUCTURE method or create a new 
+   method to retrieve arbitrary MIME entities.  Given the experience of 
+   trying to get Content-Location accepted by IMAP vendors, we chose 
+   not to go that route. 
+    
+   What we need is a way of letting the sender indicate what body-parts 
+   he considers to be critical.  The mechanism must not burden the 
+   sender with failure notifications for non-critical body parts.  The 
+   mechanism must conform to the general notification status request 
+  
+Burger                     Expires 9/30/01                   [Page 8] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+   mechanism for positive or negative notification.  When requested, 
+   the mechanism must indicate to the sender when a receiving system 
+   cannot deliver a critical body part. 
+    
+    
+8.3. Criticality Parameter 
+    
+   The criticality marking mechanism satisfies these needs.  This 
+   document introduces the CRITICALITY parameter to Content-
+   Disposition.  Values for this parameter are CRITICAL or IGNORE. 
+    
+    
+9. The Content Gateway 
+    
+   In this section, we use the definition of [13] for the term 
+   "gateway." 
+    
+   A content gateway is a gateway that connects a first network to a 
+   second network.  The second network often has lesser capability than 
+   the first network.  The canonical topology follows.  The "[MTA]" 
+   signifies an optional component. 
+    
+                             +---------+ 
+   +---------+     +-----+   |         |     +-------+   +-----------+ 
+   | Sending |=...=|[MTA]|===| Content |=...=| [MTA] |===| Receiving | 
+   |   UA    |     +-----+   | Gateway |     +-------+   |    UA     | 
+   +---------+               |         |                 +-----------+ 
+                             +---------+ 
+          First Network                         Second Network 
+    
+    
+   The content gateway can be the last hop before the receiving MTA.  
+   The content gateway can be between networks, and thus not the last 
+   hop before the receiving MTA.  The content gateway can be the first 
+   MTA the sending UA contacts.  Finally, the content gateway can be an 
+   integrated component of the receiving MTA. 
+    
+    
+9.1. Integrated Content Gateway 
+    
+   In this situation, the receiving user agent is integrated with the 
+   content gateway. The integrated content gateway knows the 
+   capabilities of the user agent.  The topology is as follows. 
+    
+                             +---------------------+ 
+   +---------+     +-----+   |         :           | 
+   | Sending |=...=|[MTA]|===| Content : Receiving | 
+   |   UA    |     +-----+   | Gateway :    UA     | 
+   +---------+               |         :           | 
+                             +---------------------+ 
+          First Network           Second Network 
+    
+  
+Burger                     Expires 9/30/01                   [Page 9] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+    
+9.2. Disaggregated Delivery Network 
+    
+   A degenerate case, although one that does occur, is where the 
+   content gateway sits behind the final MTA.  This happens when one 
+   implements the content gateway as a post-processing step to a normal 
+   delivery.  For example, one could configure a mail handling system 
+   to deliver the message to a queue or directory, where the content 
+   gateway process picks up the message.  If there were any directives 
+   for DSN processing, the delivering MTA would execute them.  For 
+   example, the message could have requested notification on successful 
+   delivery.  The delivering MTA, having delivered the message to the 
+   queue, would consider the message delivered and thus notify the 
+   sender of such.  However, the content gateway process could then 
+   discover that the receiving UA cannot render the message.  In this 
+   case, the content gateway generates a NDN, as it is the only option 
+   available. 
+    
+                           Delivered 
+                               |      +---------+ 
+   +---------+     +-----+     v      |         |     +-----------+ 
+   | Sending |=...=| MTA |--> File -->| Content |=...=| Receiving | 
+   |   UA    |     +-----+            | Gateway |     |    UA     | 
+   +---------+                        |         |     +-----------+ 
+                                      +---------+ 
+          First Network              Second Network 
+    
+    
+    
+10. Backward Compatibility Considerations 
+    
+   DSN requires ESMTP.  If MTAs in the path from the sending UA to the 
+   receiving UA do not support ESMTP, then that MTA will reject the DSN 
+   request.  In addition, the message will default to notification on 
+   delay or failure.  While not ideal, the sender will know that DSN is 
+   not available, and that critical content that fails will get 
+   notification. 
+    
+ 
+11. MIME Interactions 
+    
+11.1. multipart/alternative 
+    
+   As is true for all Content-Disposition parameters, criticality is 
+   only in effect for the selected alternative.  If the selected 
+   alternative has the critical content indicator, then the entire 
+   alternative takes on the criticality indicated.  That is, if the 
+   alternative selected has CRITICALITY=IGNORE, then the content 
+   gateway MUST NOT generate any delivery notifications. 
+    
+   NOTE: This statement explicitly shows that CRITICALITY overrides the 
+   DSN and MDN request mechanisms. 
+  
+Burger                     Expires 9/30/01                  [Page 10] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+    
+   It is unlikely for a selected alternative to fail, as the content 
+   gateway presumably picks the alternative specifically because it can 
+   render it.  
+    
+   If the selected alternative is a message/rfc822 that encloses a 
+   multipart MIME message or the selected alternative is itself a 
+   multipart MIME type, the individual top-level body parts follow the 
+   CRITICALITY mechanism described in this document. 
+    
+11.2. multipart/related 
+    
+   Criticality fits in rather well with the multipart/related 
+   construction.  For example, consider a multipart/related message 
+   consisting of a Macintosh data fork and a Macintosh resource fork.  
+   For a Microsoft Word document, the data fork is likely to be 
+   critical.  The receiving system can safely ignore the resource fork. 
+    
+11.3. message/rfc822 
+    
+   Criticality only affects the outermost level of the message or, in 
+   the case of multipart/alternative, the outermost level of the 
+   selected alternative.  Specifically, the receiving system ignores 
+   criticality indicators in embedded body parts.  This avoids the 
+   situation of a forwarded message triggering or suppressing undesired 
+   reporting.  This simply implements the procedures described in [3]. 
+    
+    
+12. Implementation Examples 
+    
+   This section is not a normative part of the definition of 
+   Criticality.  However, we hope it helps implementers to understand 
+   the mechanics of the Criticality mechanism. 
+    
+   We will examine two cases.  They are how a content gateway processes 
+   a message and how a disaggregated content gateway processes a 
+   message. 
+    
+12.1. Content Gateways 
+    
+   Content gateways examine the contents of a message from a first 
+   network before the gateway forwards the message to a second network.  
+   For the purposes of this example, we assume the second network has 
+   less capability than the first network.  In particular, we expect 
+   there will be certain message body types that the gateway cannot 
+   pass onto the second network. 
+    
+   Consider a gateway between the Internet and a text-only short 
+   message service.  A message comes through the gateway containing a 
+   text part and a tnef part.  The sender marks the text part CRITICAL.  
+   The gateway, knowing the capability of the short message service, 
+   silently deletes the non-critical, tnef part, passing the critical 
+  
+Burger                     Expires 9/30/01                  [Page 11] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+   content to the short message service network.  Any subsequent 
+   notifications, such as failure notices or delivery notices, follow 
+   the normal rules for notification. 
+    
+   Note the gateway, by silently deleting non-critical content, may 
+   affect proprietary message correlation schemes.  One can envision 
+   the sending UA inserting a body part for tracking purposes.  By 
+   deleting non-critical content, the content gateway will break such a 
+   scheme.  If a sending UA understands how to mark critical content, 
+   it should use Internet standard mechanisms for tracking messages, 
+   such as Message-ID [14]. 
+    
+   What if no body parts have critical content indicators?  In this 
+   case, the entire message is critical.  Thus, when the gateway sees 
+   the tnef part, it will reject the entire message, generating a DSN 
+   with a status code 5.6.1, "Media not supported". 
+    
+   Likewise, consider a three part message with a text annotation (part 
+   1) to a voice message (part 2) with a vCard [15] (part 3).  The 
+   sender marks the first two parts CRITICAL.  Now, let us assume the 
+   receiving MTA (gateway) is a voice mail only system, without even 
+   the capability to store text.  In this case, the gateway, acting as 
+   the receiving MTA, will reject the message, generating a DSN with 
+   the status code 5.6.1, "Media not supported". 
+ 
+12.2. Disaggregated Content Gateway 
+    
+   For this example, we will examine the processing of a three-part 
+   message.  The first part is a text annotation of the second part, an 
+   audio message.  The third part is the sender's vCard.  The sender 
+   marks the first and second parts CRITICAL.  In addition, the sender 
+   marks the message for read receipt. 
+    
+   For the purposes of example, the telephone user interface (TUI) does 
+   not perform text-to-speech conversion.  A TUI is a mail user agent 
+   (UA) that uses DTMF touch-tone digits for input and audio for output 
+   (display). 
+    
+   The TUI is unable to render the first part of the message, the text 
+   part.  In addition, it is unable to render the third part of the 
+   message, the vCard part.  Since the sender did not mark the third 
+   part of the message CRITICAL, the system ignores the failure of the 
+   TUI to render the third part of the message.  However, since the 
+   sender did mark the first part CRITICAL, and the TUI is unable to 
+   render text, the message fails. 
+    
+   What happens next is implementation dependent.  If the TUI is part 
+   of a unified messaging system, a reasonable action is to hold the 
+   message for the user.  The user can access the message at a later 
+   time from a terminal that can render all of the critical body parts.  
+   It would be reasonable for the TUI to notify the user about the 
+   undeliverable body part. 
+  
+Burger                     Expires 9/30/01                  [Page 12] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+    
+   If the TUI is part of a voice messaging system, or if the user does 
+   not subscribe to a text-to-speech service, a reasonable action is 
+   for the TUI to return a MDN with the disposition "failed" and the 
+   failure modifier "5.6.1 (Media not supported)". 
+    
+    
+13. Security Considerations 
+ 
+   Receiving systems and users should not place any authentication 
+   value on the Content-Criticality entity.  Just because a message has 
+   a particular Content-Criticality value doesn't mean that the message 
+   really originated at a given type of system. 
+    
+    
+14. IANA Considerations 
+    
+   Per section 9 of [3], here is the IANA registration for Criticality. 
+    
+   To: IANA@IANA.ORG 
+   Subject: Registration of new Content-Disposition parameter 
+    
+   Content-Disposition parameter name: 
+   CRITICALITY 
+    
+   Allowable values for this parameter: 
+   IGNORE 
+   CRITICAL 
+    
+   Description: 
+   Marks the body part as required for delivery (CRITICAL) or can be 
+   silently discarded (IGNORE).  See RFC <this document>. 
+   Per RFC 2183, the Content-Disposition parameter name is not case 
+   sensitive.  Per RFC <this document>, the values of the parameter are 
+   also not case sensitive. 
+    
+    
+    
+15. References 
+    
+ 
+   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
+      9, RFC 2026, October 1996. 
+    
+   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
+      Levels", BCP 14, RFC 2119, March 1997. 
+    
+   3  Troost, R., Dorner, S., Moore, K. (ed), "Communicating 
+      Presentation Information in Internet Messages: The Content-
+      Disposition Header Field", RFC 2183, New Century Systems, 
+      QUALCOMM, and U. Tennessee, August 1997. 
+ 
+  
+Burger                     Expires 9/30/01                  [Page 13] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+ 
+    
+   4  Moore, K., "SMTP Service Extension for Delivery Status 
+      Notifications", RFC 1981, University of Tennessee, January 1996. 
+    
+   5 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 
+      Specifications: ABNF", RFC 2234, Internet Mail Consortium and 
+      Demon Internet Ltd., November 1997. 
+    
+   6  Moore, K., "SMTP Service Extension for Delivery Status 
+      Notifications", RFC 1981, University of Tennessee, January 1996. 
+    
+   7  Moore, K. and Vaudreuil, G., "An Extensible Message Format for 
+      Delivery Status Notifications", RFC 1894, University of Tennessee 
+      and Octel Network Services, January 1996. 
+     
+   8  Fajman, R., "An Extensible Message Format for Message Disposition 
+      Notifications", RFC 2298, National Institutes of Health, March 
+      1998. 
+    
+   9  Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, 
+      Octel Network Services, January 1996. 
+    
+   10  Freed, N. and Borenstein, N., "Multipurpose Internet Mail 
+      Extensions (MIME) Part One: Format of Internet Message Bodies", 
+      RFC 2045, Innosoft and First Virtual, November 1996. 
+    
+   11  Freed, N. and Borenstein, N., "Multipurpose Internet Mail 
+      Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft and 
+      First Virtual, November 1996. 
+    
+   12  Vaudreuil, G. and Parsons, G., "Voice Profile for Internet Mail 
+      - version 2", RFC 2421, Lucent Technologies and Nortel Networks, 
+      September 1998. 
+    
+   13 Kille, S. "MIXER (Mime Internet X.400 Enhanced Relay): Mapping 
+      between X.400 and RFC 822/MIME", RFC 2156, Isode, January 1998. 
+    
+   14 Crocker, D., "Standard for the Format of ARPA Internet Text 
+      Messages", RFC 822, University of Delaware, August 1982. 
+    
+   15 Dawson, F. and Howes, T., "vCard MIME Directory Profile", RFC 
+      2426, Lotus Development Corporation and Netscape Communications, 
+      September 1998. 
+    
+   16 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 
+      Specifications: ABNF", RFC 2234, Internet Mail Consortium and 
+      Demon Internet Ltd., November 1997. 
+    
+    
+    
+    
+  
+Burger                     Expires 9/30/01                  [Page 14] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+16. Acknowledgments 
+    
+   Emily Candell of Comverse Network Systems was instrumental in 
+   helping work out the base issues in the û00 draft in Adelaide. 
+    
+   Ned Freed pointed out that this mechanism was about criticality, not 
+   notification.  That insight made the concept and descriptions 
+   infinitely more straightforward.  If it's still confusing, it's my 
+   fault! 
+    
+   Keith Moore for helped tighten-up the explanations, and he approved 
+   of the use of Content-Disposition. 
+    
+   Dropping the IMPORTANT critical content type took away one of the 
+   reasons for partial non-delivery notification.  That makes Jutta 
+   Degener very happy! 
+    
+   Harald Alvestrand and Chris Newman suggested some implementation 
+   examples. 
+    
+   Greg White asked THE key question that let us realize that critical 
+   content processing was a gateway function, and not a MTA or UA 
+   function. 
+    
+   Any errors, omissions, or silliness are my fault. 
+    
+    
+17. Author's Address 
+    
+   Eric Burger 
+   SnowShore Networks, Inc. 
+   285 Billerica Rd. 
+   Chelmsford, MA  01824-4120 
+   USA 
+    
+   Phone: +1 978 367 8403 
+   Fax:   +1 603 457 5944 
+   Email: e.burger@ieee.org 
+    
+    
+    
+    
+  
+Burger                     Expires 9/30/01                  [Page 15] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+Full Copyright Statement 
+ 
+   The IETF takes no position regarding the validity or scope of any 
+   intellectual property or other rights that might be claimed to  
+   pertain to the implementation or use of the technology described in 
+   this document or the extent to which any license under such rights 
+   might or might not be available; neither does it represent that it 
+   has made any effort to identify any such rights.  Information on the 
+   IETF's procedures with respect to rights in standards-track and 
+   standards-related documentation can be found in BCP-11.  Copies of 
+   claims of rights made available for publication and any assurances 
+   of licenses to be made available, or the result of an attempt made 
+   to obtain a general license or permission for the use of such 
+   proprietary rights by implementers or users of this specification 
+   can be obtained from the IETF Secretariat. 
+    
+   The IETF invites any interested party to bring to its attention any 
+   copyrights, patents or patent applications, or other proprietary 
+   rights that may cover technology that may be required to practice 
+   this standard.  Please address the information to the IETF Executive 
+   Director. 
+    
+   Copyright (C) 2000, 2001 The Internet Society.  All Rights Reserved. 
+    
+   This document and translations of it may be copied and furnished to 
+   others, and derivative works that comment on or otherwise explain it 
+   or assist in its implementation may be prepared, copied, published 
+   and distributed, in whole or in part, without restriction of any 
+   kind, provided that the above copyright notice and this paragraph 
+   are included on all such copies and derivative works.  However, this 
+   document itself may not be modified in any way, such as by removing 
+   the copyright notice or references to the Internet Society or other 
+   Internet organizations, except as needed for the  purpose of 
+   developing Internet standards in which case the procedures for 
+   copyrights defined in the Internet Standards process must be 
+   followed, or as required to translate it into languages other than 
+   English. 
+    
+   The limited permissions granted above are perpetual and will not be 
+   revoked by the Internet Society or its successors or assigns. 
+    
+   This document and the information contained herein is provided on an 
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
+  
+Burger                     Expires 9/30/01                  [Page 16] 
+ 
+
diff --git a/doc/devel/I-D/draft-burger-vpim-cc-00.txt b/doc/devel/I-D/draft-burger-vpim-cc-00.txt
new file mode 100644
index 00000000..d7480692
--- /dev/null
+++ b/doc/devel/I-D/draft-burger-vpim-cc-00.txt
@@ -0,0 +1,543 @@
+
+
+Network Working Group                                           E. Burger
+Internet Draft                                   Centigram Communications
+Document: draft-burger-vpim-cc-00.txt                          E. Candell
+Category: Standards Track                        Comverse Network Systems
+Expires in six Months                                        June 6, 2000
+
+
+                   Critical Content of Internet Mail
+
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026 [1].
+
+   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."
+
+   One can access the list of current Internet-Drafts at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+
+   One can access the list of Internet-Draft Shadow Directories at
+   http://www.ietf.org/shadow.html.
+
+
+
+1.
+  Abstract
+
+   This document describes a mechanism for identifying the critical
+   content body parts of a multi-part Internet mail message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                           Expires 12/6/00                    [Page 1]
+
+                  Critical Content of Internet Mail          June 2000
+
+
+
+Table of Contents
+
+1.ABSTRACT ...........................................................1
+2.CONVENTIONS USED IN THIS DOCUMENT ..................................2
+3.INTRODUCTION .......................................................2
+
+4.CONTENT-NOTIFICATION ENTITY ........................................5
+4.1. NOTIFY ..........................................................5
+4.2. PARTIAL .........................................................5
+4.3. IGNORE ..........................................................6
+4.4. Other Values ....................................................6
+4.5. Notification Precedence .........................................6
+5.BACKWARD COMPATIBILITY CONSIDERATIONS ..............................6
+6.SECURITY CONSIDERATIONS ............................................7
+
+7.COLLECTED SYNTAX ...................................................7
+8.REFERENCES .........................................................7
+9.ACKNOWLEDGMENTS ....................................................8
+10. AUTHOR'S ADDRESSES ...............................................8
+
+
+2.
+  Conventions used in this document
+
+   This document refers generically to the sender of a message in the
+   masculine (he/him/his) and the recipient of the message in the
+   feminine (she/her/hers).  This convention is purely for convenience
+   and makes no assumption about the gender of a message sender or
+   recipient.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
+   this document are to be interpreted as described in RFC-2119 [2].
+
+   FORMATTING NOTE: Notes, such at this one, provide additional
+   nonessential information that the reader may skip without missing
+   anything essential.  The primary purpose of these non-essential
+   notes is to convey information about the rationale of this document,
+   or to place this document in the proper historical or evolutionary
+   context.  Readers whose sole purpose is to construct a conformant
+   implementation may skip such information.  However, it may be of use
+   to those who wish to understand why we made certain design choices.
+
+
+3.
+  Introduction
+
+   This document describes the Critical Content identification for
+   multi-part Internet mail.
+
+   The need for a critical content identification mechanism comes about
+   because of the internetworking of Internet mail systems with legacy
+   messaging systems that do not fulfil all of the semantics of
+   Internet mail.  Such legacy systems have a limited ability to render
+
+Burger and Candell         Expires 12/6/00                    [Page 2]
+
+                  Critical Content of Internet Mail          June 2000
+
+
+
+   all parts of a given message.  This document will use the case of an
+   Internet mail system exchanging electronic messages with a legacy
+   voice messaging system for illustrative purposes.
+
+   Electronic mail has historically been text-centric.  Extensions such
+   as MIME [3] enable the desktop to send and receive multi-part,
+   multimedia messages.  Popular multimedia data types include binary
+   word processing documents, binary business presentation graphics,
+   voice, and video.
+
+   Voice mail has historically been audio-centric.  Many voice
+   messaging systems only render voice.  Extensions such as fax enable
+   the voice mail system to send and receive fax images as well as
+   create multi-part voice and fax messages.  A few voice mail systems
+   can render text using text-to-speech or text-to-fax technology.
+   Although theoretically possible, none can today render video.
+
+   An important aspect of the interchange between voice messaging
+   services and desktop e-mail client applications is that the
+   rendering capability of the voice messaging platform is often much
+   less than the rendering capability of a desktop e-mail client.  In
+   the e-mail case, the sender has the expectation that the recipient
+   receives all components of a multimedia message.  This is so even if
+   the recipient cannot render all body parts.  In most cases, the
+   recipient can either find the appropriate rendering tool or tell the
+   sender that she cannot read the particular attachment.
+
+   This is an important issue.  By definition, a MIME-enabled user
+   agent, conforming to [4] will present or make available all of the
+   body parts to the recipient.  However, a voice mail system may not
+   be capable of storing non-voice objects.  Moreover, the voice mail
+   system may not be capable of notifying the recipient that there were
+   undeliverable message parts.
+
+   The inability of the receiving system to render a body part is
+   usually a permanent failure.  Retransmission of the message will not
+   improve the likelihood of a future successful delivery.  Contrast
+   this to the case with normal data delivery.  Traditional message
+   failures, such as a garbled message or disabled link will benefit
+   from retransmission.
+
+   This situation is fundamentally different from normal Internet mail.
+   In the Internet mail case, either the system delivered the message,
+   or it didn't.  There is no concept of a system partially delivering
+   a message.
+
+   In addition, the sender would not mind if the system did not deliver
+   non-critical parts of a message.  In fact, the sender's user agent
+   may be silently adding body parts to a message unbeknownst to the
+   sender.  For example, take Microsoft Outlook as a user agent.
+   Outlook often will attach a TNEF section or other body parts. If the
+
+
+Burger and Candell         Expires 12/6/00                    [Page 3]
+
+                  Critical Content of Internet Mail          June 2000
+
+
+
+   receiving system rejected the message because it could not render
+   TNEF, the sender would be understandably confused and upset.
+
+   Thus, there is a need for a method of indicating to a Mail Transfer
+   Agent (MTA) or User Agent (UA) that the sender considers parts of a
+   message to be critical.  From the sender's perspective, he would not
+   consider the message delivered if the system did not deliver the
+   critical parts.
+
+   One method of indicating critical content of a message is to define
+   a profile.  The profile defines discard rules based on knowledge of
+   the user population for silently deleting body parts.  Citing the
+   example above, a voice profile can easily declare that MTAs or UAs
+   can silently delete TNEF data and yet consider the message
+   successfully delivered.  This is, in fact, the approach originally
+   proposed for VPIMv3 [5].
+
+   Since one aspect of the issue is deciding when to notify the sender
+   that the system cannot deliver part of a message, one could use a
+   partial non-delivery notification mechanism [6] to indicate a
+   problem with delivering a given body part.  However, this requires
+   the user request a MDN.  Moreover, the sender will receive PNDN
+   failures for objects the sender may not be aware he is sending.  An
+   example would be the TNEF part.
+
+   Summarizing the needs, we need a mechanism that will let the sender
+   or sender's UA mark body parts he considers critical to the message
+   that the system must deliver.  The mechanism MUST NOT burden the
+   sender with failure notifications for non-critical body parts.  The
+   mechanism MUST conform to the general notification status request
+   mechanism for positive or negative notification.  When requested,
+   the mechanism MUST indicate to the sender when a receiving system
+   cannot deliver a critical body part.
+
+   In short, we need a method of indicating what sort of delivery
+   notification the sender requires on a per-body part basis.
+
+   This document describes a Critical Content marking mechanism that
+   satisfies these needs.  Following the format for Internet message
+   bodies [3], this document introduces the Content-Notification body
+   part header.  Values for this header are NOTIFY, PARTIAL, or IGNORE.
+   The receiving MTA or UA will generate a DSN or PNDN if it receives a
+   request for notification and the (non-)delivery status of the parts
+   marked NOTIFY meet the criteria for notification.  Likewise, the
+   receiving UA will generate a MDN or MNDN if it receives a request
+   for notification and the (non-)delivery status of the parts marked
+   NOTIFY meet the criteria for notification.
+
+   <<<EDITOR'S NOTE: We don't have an ID for MNDN yet, but it will look
+   like PNDN.  Stay tuned.>>>
+
+
+
+Burger and Candell         Expires 12/6/00                    [Page 4]
+
+                  Critical Content of Internet Mail          June 2000
+
+
+
+
+4.
+  Content-Notification Entity
+
+   The Content-Notification field is a MIME body part header inserted
+   by the sending UA to indicate to the receiving MTA or UA whether to
+   consider this body part when generating a (non-)delivery message.
+   If the value of the field is IGNORE, the receiving MTA or UA MUST
+   NOT generate a notification.  If the value of the field is NOTIFY,
+   the receiving MTA or UA MUST generate a notification, based on the
+   normal notification request mechanisms.  Normal notification request
+   mechanisms include the SMTP RCPT NOTIFY command [7] and the
+   Disposition-Notification-To header [8].
+
+   The terms "entity" and "body part" have the meanings defined in [3].
+
+   The next sections examine the actions taken by an MTA or UA given
+   the different values of Content-Notification.
+
+   NOTE: This implies that the MTA must examine the entire message on
+   receipt to determine whether it needs to generate a notification.
+   However, the MTA need not examine the message if it knows it can
+   store and forward all media types.  Said differently, an Internet e-
+   mail MTA can, by default, handle any arbitrary MIME-encapsulated
+   type.  Some voice mail systems, on the other hand, cannot even store
+   binary attachments, such as application/ms-word.  The voice mail
+   MTA, in this example, would be scanning for non-renderable body
+   parts anyway.
+
+  4.1. NOTIFY
+
+   "Content-Notification: NOTIFY" signifies that this body part is
+   critical to the sender.  The sender wishes to receive notification
+   reports for this body part.
+
+   If the receiving system cannot render or store a body part marked
+   NOTIFY, then the entire message has failed.  In this case, the
+   receiving system MUST take the appropriate failure action.
+
+   NOTE: We say "appropriate action", because the sender may have
+   suppressed all notifications.  In this case, the appropriate action
+   is to simply discard the message.
+
+  4.2. PARTIAL
+
+   "Content-Notification: PARTIAL" signifies that the sender wishes to
+   receive notification reports for this body part.
+
+   If the receiving system cannot render or store a body part marked
+   PARTIAL, the receiving system MUST take the appropriate failure
+   action.  It is important to note that if the system is successful in
+   delivering other critical body parts, then the message delivery is
+
+
+Burger and Candell         Expires 12/6/00                    [Page 5]
+
+                  Critical Content of Internet Mail          June 2000
+
+
+
+   successful.  In this situation, the receiving system MUST return a
+   partial non-delivery notification [6].
+
+  4.3. IGNORE
+
+   "Content-Notification: IGNORE" signifies that the sender does not
+   care about notification reports for this body part.
+
+   If the receiving system cannot render or store a body part marked
+   IGNORE, the receiving system may silently delete the body part.  The
+   receiving system MUST NOT return a delivery failure, unless parts
+   marked PARTIAL or NOTIFY have also failed.
+
+  4.4. Other Values
+
+   The receiving system MUST treat unrecognized values as PARTIAL.
+   This is to provide backward compatibility with future uses of the
+   Content-Notification entity.
+
+   <<<ALTERNATIVES:
+
+   IGNORE: If I don't recognize something, ignore it!
+
+   NOTIFY: Future values are more likely to involve some sort of
+   notification, rather than non-notification.  However, if the
+   notifications are more sophisticated than NOTIFY, senders may be
+   miffed they didn't get the processing they expected.
+
+   Reject the Message: This would be too extreme!  Yes, it would weed
+   out non-conformant sending UAs, but this would really piss off
+   users.
+
+
+   So far, we have one vote for IGNORE, as that would be compatible
+   with VPIMv2.
+   We have one vote for PARTIAL, as that would provide forward-
+   compatibility with future uses of Content-Notification.
+   We expect this to be a point of discussion on the list.
+
+   End of ALTERNATIVES>>>
+
+  4.5. Notification Precedence
+
+   <<<We'll fill-in this in the next draft.>>>
+
+
+5.
+  Backward Compatibility Considerations
+
+   If there are no Content-Notification entities in the message, the
+   default value for Content-Notification is NOTIFY.  The standard
+   notification mechanisms work for sending user agents (UA) that do
+
+
+Burger and Candell         Expires 12/6/00                    [Page 6]
+
+                  Critical Content of Internet Mail          June 2000
+
+
+
+   not know about the content notification entity.  All body parts are
+   critical, because they have the default marking of NOTIFY.
+
+   If there is at least one Content-Notification entity in the message,
+   the default value for unspecified body parts is IGNORE.  The
+   philosophy is that UAs, especially manually constructed messages,
+   will explicitly mark the critical body parts.
+
+   NOTE: We could choose the default value for Content-Notification to
+   be IGNORE.  This would make VPIMv2 automatically compliant with this
+   document, as VPIMv2 has provision to silently delete undeliverable
+   parts.  However, VPIMv2 systems should not be receiving arbitrary e-
+   mail from the Internet.  If they do, they should be compliant with
+   this series of documents.  By defaulting to NOTIFY, this draft is
+   compliant with the rest of the Internet infrastructure.
+
+
+
+6.
+  Security Considerations
+
+   We anticipate no new security issues beyond those already addressed
+   by the notification RFCs.
+
+
+7.
+  Collected Syntax
+
+   The format of the collected syntax is in accordance with the ABNF of
+   [9].  Note that per RFC 2045, none of the strings are case
+   sensitive.
+
+
+        "Content-Notification" ":" notification-type CRLF
+
+        notification-type = "NOTIFY" / "PARTIAL" / "IGNORE"
+
+
+
+8.
+  References
+
+
+   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+      9, RFC 2026, October 1996.
+
+   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+      Levels", BCP 14, RFC 2119, March 1997.
+
+   3  Freed, N. and Borenstein, N., "Multipurpose Internet Mail
+      Extensions (MIME) Part One: Format of Internet Message Bodies",
+      RFC 2045, Innosoft and First Virtual, November 1996.
+
+
+
+
+Burger and Candell         Expires 12/6/00                    [Page 7]
+
+                  Critical Content of Internet Mail          June 2000
+
+
+
+
+   4  Freed, N. and Borenstein, N., "Multipurpose Internet Mail
+      Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft and
+      First Virtual, November 1996.
+
+   5  Vaudreuil, G. and Parsons, G., "Voice Profile for Internet Mail -
+      version 3", <draft-ema-vpimv3-00.txt>, Work in Progress, expired.
+
+   6  Burger, E., "Partial Non-Delivery Notification", Work in
+      Progress, draft-ema-burger-pndn-01.txt, March 2000.
+
+   7  Moore, K., "SMTP Service Extension for Delivery Status
+      Notifications", RFC 1981, University of Tennessee, January 1996.
+
+   8  Fajman, R., "An Extensible Message Format for Message Disposition
+      Notifications", RFC 2298, National Institutes of Health, March
+      1998.
+
+   9  Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
+      Specifications: ABNF", RFC 2234, Internet Mail Consortium and
+      Demon Internet Ltd., November 1997.
+
+
+
+
+9.
+  Acknowledgments
+
+   Coming soon!
+
+
+10.
+   Author's Addresses
+
+   Eric Burger
+   Centigram Communications Corporation
+   Maryland Technology Center
+   1375 Piccard Dr., MS 150I
+   Rockville, MD  20850-4311
+   USA
+
+   Phone: +1 301/212-3320
+   Email: e.burger@ieee.org
+
+
+   Emily Candell
+   Comverse Network Systems
+   200 Quannapowitt Pkwy.
+   Wakefield, MA  01880
+   USA
+
+   Phone: +1 781/213-2324
+   Email: emily@comversens.com
+
+
+Burger and Candell         Expires 12/6/00                    [Page 8]
+
+                  Critical Content of Internet Mail          June 2000
+
+
+
+
+Full Copyright Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances
+   of licenses to be made available, or the result of an attempt made
+   to obtain a general license or permission for the use of such
+   proprietary rights by implementers or users of this specification
+   can be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+   Copyright (C) 2000 The Internet Society.  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph
+   are included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the  purpose of
+
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+Burger and Candell         Expires 12/6/00                    [Page 9]
+
+
+
diff --git a/doc/devel/I-D/draft-burger-vpim-cc-01.txt b/doc/devel/I-D/draft-burger-vpim-cc-01.txt
new file mode 100644
index 00000000..f7c638c3
--- /dev/null
+++ b/doc/devel/I-D/draft-burger-vpim-cc-01.txt
@@ -0,0 +1,10 @@
+

+This document has been replaced by draft-ietf-vpim-cc-00.txt.

+For more information or a copy of the document, contact the author directly.

+

+Draft Author(s):

+

+E. Burger: e.burger@ieee.org                                                       

+E. Candell: emily@comversens.com                                                    

+

+

diff --git a/doc/devel/I-D/draft-ietf-vpim-cc-00.txt b/doc/devel/I-D/draft-ietf-vpim-cc-00.txt
new file mode 100644
index 00000000..8a2d8438
--- /dev/null
+++ b/doc/devel/I-D/draft-ietf-vpim-cc-00.txt
@@ -0,0 +1,628 @@
+
+
+Network Working Group                                           E. Burger
+Internet Draft                                   Centigram Communications
+Document: draft-ietf-vpim-cc-00.txt                            E. Candell
+Obsoletes: draft-burger-vpim-cc-00.txt           Comverse Network Systems
+Category: Standards Track                                   July 14, 2000
+Expires in six Months
+
+
+                   Critical Content of Internet Mail
+
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026 [1].
+
+   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."
+
+   One can access the list of current Internet-Drafts at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+
+   One can access the list of Internet-Draft Shadow Directories at
+   http://www.ietf.org/shadow.html.
+
+
+
+1.   Abstract
+
+   This document describes a mechanism for identifying the body parts
+   that the sender deems critical in a multi-part Internet mail
+   message.
+
+   By knowing what parts of a message the sender deems critical, a MTA
+   or UA can intelligently handle multi-part messages.  Applications of
+   critical content include, but are not limited to, the following
+   applications.  Critical content can help a smart gateway decide what
+   parts to forward.  It can indicate how hard a gateway should try to
+   deliver a body part.  It can help an MTA to select body parts to
+   silently delete when a system of lesser capability receives a
+   message.  In addition, critical content can help indicate the
+   notification strategy of the receiving system.
+
+
+
+
+
+
+                           Expires 1/14/01                    [Page 1]
+                  Critical Content of Internet Mail          July 2000
+
+
+Table of Contents
+
+1.  ABSTRACT .........................................................1
+2.  CONVENTIONS USED IN THIS DOCUMENT ................................2
+3.  INTRODUCTION .....................................................2
+
+4.  CONTENT-CRITICALITY ENTITY .......................................5
+4.1.  CRITICAL .......................................................6
+4.2.  IMPORTANT ......................................................6
+4.3.  IGNORE .........................................................6
+4.4.  Other Values ...................................................7
+4.5.  Criticality Precedence .........................................7
+4.6.  Summary ........................................................7
+5.  BACKWARD COMPATIBILITY CONSIDERATIONS ............................8
+
+6.  SECURITY CONSIDERATIONS ..........................................9
+7.  COLLECTED SYNTAX .................................................9
+8.  REFERENCES .......................................................9
+9.  ACKNOWLEDGMENTS .................................................10
+10. AUTHOR'S ADDRESSES ..............................................10
+
+
+2.   Conventions used in this document
+
+   This document refers generically to the sender of a message in the
+   masculine (he/him/his) and the recipient of the message in the
+   feminine (she/her/hers).  This convention is purely for convenience
+   and makes no assumption about the gender of a message sender or
+   recipient.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
+   this document are to be interpreted as described in RFC-2119 [2].
+
+   FORMATTING NOTE: Notes, such at this one, provide additional
+   nonessential information that the reader may skip without missing
+   anything essential.  The primary purpose of these non-essential
+   notes is to convey information about the rationale of this document,
+   or to place this document in the proper historical or evolutionary
+   context.  Readers whose sole purpose is to construct a conformant
+   implementation may skip such information.  However, it may be of use
+   to those who wish to understand why we made certain design choices.
+
+
+3.   Introduction
+
+   This document describes the Critical Content identification for
+   multi-part Internet mail.
+
+   The need for a critical content identification mechanism comes about
+   because of the internetworking of Internet mail systems with legacy
+
+
+Burger and Candell         Expires 1/14/01                    [Page 2]
+                  Critical Content of Internet Mail          July 2000
+
+
+   messaging systems that do not fulfil all of the semantics of
+   Internet mail.  Such legacy systems have a limited ability to render
+   all parts of a given message.  This document will use the case of an
+   Internet mail system exchanging electronic messages with a legacy
+   voice messaging system for illustrative purposes.
+
+   Electronic mail has historically been text-centric.  Extensions such
+   as MIME [3] enable the desktop to send and receive multi-part,
+   multimedia messages.  Popular multimedia data types include binary
+   word processing documents, binary business presentation graphics,
+   voice, and video.
+
+   Voice mail has historically been audio-centric.  Many voice
+   messaging systems only render voice.  Extensions such as fax enable
+   the voice mail system to send and receive fax images as well as
+   create multi-part voice and fax messages.  A few voice mail systems
+   can render text using text-to-speech or text-to-fax technology.
+   Although theoretically possible, none can today render video.
+
+   An important aspect of the interchange between voice messaging
+   services and desktop e-mail client applications is that the
+   rendering capability of the voice messaging platform is often much
+   less than the rendering capability of a desktop e-mail client.  In
+   the e-mail case, the sender has the expectation that the recipient
+   receives all components of a multimedia message.  This is so even if
+   the recipient cannot render all body parts.  In most cases, the
+   recipient can either find the appropriate rendering tool or tell the
+   sender that she cannot read the particular attachment.
+
+   This is an important issue.  By definition, a MIME-enabled user
+   agent, conforming to [4] will present or make available all of the
+   body parts to the recipient.  However, a voice mail system may not
+   be capable of storing non-voice objects.  Moreover, the voice mail
+   system may not be capable of notifying the recipient that there were
+   undeliverable message parts.
+
+   The inability of the receiving system to render a body part is
+   usually a permanent failure.  Retransmission of the message will not
+   improve the likelihood of a future successful delivery.  Contrast
+   this to the case with normal data delivery.  Traditional message
+   failures, such as a garbled message or disabled link will benefit
+   from retransmission.
+
+   This situation is fundamentally different from normal Internet mail.
+   In the Internet mail case, either the system delivered the message,
+   or it didn't.  There is no concept of a system partially delivering
+   a message.
+
+   In addition, the sender would not mind if the system did not deliver
+   non-critical parts of a message.  In fact, the sender's user agent
+   may be silently adding body parts to a message unbeknownst to the
+   sender.  For example, take Microsoft Outlook as a user agent.
+
+Burger and Candell         Expires 1/14/01                    [Page 3]
+                  Critical Content of Internet Mail          July 2000
+
+
+   Outlook often will attach a TNEF section or other body parts. If the
+   receiving system rejected the message because it could not render
+   TNEF, the sender would be understandably confused and upset.
+
+   Thus, there is a need for a method of indicating to a Mail Transfer
+   Agent (MTA) or User Agent (UA) that the sender considers parts of a
+   message to be critical.  From the sender's perspective, he would not
+   consider the message delivered if the system did not deliver the
+   critical parts.
+
+   One method of indicating critical content of a message is to define
+   a profile.  The profile defines discard rules based on knowledge of
+   the user population for silently deleting body parts.  Citing the
+   example above, a voice profile can easily declare that MTAs or UAs
+   can silently delete TNEF data and yet consider the message
+   successfully delivered.  This is, in fact, the approach originally
+   proposed for VPIMv3 [5].
+
+   Since one aspect of the issue is deciding when to notify the sender
+   that the system cannot deliver part of a message, one could use a
+   partial non-delivery notification mechanism [6] to indicate a
+   problem with delivering a given body part.  However, this requires
+   the user request a MDN.  Moreover, the sender will receive PNDN
+   failures for objects the sender may not be aware he is sending.  An
+   example would be the TNEF part.
+
+   Summarizing the needs, we need a mechanism that will let the sender
+   or sender's UA mark body parts he considers critical to the message
+   that the system must deliver.  The mechanism MUST NOT burden the
+   sender with failure notifications for non-critical body parts.  The
+   mechanism MUST conform to the general notification status request
+   mechanism for positive or negative notification.  When requested,
+   the mechanism MUST indicate to the sender when a receiving system
+   cannot deliver a critical body part.
+
+   In short, we need a method of letting the sender indicate what body-
+   parts he considers to be critical.
+
+   This document describes a Critical Content marking mechanism that
+   satisfies these needs.  Following the format for Internet message
+   bodies [3], this document introduces the Content-Criticality body
+   part header.  Values for this header are CRITICAL, NOTIFY, or
+   IGNORE.  The receiving MTA or UA will generate a DSN or PNDN at
+   delivery time if it receives a request for notification and the
+   (non-)delivery status of the parts marked NOTIFY meet the criteria
+   for notification.  Likewise, the receiving UA will generate a MDN or
+   PMDN at reading time if it receives a request for notification and
+   the (non-)delivery status of the parts marked CRITICAL meet the
+   criteria for notification.
+
+
+
+
+Burger and Candell         Expires 1/14/01                    [Page 4]
+                  Critical Content of Internet Mail          July 2000
+
+
+   NOTE: A straight-forward alternative implementation method for
+   marking a body part critical is to use a content-disposition
+   parameter called "criticality".
+
+   <<<EDITOR'S NOTE: Let's discuss the merits of content-disposition on
+   the list.  It's trivial to rework this ID; only the Entity changes.
+   That is, rather than having a 'Content-Criticality: Foo' part header
+   (entity), we have a 'content-disposition: ... ; criticality="Foo"'
+   parameter.  Everything else in the document stands (the parameter
+   names and actions).
+
+   I at first proposed content-disposition; Ned feels strongly about
+   it; Keith likes it.  Emily felt strongly that the indicator
+   shouldn't be content-disposition, but rather its own entity.  I
+   can't remember all the reasons, but they were enough for me to go
+   down the entity, rather than parameter path.
+
+   Comments?>>>
+
+   <<<EDITOR'S NOTE: We don't have an ID for PMDN yet, but it will look
+   like PNDN.  Stay tuned.>>>
+
+
+
+4.   Content-Criticality Entity
+
+   The Content-Criticality field is a MIME body part header inserted by
+   the sending UA to indicate to the receiving MTA or UA whether to
+   consider this body part critical.
+
+   A CRITICAL body part is one the sender requires the receiving system
+   to deliver for him to consider the message delivered.
+
+   An IMPORTANT body part is one the sender doesn't consider critical
+   to the delivery of the message.  However, the sender may be
+   interested in knowing if the receiving system delivered the body
+   part.
+
+   An IGNORE body part is one the sender doesn't care about whether the
+   receiving system delivers it or not.  The receiving system can
+   silently delete such body parts if the receiving system cannot
+   deliver the part.
+
+   The terms "entity" and "body part" have the meanings defined in [3].
+
+   One obvious application of critical content is generating a
+   (non-)delivery message.  If the value of the field is IGNORE, the
+   receiving MTA or UA MUST NOT generate a notification.  If the value
+   of the field is CRTITICAL, the receiving MTA or UA will generate a
+   notification, based on the normal notification request mechanisms.
+   Normal notification request mechanisms include the SMTP RCPT NOTIFY
+   command [7] and the Disposition-Notification-To header [8].
+
+Burger and Candell         Expires 1/14/01                    [Page 5]
+                  Critical Content of Internet Mail          July 2000
+
+
+
+   For example, if the sending system requests notification, and a
+   CRITICAL part fails, the receiving system will generate a NDN for
+   the whole message.  Conversely, if only an IGNORE part fails, the
+   receiving system will not generate a NDN.
+
+   The next sections examine the actions taken by an MTA or UA given
+   the different values of Content-Criticality.
+
+   NOTE: This implies that the MTA must examine the entire message on
+   receipt to determine whether it needs to generate a notification.
+   However, the MTA need not examine the message if it knows it can
+   store and forward all media types.  Said differently, an Internet e-
+   mail MTA can, by default, handle any arbitrary MIME-encapsulated
+   type.  Some voice mail systems, on the other hand, cannot store
+   binary attachments at all, such as application/ms-word.  The voice
+   mail MTA, in this example, would be scanning for non-renderable body
+   parts in any event.
+
+  4.1. CRITICAL
+
+   "Content-Criticality: CRITICAL" signifies that this body part is
+   critical to the sender.
+
+   If the receiving system cannot render or store a body part marked
+   CRITICAL, then the entire message has failed.  In this case, the
+   receiving system MUST take the appropriate failure action.
+
+   NOTE: We say "appropriate action", because the sender may have
+   suppressed all notifications.  In this case, the appropriate action
+   is to simply discard the message.
+
+  4.2. IMPORTANT
+
+   "Content-Criticality: IMPORTANT" signifies that the sender wishes to
+   receive notification reports for this body part.  Failure of such a
+   body part does not result in the failure of the message as a whole,
+   as happens with CRITICAL body parts.  However, the receiving system
+   MUST perform the appropriate body-part failure action.
+
+   If the receiving system cannot render or store a body part marked
+   IMPORTANT, the receiving system MUST take the appropriate failure
+   action.  It is important to note that if the system is successful in
+   delivering other critical body parts, then the message delivery is
+   successful.  In this situation, the receiving system MUST return a
+   partial non-delivery notification [6].
+
+  4.3. IGNORE
+
+   "Content-Criticality: IGNORE" signifies that the sender does not
+   care about notification reports for this body part.
+
+
+Burger and Candell         Expires 1/14/01                    [Page 6]
+                  Critical Content of Internet Mail          July 2000
+
+
+   If the receiving system cannot render or store a body part marked
+   IGNORE, the receiving system may silently delete the body part.  The
+   receiving system MUST NOT return a delivery failure, unless parts
+   marked IMPORTANT or CRITICAL have also failed.
+
+  4.4. Other Values
+
+   The receiving system MUST treat unrecognized values as IMPORTANT.
+   This is to provide backward compatibility with future uses of the
+   Content-Criticality entity.
+
+   <<<ALTERNATIVES:
+
+   IGNORE: If I don't recognize something, ignore it!
+
+   CRITICAL: Future values are more likely to involve some sort of
+   notification, rather than non-notification.  However, if the
+   notifications are more sophisticated than CRITICAL, senders may be
+   miffed they didn't get the processing they expected.
+
+   Reject the Message: This would be too extreme!  Yes, it would weed
+   out non-conformant sending UAs, but this would really piss off
+   users.
+
+
+   So far, we have one vote for IGNORE, as that would be compatible
+   with VPIMv2.
+   We have one vote for IMPORTANT, as that would provide forward-
+   compatibility with future uses of Content-Criticality.
+   We expect this to be a point of discussion on the list.
+
+   End of ALTERNATIVES>>>
+
+  4.5. Criticality Precedence
+
+   <<<We'll fill-in this in the next draft.>>>
+
+  4.6. Summary
+
+   The following table summarizes the actions expected of a conforming
+   MTA or UA.
+
+
+
+
+
+
+
+
+
+
+
+
+Burger and Candell         Expires 1/14/01                    [Page 7]
+                  Critical Content of Internet Mail          July 2000
+
+
+                            +--------------------------------------+
+                            |    Sending UA Has Marked Body Part   |
+                            |-------------+-------------+----------|
+                            |  CRITICAL   |  IMPORTANT  |  IGNORE  |
+       +--------------------+-------------+-------------+----------+
+       | Body Part is       | Appropriate | Appropriate |          |
+       | Deliverable/read   |   Action    |   Action    |  ignore  |
+       +--------------------+-------------+-------------+----------+
+       | Body Part is       | Fail Entire | Appropriate |          |
+       | Undeliverable /    |   Message   |   Action    |  ignore  |
+       |  Unreadable        |             |             |          |
+       +--------------------+--------------------------------------+
+
+   The distinction between deliverable/read is as follows.  A MTA can
+   determine if a body part is deliverable.  Sample actions a MTA can
+   take are generating a NDN or DSN.  An UA can determine if a body
+   part is readable.  A sample action an UA can take is generating a
+   MDN.
+
+   The "Appropriate Action" is the action the MTA or UA would take
+   given the context of execution.  For example, if a sender requests
+   return receipt and the receiver reads a CRITICAL body part, the
+   receiving UA must generate the appropriate MDN (following the rules
+   for MDN).
+
+   "Ignore" means the MTA or UA MUST ignore the operation on the body
+   part.  The MTA or UA MUST treat the message as if the body part was
+   not present in the message.
+
+
+5.   Backward Compatibility Considerations
+
+   If there are no Content-Criticality entities in the message, the
+   default value for Content-Criticality is CRITICAL.  The standard
+   notification mechanisms work for sending user agents (UA) that do
+   not know about the content notification entity.  All body parts are
+   critical, because they have the default marking of CRITICAL.
+
+   If there is at least one Content-Criticality entity in the message,
+   the default value for unspecified body parts is IGNORE.  The
+   philosophy is that UAs, especially manually constructed messages,
+   will explicitly mark the critical body parts.
+
+   NOTE: We could choose the default value for Content-Criticality to
+   be IGNORE.  This would make VPIMv2 automatically compliant with this
+   document, as VPIMv2 has provision to silently delete undeliverable
+   parts.  However, VPIMv2 systems should not be receiving arbitrary e-
+   mail from the Internet.  If they do, they should be compliant with
+   this series of documents.  By defaulting to CRITICAL, this draft is
+   compliant with the rest of the Internet infrastructure.
+
+
+
+Burger and Candell         Expires 1/14/01                    [Page 8]
+                  Critical Content of Internet Mail          July 2000
+
+
+   NOTE: Some VPIMv2 implementations can receive arbitrary e-mail from
+   the Internet.  However, these systems are really acting in the
+   capacity of an Internet Voice Mail system.  In this case, one would
+   expect the implementation to provide Internet Voice Mail semantics
+   to Internet Voice Mail messages.
+
+
+6.   Security Considerations
+
+   Receiving systems and users should not place any authentication
+   value on the Content-Criticality entity.  Just because a message has
+   a particular Content-Criticality value doesn't mean that the message
+   really originated at a given type of system.
+
+
+7.   Collected Syntax
+
+   The format of the collected syntax is in accordance with the ABNF of
+   [9].  Note that per RFC 2045, none of the strings are case
+   sensitive.
+
+
+        "Content-Criticality" ":" notification-type CRLF
+
+        notification-type = "CRITICAL" / "IMPORTANT" / "IGNORE"
+
+
+
+8.   References
+
+
+   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+      9, RFC 2026, October 1996.
+
+   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+      Levels", BCP 14, RFC 2119, March 1997.
+
+   3  Freed, N. and Borenstein, N., "Multipurpose Internet Mail
+      Extensions (MIME) Part One: Format of Internet Message Bodies",
+      RFC 2045, Innosoft and First Virtual, November 1996.
+
+   4  Freed, N. and Borenstein, N., "Multipurpose Internet Mail
+      Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft and
+      First Virtual, November 1996.
+
+   5  Vaudreuil, G. and Parsons, G., "Voice Profile for Internet Mail -
+      version 3", <draft-ema-vpimv3-00.txt>, Work in Progress, expired.
+
+   6  Burger, E., "Partial Non-Delivery Notification", Work in
+      Progress, draft-ema-burger-pndn-01.txt, March 2000.
+
+
+
+Burger and Candell         Expires 1/14/01                    [Page 9]
+                  Critical Content of Internet Mail          July 2000
+
+
+
+   7  Moore, K., "SMTP Service Extension for Delivery Status
+      Notifications", RFC 1981, University of Tennessee, January 1996.
+
+   8  Fajman, R., "An Extensible Message Format for Message Disposition
+      Notifications", RFC 2298, National Institutes of Health, March
+      1998.
+
+   9  Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
+      Specifications: ABNF", RFC 2234, Internet Mail Consortium and
+      Demon Internet Ltd., November 1997.
+
+
+
+
+9.   Acknowledgments
+
+   We'd like to thank Ned Freed for pointing out that this mechanism
+   was about criticality, not notification per se.  That insight made
+   the concept and descriptions infinitely more straight forward.  If
+   it's still confusing, it's our fault!
+
+   We'd also like to thank Keith Moore for helping us tighten-up our
+   explanations.
+
+
+10.    Author's Addresses
+
+   Eric Burger
+   Centigram Communications Corporation
+   Maryland Technology Center
+   1375 Piccard Dr., MS 150I
+   Rockville, MD  20850-4311
+   USA
+
+   Phone: +1 301/212-3320
+   Email: e.burger@ieee.org
+
+
+   Emily Candell
+   Comverse Network Systems
+   200 Quannapowitt Pkwy.
+   Wakefield, MA  01880
+   USA
+
+   Phone: +1 781/213-2324
+   Email: emily@comversens.com
+
+
+
+
+
+
+Burger and Candell         Expires 1/14/01                   [Page 10]
+                  Critical Content of Internet Mail          July 2000
+
+
+Full Copyright Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances
+   of licenses to be made available, or the result of an attempt made
+   to obtain a general license or permission for the use of such
+   proprietary rights by implementers or users of this specification
+   can be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+   Copyright (C) 2000 The Internet Society.  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph
+   are included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the  purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+Burger and Candell         Expires 1/14/01                   [Page 11]
+
\ No newline at end of file
diff --git a/doc/devel/I-D/draft-ietf-vpim-cc-01.txt b/doc/devel/I-D/draft-ietf-vpim-cc-01.txt
new file mode 100644
index 00000000..31c4680b
--- /dev/null
+++ b/doc/devel/I-D/draft-ietf-vpim-cc-01.txt
@@ -0,0 +1,627 @@
+
+Network Working Group                                           E. Burger
+Internet Draft                                         SnowShore Networks
+Document: draft-ietf-vpim-cc-01.txt                            E. Candell
+Category: Standards Track                        Comverse Network Systems
+Expires February 2001                                    October 18, 2000
+ 
+ 
+                   Critical Content of Internet Mail 
+ 
+ 
+Status of this Memo 
+ 
+   This document is an Internet-Draft and is in full conformance with 
+   all provisions of Section 10 of RFC2026 [1].  
+    
+   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." 
+    
+   One can access the list of current Internet-Drafts at 
+   http://www.ietf.org/ietf/1id-abstracts.txt 
+    
+   One can access the list of Internet-Draft Shadow Directories at 
+   http://www.ietf.org/shadow.html. 
+    
+    
+    
+1.   Abstract 
+    
+   This document describes a mechanism for identifying the body parts 
+   that the sender deems critical in a multi-part Internet mail 
+   message. 
+    
+   By knowing what parts of a message the sender deems critical, a MTA 
+   or UA can intelligently handle multi-part messages when gatewaying 
+   (MTA) or presenting (UA) to systems of lesser capability. Critical 
+   content can help a smart gateway decide what parts to forward.  It 
+   can indicate how hard a gateway should try to deliver a body part.  
+   It can help an MTA to select body parts to silently delete when a 
+   system of lesser capability receives a message.  In addition, 
+   critical content can help indicate the notification strategy of the 
+   receiving system. 
+    
+
+
+
+
+
+ 
+                           Expires 4/18/01                    [Page 1] 
+                  Critical Content of Internet Mail       October 2000 
+ 
+ 
+Table of Contents 
+    
+1.  ABSTRACT .........................................................1 
+2.  CONVENTIONS USED IN THIS DOCUMENT ................................2 
+3.  INTRODUCTION .....................................................2 
+4.  CONTENT-CRITICALITY ENTITY .......................................5 
+
+4.1.  CRITICAL .......................................................6 
+4.2.  IGNORE .........................................................6 
+4.3.  Other Values ...................................................6 
+4.4.  Summary ........................................................6 
+5.  BACKWARD COMPATIBILITY CONSIDERATIONS ............................7 
+6.  MIME INTERACTIONS ................................................8 
+6.1.  multipart/alternative ..........................................8 
+6.2.  multipart/related ..............................................8 
+
+6.3.  message/rfc822 .................................................8 
+7.  SECURITY CONSIDERATIONS ..........................................8 
+8.  COLLECTED SYNTAX .................................................9 
+9.  REFERENCES .......................................................9 
+10. ACKNOWLEDGMENTS .................................................10 
+11. AUTHOR'S ADDRESSES ..............................................10 
+    
+    
+2.   Conventions used in this document 
+    
+   This document refers generically to the sender of a message in the 
+   masculine (he/him/his) and the recipient of the message in the 
+   feminine (she/her/hers).  This convention is purely for convenience 
+   and makes no assumption about the gender of a message sender or 
+   recipient. 
+    
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
+   this document are to be interpreted as described in RFC-2119 [2]. 
+    
+   FORMATTING NOTE: Notes, such at this one, provide additional 
+   nonessential information that the reader may skip without missing 
+   anything essential.  The primary purpose of these non-essential 
+   notes is to convey information about the rationale of this document, 
+   or to place this document in the proper historical or evolutionary 
+   context.  Readers whose sole purpose is to construct a conformant 
+   implementation may skip such information.  However, it may be of use 
+   to those who wish to understand why we made certain design choices. 
+    
+    
+3.   Introduction 
+    
+   This document describes the Critical Content identification for 
+   multi-part Internet mail. 
+    
+
+  
+Burger and Candell         Expires 4/18/01                    [Page 2] 
+                  Critical Content of Internet Mail       October 2000 
+ 
+ 
+   The need for a critical content identification mechanism comes about 
+   because of the internetworking of Internet mail systems with legacy 
+   messaging systems that do not fulfil all of the semantics of 
+   Internet mail.  Such legacy systems have a limited ability to render 
+   all parts of a given message.  This document will use the case of an 
+   Internet mail system exchanging electronic messages with a legacy 
+   voice messaging system for illustrative purposes. 
+    
+   Electronic mail has historically been text-centric.  Extensions such 
+   as MIME [3] enable the desktop to send and receive multi-part, 
+   multimedia messages.  Popular multimedia data types include binary 
+   word processing documents, binary business presentation graphics, 
+   voice, and video. 
+    
+   Voice mail has historically been audio-centric.  Many voice 
+   messaging systems only render voice.  Extensions such as fax enable 
+   the voice mail system to send and receive fax images as well as 
+   create multi-part voice and fax messages.  A few voice mail systems 
+   can render text using text-to-speech or text-to-fax technology.  
+   Although theoretically possible, none can today render video. 
+    
+   An important aspect of the interchange between voice messaging 
+   services and desktop e-mail client applications is that the 
+   rendering capability of the voice messaging platform is often much 
+   less than the rendering capability of a desktop e-mail client.  In 
+   the e-mail case, the sender has the expectation that the recipient 
+   receives all components of a multimedia message.  This is so even if 
+   the recipient cannot render all body parts.  In most cases, the 
+   recipient can either find the appropriate rendering tool or tell the 
+   sender that she cannot read the particular attachment. 
+    
+   This is an important issue.  By definition, a MIME-enabled user 
+   agent, conforming to [4] will present or make available all of the 
+   body parts to the recipient.  However, a voice mail system may not 
+   be capable of storing non-voice objects.  Moreover, the voice mail 
+   system may not be capable of notifying the recipient that there were 
+   undeliverable message parts. 
+    
+   The inability of the receiving system to render a body part is 
+   usually a permanent failure.  Retransmission of the message will not 
+   improve the likelihood of a future successful delivery.  Contrast 
+   this to the case with normal data delivery.  Traditional message 
+   failures, such as a garbled message or disabled link will benefit 
+   from retransmission. 
+    
+   This situation is fundamentally different from normal Internet mail.  
+   In the Internet mail case, either the system delivered the message, 
+   or it didn't.  There is no concept of a system partially delivering 
+   a message. 
+    
+   In addition, the sender would not mind if the system did not deliver 
+   non-critical parts of a message.  In fact, the sender's user agent 
+  
+Burger and Candell         Expires 4/18/01                    [Page 3] 
+                  Critical Content of Internet Mail       October 2000 
+ 
+ 
+   may be silently adding body parts to a message unbeknownst to the 
+   sender.  For example, take Microsoft Outlook as a user agent.  
+   Outlook often will attach a TNEF section or other body parts. If the 
+   receiving system rejected the message because it could not render 
+   TNEF, the sender would be understandably confused and upset. 
+    
+   Thus, there is a need for a method of indicating to a Mail Transfer 
+   Agent (MTA) or User Agent (UA) that the sender considers parts of a 
+   message to be critical.  From the sender's perspective, he would not 
+   consider the message delivered if the system did not deliver the 
+   critical parts. 
+    
+   One method of indicating critical content of a message is to define 
+   a profile.  The profile defines discard rules based on knowledge of 
+   the user population for silently deleting body parts.  Citing the 
+   example above, a voice profile can easily declare that MTAs or UAs 
+   can silently delete TNEF data and yet consider the message 
+   successfully delivered.  This is, in fact, the approach taken by 
+   VPIMv2 [5]. 
+    
+   Since one aspect of the issue is deciding when to notify the sender 
+   that the system cannot deliver part of a message, one could use a 
+   partial non-delivery notification mechanism [6] to indicate a 
+   problem with delivering a given body part.  However, this requires 
+   the user request a MDN.  Moreover, the sender will receive PNDN 
+   failures for objects the sender may not be aware he is sending.  An 
+   example would be the TNEF part. 
+    
+   Summarizing the needs, we need a mechanism that will let the sender 
+   or sender's UA mark body parts he considers critical to the message 
+   that the system must deliver.  The mechanism MUST NOT burden the 
+   sender with failure notifications for non-critical body parts.  The 
+   mechanism MUST conform to the general notification status request 
+   mechanism for positive or negative notification.  When requested, 
+   the mechanism MUST indicate to the sender when a receiving system 
+   cannot deliver a critical body part. 
+    
+   In short, we need a method of letting the sender indicate what body-
+   parts he considers to be critical. 
+    
+   This document describes a Critical Content marking mechanism that 
+   satisfies these needs.  Following the format for Internet message 
+   bodies [3], this document introduces the Content-Criticality body 
+   part header.  Values for this header are CRITICAL, NOTIFY, or 
+   IGNORE.  The receiving MTA or UA will generate a DSN or MDN at 
+   delivery time or reading time if it receives a request for 
+   notification and the (non-)delivery status of the parts marked 
+   NOTIFY meet the criteria for notification.   
+    
+   NOTE: A straight-forward alternative implementation method for 
+   marking a body part critical is to use a content-disposition 
+   parameter called "criticality". 
+  
+Burger and Candell         Expires 4/18/01                    [Page 4] 
+                  Critical Content of Internet Mail       October 2000 
+ 
+ 
+    
+   NOTE: We could have made the critical content indicator a parameter 
+   to content-disposition.  This has the benefit of being very easy for 
+   IMAP servers to implement.  In particular, IMAP servers 
+   automatically present the content-disposition entity when a UA 
+   requests information on a message.  On the other hand, the UA must 
+   explicitly request the presence and value of different entities, 
+   such as content-criticality.  However, implementing the critical 
+   content indicator as a parameter to content-disposition overloads 
+   the meaning of the entity.  Moreover, IMAP servers can present, in 
+   the future, content-criticality by default.  Lastly, most UA's that 
+   have interest in content-criticality will explicitly request the 
+   header in any event. 
+    
+    
+4.   Content-Criticality Entity 
+    
+   The Content-Criticality field is a MIME body part header inserted by 
+   the sending UA to indicate to the receiving MTA or UA whether to 
+   consider this body part critical. 
+    
+   A CRITICAL body part is one the sender requires the receiving system 
+   to deliver for him to consider the message delivered. 
+    
+   An IGNORE body part is one the sender doesn't care whether the 
+   receiving system delivers it or not.  The receiving system can 
+   silently delete such body parts if the receiving system cannot 
+   deliver the part. 
+    
+   The terms "entity" and "body part" have the meanings defined in [3]. 
+    
+   One obvious application of critical content is generating a 
+   (non-)delivery message.  If the value of the field is IGNORE, the 
+   receiving MTA or UA MUST NOT generate a notification.  If the value 
+   of the field is CRTITICAL, the receiving MTA or UA will generate a 
+   notification, based on the normal notification request mechanisms.  
+   Normal notification request mechanisms include the SMTP RCPT NOTIFY 
+   command [7] and the Disposition-Notification-To header [8]. 
+    
+   For example, if the sending system requests a notification, and a 
+   CRITICAL part fails, the receiving system will generate a NDN for 
+   the whole message.  Conversely, if only an IGNORE part fails, the 
+   receiving system will not generate a NDN.  
+    
+   The next sections examine the actions taken by an MTA or UA given 
+   the different values of Content-Criticality. 
+    
+   NOTE: This implies that the MTA must examine the entire message on 
+   receipt to determine whether it needs to generate a notification.  
+   However, the MTA need not examine the message if it knows it can 
+   store and forward all media types.  Said differently, an Internet e-
+   mail MTA can, by default, handle any arbitrary MIME-encapsulated 
+  
+Burger and Candell         Expires 4/18/01                    [Page 5] 
+                  Critical Content of Internet Mail       October 2000 
+ 
+ 
+   type.  Some voice mail systems, on the other hand, cannot store 
+   binary attachments at all, such as application/ms-word.  The voice 
+   mail MTA, in this example, would be scanning for non-renderable body 
+   parts in any event.  
+    
+  4.1. CRITICAL 
+    
+   "Content-Criticality: CRITICAL" signifies that this body part is 
+   critical to the sender. 
+    
+   If the receiving system cannot render or store a body part marked 
+   CRITICAL, then the entire message has failed.  In this case, the 
+   receiving system MUST take the appropriate failure action. 
+    
+   NOTE: We say "appropriate action", because the sender may have 
+   suppressed all notifications.  In this case, the appropriate action 
+   is to simply discard the message. 
+    
+  4.2. IGNORE 
+    
+   "Content-Criticality: IGNORE" signifies that the sender does not 
+   care about notification reports for this body part. 
+    
+   If the receiving system cannot render or store a body part marked 
+   IGNORE, the receiving system may silently delete the body part.  The 
+   receiving system MUST NOT return a delivery failure, unless parts 
+   marked IMPORTANT or CRITICAL have also failed. 
+    
+  4.3. Other Values 
+    
+   The receiving system MUST treat unrecognized values as CRITICAL.  
+   This is to provide backward compatibility with future uses of the 
+   Content-Criticality entity. 
+    
+   The most likely new value is IMPORTANT.  An IMPORTANT body part is 
+   something the sender wants the receiver to get, but would not want 
+   the message rejected outright if the IMPORTANT body part fails.  A 
+   receiving system that does not understand IMPORTANT MUST take the 
+   default value of CRITICAL.  In this case, the MTA or UA MUST take 
+   the conservative action of rejecting the message. 
+     
+  4.4. Summary 
+    
+   The following table summarizes the actions expected of a conforming 
+   MTA or UA. 
+    
+
+
+
+
+
+
+  
+Burger and Candell         Expires 4/18/01                    [Page 6] 
+                  Critical Content of Internet Mail       October 2000 
+ 
+ 
+                            +--------------------------------------+ 
+                            |    Sending UA Has Marked Body Part   | 
+                            |---------------------+----------------| 
+                            |      CRITICAL       |     IGNORE     | 
+       +--------------------+---------------------+----------------+ 
+       | Body Part is       |                     |                | 
+       | Deliverable/read   | Appropriate Action  |     ignore     | 
+       +--------------------+---------------------+----------------+ 
+       | Body Part is       |                     |                | 
+       | Undeliverable /    |                     |                | 
+       |  Unreadable        | Fail Entire Message |     ignore     | 
+       +--------------------+--------------------------------------+ 
+    
+   The distinction between deliverable/read is as follows.  A MTA can 
+   determine if a body part is deliverable.  Sample actions a MTA can 
+   take are generating a NDN or DSN.  An UA can determine if a body 
+   part is readable.  A sample action an UA can take is generating a 
+   MDN. 
+    
+   The "Appropriate Action" is the action the MTA or UA would take 
+   given the context of execution.  For example, if a sender requests 
+   return receipt and the receiver reads a CRITICAL body part, the 
+   receiving UA must generate the appropriate MDN (following the rules 
+   for MDN). 
+    
+   "Ignore" means the MTA or UA MUST ignore the operation on the body 
+   part.  The MTA or UA MUST treat the message as if the body part was 
+   not present in the message. 
+    
+    
+5.   Backward Compatibility Considerations 
+    
+   If there are no Content-Criticality entities in the message, the 
+   default value for Content-Criticality is CRITICAL.  The standard 
+   notification mechanisms work for sending user agents (UA) that do 
+   not know about the content notification entity.  All body parts are 
+   critical, because they have the default marking of CRITICAL. 
+    
+   If there is at least one Content-Criticality entity in the message, 
+   the default value for unspecified body parts is IGNORE.  The 
+   philosophy is that UAs, especially manually constructed messages, 
+   will explicitly mark the critical body parts. 
+    
+   NOTE: We could choose the default value for Content-Criticality to 
+   be IGNORE.  This would make VPIMv2 automatically compliant with this 
+   document, as VPIMv2 has provision to silently delete undeliverable 
+   parts.  However, VPIMv2 systems should not be receiving arbitrary e-
+   mail from the Internet.  If they do, they should be compliant with 
+   this series of documents.  By defaulting to CRITICAL, this draft is 
+   compliant with the rest of the Internet infrastructure. 
+    
+
+  
+Burger and Candell         Expires 4/18/01                    [Page 7] 
+                  Critical Content of Internet Mail       October 2000 
+ 
+ 
+   NOTE: Some VPIMv2 implementations can receive arbitrary e-mail from 
+   the Internet.  However, these systems are really acting in the 
+   capacity of an Internet Voice Mail system.  In this case, one would 
+   expect the implementation to provide Internet Voice Mail semantics 
+   to Internet Voice Mail messages. 
+    
+ 
+6.   MIME Interactions 
+    
+  6.1. multipart/alternative 
+    
+   Content-Criticality is only in effect for the selected alternative.  
+   If the selected alternative has the critical content indicator, then 
+   the entire alternative takes on the criticality indicated.  That is, 
+   if the alternative selected has Content-Criticality: IGNORE, then 
+   the receiving system MUST NOT generate any delivery notifications 
+   (MDN, NDN, return-receipt, etc.). 
+    
+   It is unlikely for a selected alternative to fail, as the receiving 
+   UA presumably picks the alternative specifically because it can 
+   render it.  
+    
+   If the selected alternative is a message/rfc822 that encloses a 
+   multipart MIME message or the selected alternative is itself a 
+   multipart MIME type, the individual top-level body parts follow the 
+   Content-Criticality mechanism described in this document. 
+    
+  6.2. multipart/related 
+    
+   Content-Criticality fits in rather well with the multipart/related 
+   construction.  For example, consider a multipart/related message 
+   consisting of a Macintosh data fork and a Macintosh resource fork.  
+   For a Microsoft Word document, the data fork is likely to be 
+   critical.  The receiving system can safely ignore the resource fork. 
+    
+  6.3. message/rfc822 
+    
+   Content-Criticality only affects the outermost level of the message 
+   or, in the case of multipart/alternative, the outermost level of the 
+   selected alternative.  Specifically, the receiving system ignores 
+   Content-Criticality indicators in embedded body parts.  This avoids 
+   the situation of a forwarded message triggering or suppressing 
+   undesired or desired reporting. 
+    
+7.   Security Considerations 
+ 
+   Receiving systems and users should not place any authentication 
+   value on the Content-Criticality entity.  Just because a message has 
+   a particular Content-Criticality value doesn't mean that the message 
+   really originated at a given type of system. 
+    
+    
+  
+Burger and Candell         Expires 4/18/01                    [Page 8] 
+                  Critical Content of Internet Mail       October 2000 
+ 
+ 
+8.   Collected Syntax 
+    
+   The format of the collected syntax is in accordance with the ABNF of 
+   [9].  Note that per RFC 2045, none of the strings are case 
+   sensitive. 
+    
+    
+        "Content-Criticality" ":" notification-type CRLF 
+    
+        notification-type = "CRITICAL" / "IGNORE" 
+    
+    
+ 
+9.   References 
+    
+ 
+   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
+      9, RFC 2026, October 1996. 
+    
+   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
+      Levels", BCP 14, RFC 2119, March 1997. 
+    
+   3  Freed, N. and Borenstein, N., "Multipurpose Internet Mail 
+      Extensions (MIME) Part One: Format of Internet Message Bodies", 
+      RFC 2045, Innosoft and First Virtual, November 1996. 
+    
+   4  Freed, N. and Borenstein, N., "Multipurpose Internet Mail 
+      Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft and 
+      First Virtual, November 1996. 
+    
+   5  Vaudreuil, G. and Parsons, G., "Voice Profile for Internet Mail -         
+      version 2", RFC 2321, Lucent Technologies and Nortel Networks, 
+      September 1998. 
+    
+   6  Burger, E., "Partial Non-Delivery Notification", Work in 
+      Progress, draft-ema-burger-pndn-01.txt, March 2000. 
+    
+   7  Moore, K., "SMTP Service Extension for Delivery Status 
+      Notifications", RFC 1981, University of Tennessee, January 1996. 
+    
+   8  Fajman, R., "An Extensible Message Format for Message Disposition 
+      Notifications", RFC 2298, National Institutes of Health, March 
+      1998. 
+    
+   9  Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 
+      Specifications: ABNF", RFC 2234, Internet Mail Consortium and 
+      Demon Internet Ltd., November 1997. 
+    
+    
+    
+    
+
+  
+Burger and Candell         Expires 4/18/01                    [Page 9] 
+                  Critical Content of Internet Mail       October 2000 
+ 
+ 
+10.    Acknowledgments 
+    
+   We'd like to thank Ned Freed for pointing out that this mechanism 
+   was about criticality, not notification per se.  That insight made 
+   the concept and descriptions infinitely more straight forward.  If 
+   it's still confusing, it's our fault! 
+    
+   We'd also like to thank Keith Moore for helping us tighten-up our 
+   explanations. 
+    
+   Dropping the IMPORTANT critical content type took away one of the 
+   reasons for partial non-delivery notification.  That makes Jutta 
+   Degener very happy! 
+    
+    
+11.    Author's Addresses 
+    
+   Eric Burger 
+   SnowShore Networks 
+   c/o CRV 
+   1000 Winter St. 
+   Waltham, MA  02451 
+   USA 
+    
+   Phone: +1 703/304-3883 
+   Email: e.burger@ieee.org 
+    
+    
+   Emily Candell 
+   Comverse Network Systems 
+   200 Quannapowitt Pkwy. 
+   Wakefield, MA  01880 
+   USA 
+    
+   Phone: +1 781/213-2324 
+   Email: emily@comversens.com 
+    
+    
+Full Copyright Statement                         
+
+   The IETF takes no position regarding the validity or scope of any 
+   intellectual property or other rights that might be claimed to  
+   pertain to the implementation or use of the technology described in 
+   this document or the extent to which any license under such rights 
+   might or might not be available; neither does it represent that it 
+   has made any effort to identify any such rights.  Information on the 
+   IETF's procedures with respect to rights in standards-track and 
+   standards-related documentation can be found in BCP-11.  Copies of 
+   claims of rights made available for publication and any assurances 
+   of licenses to be made available, or the result of an attempt made 
+   to obtain a general license or permission for the use of such 
+
+  
+Burger and Candell         Expires 4/18/01                   [Page 10] 
+                  Critical Content of Internet Mail       October 2000 
+ 
+ 
+   proprietary rights by implementers or users of this specification 
+   can be obtained from the IETF Secretariat. 
+    
+   The IETF invites any interested party to bring to its attention any 
+   copyrights, patents or patent applications, or other proprietary 
+   rights which may cover technology that may be required to practice 
+   this standard.  Please address the information to the IETF Executive 
+   Director. 
+    
+   Copyright (C) 2000 The Internet Society.  All Rights Reserved. 
+    
+   This document and translations of it may be copied and furnished to 
+   others, and derivative works that comment on or otherwise explain it 
+   or assist in its implementation may be prepared, copied, published 
+   and distributed, in whole or in part, without restriction of any 
+   kind, provided that the above copyright notice and this paragraph 
+   are included on all such copies and derivative works.  However, this 
+   document itself may not be modified in any way, such as by removing 
+   the copyright notice or references to the Internet Society or other 
+   Internet organizations, except as needed for the  purpose of 
+   developing Internet standards in which case the procedures for 
+   copyrights defined in the Internet Standards process must be 
+   followed, or as required to translate it into languages other than 
+   English. 
+    
+   The limited permissions granted above are perpetual and will not be 
+   revoked by the Internet Society or its successors or assigns. 
+    
+   This document and the information contained herein is provided on an 
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Burger and Candell         Expires 4/18/01                   [Page 11] 
+
\ No newline at end of file
diff --git a/doc/devel/I-D/draft-ietf-vpim-cc-02.txt b/doc/devel/I-D/draft-ietf-vpim-cc-02.txt
new file mode 100644
index 00000000..36a0cbe4
--- /dev/null
+++ b/doc/devel/I-D/draft-ietf-vpim-cc-02.txt
@@ -0,0 +1,783 @@
+
+Network Working Group                                           E. Burger
+Internet Draft                                         SnowShore Networks
+Document: draft-ietf-vpim-cc-02.txt                            E. Candell
+Category: Standards Track                        Comverse Network Systems
+Expires May 2001                                        November 24, 2000
+ 
+ 
+                   Critical Content of Internet Mail 
+ 
+ 
+Status of this Memo 
+ 
+   This document is an Internet-Draft and is in full conformance with 
+   all provisions of Section 10 of RFC2026 [1].  
+    
+   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." 
+    
+   One can access the list of current Internet-Drafts at 
+   http://www.ietf.org/ietf/1id-abstracts.txt 
+    
+   One can access the list of Internet-Draft Shadow Directories at 
+   http://www.ietf.org/shadow.html. 
+    
+   This document is a work product of the IETF Voice Profile for 
+   Internet Mail (vpim) Work Group.  The URL for the VPIM website is 
+   <http://www.vpim.org>. 
+    
+    
+1. Abstract 
+    
+   This document describes a mechanism for identifying the body parts 
+   that the sender deems critical in a multi-part Internet mail 
+   message. 
+    
+   By knowing what parts of a message the sender deems critical, a MTA 
+   or UA can intelligently handle multi-part messages when gatewaying 
+   (MTA) or presenting (UA) to systems of lesser capability. Critical 
+   content can help a smart gateway decide what parts to forward.  It 
+   can indicate how hard a gateway should try to deliver a body part.  
+   It can help an MTA to select body parts to silently delete when a 
+   system of lesser capability receives a message.  In addition, 
+   critical content can help indicate the notification strategy of the 
+   receiving system. 
+    
+
+
+ 
+                           Expires 5/24/01                    [Page 1] 
+                  Critical Content of Internet Mail      November 2000   
+ 
+Table of Contents 
+    
+1.  ABSTRACT .........................................................1 
+2.  CONVENTIONS USED IN THIS DOCUMENT ................................2 
+3.  INTRODUCTION .....................................................3 
+4.  CONTENT-CRITICALITY ENTITY .......................................5 
+4.1.  CRITICAL .......................................................6 
+4.2.  IGNORE .........................................................6 
+4.3.  Other Values ...................................................6 
+4.4.  Summary ........................................................7 
+5.  STATUS CODE ......................................................7 
+6.  BACKWARD COMPATIBILITY CONSIDERATIONS ............................8 
+7.  MIME INTERACTIONS ................................................8 
+7.1.  multipart/alternative ..........................................8 
+7.2.  multipart/related ..............................................9 
+7.3.  message/rfc822 .................................................9 
+8.  IMPLEMENTATION EXAMPLES ..........................................9 
+8.1.  Content Gateways ...............................................9 
+8.2.  Non-Traditional UA ............................................10 
+9.  SECURITY CONSIDERATIONS .........................................11 
+10. COLLECTED SYNTAX ................................................11 
+11. REFERENCES ......................................................11 
+12. ACKNOWLEDGMENTS .................................................12 
+13. AUTHOR'S ADDRESSES ..............................................13 
+    
+    
+2. Conventions used in this document 
+    
+   This document refers generically to the sender of a message in the 
+   masculine (he/him/his) and the recipient of the message in the 
+   feminine (she/her/hers).  This convention is purely for convenience 
+   and makes no assumption about the gender of a message sender or 
+   recipient. 
+    
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
+   this document are to be interpreted as described in RFC-2119 [2]. 
+    
+   FORMATTING NOTE: Notes, such at this one, provide additional 
+   nonessential information that the reader may skip without missing 
+   anything essential.  The primary purpose of these non-essential 
+   notes is to convey information about the rationale of this document, 
+   or to place this document in the proper historical or evolutionary 
+   context.  Readers whose sole purpose is to construct a conformant 
+   implementation may skip such information.  However, it may be of use 
+   to those who wish to understand why we made certain design choices. 
+    
+    
+
+  
+Burger and Candell         Expires 5/24/01                    [Page 2] 
+                  Critical Content of Internet Mail      November 2000   
+ 
+3. Introduction 
+    
+   This document describes the Critical Content identification for 
+   multi-part Internet mail. 
+    
+   The need for a critical content identification mechanism comes about 
+   because of the internetworking of Internet mail systems with legacy 
+   messaging systems that do not fulfil all of the semantics of 
+   Internet mail.  Such legacy systems have a limited ability to render 
+   all parts of a given message.  This document will use the case of an 
+   Internet mail system exchanging electronic messages with a legacy 
+   voice messaging system for illustrative purposes. 
+    
+   Electronic mail has historically been text-centric.  Extensions such 
+   as MIME [3] enable the desktop to send and receive multi-part, 
+   multimedia messages.  Popular multimedia data types include binary 
+   word processing documents, binary business presentation graphics, 
+   voice, and video. 
+    
+   Voice mail has historically been audio-centric.  Many voice-
+   messaging systems only render voice.  Extensions such as fax enable 
+   the voice mail system to send and receive fax images as well as 
+   create multi-part voice and fax messages.  A few voice mail systems 
+   can render text using text-to-speech or text-to-fax technology.  
+   Although theoretically possible, none can today render video. 
+    
+   An important aspect of the interchange between voice messaging 
+   services and desktop e-mail client applications is that the 
+   rendering capability of the voice-messaging platform is often much 
+   less than the rendering capability of a desktop e-mail client.  In 
+   the e-mail case, the sender has the expectation that the recipient 
+   receives all components of a multimedia message.  This is so even if 
+   the recipient cannot render all body parts.  In most cases, the 
+   recipient can either find the appropriate rendering tool or tell the 
+   sender that she cannot read the particular attachment. 
+    
+   This is an important issue.  By definition, a MIME-enabled user 
+   agent, conforming to [4] will present or make available all of the 
+   body parts to the recipient.  However, a voice mail system may not 
+   be capable of storing non-voice objects.  Moreover, the voice mail 
+   system may not be capable of notifying the recipient that there were 
+   undeliverable message parts. 
+    
+   The inability of the receiving system to render a body part is 
+   usually a permanent failure.  Retransmission of the message will not 
+   improve the likelihood of a future successful delivery.  Contrast 
+   this to the case with normal data delivery.  Traditional message 
+   failures, such as a garbled message or disabled link will benefit 
+   from retransmission. 
+    
+   This situation is fundamentally different from normal Internet mail.  
+   In the Internet mail case, either the system delivered the message, 
+  
+Burger and Candell         Expires 5/24/01                    [Page 3] 
+                  Critical Content of Internet Mail      November 2000   
+ 
+   or it didn't.  There is no concept of a system partially delivering 
+   a message. 
+    
+   In addition, the sender would not mind if the system did not deliver 
+   non-critical parts of a message.  In fact, the sender's user agent 
+   may be silently adding body parts to a message unbeknownst to the 
+   sender.  For example, take Microsoft Outlook as a user agent.  
+   Outlook often will attach a TNEF section or other body parts. If the 
+   receiving system rejected the message because it could not render 
+   TNEF, the sender would be understandably confused and upset. 
+    
+   Thus, there is a need for a method of indicating to a Mail Transfer 
+   Agent (MTA) or User Agent (UA) that the sender considers parts of a 
+   message to be critical.  From the sender's perspective, he would not 
+   consider the message delivered if the system did not deliver the 
+   critical parts. 
+    
+   One method of indicating critical content of a message is to define 
+   a profile.  The profile defines discard rules based on knowledge of 
+   the user population for silently deleting body parts.  Citing the 
+   example above, a voice profile can easily declare that MTAs or UAs 
+   can silently delete TNEF data and yet consider the message 
+   successfully delivered.  This is, in fact, the approach taken by 
+   VPIMv2 [5]. 
+    
+   Since one aspect of the issue is deciding when to notify the sender 
+   that the system cannot deliver part of a message, one could use a 
+   partial non-delivery notification mechanism [6] to indicate a 
+   problem with delivering a given body part.  However, this requires 
+   the user request a MDN.  Moreover, the sender will receive PNDN 
+   failures for objects the sender may not be aware he is sending.  An 
+   example would be the TNEF part. 
+    
+   Summarizing the needs, we need a mechanism that will let the sender 
+   or sender's UA mark body parts he considers critical to the message 
+   that the system must deliver.  The mechanism MUST NOT burden the 
+   sender with failure notifications for non-critical body parts.  The 
+   mechanism MUST conform to the general notification status request 
+   mechanism for positive or negative notification.  When requested, 
+   the mechanism MUST indicate to the sender when a receiving system 
+   cannot deliver a critical body part. 
+    
+   In short, we need a method of letting the sender indicate what body-
+   parts he considers to be critical. 
+    
+   This document describes a Critical Content marking mechanism that 
+   satisfies these needs.  Following the format for Internet message 
+   bodies [3], this document introduces the Content-Criticality body 
+   part header.  Values for this header are CRITICAL, NOTIFY, or 
+   IGNORE.  The receiving MTA or UA will generate a delivery status 
+   notification (DSN) [7] or Message Disposition Notification (MDN) [8] 
+   at delivery time or reading time if it receives a request for 
+  
+Burger and Candell         Expires 5/24/01                    [Page 4] 
+                  Critical Content of Internet Mail      November 2000   
+ 
+   notification and the (non-)delivery status of the parts marked 
+   NOTIFY meet the criteria for notification.   
+    
+   NOTE: A straightforward alternative implementation method for 
+   marking a body part critical is to use a content-disposition 
+   parameter called "criticality". 
+    
+   NOTE: We could have made the critical content indicator a parameter 
+   to content-disposition.  This has the benefit of being very easy for 
+   IMAP servers to implement.  In particular, IMAP servers 
+   automatically present the content-disposition entity when a UA 
+   requests information on a message.  On the other hand, the UA must 
+   explicitly request the presence and value of different entities, 
+   such as content-criticality.  However, implementing the critical 
+   content indicator as a parameter to content-disposition overloads 
+   the meaning of the entity.  Moreover, IMAP servers can present, in 
+   the future, content-criticality by default.  Lastly, most UA's that 
+   have interest in content-criticality will explicitly request the 
+   header in any event. 
+    
+    
+4. Content-Criticality Entity 
+    
+   The Content-Criticality field is a MIME body part header inserted by 
+   the sending UA to indicate to the receiving MTA or UA whether to 
+   consider this body part critical. 
+    
+   A CRITICAL body part is one the sender requires the receiving system 
+   to deliver for him to consider the message delivered. 
+    
+   An IGNORE body part is one the sender doesn't care whether the 
+   receiving system delivers it or not.  The receiving system can 
+   silently delete such body parts if the receiving system cannot 
+   deliver the part. 
+    
+   The terms "entity" and "body part" have the meanings defined in [3]. 
+    
+   One obvious application of critical content is generating a 
+   (non-)delivery message.  If the value of the field is IGNORE, the 
+   receiving MTA or UA MUST NOT generate a notification.  If the value 
+   of the field is CRTITICAL, the receiving MTA or UA will generate a 
+   notification, based on the normal notification request mechanisms.  
+   Normal notification request mechanisms include the SMTP RCPT NOTIFY 
+   command [9] and the Disposition-Notification-To header [8]. 
+    
+   For example, if the sending system requests a notification, and a 
+   CRITICAL part fails, the receiving system will generate a NDN for 
+   the whole message.  Conversely, if only an IGNORE part fails, the 
+   receiving system will not generate a NDN.  
+    
+   The next sections examine the actions taken by an MTA or UA given 
+   the different values of Content-Criticality. 
+  
+Burger and Candell         Expires 5/24/01                    [Page 5] 
+                  Critical Content of Internet Mail      November 2000   
+ 
+    
+   NOTE: This implies that the MTA must examine the entire message on 
+   receipt to determine whether it needs to generate a notification.  
+   However, the MTA need not examine the message if it knows it can 
+   store and forward all media types.  Said differently, Internet e-
+   mail MTA can, by default, handle any arbitrary MIME-encapsulated 
+   type.  Some voice mail systems, on the other hand, cannot store 
+   binary attachments at all, such as application/ms-word.  The voice 
+   mail MTA, in this example, would be scanning for non-renderable body 
+   parts in any event.  
+    
+  4.1. CRITICAL 
+    
+   "Content-Criticality: CRITICAL" signifies that this body part is 
+   critical to the sender. 
+    
+   If the receiving system cannot render or store a body part marked 
+   CRITICAL, then the entire message has failed.  In this case, the 
+   receiving system MUST take the appropriate failure action. 
+    
+   NOTE: We say "appropriate action", because the sender may have 
+   suppressed all notifications.  In this case, the appropriate action 
+   is to simply discard the message. 
+    
+  4.2. IGNORE 
+    
+   "Content-Criticality: IGNORE" signifies that the sender does not 
+   care about notification reports for this body part. 
+    
+   If the receiving system cannot render or store a body part marked 
+   IGNORE, the receiving system may silently delete the body part.  The 
+   receiving system MUST NOT return a delivery failure, unless parts 
+   marked IMPORTANT or CRITICAL have also failed. 
+    
+  4.3. Other Values 
+    
+   The receiving system MUST treat unrecognized values as CRITICAL.  
+   This is to provide backward compatibility with future uses of the 
+   Content-Criticality entity. 
+    
+   The most likely new value is IMPORTANT.  An IMPORTANT body part is 
+   something the sender wants the receiver to get, but would not want 
+   the message rejected outright if the IMPORTANT body part fails.  A 
+   receiving system that does not understand IMPORTANT MUST take the 
+   default value of CRITICAL.  In this case, the MTA or UA MUST take 
+   the conservative action of rejecting the message. 
+     
+
+
+
+
+
+  
+Burger and Candell         Expires 5/24/01                    [Page 6] 
+                  Critical Content of Internet Mail      November 2000   
+ 
+  4.4. Summary 
+    
+   The following table summarizes the actions expected of a conforming 
+   MTA or UA. 
+    
+   NOTE: This section is normative: it suggests what to put into the 
+   DSN or MDN.  
+                            +--------------------------------------+ 
+                            |    Sending UA Has Marked Body Part   | 
+                            |---------------------+----------------| 
+                            |      CRITICAL       |     IGNORE     | 
+       +--------------------+---------------------+----------------+ 
+       | Body Part is       |                     |                | 
+       | Deliverable/read   | Appropriate Action  |     ignore     | 
+       +--------------------+---------------------+----------------+ 
+       | Body Part is       |                     |                | 
+       | Undeliverable /    |                     |                | 
+       |  Unreadable        | Fail Entire Message |     ignore     | 
+       +--------------------+--------------------------------------+ 
+    
+   The distinction between deliverable/read is as follows.  A MTA can 
+   determine if a body part is deliverable.  If the body part is not 
+   deliverable and is critical, the MTA could generate a DSN.  An 
+   example of such a MTA is a content-converting gateway. 
+    
+   An UA can determine if a body part is readable.  If the body part is 
+   not readable and is critical the UA could generate a MDN.  
+    
+   The "Appropriate Action" is the action the MTA or UA would take 
+   given the context of execution.  For example, if a sender requests 
+   return receipt and the receiver reads a CRITICAL body part, the 
+   receiving UA must generate the appropriate MDN (following the rules 
+   for MDN).  Likewise, if the MTA or UA cannot deliver the body part 
+   and the body part is critical, the MTA or UA MUST generate the 
+   appropriate DSN or MDN.  
+    
+   "Ignore" means the MTA or UA MUST ignore the operation on the body 
+   part.  The MTA or UA MUST treat the message as if the body part was 
+   not present in the message. 
+    
+    
+5. Status Code 
+    
+   The critical content indication, in itself, does not guarantee any 
+   notification.  Notification follows the rules described in [7] and 
+   [8]. 
+    
+   NOTE: The content of actual DSNs or MDNs are beyond the scope of 
+   this document.  This document only specifies how to mark a critical 
+   body part.  On the other hand, we do envision sensible DSN and MDN 
+   contents.  For example, DSNs should include the appropriate failure 
+
+  
+Burger and Candell         Expires 5/24/01                    [Page 7] 
+                  Critical Content of Internet Mail      November 2000   
+ 
+   code as enumerated in [10].  Likewise, MDNs should include the 
+   failure code in the MDN "Failure:" field. 
+    
+   If the receiving system is to generate a notification based on its 
+   inability to render or store the media type, the notification MUST 
+   include the status code 5.6.1, "Media not supported", from [10]. 
+ 
+    
+    
+6. Backward Compatibility Considerations 
+    
+   If there are no Content-Criticality entities in the message, the 
+   default value for Content-Criticality is CRITICAL.  The standard 
+   notification mechanisms work for sending user agents (UA) that do 
+   not know about the content notification entity.  All body parts are 
+   critical, because they have the default marking of CRITICAL. 
+    
+   If there is at least one Content-Criticality entity in the message, 
+   the default value for unspecified body parts is IGNORE.  The 
+   philosophy is that UAs, especially manually constructed messages, 
+   will explicitly mark the critical body parts. 
+    
+   NOTE: We could choose the default value for Content-Criticality to 
+   be IGNORE.  This would make VPIMv2 automatically compliant with this 
+   document, as VPIMv2 has provision to silently delete undeliverable 
+   parts.  However, VPIMv2 systems should not be receiving arbitrary e-
+   mail from the Internet.  If they do, they should be compliant with 
+   this series of documents.  By defaulting to CRITICAL, this draft is 
+   compliant with the rest of the Internet infrastructure. 
+    
+   NOTE: Some VPIMv2 implementations can receive arbitrary e-mail from 
+   the Internet.  However, these systems are really acting in the 
+   capacity of an Internet Voice Mail system.  In this case, one would 
+   expect the implementation to provide Internet Voice Mail semantics 
+   to Internet Voice Mail messages. 
+    
+ 
+7. MIME Interactions 
+    
+  7.1. multipart/alternative 
+    
+   Content-Criticality is only in effect for the selected alternative.  
+   If the selected alternative has the critical content indicator, then 
+   the entire alternative takes on the criticality indicated.  That is, 
+   if the alternative selected has Content-Criticality: IGNORE, then 
+   the receiving system MUST NOT generate any delivery notifications 
+   (MDN, NDN, return-receipt, etc.). 
+    
+   It is unlikely for a selected alternative to fail, as the receiving 
+   UA presumably picks the alternative specifically because it can 
+   render it.  
+    
+  
+Burger and Candell         Expires 5/24/01                    [Page 8] 
+                  Critical Content of Internet Mail      November 2000   
+ 
+   If the selected alternative is a message/rfc822 that encloses a 
+   multipart MIME message or the selected alternative is itself a 
+   multipart MIME type, the individual top-level body parts follow the 
+   Content-Criticality mechanism described in this document. 
+    
+  7.2. multipart/related 
+    
+   Content-Criticality fits in rather well with the multipart/related 
+   construction.  For example, consider a multipart/related message 
+   consisting of a Macintosh data fork and a Macintosh resource fork.  
+   For a Microsoft Word document, the data fork is likely to be 
+   critical.  The receiving system can safely ignore the resource fork. 
+    
+  7.3. message/rfc822 
+    
+   Content-Criticality only affects the outermost level of the message 
+   or, in the case of multipart/alternative, the outermost level of the 
+   selected alternative.  Specifically, the receiving system ignores 
+   Content-Criticality indicators in embedded body parts.  This avoids 
+   the situation of a forwarded message triggering or suppressing 
+   undesired or desired reporting. 
+    
+    
+8. Implementation Examples 
+    
+   This section is not a normative part of the definition of Content-
+   Criticality.  However, we hope it helps implementers to understand 
+   the mechanics of the Content-Criticality mechanism. 
+    
+   We will examine two cases.  They are how a content gateway processes 
+   a message and how a UA processes a message. 
+    
+  8.1. Content Gateways 
+    
+   Content gateways examine the contents of a message from a first 
+   network before the gateway forwards the message to a second network.  
+   For the purposes of this example, we assume the second network has 
+   less capability than the first network.  In particular, we expect 
+   there will be certain message body types that the gateway cannot 
+   pass onto the second network. 
+    
+   Consider a gateway between the Internet and a text-only short 
+   message service.  A message comes through the gateway containing a 
+   text part and a tnef part.  The sender marks the text part CRITICAL.  
+   The gateway, knowing the capability of the short message service, 
+   silently deletes the non-critical, tnef part, passing the critical 
+   content to the shore message service network.  Any subsequent 
+   notifications, such as failure notices or delivery notices, follow 
+   the normal rules for notification. 
+    
+   Note the gateway, by silently deleting non-critical content, may 
+   affect proprietary message correlation schemes.  One can envision 
+  
+Burger and Candell         Expires 5/24/01                    [Page 9] 
+                  Critical Content of Internet Mail      November 2000   
+ 
+   the sending UA inserting a body part for tracking purposes.  By 
+   deleting non-critical content, the content gateway will break such a 
+   scheme.  If a sending UA understands how to mark critical content, 
+   it should use Internet standard mechanisms for tracking messages, 
+   such as Message-ID [11]. 
+    
+   What if no body parts have critical content indicators?  In this 
+   case, the entire message is critical.  Thus, when the gateway sees 
+   the tnef part, it will reject the entire message, generating a DSN 
+   with a status code 5.6.1, "Media not supported". 
+    
+   Likewise, consider a three part message with a text annotation (part 
+   1) to a voice message (part 2) with a vCard [12] (part 3).  The 
+   sender marks the first two parts CRITICAL.  Now, let us assume the 
+   receiving MTA (gateway) is a voice mail only system, without even 
+   the capability to store text.  In this case, the gateway (receiving 
+   MTA) will reject the message, generating a DSN with a status code 
+   5.6.1, "Media not supported". 
+ 
+  8.2. Non-Traditional UA 
+    
+   For this example, we will examine the processing of a three-part 
+   message.  The first part is a text annotation of the second part, an 
+   audio message.  The third part is the sender's vCard.  The sender 
+   marks the first and second parts CRITICAL.  In addition, the sender 
+   marks the message for read receipt. 
+    
+   For the purposes of example, the telephone user interface (TUI) does 
+   not perform text-to-speech conversion.  A TUI is a mail user agent 
+   (UA) that uses DTMF touch-tone digits for input and audio for output 
+   (display). 
+    
+   The TUI is unable to render the first part of the message, the text 
+   part.  In addition, it is unable to render the third part of the 
+   message, the vCard part.  Since the sender did not mark the third 
+   part of the message CRITICAL, the system ignores the failure of the 
+   TUI to render the third part of the message.  However, since the 
+   sender did mark the first part CRITICAL, and the TUI is unable to 
+   render text, the message fails. 
+    
+   What happens next is implementation dependent.  If the TUI is part 
+   of a unified messaging system, a reasonable action is to hold the 
+   message for the user.  The user can access the message at a later 
+   time from a terminal that can render all of the critical body parts.  
+   It would be reasonable for the TUI to notify the user about the 
+   message. 
+    
+   If the TUI is part of a voice messaging system, or if the user does 
+   not subscribe to a text-to-speech service, a reasonable action is 
+   for the TUI to return a MDN with the disposition "failed" and the 
+   failure modifier "5.6.1 (Media not supported)". 
+    
+  
+Burger and Candell         Expires 5/24/01                   [Page 10] 
+                  Critical Content of Internet Mail      November 2000   
+ 
+    
+9. Security Considerations 
+ 
+   Receiving systems and users should not place any authentication 
+   value on the Content-Criticality entity.  Just because a message has 
+   a particular Content-Criticality value doesn't mean that the message 
+   really originated at a given type of system. 
+    
+    
+10. Collected Syntax 
+    
+   The format of the collected syntax is in accordance with the ABNF of 
+   [13].  Note that per RFC 2045, none of the strings are case 
+   sensitive. 
+    
+    
+        "Content-Criticality" ":" notification-type CRLF 
+    
+        notification-type = "CRITICAL" / "IGNORE" 
+    
+    
+ 
+11. References 
+    
+ 
+   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
+      9, RFC 2026, October 1996. 
+    
+   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
+      Levels", BCP 14, RFC 2119, March 1997. 
+    
+   3  Freed, N. and Borenstein, N., "Multipurpose Internet Mail 
+      Extensions (MIME) Part One: Format of Internet Message Bodies", 
+      RFC 2045, Innosoft and First Virtual, November 1996. 
+    
+   4  Freed, N. and Borenstein, N., "Multipurpose Internet Mail 
+      Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft and 
+      First Virtual, November 1996. 
+    
+   5  Vaudreuil, G. and Parsons, G., "Voice Profile for Internet Mail - 
+      version 2", RFC 2321, Lucent Technologies and Nortel Networks, 
+      September 1998. 
+    
+   6  Burger, E., "Partial Non-Delivery Notification", Work in 
+      Progress, draft-ema-burger-pndn-01.txt, March 2000. 
+    
+   7  Moore, K. and Vaudreuil, G., "An Extensible Message Format for 
+      Delivery Status Notifications", RFC 1894, University of Tennessee 
+      and Octel Network Services, January 1996. 
+     
+
+
+  
+Burger and Candell         Expires 5/24/01                   [Page 11] 
+                  Critical Content of Internet Mail      November 2000   
+ 
+ 
+   8  Fajman, R., "An Extensible Message Format for Message Disposition 
+      Notifications", RFC 2298, National Institutes of Health, March 
+      1998. 
+    
+   9  Moore, K., "SMTP Service Extension for Delivery Status 
+      Notifications", RFC 1981, University of Tennessee, January 1996. 
+    
+   10 Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, 
+      Octel Network Services, January 1996. 
+    
+   11 Crocker, D., "Standard for the Format of ARPA Internet Text 
+      Messages", RFC 822, University of Delaware, August 1982. 
+    
+   12 Dawson, F. and Howes, T., "vCard MIME Directory Profile", RFC 
+      2426, Lotus Development Corporation and Netscape Communications, 
+      September 1998. 
+    
+   13 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 
+      Specifications: ABNF", RFC 2234, Internet Mail Consortium and 
+      Demon Internet Ltd., November 1997. 
+    
+    
+    
+    
+12. Acknowledgments 
+    
+   We'd like to thank Ned Freed for pointing out that this mechanism 
+   was about criticality, not notification per se.  That insight made 
+   the concept and descriptions infinitely more straightforward.  If 
+   it's still confusing, it's our fault! 
+    
+   We'd also like to thank Keith Moore for helping us tighten-up our 
+   explanations. 
+    
+   Dropping the IMPORTANT critical content type took away one of the 
+   reasons for partial non-delivery notification.  That makes Jutta 
+   Degener very happy! 
+    
+   Harald Alvestrand and Chris Newman suggested we add implementation 
+   examples, which we did. 
+    
+    
+
+
+
+
+
+
+
+
+
+  
+Burger and Candell         Expires 5/24/01                   [Page 12] 
+                  Critical Content of Internet Mail      November 2000   
+ 
+13. Author's Addresses 
+    
+   Eric Burger 
+   SnowShore Networks 
+   c/o CRV 
+   1000 Winter St. 
+   Waltham, MA  02451 
+   USA 
+    
+   Phone: +1 703/304-3883 
+   Email: e.burger@ieee.org 
+    
+    
+   Emily Candell 
+   Comverse Network Systems 
+   200 Quannapowitt Pkwy. 
+   Wakefield, MA  01880 
+   USA 
+    
+   Phone: +1 781/213-2324 
+   Email: emily@comversens.com 
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Burger and Candell         Expires 5/24/01                   [Page 13] 
+                  Critical Content of Internet Mail      November 2000   
+ 
+ 
+Full Copyright Statement 
+
+   The IETF takes no position regarding the validity or scope of any 
+   intellectual property or other rights that might be claimed to  
+   pertain to the implementation or use of the technology described in 
+   this document or the extent to which any license under such rights 
+   might or might not be available; neither does it represent that it 
+   has made any effort to identify any such rights.  Information on the 
+   IETF's procedures with respect to rights in standards-track and 
+   standards-related documentation can be found in BCP-11.  Copies of 
+   claims of rights made available for publication and any assurances 
+   of licenses to be made available, or the result of an attempt made 
+   to obtain a general license or permission for the use of such 
+   proprietary rights by implementers or users of this specification 
+   can be obtained from the IETF Secretariat. 
+    
+   The IETF invites any interested party to bring to its attention any 
+   copyrights, patents or patent applications, or other proprietary 
+   rights that may cover technology that may be required to practice 
+   this standard.  Please address the information to the IETF Executive 
+   Director. 
+    
+   Copyright (C) 2000 The Internet Society.  All Rights Reserved. 
+    
+   This document and translations of it may be copied and furnished to 
+   others, and derivative works that comment on or otherwise explain it 
+   or assist in its implementation may be prepared, copied, published 
+   and distributed, in whole or in part, without restriction of any 
+   kind, provided that the above copyright notice and this paragraph 
+   are included on all such copies and derivative works.  However, this 
+   document itself may not be modified in any way, such as by removing 
+   the copyright notice or references to the Internet Society or other 
+   Internet organizations, except as needed for the  purpose of 
+   developing Internet standards in which case the procedures for 
+   copyrights defined in the Internet Standards process must be 
+   followed, or as required to translate it into languages other than 
+   English. 
+    
+   The limited permissions granted above are perpetual and will not be 
+   revoked by the Internet Society or its successors or assigns. 
+    
+   This document and the information contained herein is provided on an 
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
+
+
+
+
+
+  
+Burger and Candell         Expires 5/24/01                   [Page 14] 
+
diff --git a/doc/devel/I-D/draft-ietf-vpim-cc-03.txt b/doc/devel/I-D/draft-ietf-vpim-cc-03.txt
new file mode 100644
index 00000000..d6a549d7
--- /dev/null
+++ b/doc/devel/I-D/draft-ietf-vpim-cc-03.txt
@@ -0,0 +1,894 @@
+
+Network Working Group                                           E. Burger
+Internet Draft                                         SnowShore Networks
+Document: draft-ietf-vpim-cc-03.txt                            E. Candell
+Category: Standards Track                        Comverse Network Systems
+Expires September 2001                                      March 2, 2001
+ 
+ 
+                   Critical Content of Internet Mail 
+ 
+ 
+Status of this Memo 
+ 
+   This document is an Internet-Draft and is in full conformance with 
+   all provisions of Section 10 of RFC 2026 [1].  
+    
+   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." 
+    
+   One can access the list of current Internet-Drafts at 
+   http://www.ietf.org/ietf/1id-abstracts.txt 
+    
+   One can access the list of Internet-Draft Shadow Directories at 
+   http://www.ietf.org/shadow.html. 
+    
+   This document is a work product of the IETF Voice Profile for 
+   Internet Mail (VPIM) Work Group.  The URL for the VPIM website is 
+   <http://www.vpim.org>. 
+    
+    
+1. Abstract 
+    
+   This document describes a mechanism for identifying the body parts 
+   that the sender deems critical in a multi-part Internet mail 
+   message. 
+    
+   By knowing what parts of a message the sender deems critical, a 
+   content gateway can intelligently handle multi-part messages when 
+   gatewaying 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 of the receiving system. 
+
+
+
+ 
+                            Expires 9/2/01                    [Page 1] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+Table of Contents 
+    
+1.  Abstract .........................................................1 
+2.  Conventions used in this document ................................2 
+3.  Introduction .....................................................3 
+4.  Content-Criticality Entity .......................................3 
+4.1.  CRITICAL .......................................................4 
+4.2.  IGNORE .........................................................4 
+4.3.  Default Values .................................................4 
+4.4.  Other Values ...................................................5 
+4.5.  DSN vs MDN Generation ..........................................5 
+4.6.  Summary ........................................................5 
+5.  Status Code ......................................................6 
+6.  Requirements for Critical Content ................................6 
+6.1.  Needs ..........................................................6 
+6.2.  Current Approaches .............................................8 
+6.3.  Critical-Content Entity ........................................8 
+7.  The Content Gateway ..............................................9 
+7.1.  Integrated Content Gateway .....................................9 
+7.2.  Disaggregated Delivery Network .................................9 
+8.  Backward Compatibility Considerations ...........................10 
+9.  MIME Interactions ...............................................10 
+9.1.  multipart/alternative .........................................10 
+9.2.  multipart/related .............................................10 
+9.3.  message/rfc822 ................................................11 
+10. Implementation Examples .........................................11 
+10.1. Content Gateways ..............................................11 
+10.2. Disaggregated Content Gateway .................................12 
+11. Security Considerations .........................................12 
+12. Collected Syntax ................................................13 
+13. References ......................................................13 
+14. Acknowledgments .................................................14 
+15. Author's Addresses ..............................................15 
+    
+    
+2. Conventions used in this document 
+    
+   This document refers generically to the sender of a message in the 
+   masculine (he/him/his) and the recipient of the message in the 
+   feminine (she/her/hers).  This convention is purely for convenience 
+   and makes no assumption about the gender of a message sender or 
+   recipient. 
+    
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
+   this document are to be interpreted as described in RFC 2119 [2]. 
+    
+
+  
+Burger and Candell          Expires 9/2/01                    [Page 2] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+   NOTE: Notes, such at this one, provide additional nonessential 
+   information that the reader may skip without missing anything 
+   essential.  The primary purpose of these non-essential notes is to 
+   convey information about the rationale of this document, or to place 
+   this document in the proper historical or evolutionary context.  
+   Readers whose sole purpose is to construct a conformant 
+   implementation may skip such information.  However, it may be of use 
+   to those who wish to understand why we made certain design choices. 
+    
+    
+3. Introduction 
+ 
+   The specification of Critical Content is small and compact.  For the 
+   benefit of developers, the specification comes first, the rationale 
+   after. 
+    
+   The content gateway issues notifications to the sender if the 
+   receiving user agent cannot deliver a critical part of the message.  
+   Conversely, the content gateway silently deletes parts of the 
+   message that the receiving user agent cannot receive. 
+    
+   One concept that an implementer must understand is the content 
+   gateway.  Section 7 describes the content gateway.  In brief, a 
+   content gateway has knowledge of the receiving system's 
+   capabilities.  The content gateway passes messages the receiving 
+   system can render or store.  The content gateway can modify a 
+   message, for example by deleting unrenderable or storable body 
+   parts, for delivery to the receiving system.  Finally, the content 
+   gateway can reject a message that the receiving system cannot 
+   handle. 
+    
+4. Content-Criticality Entity 
+    
+   The Content-Criticality field is a MIME body part header inserted by 
+   the sending UA to indicate to the content gateway whether to 
+   consider the marked body part critical. 
+    
+   A CRITICAL body part is one the sender requires the receiving system 
+   to deliver for him to consider the message delivered. 
+    
+   An IGNORE body part is one the sender doesn't care whether the 
+   receiving system delivers it or not.  A content gateway can silently 
+   delete such body parts if the receiving system cannot deliver the 
+   part. 
+    
+   The terms "entity" and "body part" have the meanings defined in [7]. 
+    
+   One obvious application of critical content is generating a 
+   (non-)delivery message.  If the value of the field is IGNORE, the 
+   content gateway MUST NOT generate a notification.  If the value of 
+   the field is CRTITICAL, the content gateway MAY generate a 
+   notification, based on the normal notification request mechanisms.  
+  
+Burger and Candell          Expires 9/2/01                    [Page 3] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+   Normal notification request mechanisms include the SMTP RCPT NOTIFY 
+   command [3] and the Disposition-Notification-To header [5]. 
+    
+   For example, if the sending system requests a notification, and a 
+   CRITICAL part fails, the content gateway will generate a NDN for the 
+   whole message.  Conversely, if the gateway cannot pass on a body 
+   part marked IGNORE, the gateway will not generate a NDN.  
+    
+   The next sections examine the actions taken by the content gateway, 
+   given the different values of Content-Criticality. 
+    
+   NOTE: This implies that the content gateway must examine the entire 
+   message to determine whether it needs to generate a notification.  
+   However, the content gateway need not examine the message if it 
+   knows it can store and forward all media types.  Said differently, 
+   Internet e-mail MTAs or gateways can, by default, handle any 
+   arbitrary MIME-encapsulated type.  Some voice mail systems, on the 
+   other hand, cannot store binary attachments at all, such as 
+   application/ms-word.  The voice mail content gateway, in this 
+   example, would be scanning for non-renderable body parts in any 
+   event.  
+    
+4.1. CRITICAL 
+    
+   "Content-Criticality: CRITICAL" signifies that this body part is 
+   critical to the sender. 
+    
+   If the content gateway cannot pass a body part marked CRITICAL, then 
+   the entire message has failed.  In this case, the content gateway 
+   MUST take the appropriate failure action. 
+    
+   NOTE: We say "appropriate action", because the sender may have 
+   suppressed all notifications.  In this case, the appropriate action 
+   is to silently discard the message. 
+    
+4.2. IGNORE 
+    
+   "Content-Criticality: IGNORE" signifies that the sender does not 
+   care about notification reports for this body part. 
+    
+   If the content gateway cannot pass a body part marked IGNORE, the 
+   receiving system may silently delete the body part.  The receiving 
+   system MUST NOT return a delivery failure, unless parts marked 
+   IMPORTANT or CRITICAL have also failed. 
+    
+4.3. Default Values 
+    
+   The default value for Content-Criticality for a given body part is 
+   CRITICAL.  This enables the existing notification mechanisms to work 
+   for user agents that do not know about the content notification 
+   entity.  All body parts are critical, because they have the default 
+   marking of CRITICAL. 
+  
+Burger and Candell          Expires 9/2/01                    [Page 4] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+    
+   NOTE: Remember that critical content processing is a function of the 
+   content gateway, and not the MTA or UA.  In practice, the entity 
+   performing content gateway processing is the receiving UA.  However, 
+   it is acting as a content gateway.  Thus the default action for any 
+   MIME-compliant user agent to ignore unrecognized MIME entities 
+   ensures that this mechanism is compatible with the Internet 
+   architecture. 
+    
+   NOTE: Some VPIMv2 implementations can receive arbitrary e-mail from 
+   the Internet.  However, these systems are really acting in the 
+   capacity of an Internet Voice Mail system.  In this case, one would 
+   expect the implementation to provide Internet Voice Mail semantics 
+   to Internet Voice Mail messages. 
+    
+    
+    
+4.4. Other Values 
+    
+   The content gateway MUST treat unrecognized values as CRITICAL.  
+   This is to provide backward compatibility with future uses of the 
+   Content-Criticality entity. 
+    
+   The most likely new value is IMPORTANT.  An IMPORTANT body part is 
+   something the sender wants the receiver to get, but would not want 
+   the message rejected outright if the IMPORTANT body part fails.  A 
+   content gateway that does not understand IMPORTANT MUST take the 
+   default value of CRITICAL.  This is because the content gateway has 
+   to take the conservative action of rejecting the message. 
+     
+4.5. DSN vs MDN Generation 
+    
+   The content gateway generates a delivery status notification (DSN) 
+   [4] if it operates as a gateway.  The content gateway generates a 
+   Message Disposition Notification (MDN) [5] if it operates as a user 
+   agent.  Section 7 describes the operating modes of a content 
+   gateway.  In short, if there is a MTA that "delivers" the message to 
+   the content gateway for processing, the MTA takes responsibility for 
+   DSN processing.  In this case, the only option available to the 
+   content gateway is to generate MDNs.  If the content gateway 
+   operates as a MTA, then it generates DSNs.  DSN generation is the 
+   preferred option. 
+    
+    
+4.6. Summary 
+    
+   The following table summarizes the actions expected of a conforming 
+   content gateway. 
+    
+   NOTE: This section is normative: it suggests what to put into the 
+   DSN or MDN.  
+
+  
+Burger and Candell          Expires 9/2/01                    [Page 5] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+                            +--------------------------------------+ 
+                            |    Sending UA Has Marked Body Part   | 
+                            |---------------------+----------------| 
+                            |      CRITICAL       |     IGNORE     | 
+       +--------------------+---------------------+----------------+ 
+       | Body Part is       |                     |                | 
+       | Deliverable        | Appropriate Action  |     ignore     | 
+       +--------------------+---------------------+----------------+ 
+       | Body Part is       |                     |                | 
+       | Undeliverable      | Fail Entire Message |     ignore     | 
+       +--------------------+--------------------------------------+ 
+    
+    
+   The "Appropriate Action" is the action the content gateway would 
+   take given the context of execution.  For example, if a sender 
+   requests return receipt and the receiver reads a CRITICAL body part, 
+   the receiving UA must generate the appropriate MDN (following the 
+   rules for MDN).  Likewise, if the content gateway cannot deliver the 
+   body part and the body part is critical, the content gateway 
+   generates the appropriate DSN or MDN.  
+    
+   "Ignore" means the content gateway ignores the disposition of the 
+   body part.  The content gateway treats the message as if the body 
+   part was not present in the message. 
+    
+    
+5. Status Code 
+    
+   The critical content indication, in itself, does not guarantee any 
+   notification.  Notification follows the rules described in [4] and 
+   [5]. 
+    
+   NOTE: The content of actual DSNs or MDNs are beyond the scope of 
+   this document.  This document only specifies how to mark a critical 
+   body part.  On the other hand, we do envision sensible DSN and MDN 
+   contents.  For example, DSNs should include the appropriate failure 
+   code as enumerated in [6].  Likewise, MDNs should include the 
+   failure code in the MDN "Failure:" field. 
+    
+   If the receiving system is to generate a notification based on its 
+   inability to render or store the media type, the notification MUST 
+   include the status code 5.6.1, "Media not supported", from [6]. 
+    
+    
+6. Requirements for Critical Content 
+    
+6.1. Needs 
+    
+   The need for a critical content identification mechanism comes about 
+   because of the internetworking of Internet mail systems with 
+   messaging systems that do not fulfill all of the semantics of 
+   Internet mail.  Such legacy systems have a limited ability to render 
+  
+Burger and Candell          Expires 9/2/01                    [Page 6] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+   or store all parts of a given message.  This document will use the 
+   case of an Internet mail system exchanging electronic messages with 
+   a legacy voice messaging system for illustrative purposes. 
+    
+   Electronic mail has historically been text-centric.  Extensions such 
+   as MIME [7] enable the user agents to send and receive multi-part, 
+   multimedia messages.  Popular multimedia data types include binary 
+   word processing documents, binary business presentation graphics, 
+   voice, and video. 
+    
+   Voice mail has historically been audio-centric.  Many voice-
+   messaging systems only render voice.  Extensions such as fax enable 
+   the voice mail system to send and receive fax images as well as 
+   create multi-part voice and fax messages.  A few voice mail systems 
+   can render text using text-to-speech or text-to-fax technology.  
+   Although theoretically possible, none can today render video. 
+    
+   An important aspect of the interchange between voice messaging 
+   services and desktop e-mail client applications is that the 
+   rendering capability of the voice-messaging platform is often much 
+   less than the rendering capability of a desktop e-mail client.  In 
+   the e-mail case, the sender has the expectation that the recipient 
+   receives all components of a multimedia message.  This is so even if 
+   the recipient cannot render all body parts.  In most cases, the 
+   recipient can either find the appropriate rendering tool or tell the 
+   sender that she cannot read the particular attachment. 
+    
+   This is an important issue.  By definition, a MIME-enabled user 
+   agent, conforming to [8], will present or make available all of the 
+   body parts to the recipient.  However, a voice mail system may not 
+   be capable of storing non-voice objects.  Moreover, the voice mail 
+   system may not be capable of notifying the recipient that there were 
+   undeliverable message parts. 
+    
+   The inability of the receiving system to render a body part is 
+   usually a permanent failure.  Retransmission of the message will not 
+   improve the likelihood of a future successful delivery.  Contrast 
+   this with the case with normal data delivery.  Traditional message 
+   failures, such as a garbled message or disabled link will benefit 
+   from retransmission. 
+    
+   This situation is fundamentally different from normal Internet mail.  
+   In the Internet mail case, either the system delivered the message, 
+   or it didn't.  There is no concept of a system partially delivering 
+   a message. 
+ 
+   In addition, there are many situations where the sender would not 
+   mind if the system did not deliver non-critical parts of a message.  
+   For example, the sender's user agent may add body parts to a message 
+   unbeknownst to the sender.  If the receiving system rejected the 
+   message because it could not render a hidden body part, the sender 
+   would be understandably confused and upset. 
+  
+Burger and Candell          Expires 9/2/01                    [Page 7] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+    
+   Thus, there is a need for a method of indicating to a Mail Transfer 
+   Agent (MTA) or User Agent (UA) that the sender considers parts of a 
+   message to be critical.  From the sender's perspective, he would not 
+   consider the message delivered if the system did not deliver the 
+   critical parts. 
+    
+6.2. Current Approaches 
+    
+   One method of indicating critical content of a message is to define 
+   a profile.  The profile defines rules for silently deleting mail 
+   body parts based on knowledge of the UA capabilities.  Citing the 
+   example above, a voice profile can easily declare that MTAs or UAs 
+   can silently delete TNEF data and yet consider the message 
+   successfully delivered.  This is, in fact, the approach taken by 
+   VPIMv2 [9]. 
+    
+   Since one aspect of the issue is deciding when to notify the sender 
+   that the system cannot deliver part of a message, one could use a 
+   partial non-delivery notification mechanism to indicate a problem 
+   with delivering a given body part.  However, this requires the user 
+   request a MDN. 
+    
+   A straightforward alternative implementation method for marking a 
+   body part critical is to use a content-disposition parameter called 
+   "criticality".  This would have the benefit of being very easy for 
+   IMAP servers to implement.  In particular, IMAP servers 
+   automatically present the content-disposition entity when a client 
+   requests information on a message.  On the other hand, the client 
+   must explicitly request the presence and value of different 
+   entities, such as content-criticality.  However, implementing the 
+   critical content indicator as a parameter to content-disposition 
+   overloads the meaning of the entity.  Moreover, IMAP servers can 
+   present, in the future, content-criticality by default.  Lastly, 
+   most clients that have interest in content-criticality will 
+   explicitly request the header in any event. 
+    
+   In short, we need a way of letting the sender indicate what body-
+   parts he considers to be critical.  The mechanism must not burden 
+   the sender with failure notifications for non-critical body parts.  
+   The mechanism must conform to the general notification status 
+   request mechanism for positive or negative notification.  When 
+   requested, the mechanism must indicate to the sender when a 
+   receiving system cannot deliver a critical body part. 
+    
+    
+6.3. Critical-Content Entity 
+    
+   The Critical Content marking mechanism satisfies these needs.  
+   Following the format for Internet message bodies [7], this document 
+   introduces the Content-Criticality body part header.  Values for 
+   this header are CRITICAL or IGNORE. 
+  
+Burger and Candell          Expires 9/2/01                    [Page 8] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+    
+7. The Content Gateway 
+    
+   In this section, we use the definition of [10] for the term 
+   "gateway." 
+    
+   A content gateway is a gateway that connects a first network to a 
+   second network.  The second network often has lesser capability than 
+   the first network.  The canonical topology follows.  The "[MTA]" 
+   signifies an optional component. 
+    
+                             +---------+ 
+   +---------+     +-----+   |         |     +-------+   +-----------+ 
+   | Sending |=...=|[MTA]|===| Content |=...=| [MTA] |===| Receiving | 
+   |   UA    |     +-----+   | Gateway |     +-------+   |    UA     | 
+   +---------+               |         |                 +-----------+ 
+                             +---------+ 
+          First Network                         Second Network 
+    
+    
+   The content gateway can be the last hop before the receiving MTA.  
+   The content gateway can be between networks, and thus not the last 
+   hop before the receiving MTA.  The content gateway can be the first 
+   MTA the sending UA contacts.  Finally, the content gateway can be an 
+   integrated component of the receiving MTA. 
+    
+    
+7.1. Integrated Content Gateway 
+    
+   In this situation, the receiving user agent is integrated with the 
+   content gateway. The integrated content gateway knows the 
+   capabilities of the user agent.  The topology is as follows. 
+    
+                             +---------------------+ 
+   +---------+     +-----+   |         :           | 
+   | Sending |=...=|[MTA]|===| Content : Receiving | 
+   |   UA    |     +-----+   | Gateway :    UA     | 
+   +---------+               |         :           | 
+                             +---------------------+ 
+          First Network           Second Network 
+    
+    
+7.2. Disaggregated Delivery Network 
+    
+   A degenerate case, although one that does occur, is where the 
+   content gateway sits behind the final MTA.  This happens when one 
+   implements the content gateway as a post-processing step to a normal 
+   delivery.  For example, one could configure a mail handling system 
+   to deliver the message to a queue or directory, where the content 
+   gateway process picks up the message.  If there were any directives 
+   for DSN processing, the delivering MTA would execute them.  For 
+   example, the message could have requested notification on successful 
+  
+Burger and Candell          Expires 9/2/01                    [Page 9] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+   delivery.  The delivering MTA, having delivered the message to the 
+   queue, would consider the message delivered and thus notify the 
+   sender of such.  However, the content gateway process could then 
+   discover that the receiving UA cannot render the message.  In this 
+   case, the content gateway generates a NDN, as it is the only option 
+   available. 
+    
+                           Delivered 
+                               |      +---------+ 
+   +---------+     +-----+     v      |         |     +-----------+ 
+   | Sending |=...=| MTA |--> File -->| Content |=...=| Receiving | 
+   |   UA    |     +-----+            | Gateway |     |    UA     | 
+   +---------+                        |         |     +-----------+ 
+                                      +---------+ 
+          First Network              Second Network 
+    
+    
+    
+8. Backward Compatibility Considerations 
+    
+   DSN requires ESMTP.  If MTAs in the path from the sending UA to the 
+   receiving UA do not support ESMTP, then that MTA will reject the DSN 
+   request.  In addition, the message will default to notification on 
+   delay or failure.  While not ideal, the sender will know that DSN is 
+   not available, and that critical content that fails will get 
+   notification. 
+    
+ 
+9. MIME Interactions 
+    
+9.1. multipart/alternative 
+    
+   Content-Criticality is only in effect for the selected alternative.  
+   If the selected alternative has the critical content indicator, then 
+   the entire alternative takes on the criticality indicated.  That is, 
+   if the alternative selected has Content-Criticality: IGNORE, then 
+   the content gateway MUST NOT generate any delivery notifications. 
+    
+   It is unlikely for a selected alternative to fail, as the content 
+   gateway presumably picks the alternative specifically because it can 
+   render it.  
+    
+   If the selected alternative is a message/rfc822 that encloses a 
+   multipart MIME message or the selected alternative is itself a 
+   multipart MIME type, the individual top-level body parts follow the 
+   Content-Criticality mechanism described in this document. 
+    
+9.2. multipart/related 
+    
+   Content-Criticality fits in rather well with the multipart/related 
+   construction.  For example, consider a multipart/related message 
+   consisting of a Macintosh data fork and a Macintosh resource fork.  
+  
+Burger and Candell          Expires 9/2/01                   [Page 10] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+   For a Microsoft Word document, the data fork is likely to be 
+   critical.  The receiving system can safely ignore the resource fork. 
+    
+9.3. message/rfc822 
+    
+   Content-Criticality only affects the outermost level of the message 
+   or, in the case of multipart/alternative, the outermost level of the 
+   selected alternative.  Specifically, the receiving system ignores 
+   Content-Criticality indicators in embedded body parts.  This avoids 
+   the situation of a forwarded message triggering or suppressing 
+   undesired reporting. 
+    
+    
+10. Implementation Examples 
+    
+   This section is not a normative part of the definition of Content-
+   Criticality.  However, we hope it helps implementers to understand 
+   the mechanics of the Content-Criticality mechanism. 
+    
+   We will examine two cases.  They are how a content gateway processes 
+   a message and how a disaggregated content gateway processes a 
+   message. 
+    
+10.1. Content Gateways 
+    
+   Content gateways examine the contents of a message from a first 
+   network before the gateway forwards the message to a second network.  
+   For the purposes of this example, we assume the second network has 
+   less capability than the first network.  In particular, we expect 
+   there will be certain message body types that the gateway cannot 
+   pass onto the second network. 
+    
+   Consider a gateway between the Internet and a text-only short 
+   message service.  A message comes through the gateway containing a 
+   text part and a tnef part.  The sender marks the text part CRITICAL.  
+   The gateway, knowing the capability of the short message service, 
+   silently deletes the non-critical, tnef part, passing the critical 
+   content to the short message service network.  Any subsequent 
+   notifications, such as failure notices or delivery notices, follow 
+   the normal rules for notification. 
+    
+   Note the gateway, by silently deleting non-critical content, may 
+   affect proprietary message correlation schemes.  One can envision 
+   the sending UA inserting a body part for tracking purposes.  By 
+   deleting non-critical content, the content gateway will break such a 
+   scheme.  If a sending UA understands how to mark critical content, 
+   it should use Internet standard mechanisms for tracking messages, 
+   such as Message-ID [11]. 
+    
+   What if no body parts have critical content indicators?  In this 
+   case, the entire message is critical.  Thus, when the gateway sees 
+
+  
+Burger and Candell          Expires 9/2/01                   [Page 11] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+   the tnef part, it will reject the entire message, generating a DSN 
+   with a status code 5.6.1, "Media not supported". 
+    
+   Likewise, consider a three part message with a text annotation (part 
+   1) to a voice message (part 2) with a vCard [12] (part 3).  The 
+   sender marks the first two parts CRITICAL.  Now, let us assume the 
+   receiving MTA (gateway) is a voice mail only system, without even 
+   the capability to store text.  In this case, the gateway, acting as 
+   the receiving MTA, will reject the message, generating a DSN with 
+   the status code 5.6.1, "Media not supported". 
+ 
+10.2. Disaggregated Content Gateway 
+    
+   For this example, we will examine the processing of a three-part 
+   message.  The first part is a text annotation of the second part, an 
+   audio message.  The third part is the sender's vCard.  The sender 
+   marks the first and second parts CRITICAL.  In addition, the sender 
+   marks the message for read receipt. 
+    
+   For the purposes of example, the telephone user interface (TUI) does 
+   not perform text-to-speech conversion.  A TUI is a mail user agent 
+   (UA) that uses DTMF touch-tone digits for input and audio for output 
+   (display). 
+    
+   The TUI is unable to render the first part of the message, the text 
+   part.  In addition, it is unable to render the third part of the 
+   message, the vCard part.  Since the sender did not mark the third 
+   part of the message CRITICAL, the system ignores the failure of the 
+   TUI to render the third part of the message.  However, since the 
+   sender did mark the first part CRITICAL, and the TUI is unable to 
+   render text, the message fails. 
+    
+   What happens next is implementation dependent.  If the TUI is part 
+   of a unified messaging system, a reasonable action is to hold the 
+   message for the user.  The user can access the message at a later 
+   time from a terminal that can render all of the critical body parts.  
+   It would be reasonable for the TUI to notify the user about the 
+   message. 
+    
+   If the TUI is part of a voice messaging system, or if the user does 
+   not subscribe to a text-to-speech service, a reasonable action is 
+   for the TUI to return a MDN with the disposition "failed" and the 
+   failure modifier "5.6.1 (Media not supported)". 
+    
+    
+11. Security Considerations 
+ 
+   Receiving systems and users should not place any authentication 
+   value on the Content-Criticality entity.  Just because a message has 
+   a particular Content-Criticality value doesn't mean that the message 
+   really originated at a given type of system. 
+    
+  
+Burger and Candell          Expires 9/2/01                   [Page 12] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+    
+12. IANA Considerations 
+    
+   None. 
+    
+    
+13. Collected Syntax 
+    
+   The format of the collected syntax is in accordance with the ABNF of 
+   [13].  Note that per RFC 2045, none of the strings are case 
+   sensitive. 
+    
+    
+        "Content-Criticality" ":" notification-type CRLF 
+    
+        notification-type = "CRITICAL" / "IGNORE" 
+    
+    
+ 
+14. References 
+    
+ 
+   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
+      9, RFC 2026, October 1996. 
+    
+   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
+      Levels", BCP 14, RFC 2119, March 1997. 
+    
+   3  Moore, K., "SMTP Service Extension for Delivery Status 
+      Notifications", RFC 1981, University of Tennessee, January 1996. 
+    
+   4  Moore, K. and Vaudreuil, G., "An Extensible Message Format for 
+      Delivery Status Notifications", RFC 1894, University of Tennessee 
+      and Octel Network Services, January 1996. 
+     
+   5  Fajman, R., "An Extensible Message Format for Message Disposition 
+      Notifications", RFC 2298, National Institutes of Health, March 
+      1998. 
+    
+   6  Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, 
+      Octel Network Services, January 1996. 
+    
+   7  Freed, N. and Borenstein, N., "Multipurpose Internet Mail 
+      Extensions (MIME) Part One: Format of Internet Message Bodies", 
+      RFC 2045, Innosoft and First Virtual, November 1996. 
+    
+   8  Freed, N. and Borenstein, N., "Multipurpose Internet Mail 
+      Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft and 
+      First Virtual, November 1996. 
+    
+
+
+  
+Burger and Candell          Expires 9/2/01                   [Page 13] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+ 
+   9  Vaudreuil, G. and Parsons, G., "Voice Profile for Internet Mail - 
+      version 2", RFC 2421, Lucent Technologies and Nortel Networks, 
+      September 1998. 
+    
+   10 Kille, S. "MIXER (Mime Internet X.400 Enhanced Relay): Mapping 
+      between X.400 and RFC 822/MIME", RFC 2156, Isode, January 1998. 
+    
+   11 Crocker, D., "Standard for the Format of ARPA Internet Text 
+      Messages", RFC 822, University of Delaware, August 1982. 
+    
+   12 Dawson, F. and Howes, T., "vCard MIME Directory Profile", RFC 
+      2426, Lotus Development Corporation and Netscape Communications, 
+      September 1998. 
+    
+   13 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 
+      Specifications: ABNF", RFC 2234, Internet Mail Consortium and 
+      Demon Internet Ltd., November 1997. 
+    
+    
+    
+    
+15. Acknowledgments 
+    
+   We'd like to thank Ned Freed for pointing out that this mechanism 
+   was about criticality, not notification per se.  That insight made 
+   the concept and descriptions infinitely more straightforward.  If 
+   it's still confusing, it's our fault! 
+    
+   We'd also like to thank Keith Moore for helping us tighten-up our 
+   explanations. 
+    
+   Dropping the IMPORTANT critical content type took away one of the 
+   reasons for partial non-delivery notification.  That makes Jutta 
+   Degener very happy! 
+    
+   Harald Alvestrand and Chris Newman suggested we add implementation 
+   examples, which we did. 
+    
+   Greg asked the key question that let us realize that critical 
+   content processing was a gateway, and not a MTA or UA function. 
+    
+    
+
+
+
+
+
+
+
+
+
+  
+Burger and Candell          Expires 9/2/01                   [Page 14] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+16. Author's Addresses 
+    
+   Eric Burger 
+   SnowShore Networks, Inc. 
+   285 Billerica Rd. 
+   Chelmsford, MA  01824-4120 
+   USA 
+    
+   Phone: +1 978 367 8403 
+   Fax:   +1 603 457 5944 
+   Email: e.burger@ieee.org 
+    
+    
+   Emily Candell 
+   Comverse Network Systems 
+   200 Quannapowitt Pkwy. 
+   Wakefield, MA  01880 
+   USA 
+    
+   Phone: +1 781 213 2324 
+   Email: emily@comversens.com 
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Burger and Candell          Expires 9/2/01                   [Page 15] 
+                  Critical Content of Internet Mail         March 2001   
+ 
+ 
+Full Copyright Statement 
+
+   The IETF takes no position regarding the validity or scope of any 
+   intellectual property or other rights that might be claimed to  
+   pertain to the implementation or use of the technology described in 
+   this document or the extent to which any license under such rights 
+   might or might not be available; neither does it represent that it 
+   has made any effort to identify any such rights.  Information on the 
+   IETF's procedures with respect to rights in standards-track and 
+   standards-related documentation can be found in BCP-11.  Copies of 
+   claims of rights made available for publication and any assurances 
+   of licenses to be made available, or the result of an attempt made 
+   to obtain a general license or permission for the use of such 
+   proprietary rights by implementers or users of this specification 
+   can be obtained from the IETF Secretariat. 
+    
+   The IETF invites any interested party to bring to its attention any 
+   copyrights, patents or patent applications, or other proprietary 
+   rights that may cover technology that may be required to practice 
+   this standard.  Please address the information to the IETF Executive 
+   Director. 
+    
+   Copyright (C) 2000, 2001 The Internet Society.  All Rights Reserved. 
+    
+   This document and translations of it may be copied and furnished to 
+   others, and derivative works that comment on or otherwise explain it 
+   or assist in its implementation may be prepared, copied, published 
+   and distributed, in whole or in part, without restriction of any 
+   kind, provided that the above copyright notice and this paragraph 
+   are included on all such copies and derivative works.  However, this 
+   document itself may not be modified in any way, such as by removing 
+   the copyright notice or references to the Internet Society or other 
+   Internet organizations, except as needed for the  purpose of 
+   developing Internet standards in which case the procedures for 
+   copyrights defined in the Internet Standards process must be 
+   followed, or as required to translate it into languages other than 
+   English. 
+    
+   The limited permissions granted above are perpetual and will not be 
+   revoked by the Internet Society or its successors or assigns. 
+    
+   This document and the information contained herein is provided on an 
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
+
+
+
+
+
+  
+Burger and Candell          Expires 9/2/01                   [Page 16] 
+
diff --git a/doc/devel/I-D/draft-ietf-vpim-cc-04.txt b/doc/devel/I-D/draft-ietf-vpim-cc-04.txt
new file mode 100644
index 00000000..0a5be272
--- /dev/null
+++ b/doc/devel/I-D/draft-ietf-vpim-cc-04.txt
@@ -0,0 +1,901 @@
+
+
+Network Working Group                                           E. Burger 
+Internet Draft                                         SnowShore Networks 
+Document: draft-ietf-vpim-cc-04.txt                                       
+Category: Standards Track                                                 
+Expires September 2001                                     March 30, 2001 
+ 
+ 
+                   Critical Content of Internet Mail 
+ 
+ 
+Status of this Memo 
+ 
+   This document is an Internet-Draft and is in full conformance with 
+   all provisions of Section 10 of RFC 2026 [1].  
+    
+   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." 
+    
+   One can access the list of current Internet-Drafts at 
+   http://www.ietf.org/ietf/1id-abstracts.txt 
+    
+   One can access the list of Internet-Draft Shadow Directories at 
+   http://www.ietf.org/shadow.html. 
+    
+   This document is a work product of the IETF Voice Profile for 
+   Internet Mail (VPIM) Work Group. 
+    
+    
+1. Abstract 
+    
+   This document describes a mechanism for identifying body parts that 
+   a sender deems critical in a multi-part Internet mail message [10].  
+   The mechanism described is a parameter to Content-Disposition. 
+    
+   By knowing what parts of a message the sender deems critical, a 
+   content gateway can intelligently handle multi-part messages when 
+   gatewaying 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. 
+ 
+                           Expires 9/30/01                   [Page 1] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+Table of Contents 
+    
+1. Abstract...........................................................1 
+2. Conventions used in this document..................................2 
+3. Introduction.......................................................3 
+4. Criticality Parameter..............................................3 
+4.1. CRITICAL.........................................................3 
+4.2. IGNORE...........................................................4 
+4.3. Default Values...................................................4 
+4.4. Other Values.....................................................4 
+5. Collected Syntax...................................................5 
+6. Notification.......................................................5 
+6.1. DSN vs MDN Generation............................................5 
+6.2. Summary..........................................................6 
+7. Status Code........................................................6 
+8. Requirements for Critical Content..................................7 
+8.1. Needs............................................................7 
+8.2. Current Approaches...............................................8 
+8.3. Criticality Parameter............................................9 
+9. The Content Gateway................................................9 
+9.1. Integrated Content Gateway.......................................9 
+9.2. Disaggregated Delivery Network..................................10 
+10. Backward Compatibility Considerations............................10 
+11. MIME Interactions................................................10 
+11.1. multipart/alternative..........................................10 
+11.2. multipart/related..............................................11 
+11.3. message/rfc822.................................................11 
+12. Implementation Examples..........................................11 
+12.1. Content Gateways...............................................11 
+12.2. Disaggregated Content Gateway..................................12 
+13. Security Considerations..........................................13 
+14. IANA Considerations..............................................13 
+15. References.......................................................13 
+16. Acknowledgments..................................................15 
+17. Author's Address.................................................15 
+    
+    
+2. Conventions used in this document 
+    
+   This document refers generically to the sender of a message in the 
+   masculine (he/him/his) and the recipient of the message in the 
+   feminine (she/her/hers).  This convention is purely for convenience 
+   and makes no assumption about the gender of a message sender or 
+   recipient. 
+    
+  
+Burger                     Expires 9/30/01                   [Page 2] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
+   this document are to be interpreted as described in RFC 2119 [2]. 
+    
+   NOTE: Notes, such at this one, provide additional nonessential 
+   information that the reader may skip without missing anything 
+   essential.  The primary purpose of these non-essential notes is to 
+   convey information about the rationale of this document, or to place 
+   this document in the proper historical or evolutionary context.  
+   Readers whose sole purpose is to construct a conformant 
+   implementation may skip such information.  However, it may be of use 
+   to those who wish to understand why we made certain design choices. 
+    
+    
+3. Introduction 
+ 
+   The specification of Critical Content is small and compact.  For the 
+   benefit of developers, the specification comes first, the rationale 
+   after. 
+    
+   One concept that an implementer must understand is the content 
+   gateway.  Section 7 describes the content gateway.  In brief, a 
+   content gateway has knowledge of the receiving system's 
+   capabilities.  The content gateway passes messages the receiving 
+   system can render or store.  The content gateway can modify a 
+   message, for example by deleting unrenderable or storable body 
+   parts, for delivery to the receiving system.  Finally, the content 
+   gateway can reject a message that the receiving system cannot 
+   handle. 
+    
+4. Criticality Parameter 
+    
+   The Criticality parameter is a Content-Disposition [3] parameter 
+   inserted by the sending UA to indicate to the content gateway 
+   whether to consider the marked body part critical. 
+    
+   A CRITICAL body part is one the sender requires the receiving system 
+   to deliver for him to consider the message delivered. 
+    
+   An IGNORE body part is one the sender doesn't care whether the 
+   receiving system delivers it or not.  A content gateway can silently 
+   delete such body parts if the receiving system cannot deliver the 
+   part. 
+    
+   The terms "entity" and "body part" have the meanings defined in 
+   [10]. 
+    
+4.1. CRITICAL 
+    
+   "Criticality=CRITICAL" signifies that this body part is critical to 
+   the sender. 
+    
+  
+Burger                     Expires 9/30/01                   [Page 3] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+   If the content gateway cannot pass a body part marked CRITICAL, then 
+   the entire message has failed.  In this case, the content gateway 
+   MUST take the appropriate failure action. 
+    
+   NOTE: We say "appropriate action", because the sender may have 
+   suppressed all notifications.  In this case, the appropriate action 
+   is to silently discard the message. 
+    
+4.2. IGNORE 
+    
+   "Criticality=IGNORE" signifies that the sender does not care about 
+   notification reports for this body part. 
+    
+   If the content gateway cannot pass a body part marked IGNORE, the 
+   receiving system may silently delete the body part.  The receiving 
+   system MUST NOT return a delivery failure, unless parts marked 
+   IMPORTANT or CRITICAL have also failed. 
+    
+4.3. Default Values 
+    
+   The default value for Criticality for a given body part is CRITICAL.  
+   This enables the existing notification mechanisms to work for user 
+   agents that do not know about the content notification entity.  All 
+   body parts are critical, because they have the default marking of 
+   CRITICAL. 
+    
+   NOTE: Remember that critical content processing is a function of the 
+   content gateway, and not the MTA or UA.  Often, the entity 
+   performing content gateway processing is the receiving UA.  However, 
+   it is acting as a content gateway.  Thus the default action for any 
+   Content-Disposition [3]-compliant user agent to ignore unrecognized 
+   disposition parameters ensures that this mechanism is compatible 
+   with the Internet architecture. 
+    
+   NOTE: Some VPIMv2 implementations can receive arbitrary e-mail from 
+   the Internet.  However, these systems are really acting in the 
+   capacity of an Internet Voice Mail system.  In this case, one would 
+   expect the implementation to provide Internet Voice Mail semantics 
+   to Internet Voice Mail messages. 
+    
+    
+    
+4.4. Other Values 
+    
+   The content gateway MUST treat unrecognized values as CRITICAL.  
+   This is to provide backward compatibility with future uses of the 
+   Content-Criticality entity. 
+    
+   NOTE: A possible new value is IMPORTANT.  An IMPORTANT body part is 
+   something the sender wants the receiver to get, but would not want 
+   the message rejected outright if the IMPORTANT body part fails, but 
+   they do want notification of the failure.  However, as no 
+  
+Burger                     Expires 9/30/01                   [Page 4] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+   implementations do IMPORTANT, it is not important to this version of 
+   this document. 
+    
+    
+5. Collected Syntax 
+    
+   The format of the collected syntax is in accordance with the ABNF of 
+   [5].  Note that per RFC 2183 [3], the CRITICALITY Content-
+   Disposition parameter is not case sensitive.  In addition, the 
+   notification-type is not case sensitive. 
+    
+        "criticality" "=" notification-type CRLF 
+    
+        notification-type = "CRITICAL" / "IGNORE" 
+    
+    
+ 
+6. Notification 
+    
+   One obvious application of critical content is generating a 
+   (non-)delivery notification.  If the value of the field is IGNORE, 
+   the content gateway MUST NOT generate a notification.  If the value 
+   of the field is CRTITICAL, the content gateway MAY generate a 
+   notification, based on the normal notification request mechanisms.  
+   Normal notification request mechanisms include the SMTP RCPT NOTIFY 
+   command [6] and the Disposition-Notification-To header [8]. 
+    
+   If the sending system requests a notification, and a CRITICAL part 
+   fails, the content gateway will generate a notification for the 
+   whole message.  Conversely, if the gateway cannot pass on a body 
+   part marked IGNORE, the gateway will not generate a notification.  
+    
+   NOTE: This implies that the content gateway must examine the entire 
+   message to determine whether it needs to generate a notification.  
+   However, the content gateway need not examine the message if it 
+   knows it can store and forward all media types.  Said differently, 
+   Internet e-mail MTAs or gateways can, by default, handle any 
+   arbitrary MIME-encapsulated type.  Some voice mail systems, on the 
+   other hand, cannot store binary attachments at all, such as 
+   application/ms-word.  The voice mail content gateway, in this 
+   example, would be scanning for non-renderable body parts in any 
+   event.  
+     
+6.1. DSN vs MDN Generation 
+    
+   The content gateway generates a delivery status notification (DSN) 
+   [7] if it operates as a gateway.  The content gateway generates a 
+   Message Disposition Notification (MDN) [8] if it operates as a user 
+   agent.  Section 7 describes the operating modes of a content 
+   gateway.  In short, if there is a MTA that "delivers" the message to 
+   the content gateway for processing, the MTA takes responsibility for 
+   DSN processing.  In this case, the only option available to the 
+  
+Burger                     Expires 9/30/01                   [Page 5] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+   content gateway is to generate MDNs.  If the content gateway 
+   operates as a MTA, then it generates DSNs.  DSN generation is the 
+   preferred option. 
+    
+    
+6.2. Summary 
+    
+   The following table summarizes the actions expected of a conforming 
+   content gateway. 
+    
+   NOTE: This section is normative: it suggests what to put into the 
+   DSN or MDN.  
+                            +--------------------------------------+ 
+                            |    Sending UA Has Marked Body Part   | 
+                            |---------------------+----------------| 
+                            |      CRITICAL       |     IGNORE     | 
+       +--------------------+---------------------+----------------+ 
+       | Body Part is       |                     |                | 
+       | Deliverable        | Appropriate Action  |     ignore     | 
+       +--------------------+---------------------+----------------+ 
+       | Body Part is       |                     |                | 
+       | Undeliverable      | Fail Entire Message |     ignore     | 
+       +--------------------+--------------------------------------+ 
+    
+    
+   The "Appropriate Action" is the action the content gateway would 
+   take given the context of execution.  For example, if a sender 
+   requests return receipt and the receiver reads a CRITICAL body part, 
+   the receiving UA must generate the appropriate MDN (following the 
+   rules for MDN).  Likewise, if the content gateway cannot deliver the 
+   body part and the body part is critical, the content gateway 
+   generates the appropriate DSN or MDN.  
+    
+   "Ignore" means the content gateway ignores the disposition of the 
+   body part.  The content gateway treats the message as if the body 
+   part was not present in the message. 
+    
+    
+7. Status Code 
+    
+   The critical content indication, in itself, does not guarantee any 
+   notification.  Notification follows the rules described in [7] and 
+   [8]. 
+    
+   NOTE: The content of actual DSNs or MDNs are beyond the scope of 
+   this document.  This document only specifies how to mark a critical 
+   body part.  On the other hand, we do envision sensible DSN and MDN 
+   contents.  For example, DSNs should include the appropriate failure 
+   code as enumerated in [9].  Likewise, MDNs should include the 
+   failure code in the MDN "Failure:" field. 
+    
+  
+Burger                     Expires 9/30/01                   [Page 6] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+   If the receiving system is to generate a notification based on its 
+   inability to render or store the media type, the notification should 
+   use the status code 5.6.1, "Media not supported", from [9]. 
+    
+    
+8. Requirements for Critical Content 
+    
+8.1. Needs 
+    
+   The need for a critical content identification mechanism comes about 
+   because of the internetworking of Internet mail systems with 
+   messaging systems that do not fulfill all of the semantics of 
+   Internet mail.  Such legacy systems have a limited ability to render 
+   or store all parts of a given message.  This document will use the 
+   case of an Internet mail system exchanging electronic messages with 
+   a legacy voice messaging system for illustrative purposes. 
+    
+   Electronic mail has historically been text-centric.  Extensions such 
+   as MIME [10] enable the user agents to send and receive multi-part, 
+   multimedia messages.  Popular multimedia data types include binary 
+   word processing documents, binary business presentation graphics, 
+   voice, and video. 
+    
+   Voice mail has historically been audio-centric.  Many voice-
+   messaging systems only render voice.  Extensions such as fax enable 
+   the voice mail system to send and receive fax images as well as 
+   create multi-part voice and fax messages.  A few voice mail systems 
+   can render text using text-to-speech or text-to-fax technology.  
+   Although theoretically possible, none can today render video. 
+    
+   An important aspect of the interchange between voice messaging 
+   services and desktop e-mail client applications is that the 
+   rendering capability of the voice-messaging platform is often much 
+   less than the rendering capability of a desktop e-mail client.  In 
+   the e-mail case, the sender has the expectation that the recipient 
+   receives all components of a multimedia message.  This is so even if 
+   the recipient cannot render all body parts.  In most cases, the 
+   recipient can either find the appropriate rendering tool or tell the 
+   sender that she cannot read the particular attachment. 
+    
+   This is an important issue.  By definition, a MIME-enabled user 
+   agent, conforming to [11], will present or make available all of the 
+   body parts to the recipient.  However, a voice mail system may not 
+   be capable of storing non-voice objects.  Moreover, the voice mail 
+   system may not be capable of notifying the recipient that there were 
+   undeliverable message parts. 
+    
+   The inability of the receiving system to render a body part is 
+   usually a permanent failure.  Retransmission of the message will not 
+   improve the likelihood of a future successful delivery.  Contrast 
+   this with the case with normal data delivery.  Traditional message 
+  
+Burger                     Expires 9/30/01                   [Page 7] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+   failures, such as a garbled message or disabled link will benefit 
+   from retransmission. 
+    
+   This situation is fundamentally different from normal Internet mail.  
+   In the Internet mail case, either the system delivered the message, 
+   or it didn't.  There is no concept of a system partially delivering 
+   a message. 
+ 
+   In addition, there are many situations where the sender would not 
+   mind if the system did not deliver non-critical parts of a message.  
+   For example, the sender's user agent may add body parts to a message 
+   unbeknownst to the sender.  If the receiving system rejected the 
+   message because it could not render a hidden body part, the sender 
+   would be understandably confused and upset. 
+    
+   Thus, there is a need for a method of indicating to a Mail Transfer 
+   Agent (MTA) or User Agent (UA) that the sender considers parts of a 
+   message to be critical.  From the sender's perspective, he would not 
+   consider the message delivered if the system did not deliver the 
+   critical parts. 
+    
+8.2. Current Approaches 
+    
+   One method of indicating critical content of a message is to define 
+   a profile.  The profile defines rules for silently deleting mail 
+   body parts based on knowledge of the UA capabilities.  Citing the 
+   example above, a voice profile can easily declare that MTAs or UAs 
+   can silently delete TNEF data and yet consider the message 
+   successfully delivered.  This is, in fact, the approach taken by 
+   VPIMv2 [12]. 
+    
+   Since one aspect of the issue is deciding when to notify the sender 
+   that the system cannot deliver part of a message, one could use a 
+   partial non-delivery notification mechanism to indicate a problem 
+   with delivering a given body part.  However, this requires the user 
+   request a delivery notification.  In addition, the sender may not be 
+   aware of parts added by the sending user agent.  In this case, a 
+   failure notice would mystify the sender. 
+    
+   A straightforward alternative implementation method for marking a 
+   body part critical is to use a Critical-Content MIME entity.  This 
+   has the benefit that criticality is meta information for the body 
+   part.  However, IMAP servers in particular would need to either put 
+   Critical-Content into the BODYSTRUCTURE method or create a new 
+   method to retrieve arbitrary MIME entities.  Given the experience of 
+   trying to get Content-Location accepted by IMAP vendors, we chose 
+   not to go that route. 
+    
+   What we need is a way of letting the sender indicate what body-parts 
+   he considers to be critical.  The mechanism must not burden the 
+   sender with failure notifications for non-critical body parts.  The 
+   mechanism must conform to the general notification status request 
+  
+Burger                     Expires 9/30/01                   [Page 8] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+   mechanism for positive or negative notification.  When requested, 
+   the mechanism must indicate to the sender when a receiving system 
+   cannot deliver a critical body part. 
+    
+    
+8.3. Criticality Parameter 
+    
+   The criticality marking mechanism satisfies these needs.  This 
+   document introduces the CRITICALITY parameter to Content-
+   Disposition.  Values for this parameter are CRITICAL or IGNORE. 
+    
+    
+9. The Content Gateway 
+    
+   In this section, we use the definition of [13] for the term 
+   "gateway." 
+    
+   A content gateway is a gateway that connects a first network to a 
+   second network.  The second network often has lesser capability than 
+   the first network.  The canonical topology follows.  The "[MTA]" 
+   signifies an optional component. 
+    
+                             +---------+ 
+   +---------+     +-----+   |         |     +-------+   +-----------+ 
+   | Sending |=...=|[MTA]|===| Content |=...=| [MTA] |===| Receiving | 
+   |   UA    |     +-----+   | Gateway |     +-------+   |    UA     | 
+   +---------+               |         |                 +-----------+ 
+                             +---------+ 
+          First Network                         Second Network 
+    
+    
+   The content gateway can be the last hop before the receiving MTA.  
+   The content gateway can be between networks, and thus not the last 
+   hop before the receiving MTA.  The content gateway can be the first 
+   MTA the sending UA contacts.  Finally, the content gateway can be an 
+   integrated component of the receiving MTA. 
+    
+    
+9.1. Integrated Content Gateway 
+    
+   In this situation, the receiving user agent is integrated with the 
+   content gateway. The integrated content gateway knows the 
+   capabilities of the user agent.  The topology is as follows. 
+    
+                             +---------------------+ 
+   +---------+     +-----+   |         :           | 
+   | Sending |=...=|[MTA]|===| Content : Receiving | 
+   |   UA    |     +-----+   | Gateway :    UA     | 
+   +---------+               |         :           | 
+                             +---------------------+ 
+          First Network           Second Network 
+    
+  
+Burger                     Expires 9/30/01                   [Page 9] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+    
+9.2. Disaggregated Delivery Network 
+    
+   A degenerate case, although one that does occur, is where the 
+   content gateway sits behind the final MTA.  This happens when one 
+   implements the content gateway as a post-processing step to a normal 
+   delivery.  For example, one could configure a mail handling system 
+   to deliver the message to a queue or directory, where the content 
+   gateway process picks up the message.  If there were any directives 
+   for DSN processing, the delivering MTA would execute them.  For 
+   example, the message could have requested notification on successful 
+   delivery.  The delivering MTA, having delivered the message to the 
+   queue, would consider the message delivered and thus notify the 
+   sender of such.  However, the content gateway process could then 
+   discover that the receiving UA cannot render the message.  In this 
+   case, the content gateway generates a NDN, as it is the only option 
+   available. 
+    
+                           Delivered 
+                               |      +---------+ 
+   +---------+     +-----+     v      |         |     +-----------+ 
+   | Sending |=...=| MTA |--> File -->| Content |=...=| Receiving | 
+   |   UA    |     +-----+            | Gateway |     |    UA     | 
+   +---------+                        |         |     +-----------+ 
+                                      +---------+ 
+          First Network              Second Network 
+    
+    
+    
+10. Backward Compatibility Considerations 
+    
+   DSN requires ESMTP.  If MTAs in the path from the sending UA to the 
+   receiving UA do not support ESMTP, then that MTA will reject the DSN 
+   request.  In addition, the message will default to notification on 
+   delay or failure.  While not ideal, the sender will know that DSN is 
+   not available, and that critical content that fails will get 
+   notification. 
+    
+ 
+11. MIME Interactions 
+    
+11.1. multipart/alternative 
+    
+   As is true for all Content-Disposition parameters, criticality is 
+   only in effect for the selected alternative.  If the selected 
+   alternative has the critical content indicator, then the entire 
+   alternative takes on the criticality indicated.  That is, if the 
+   alternative selected has CRITICALITY=IGNORE, then the content 
+   gateway MUST NOT generate any delivery notifications. 
+    
+   NOTE: This statement explicitly shows that CRITICALITY overrides the 
+   DSN and MDN request mechanisms. 
+  
+Burger                     Expires 9/30/01                  [Page 10] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+    
+   It is unlikely for a selected alternative to fail, as the content 
+   gateway presumably picks the alternative specifically because it can 
+   render it.  
+    
+   If the selected alternative is a message/rfc822 that encloses a 
+   multipart MIME message or the selected alternative is itself a 
+   multipart MIME type, the individual top-level body parts follow the 
+   CRITICALITY mechanism described in this document. 
+    
+11.2. multipart/related 
+    
+   Criticality fits in rather well with the multipart/related 
+   construction.  For example, consider a multipart/related message 
+   consisting of a Macintosh data fork and a Macintosh resource fork.  
+   For a Microsoft Word document, the data fork is likely to be 
+   critical.  The receiving system can safely ignore the resource fork. 
+    
+11.3. message/rfc822 
+    
+   Criticality only affects the outermost level of the message or, in 
+   the case of multipart/alternative, the outermost level of the 
+   selected alternative.  Specifically, the receiving system ignores 
+   criticality indicators in embedded body parts.  This avoids the 
+   situation of a forwarded message triggering or suppressing undesired 
+   reporting.  This simply implements the procedures described in [3]. 
+    
+    
+12. Implementation Examples 
+    
+   This section is not a normative part of the definition of 
+   Criticality.  However, we hope it helps implementers to understand 
+   the mechanics of the Criticality mechanism. 
+    
+   We will examine two cases.  They are how a content gateway processes 
+   a message and how a disaggregated content gateway processes a 
+   message. 
+    
+12.1. Content Gateways 
+    
+   Content gateways examine the contents of a message from a first 
+   network before the gateway forwards the message to a second network.  
+   For the purposes of this example, we assume the second network has 
+   less capability than the first network.  In particular, we expect 
+   there will be certain message body types that the gateway cannot 
+   pass onto the second network. 
+    
+   Consider a gateway between the Internet and a text-only short 
+   message service.  A message comes through the gateway containing a 
+   text part and a tnef part.  The sender marks the text part CRITICAL.  
+   The gateway, knowing the capability of the short message service, 
+   silently deletes the non-critical, tnef part, passing the critical 
+  
+Burger                     Expires 9/30/01                  [Page 11] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+   content to the short message service network.  Any subsequent 
+   notifications, such as failure notices or delivery notices, follow 
+   the normal rules for notification. 
+    
+   Note the gateway, by silently deleting non-critical content, may 
+   affect proprietary message correlation schemes.  One can envision 
+   the sending UA inserting a body part for tracking purposes.  By 
+   deleting non-critical content, the content gateway will break such a 
+   scheme.  If a sending UA understands how to mark critical content, 
+   it should use Internet standard mechanisms for tracking messages, 
+   such as Message-ID [14]. 
+    
+   What if no body parts have critical content indicators?  In this 
+   case, the entire message is critical.  Thus, when the gateway sees 
+   the tnef part, it will reject the entire message, generating a DSN 
+   with a status code 5.6.1, "Media not supported". 
+    
+   Likewise, consider a three part message with a text annotation (part 
+   1) to a voice message (part 2) with a vCard [15] (part 3).  The 
+   sender marks the first two parts CRITICAL.  Now, let us assume the 
+   receiving MTA (gateway) is a voice mail only system, without even 
+   the capability to store text.  In this case, the gateway, acting as 
+   the receiving MTA, will reject the message, generating a DSN with 
+   the status code 5.6.1, "Media not supported". 
+ 
+12.2. Disaggregated Content Gateway 
+    
+   For this example, we will examine the processing of a three-part 
+   message.  The first part is a text annotation of the second part, an 
+   audio message.  The third part is the sender's vCard.  The sender 
+   marks the first and second parts CRITICAL.  In addition, the sender 
+   marks the message for read receipt. 
+    
+   For the purposes of example, the telephone user interface (TUI) does 
+   not perform text-to-speech conversion.  A TUI is a mail user agent 
+   (UA) that uses DTMF touch-tone digits for input and audio for output 
+   (display). 
+    
+   The TUI is unable to render the first part of the message, the text 
+   part.  In addition, it is unable to render the third part of the 
+   message, the vCard part.  Since the sender did not mark the third 
+   part of the message CRITICAL, the system ignores the failure of the 
+   TUI to render the third part of the message.  However, since the 
+   sender did mark the first part CRITICAL, and the TUI is unable to 
+   render text, the message fails. 
+    
+   What happens next is implementation dependent.  If the TUI is part 
+   of a unified messaging system, a reasonable action is to hold the 
+   message for the user.  The user can access the message at a later 
+   time from a terminal that can render all of the critical body parts.  
+   It would be reasonable for the TUI to notify the user about the 
+   undeliverable body part. 
+  
+Burger                     Expires 9/30/01                  [Page 12] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+    
+   If the TUI is part of a voice messaging system, or if the user does 
+   not subscribe to a text-to-speech service, a reasonable action is 
+   for the TUI to return a MDN with the disposition "failed" and the 
+   failure modifier "5.6.1 (Media not supported)". 
+    
+    
+13. Security Considerations 
+ 
+   Receiving systems and users should not place any authentication 
+   value on the Content-Criticality entity.  Just because a message has 
+   a particular Content-Criticality value doesn't mean that the message 
+   really originated at a given type of system. 
+    
+    
+14. IANA Considerations 
+    
+   Per section 9 of [3], here is the IANA registration for Criticality. 
+    
+   To: IANA@IANA.ORG 
+   Subject: Registration of new Content-Disposition parameter 
+    
+   Content-Disposition parameter name: 
+   CRITICALITY 
+    
+   Allowable values for this parameter: 
+   IGNORE 
+   CRITICAL 
+    
+   Description: 
+   Marks the body part as required for delivery (CRITICAL) or can be 
+   silently discarded (IGNORE).  See RFC <this document>. 
+   Per RFC 2183, the Content-Disposition parameter name is not case 
+   sensitive.  Per RFC <this document>, the values of the parameter are 
+   also not case sensitive. 
+    
+    
+    
+15. References 
+    
+ 
+   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
+      9, RFC 2026, October 1996. 
+    
+   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
+      Levels", BCP 14, RFC 2119, March 1997. 
+    
+   3  Troost, R., Dorner, S., Moore, K. (ed), "Communicating 
+      Presentation Information in Internet Messages: The Content-
+      Disposition Header Field", RFC 2183, New Century Systems, 
+      QUALCOMM, and U. Tennessee, August 1997. 
+ 
+  
+Burger                     Expires 9/30/01                  [Page 13] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+ 
+    
+   4  Moore, K., "SMTP Service Extension for Delivery Status 
+      Notifications", RFC 1981, University of Tennessee, January 1996. 
+    
+   5 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 
+      Specifications: ABNF", RFC 2234, Internet Mail Consortium and 
+      Demon Internet Ltd., November 1997. 
+    
+   6  Moore, K., "SMTP Service Extension for Delivery Status 
+      Notifications", RFC 1981, University of Tennessee, January 1996. 
+    
+   7  Moore, K. and Vaudreuil, G., "An Extensible Message Format for 
+      Delivery Status Notifications", RFC 1894, University of Tennessee 
+      and Octel Network Services, January 1996. 
+     
+   8  Fajman, R., "An Extensible Message Format for Message Disposition 
+      Notifications", RFC 2298, National Institutes of Health, March 
+      1998. 
+    
+   9  Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, 
+      Octel Network Services, January 1996. 
+    
+   10  Freed, N. and Borenstein, N., "Multipurpose Internet Mail 
+      Extensions (MIME) Part One: Format of Internet Message Bodies", 
+      RFC 2045, Innosoft and First Virtual, November 1996. 
+    
+   11  Freed, N. and Borenstein, N., "Multipurpose Internet Mail 
+      Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft and 
+      First Virtual, November 1996. 
+    
+   12  Vaudreuil, G. and Parsons, G., "Voice Profile for Internet Mail 
+      - version 2", RFC 2421, Lucent Technologies and Nortel Networks, 
+      September 1998. 
+    
+   13 Kille, S. "MIXER (Mime Internet X.400 Enhanced Relay): Mapping 
+      between X.400 and RFC 822/MIME", RFC 2156, Isode, January 1998. 
+    
+   14 Crocker, D., "Standard for the Format of ARPA Internet Text 
+      Messages", RFC 822, University of Delaware, August 1982. 
+    
+   15 Dawson, F. and Howes, T., "vCard MIME Directory Profile", RFC 
+      2426, Lotus Development Corporation and Netscape Communications, 
+      September 1998. 
+    
+   16 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 
+      Specifications: ABNF", RFC 2234, Internet Mail Consortium and 
+      Demon Internet Ltd., November 1997. 
+    
+    
+    
+    
+  
+Burger                     Expires 9/30/01                  [Page 14] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+16. Acknowledgments 
+    
+   Emily Candell of Comverse Network Systems was instrumental in 
+   helping work out the base issues in the û00 draft in Adelaide. 
+    
+   Ned Freed pointed out that this mechanism was about criticality, not 
+   notification.  That insight made the concept and descriptions 
+   infinitely more straightforward.  If it's still confusing, it's my 
+   fault! 
+    
+   Keith Moore for helped tighten-up the explanations, and he approved 
+   of the use of Content-Disposition. 
+    
+   Dropping the IMPORTANT critical content type took away one of the 
+   reasons for partial non-delivery notification.  That makes Jutta 
+   Degener very happy! 
+    
+   Harald Alvestrand and Chris Newman suggested some implementation 
+   examples. 
+    
+   Greg White asked THE key question that let us realize that critical 
+   content processing was a gateway function, and not a MTA or UA 
+   function. 
+    
+   Any errors, omissions, or silliness are my fault. 
+    
+    
+17. Author's Address 
+    
+   Eric Burger 
+   SnowShore Networks, Inc. 
+   285 Billerica Rd. 
+   Chelmsford, MA  01824-4120 
+   USA 
+    
+   Phone: +1 978 367 8403 
+   Fax:   +1 603 457 5944 
+   Email: e.burger@ieee.org 
+    
+    
+    
+    
+  
+Burger                     Expires 9/30/01                  [Page 15] 
+ 
+                  Critical Content of Internet Mail        March 2001 
+ 
+ 
+Full Copyright Statement 
+ 
+   The IETF takes no position regarding the validity or scope of any 
+   intellectual property or other rights that might be claimed to  
+   pertain to the implementation or use of the technology described in 
+   this document or the extent to which any license under such rights 
+   might or might not be available; neither does it represent that it 
+   has made any effort to identify any such rights.  Information on the 
+   IETF's procedures with respect to rights in standards-track and 
+   standards-related documentation can be found in BCP-11.  Copies of 
+   claims of rights made available for publication and any assurances 
+   of licenses to be made available, or the result of an attempt made 
+   to obtain a general license or permission for the use of such 
+   proprietary rights by implementers or users of this specification 
+   can be obtained from the IETF Secretariat. 
+    
+   The IETF invites any interested party to bring to its attention any 
+   copyrights, patents or patent applications, or other proprietary 
+   rights that may cover technology that may be required to practice 
+   this standard.  Please address the information to the IETF Executive 
+   Director. 
+    
+   Copyright (C) 2000, 2001 The Internet Society.  All Rights Reserved. 
+    
+   This document and translations of it may be copied and furnished to 
+   others, and derivative works that comment on or otherwise explain it 
+   or assist in its implementation may be prepared, copied, published 
+   and distributed, in whole or in part, without restriction of any 
+   kind, provided that the above copyright notice and this paragraph 
+   are included on all such copies and derivative works.  However, this 
+   document itself may not be modified in any way, such as by removing 
+   the copyright notice or references to the Internet Society or other 
+   Internet organizations, except as needed for the  purpose of 
+   developing Internet standards in which case the procedures for 
+   copyrights defined in the Internet Standards process must be 
+   followed, or as required to translate it into languages other than 
+   English. 
+    
+   The limited permissions granted above are perpetual and will not be 
+   revoked by the Internet Society or its successors or assigns. 
+    
+   This document and the information contained herein is provided on an 
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
+  
+Burger                     Expires 9/30/01                  [Page 16] 
+ 
+