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]
