

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] 
 

