idnits 2.17.1 draft-ietf-vpim-cc-03.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 735 has weird spacing: '...for the purpo...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2, 2001) is 8453 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 13 looks like a reference -- Missing reference section? '2' on line 94 looks like a reference -- Missing reference section? '7' on line 397 looks like a reference -- Missing reference section? '3' on line 148 looks like a reference -- Missing reference section? '5' on line 276 looks like a reference -- Missing reference section? '4' on line 275 looks like a reference -- Missing reference section? '6' on line 287 looks like a reference -- Missing reference section? '8' on line 325 looks like a reference -- Missing reference section? '9' on line 364 looks like a reference -- Missing reference section? '10' on line 403 looks like a reference -- Missing reference section? 'MTA' on line 413 looks like a reference -- Missing reference section? '11' on line 545 looks like a reference -- Missing reference section? '12' on line 553 looks like a reference -- Missing reference section? '13' on line 607 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group E. Burger 2 Internet Draft SnowShore Networks 3 Document: draft-ietf-vpim-cc-03.txt E. Candell 4 Category: Standards Track Comverse Network Systems 5 Expires September 2001 March 2, 2001 7 Critical Content of Internet Mail 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026 [1]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. Internet-Drafts are draft documents valid for a maximum of 18 six months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet-Drafts 20 as reference material or to cite them other than as "work in 21 progress." 23 One can access the list of current Internet-Drafts at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 One can access the list of Internet-Draft Shadow Directories at 27 http://www.ietf.org/shadow.html. 29 This document is a work product of the IETF Voice Profile for 30 Internet Mail (VPIM) Work Group. The URL for the VPIM website is 31 . 33 1. Abstract 35 This document describes a mechanism for identifying the body parts 36 that the sender deems critical in a multi-part Internet mail 37 message. 39 By knowing what parts of a message the sender deems critical, a 40 content gateway can intelligently handle multi-part messages when 41 gatewaying to systems of lesser capability. Critical content can 42 help a content gateway to decide what parts to forward. It can 43 indicate how hard a gateway should try to deliver a body part. It 44 can help the gateway to pick body parts that are safe to silently 45 delete when a system of lesser capability receives a message. In 46 addition, critical content can help the gateway chose the 47 notification strategy of the receiving system. 49 Table of Contents 51 1. Abstract .........................................................1 52 2. Conventions used in this document ................................2 53 3. Introduction .....................................................3 54 4. Content-Criticality Entity .......................................3 55 4.1. CRITICAL .......................................................4 56 4.2. IGNORE .........................................................4 57 4.3. Default Values .................................................4 58 4.4. Other Values ...................................................5 59 4.5. DSN vs MDN Generation ..........................................5 60 4.6. Summary ........................................................5 61 5. Status Code ......................................................6 62 6. Requirements for Critical Content ................................6 63 6.1. Needs ..........................................................6 64 6.2. Current Approaches .............................................8 65 6.3. Critical-Content Entity ........................................8 66 7. The Content Gateway ..............................................9 67 7.1. Integrated Content Gateway .....................................9 68 7.2. Disaggregated Delivery Network .................................9 69 8. Backward Compatibility Considerations ...........................10 70 9. MIME Interactions ...............................................10 71 9.1. multipart/alternative .........................................10 72 9.2. multipart/related .............................................10 73 9.3. message/rfc822 ................................................11 74 10. Implementation Examples .........................................11 75 10.1. Content Gateways ..............................................11 76 10.2. Disaggregated Content Gateway .................................12 77 11. Security Considerations .........................................12 78 12. Collected Syntax ................................................13 79 13. References ......................................................13 80 14. Acknowledgments .................................................14 81 15. Author's Addresses ..............................................15 83 2. Conventions used in this document 85 This document refers generically to the sender of a message in the 86 masculine (he/him/his) and the recipient of the message in the 87 feminine (she/her/hers). This convention is purely for convenience 88 and makes no assumption about the gender of a message sender or 89 recipient. 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 93 this document are to be interpreted as described in RFC 2119 [2]. 95 NOTE: Notes, such at this one, provide additional nonessential 96 information that the reader may skip without missing anything 97 essential. The primary purpose of these non-essential notes is to 98 convey information about the rationale of this document, or to place 99 this document in the proper historical or evolutionary context. 100 Readers whose sole purpose is to construct a conformant 101 implementation may skip such information. However, it may be of use 102 to those who wish to understand why we made certain design choices. 104 3. Introduction 106 The specification of Critical Content is small and compact. For the 107 benefit of developers, the specification comes first, the rationale 108 after. 110 The content gateway issues notifications to the sender if the 111 receiving user agent cannot deliver a critical part of the message. 112 Conversely, the content gateway silently deletes parts of the 113 message that the receiving user agent cannot receive. 115 One concept that an implementer must understand is the content 116 gateway. Section 7 describes the content gateway. In brief, a 117 content gateway has knowledge of the receiving system's 118 capabilities. The content gateway passes messages the receiving 119 system can render or store. The content gateway can modify a 120 message, for example by deleting unrenderable or storable body 121 parts, for delivery to the receiving system. Finally, the content 122 gateway can reject a message that the receiving system cannot 123 handle. 125 4. Content-Criticality Entity 127 The Content-Criticality field is a MIME body part header inserted by 128 the sending UA to indicate to the content gateway whether to 129 consider the marked body part critical. 131 A CRITICAL body part is one the sender requires the receiving system 132 to deliver for him to consider the message delivered. 134 An IGNORE body part is one the sender doesn't care whether the 135 receiving system delivers it or not. A content gateway can silently 136 delete such body parts if the receiving system cannot deliver the 137 part. 139 The terms "entity" and "body part" have the meanings defined in [7]. 141 One obvious application of critical content is generating a 142 (non-)delivery message. If the value of the field is IGNORE, the 143 content gateway MUST NOT generate a notification. If the value of 144 the field is CRTITICAL, the content gateway MAY generate a 145 notification, based on the normal notification request mechanisms. 147 Normal notification request mechanisms include the SMTP RCPT NOTIFY 148 command [3] and the Disposition-Notification-To header [5]. 150 For example, if the sending system requests a notification, and a 151 CRITICAL part fails, the content gateway will generate a NDN for the 152 whole message. Conversely, if the gateway cannot pass on a body 153 part marked IGNORE, the gateway will not generate a NDN. 155 The next sections examine the actions taken by the content gateway, 156 given the different values of Content-Criticality. 158 NOTE: This implies that the content gateway must examine the entire 159 message to determine whether it needs to generate a notification. 160 However, the content gateway need not examine the message if it 161 knows it can store and forward all media types. Said differently, 162 Internet e-mail MTAs or gateways can, by default, handle any 163 arbitrary MIME-encapsulated type. Some voice mail systems, on the 164 other hand, cannot store binary attachments at all, such as 165 application/ms-word. The voice mail content gateway, in this 166 example, would be scanning for non-renderable body parts in any 167 event. 169 4.1. CRITICAL 171 "Content-Criticality: CRITICAL" signifies that this body part is 172 critical to the sender. 174 If the content gateway cannot pass a body part marked CRITICAL, then 175 the entire message has failed. In this case, the content gateway 176 MUST take the appropriate failure action. 178 NOTE: We say "appropriate action", because the sender may have 179 suppressed all notifications. In this case, the appropriate action 180 is to silently discard the message. 182 4.2. IGNORE 184 "Content-Criticality: IGNORE" signifies that the sender does not 185 care about notification reports for this body part. 187 If the content gateway cannot pass a body part marked IGNORE, the 188 receiving system may silently delete the body part. The receiving 189 system MUST NOT return a delivery failure, unless parts marked 190 IMPORTANT or CRITICAL have also failed. 192 4.3. Default Values 194 The default value for Content-Criticality for a given body part is 195 CRITICAL. This enables the existing notification mechanisms to work 196 for user agents that do not know about the content notification 197 entity. All body parts are critical, because they have the default 198 marking of CRITICAL. 200 NOTE: Remember that critical content processing is a function of the 201 content gateway, and not the MTA or UA. In practice, the entity 202 performing content gateway processing is the receiving UA. However, 203 it is acting as a content gateway. Thus the default action for any 204 MIME-compliant user agent to ignore unrecognized MIME entities 205 ensures that this mechanism is compatible with the Internet 206 architecture. 208 NOTE: Some VPIMv2 implementations can receive arbitrary e-mail from 209 the Internet. However, these systems are really acting in the 210 capacity of an Internet Voice Mail system. In this case, one would 211 expect the implementation to provide Internet Voice Mail semantics 212 to Internet Voice Mail messages. 214 4.4. Other Values 216 The content gateway MUST treat unrecognized values as CRITICAL. 217 This is to provide backward compatibility with future uses of the 218 Content-Criticality entity. 220 The most likely new value is IMPORTANT. An IMPORTANT body part is 221 something the sender wants the receiver to get, but would not want 222 the message rejected outright if the IMPORTANT body part fails. A 223 content gateway that does not understand IMPORTANT MUST take the 224 default value of CRITICAL. This is because the content gateway has 225 to take the conservative action of rejecting the message. 227 4.5. DSN vs MDN Generation 229 The content gateway generates a delivery status notification (DSN) 230 [4] if it operates as a gateway. The content gateway generates a 231 Message Disposition Notification (MDN) [5] if it operates as a user 232 agent. Section 7 describes the operating modes of a content 233 gateway. In short, if there is a MTA that "delivers" the message to 234 the content gateway for processing, the MTA takes responsibility for 235 DSN processing. In this case, the only option available to the 236 content gateway is to generate MDNs. If the content gateway 237 operates as a MTA, then it generates DSNs. DSN generation is the 238 preferred option. 240 4.6. Summary 242 The following table summarizes the actions expected of a conforming 243 content gateway. 245 NOTE: This section is normative: it suggests what to put into the 246 DSN or MDN. 248 +--------------------------------------+ 249 | Sending UA Has Marked Body Part | 250 |---------------------+----------------| 251 | CRITICAL | IGNORE | 252 +--------------------+---------------------+----------------+ 253 | Body Part is | | | 254 | Deliverable | Appropriate Action | ignore | 255 +--------------------+---------------------+----------------+ 256 | Body Part is | | | 257 | Undeliverable | Fail Entire Message | ignore | 258 +--------------------+--------------------------------------+ 260 The "Appropriate Action" is the action the content gateway would 261 take given the context of execution. For example, if a sender 262 requests return receipt and the receiver reads a CRITICAL body part, 263 the receiving UA must generate the appropriate MDN (following the 264 rules for MDN). Likewise, if the content gateway cannot deliver the 265 body part and the body part is critical, the content gateway 266 generates the appropriate DSN or MDN. 268 "Ignore" means the content gateway ignores the disposition of the 269 body part. The content gateway treats the message as if the body 270 part was not present in the message. 272 5. Status Code 274 The critical content indication, in itself, does not guarantee any 275 notification. Notification follows the rules described in [4] and 276 [5]. 278 NOTE: The content of actual DSNs or MDNs are beyond the scope of 279 this document. This document only specifies how to mark a critical 280 body part. On the other hand, we do envision sensible DSN and MDN 281 contents. For example, DSNs should include the appropriate failure 282 code as enumerated in [6]. Likewise, MDNs should include the 283 failure code in the MDN "Failure:" field. 285 If the receiving system is to generate a notification based on its 286 inability to render or store the media type, the notification MUST 287 include the status code 5.6.1, "Media not supported", from [6]. 289 6. Requirements for Critical Content 291 6.1. Needs 293 The need for a critical content identification mechanism comes about 294 because of the internetworking of Internet mail systems with 295 messaging systems that do not fulfill all of the semantics of 296 Internet mail. Such legacy systems have a limited ability to render 297 or store all parts of a given message. This document will use the 298 case of an Internet mail system exchanging electronic messages with 299 a legacy voice messaging system for illustrative purposes. 301 Electronic mail has historically been text-centric. Extensions such 302 as MIME [7] enable the user agents to send and receive multi-part, 303 multimedia messages. Popular multimedia data types include binary 304 word processing documents, binary business presentation graphics, 305 voice, and video. 307 Voice mail has historically been audio-centric. Many voice- 308 messaging systems only render voice. Extensions such as fax enable 309 the voice mail system to send and receive fax images as well as 310 create multi-part voice and fax messages. A few voice mail systems 311 can render text using text-to-speech or text-to-fax technology. 312 Although theoretically possible, none can today render video. 314 An important aspect of the interchange between voice messaging 315 services and desktop e-mail client applications is that the 316 rendering capability of the voice-messaging platform is often much 317 less than the rendering capability of a desktop e-mail client. In 318 the e-mail case, the sender has the expectation that the recipient 319 receives all components of a multimedia message. This is so even if 320 the recipient cannot render all body parts. In most cases, the 321 recipient can either find the appropriate rendering tool or tell the 322 sender that she cannot read the particular attachment. 324 This is an important issue. By definition, a MIME-enabled user 325 agent, conforming to [8], will present or make available all of the 326 body parts to the recipient. However, a voice mail system may not 327 be capable of storing non-voice objects. Moreover, the voice mail 328 system may not be capable of notifying the recipient that there were 329 undeliverable message parts. 331 The inability of the receiving system to render a body part is 332 usually a permanent failure. Retransmission of the message will not 333 improve the likelihood of a future successful delivery. Contrast 334 this with the case with normal data delivery. Traditional message 335 failures, such as a garbled message or disabled link will benefit 336 from retransmission. 338 This situation is fundamentally different from normal Internet mail. 339 In the Internet mail case, either the system delivered the message, 340 or it didn't. There is no concept of a system partially delivering 341 a message. 343 In addition, there are many situations where the sender would not 344 mind if the system did not deliver non-critical parts of a message. 345 For example, the sender's user agent may add body parts to a message 346 unbeknownst to the sender. If the receiving system rejected the 347 message because it could not render a hidden body part, the sender 348 would be understandably confused and upset. 350 Thus, there is a need for a method of indicating to a Mail Transfer 351 Agent (MTA) or User Agent (UA) that the sender considers parts of a 352 message to be critical. From the sender's perspective, he would not 353 consider the message delivered if the system did not deliver the 354 critical parts. 356 6.2. Current Approaches 358 One method of indicating critical content of a message is to define 359 a profile. The profile defines rules for silently deleting mail 360 body parts based on knowledge of the UA capabilities. Citing the 361 example above, a voice profile can easily declare that MTAs or UAs 362 can silently delete TNEF data and yet consider the message 363 successfully delivered. This is, in fact, the approach taken by 364 VPIMv2 [9]. 366 Since one aspect of the issue is deciding when to notify the sender 367 that the system cannot deliver part of a message, one could use a 368 partial non-delivery notification mechanism to indicate a problem 369 with delivering a given body part. However, this requires the user 370 request a MDN. 372 A straightforward alternative implementation method for marking a 373 body part critical is to use a content-disposition parameter called 374 "criticality". This would have the benefit of being very easy for 375 IMAP servers to implement. In particular, IMAP servers 376 automatically present the content-disposition entity when a client 377 requests information on a message. On the other hand, the client 378 must explicitly request the presence and value of different 379 entities, such as content-criticality. However, implementing the 380 critical content indicator as a parameter to content-disposition 381 overloads the meaning of the entity. Moreover, IMAP servers can 382 present, in the future, content-criticality by default. Lastly, 383 most clients that have interest in content-criticality will 384 explicitly request the header in any event. 386 In short, we need a way of letting the sender indicate what body- 387 parts he considers to be critical. The mechanism must not burden 388 the sender with failure notifications for non-critical body parts. 389 The mechanism must conform to the general notification status 390 request mechanism for positive or negative notification. When 391 requested, the mechanism must indicate to the sender when a 392 receiving system cannot deliver a critical body part. 394 6.3. Critical-Content Entity 396 The Critical Content marking mechanism satisfies these needs. 397 Following the format for Internet message bodies [7], this document 398 introduces the Content-Criticality body part header. Values for 399 this header are CRITICAL or IGNORE. 401 7. The Content Gateway 403 In this section, we use the definition of [10] for the term 404 "gateway." 406 A content gateway is a gateway that connects a first network to a 407 second network. The second network often has lesser capability than 408 the first network. The canonical topology follows. The "[MTA]" 409 signifies an optional component. 411 +---------+ 412 +---------+ +-----+ | | +-------+ +-----------+ 413 | Sending |=...=|[MTA]|===| Content |=...=| [MTA] |===| Receiving | 414 | UA | +-----+ | Gateway | +-------+ | UA | 415 +---------+ | | +-----------+ 416 +---------+ 417 First Network Second Network 419 The content gateway can be the last hop before the receiving MTA. 420 The content gateway can be between networks, and thus not the last 421 hop before the receiving MTA. The content gateway can be the first 422 MTA the sending UA contacts. Finally, the content gateway can be an 423 integrated component of the receiving MTA. 425 7.1. Integrated Content Gateway 427 In this situation, the receiving user agent is integrated with the 428 content gateway. The integrated content gateway knows the 429 capabilities of the user agent. The topology is as follows. 431 +---------------------+ 432 +---------+ +-----+ | : | 433 | Sending |=...=|[MTA]|===| Content : Receiving | 434 | UA | +-----+ | Gateway : UA | 435 +---------+ | : | 436 +---------------------+ 437 First Network Second Network 439 7.2. Disaggregated Delivery Network 441 A degenerate case, although one that does occur, is where the 442 content gateway sits behind the final MTA. This happens when one 443 implements the content gateway as a post-processing step to a normal 444 delivery. For example, one could configure a mail handling system 445 to deliver the message to a queue or directory, where the content 446 gateway process picks up the message. If there were any directives 447 for DSN processing, the delivering MTA would execute them. For 448 example, the message could have requested notification on successful 449 delivery. The delivering MTA, having delivered the message to the 450 queue, would consider the message delivered and thus notify the 451 sender of such. However, the content gateway process could then 452 discover that the receiving UA cannot render the message. In this 453 case, the content gateway generates a NDN, as it is the only option 454 available. 456 Delivered 457 | +---------+ 458 +---------+ +-----+ v | | +-----------+ 459 | Sending |=...=| MTA |--> File -->| Content |=...=| Receiving | 460 | UA | +-----+ | Gateway | | UA | 461 +---------+ | | +-----------+ 462 +---------+ 463 First Network Second Network 465 8. Backward Compatibility Considerations 467 DSN requires ESMTP. If MTAs in the path from the sending UA to the 468 receiving UA do not support ESMTP, then that MTA will reject the DSN 469 request. In addition, the message will default to notification on 470 delay or failure. While not ideal, the sender will know that DSN is 471 not available, and that critical content that fails will get 472 notification. 474 9. MIME Interactions 476 9.1. multipart/alternative 478 Content-Criticality is only in effect for the selected alternative. 479 If the selected alternative has the critical content indicator, then 480 the entire alternative takes on the criticality indicated. That is, 481 if the alternative selected has Content-Criticality: IGNORE, then 482 the content gateway MUST NOT generate any delivery notifications. 484 It is unlikely for a selected alternative to fail, as the content 485 gateway presumably picks the alternative specifically because it can 486 render it. 488 If the selected alternative is a message/rfc822 that encloses a 489 multipart MIME message or the selected alternative is itself a 490 multipart MIME type, the individual top-level body parts follow the 491 Content-Criticality mechanism described in this document. 493 9.2. multipart/related 495 Content-Criticality fits in rather well with the multipart/related 496 construction. For example, consider a multipart/related message 497 consisting of a Macintosh data fork and a Macintosh resource fork. 499 For a Microsoft Word document, the data fork is likely to be 500 critical. The receiving system can safely ignore the resource fork. 502 9.3. message/rfc822 504 Content-Criticality only affects the outermost level of the message 505 or, in the case of multipart/alternative, the outermost level of the 506 selected alternative. Specifically, the receiving system ignores 507 Content-Criticality indicators in embedded body parts. This avoids 508 the situation of a forwarded message triggering or suppressing 509 undesired reporting. 511 10. Implementation Examples 513 This section is not a normative part of the definition of Content- 514 Criticality. However, we hope it helps implementers to understand 515 the mechanics of the Content-Criticality mechanism. 517 We will examine two cases. They are how a content gateway processes 518 a message and how a disaggregated content gateway processes a 519 message. 521 10.1. Content Gateways 523 Content gateways examine the contents of a message from a first 524 network before the gateway forwards the message to a second network. 525 For the purposes of this example, we assume the second network has 526 less capability than the first network. In particular, we expect 527 there will be certain message body types that the gateway cannot 528 pass onto the second network. 530 Consider a gateway between the Internet and a text-only short 531 message service. A message comes through the gateway containing a 532 text part and a tnef part. The sender marks the text part CRITICAL. 533 The gateway, knowing the capability of the short message service, 534 silently deletes the non-critical, tnef part, passing the critical 535 content to the short message service network. Any subsequent 536 notifications, such as failure notices or delivery notices, follow 537 the normal rules for notification. 539 Note the gateway, by silently deleting non-critical content, may 540 affect proprietary message correlation schemes. One can envision 541 the sending UA inserting a body part for tracking purposes. By 542 deleting non-critical content, the content gateway will break such a 543 scheme. If a sending UA understands how to mark critical content, 544 it should use Internet standard mechanisms for tracking messages, 545 such as Message-ID [11]. 547 What if no body parts have critical content indicators? In this 548 case, the entire message is critical. Thus, when the gateway sees 549 the tnef part, it will reject the entire message, generating a DSN 550 with a status code 5.6.1, "Media not supported". 552 Likewise, consider a three part message with a text annotation (part 553 1) to a voice message (part 2) with a vCard [12] (part 3). The 554 sender marks the first two parts CRITICAL. Now, let us assume the 555 receiving MTA (gateway) is a voice mail only system, without even 556 the capability to store text. In this case, the gateway, acting as 557 the receiving MTA, will reject the message, generating a DSN with 558 the status code 5.6.1, "Media not supported". 560 10.2. Disaggregated Content Gateway 562 For this example, we will examine the processing of a three-part 563 message. The first part is a text annotation of the second part, an 564 audio message. The third part is the sender's vCard. The sender 565 marks the first and second parts CRITICAL. In addition, the sender 566 marks the message for read receipt. 568 For the purposes of example, the telephone user interface (TUI) does 569 not perform text-to-speech conversion. A TUI is a mail user agent 570 (UA) that uses DTMF touch-tone digits for input and audio for output 571 (display). 573 The TUI is unable to render the first part of the message, the text 574 part. In addition, it is unable to render the third part of the 575 message, the vCard part. Since the sender did not mark the third 576 part of the message CRITICAL, the system ignores the failure of the 577 TUI to render the third part of the message. However, since the 578 sender did mark the first part CRITICAL, and the TUI is unable to 579 render text, the message fails. 581 What happens next is implementation dependent. If the TUI is part 582 of a unified messaging system, a reasonable action is to hold the 583 message for the user. The user can access the message at a later 584 time from a terminal that can render all of the critical body parts. 585 It would be reasonable for the TUI to notify the user about the 586 message. 588 If the TUI is part of a voice messaging system, or if the user does 589 not subscribe to a text-to-speech service, a reasonable action is 590 for the TUI to return a MDN with the disposition "failed" and the 591 failure modifier "5.6.1 (Media not supported)". 593 11. Security Considerations 595 Receiving systems and users should not place any authentication 596 value on the Content-Criticality entity. Just because a message has 597 a particular Content-Criticality value doesn't mean that the message 598 really originated at a given type of system. 600 12. IANA Considerations 602 None. 604 13. Collected Syntax 606 The format of the collected syntax is in accordance with the ABNF of 607 [13]. Note that per RFC 2045, none of the strings are case 608 sensitive. 610 "Content-Criticality" ":" notification-type CRLF 612 notification-type = "CRITICAL" / "IGNORE" 614 14. References 616 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 617 9, RFC 2026, October 1996. 619 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 620 Levels", BCP 14, RFC 2119, March 1997. 622 3 Moore, K., "SMTP Service Extension for Delivery Status 623 Notifications", RFC 1981, University of Tennessee, January 1996. 625 4 Moore, K. and Vaudreuil, G., "An Extensible Message Format for 626 Delivery Status Notifications", RFC 1894, University of Tennessee 627 and Octel Network Services, January 1996. 629 5 Fajman, R., "An Extensible Message Format for Message Disposition 630 Notifications", RFC 2298, National Institutes of Health, March 631 1998. 633 6 Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, 634 Octel Network Services, January 1996. 636 7 Freed, N. and Borenstein, N., "Multipurpose Internet Mail 637 Extensions (MIME) Part One: Format of Internet Message Bodies", 638 RFC 2045, Innosoft and First Virtual, November 1996. 640 8 Freed, N. and Borenstein, N., "Multipurpose Internet Mail 641 Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft and 642 First Virtual, November 1996. 644 9 Vaudreuil, G. and Parsons, G., "Voice Profile for Internet Mail - 645 version 2", RFC 2421, Lucent Technologies and Nortel Networks, 646 September 1998. 648 10 Kille, S. "MIXER (Mime Internet X.400 Enhanced Relay): Mapping 649 between X.400 and RFC 822/MIME", RFC 2156, Isode, January 1998. 651 11 Crocker, D., "Standard for the Format of ARPA Internet Text 652 Messages", RFC 822, University of Delaware, August 1982. 654 12 Dawson, F. and Howes, T., "vCard MIME Directory Profile", RFC 655 2426, Lotus Development Corporation and Netscape Communications, 656 September 1998. 658 13 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 659 Specifications: ABNF", RFC 2234, Internet Mail Consortium and 660 Demon Internet Ltd., November 1997. 662 15. Acknowledgments 664 We'd like to thank Ned Freed for pointing out that this mechanism 665 was about criticality, not notification per se. That insight made 666 the concept and descriptions infinitely more straightforward. If 667 it's still confusing, it's our fault! 669 We'd also like to thank Keith Moore for helping us tighten-up our 670 explanations. 672 Dropping the IMPORTANT critical content type took away one of the 673 reasons for partial non-delivery notification. That makes Jutta 674 Degener very happy! 676 Harald Alvestrand and Chris Newman suggested we add implementation 677 examples, which we did. 679 Greg asked the key question that let us realize that critical 680 content processing was a gateway, and not a MTA or UA function. 682 16. Author's Addresses 684 Eric Burger 685 SnowShore Networks, Inc. 686 285 Billerica Rd. 687 Chelmsford, MA 01824-4120 688 USA 690 Phone: +1 978 367 8403 691 Fax: +1 603 457 5944 692 Email: e.burger@ieee.org 694 Emily Candell 695 Comverse Network Systems 696 200 Quannapowitt Pkwy. 697 Wakefield, MA 01880 698 USA 700 Phone: +1 781 213 2324 701 Email: emily@comversens.com 703 Full Copyright Statement 705 The IETF takes no position regarding the validity or scope of any 706 intellectual property or other rights that might be claimed to 707 pertain to the implementation or use of the technology described in 708 this document or the extent to which any license under such rights 709 might or might not be available; neither does it represent that it 710 has made any effort to identify any such rights. Information on the 711 IETF's procedures with respect to rights in standards-track and 712 standards-related documentation can be found in BCP-11. Copies of 713 claims of rights made available for publication and any assurances 714 of licenses to be made available, or the result of an attempt made 715 to obtain a general license or permission for the use of such 716 proprietary rights by implementers or users of this specification 717 can be obtained from the IETF Secretariat. 719 The IETF invites any interested party to bring to its attention any 720 copyrights, patents or patent applications, or other proprietary 721 rights that may cover technology that may be required to practice 722 this standard. Please address the information to the IETF Executive 723 Director. 725 Copyright (C) 2000, 2001 The Internet Society. All Rights Reserved. 727 This document and translations of it may be copied and furnished to 728 others, and derivative works that comment on or otherwise explain it 729 or assist in its implementation may be prepared, copied, published 730 and distributed, in whole or in part, without restriction of any 731 kind, provided that the above copyright notice and this paragraph 732 are included on all such copies and derivative works. However, this 733 document itself may not be modified in any way, such as by removing 734 the copyright notice or references to the Internet Society or other 735 Internet organizations, except as needed for the purpose of 736 developing Internet standards in which case the procedures for 737 copyrights defined in the Internet Standards process must be 738 followed, or as required to translate it into languages other than 739 English. 741 The limited permissions granted above are perpetual and will not be 742 revoked by the Internet Society or its successors or assigns. 744 This document and the information contained herein is provided on an 745 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 746 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 747 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 748 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 749 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.