idnits 2.17.1 draft-ietf-vpim-cc-04.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. == There is 1 instance of lines with non-ascii characters in the document. 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 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([10]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 756 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 30, 2001) is 8428 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 14 looks like a reference -- Missing reference section? '10' on line 308 looks like a reference -- Missing reference section? '2' on line 96 looks like a reference -- Missing reference section? '3' on line 607 looks like a reference -- Missing reference section? '5' on line 200 looks like a reference -- Missing reference section? '6' on line 216 looks like a reference -- Missing reference section? '8' on line 282 looks like a reference -- Missing reference section? '7' on line 281 looks like a reference -- Missing reference section? '9' on line 293 looks like a reference -- Missing reference section? '11' on line 331 looks like a reference -- Missing reference section? '12' on line 370 looks like a reference -- Missing reference section? '13' on line 405 looks like a reference -- Missing reference section? 'MTA' on line 415 looks like a reference -- Missing reference section? '14' on line 550 looks like a reference -- Missing reference section? '15' on line 558 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Burger 3 Internet Draft SnowShore Networks 4 Document: draft-ietf-vpim-cc-04.txt 5 Category: Standards Track 6 Expires September 2001 March 30, 2001 8 Critical Content of Internet Mail 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026 [1]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. Internet-Drafts are draft documents valid for a maximum of 19 six months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 One can access the list of current Internet-Drafts at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 One can access the list of Internet-Draft Shadow Directories at 28 http://www.ietf.org/shadow.html. 30 This document is a work product of the IETF Voice Profile for 31 Internet Mail (VPIM) Work Group. 33 1. Abstract 35 This document describes a mechanism for identifying body parts that 36 a sender deems critical in a multi-part Internet mail message [10]. 37 The mechanism described is a parameter to Content-Disposition. 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 for 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. Criticality Parameter..............................................3 55 4.1. CRITICAL.........................................................3 56 4.2. IGNORE...........................................................4 57 4.3. Default Values...................................................4 58 4.4. Other Values.....................................................4 59 5. Collected Syntax...................................................5 60 6. Notification.......................................................5 61 6.1. DSN vs MDN Generation............................................5 62 6.2. Summary..........................................................6 63 7. Status Code........................................................6 64 8. Requirements for Critical Content..................................7 65 8.1. Needs............................................................7 66 8.2. Current Approaches...............................................8 67 8.3. Criticality Parameter............................................9 68 9. The Content Gateway................................................9 69 9.1. Integrated Content Gateway.......................................9 70 9.2. Disaggregated Delivery Network..................................10 71 10. Backward Compatibility Considerations............................10 72 11. MIME Interactions................................................10 73 11.1. multipart/alternative..........................................10 74 11.2. multipart/related..............................................11 75 11.3. message/rfc822.................................................11 76 12. Implementation Examples..........................................11 77 12.1. Content Gateways...............................................11 78 12.2. Disaggregated Content Gateway..................................12 79 13. Security Considerations..........................................13 80 14. IANA Considerations..............................................13 81 15. References.......................................................13 82 16. Acknowledgments..................................................15 83 17. Author's Address.................................................15 85 2. Conventions used in this document 87 This document refers generically to the sender of a message in the 88 masculine (he/him/his) and the recipient of the message in the 89 feminine (she/her/hers). This convention is purely for convenience 90 and makes no assumption about the gender of a message sender or 91 recipient. 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 95 this document are to be interpreted as described in RFC 2119 [2]. 97 NOTE: Notes, such at this one, provide additional nonessential 98 information that the reader may skip without missing anything 99 essential. The primary purpose of these non-essential notes is to 100 convey information about the rationale of this document, or to place 101 this document in the proper historical or evolutionary context. 102 Readers whose sole purpose is to construct a conformant 103 implementation may skip such information. However, it may be of use 104 to those who wish to understand why we made certain design choices. 106 3. Introduction 108 The specification of Critical Content is small and compact. For the 109 benefit of developers, the specification comes first, the rationale 110 after. 112 One concept that an implementer must understand is the content 113 gateway. Section 7 describes the content gateway. In brief, a 114 content gateway has knowledge of the receiving system's 115 capabilities. The content gateway passes messages the receiving 116 system can render or store. The content gateway can modify a 117 message, for example by deleting unrenderable or storable body 118 parts, for delivery to the receiving system. Finally, the content 119 gateway can reject a message that the receiving system cannot 120 handle. 122 4. Criticality Parameter 124 The Criticality parameter is a Content-Disposition [3] parameter 125 inserted by the sending UA to indicate to the content gateway 126 whether to consider the marked body part critical. 128 A CRITICAL body part is one the sender requires the receiving system 129 to deliver for him to consider the message delivered. 131 An IGNORE body part is one the sender doesn't care whether the 132 receiving system delivers it or not. A content gateway can silently 133 delete such body parts if the receiving system cannot deliver the 134 part. 136 The terms "entity" and "body part" have the meanings defined in 137 [10]. 139 4.1. CRITICAL 141 "Criticality=CRITICAL" signifies that this body part is critical to 142 the sender. 144 If the content gateway cannot pass a body part marked CRITICAL, then 145 the entire message has failed. In this case, the content gateway 146 MUST take the appropriate failure action. 148 NOTE: We say "appropriate action", because the sender may have 149 suppressed all notifications. In this case, the appropriate action 150 is to silently discard the message. 152 4.2. IGNORE 154 "Criticality=IGNORE" signifies that the sender does not care about 155 notification reports for this body part. 157 If the content gateway cannot pass a body part marked IGNORE, the 158 receiving system may silently delete the body part. The receiving 159 system MUST NOT return a delivery failure, unless parts marked 160 IMPORTANT or CRITICAL have also failed. 162 4.3. Default Values 164 The default value for Criticality for a given body part is CRITICAL. 165 This enables the existing notification mechanisms to work for user 166 agents that do not know about the content notification entity. All 167 body parts are critical, because they have the default marking of 168 CRITICAL. 170 NOTE: Remember that critical content processing is a function of the 171 content gateway, and not the MTA or UA. Often, the entity 172 performing content gateway processing is the receiving UA. However, 173 it is acting as a content gateway. Thus the default action for any 174 Content-Disposition [3]-compliant user agent to ignore unrecognized 175 disposition parameters ensures that this mechanism is compatible 176 with the Internet architecture. 178 NOTE: Some VPIMv2 implementations can receive arbitrary e-mail from 179 the Internet. However, these systems are really acting in the 180 capacity of an Internet Voice Mail system. In this case, one would 181 expect the implementation to provide Internet Voice Mail semantics 182 to Internet Voice Mail messages. 184 4.4. Other Values 186 The content gateway MUST treat unrecognized values as CRITICAL. 187 This is to provide backward compatibility with future uses of the 188 Content-Criticality entity. 190 NOTE: A possible new value is IMPORTANT. An IMPORTANT body part is 191 something the sender wants the receiver to get, but would not want 192 the message rejected outright if the IMPORTANT body part fails, but 193 they do want notification of the failure. However, as no 194 implementations do IMPORTANT, it is not important to this version of 195 this document. 197 5. Collected Syntax 199 The format of the collected syntax is in accordance with the ABNF of 200 [5]. Note that per RFC 2183 [3], the CRITICALITY Content- 201 Disposition parameter is not case sensitive. In addition, the 202 notification-type is not case sensitive. 204 "criticality" "=" notification-type CRLF 206 notification-type = "CRITICAL" / "IGNORE" 208 6. Notification 210 One obvious application of critical content is generating a 211 (non-)delivery notification. If the value of the field is IGNORE, 212 the content gateway MUST NOT generate a notification. If the value 213 of the field is CRTITICAL, the content gateway MAY generate a 214 notification, based on the normal notification request mechanisms. 215 Normal notification request mechanisms include the SMTP RCPT NOTIFY 216 command [6] and the Disposition-Notification-To header [8]. 218 If the sending system requests a notification, and a CRITICAL part 219 fails, the content gateway will generate a notification for the 220 whole message. Conversely, if the gateway cannot pass on a body 221 part marked IGNORE, the gateway will not generate a notification. 223 NOTE: This implies that the content gateway must examine the entire 224 message to determine whether it needs to generate a notification. 225 However, the content gateway need not examine the message if it 226 knows it can store and forward all media types. Said differently, 227 Internet e-mail MTAs or gateways can, by default, handle any 228 arbitrary MIME-encapsulated type. Some voice mail systems, on the 229 other hand, cannot store binary attachments at all, such as 230 application/ms-word. The voice mail content gateway, in this 231 example, would be scanning for non-renderable body parts in any 232 event. 234 6.1. DSN vs MDN Generation 236 The content gateway generates a delivery status notification (DSN) 237 [7] if it operates as a gateway. The content gateway generates a 238 Message Disposition Notification (MDN) [8] if it operates as a user 239 agent. Section 7 describes the operating modes of a content 240 gateway. In short, if there is a MTA that "delivers" the message to 241 the content gateway for processing, the MTA takes responsibility for 242 DSN processing. In this case, the only option available to the 243 content gateway is to generate MDNs. If the content gateway 244 operates as a MTA, then it generates DSNs. DSN generation is the 245 preferred option. 247 6.2. Summary 249 The following table summarizes the actions expected of a conforming 250 content gateway. 252 NOTE: This section is normative: it suggests what to put into the 253 DSN or MDN. 254 +--------------------------------------+ 255 | Sending UA Has Marked Body Part | 256 |---------------------+----------------| 257 | CRITICAL | IGNORE | 258 +--------------------+---------------------+----------------+ 259 | Body Part is | | | 260 | Deliverable | Appropriate Action | ignore | 261 +--------------------+---------------------+----------------+ 262 | Body Part is | | | 263 | Undeliverable | Fail Entire Message | ignore | 264 +--------------------+--------------------------------------+ 266 The "Appropriate Action" is the action the content gateway would 267 take given the context of execution. For example, if a sender 268 requests return receipt and the receiver reads a CRITICAL body part, 269 the receiving UA must generate the appropriate MDN (following the 270 rules for MDN). Likewise, if the content gateway cannot deliver the 271 body part and the body part is critical, the content gateway 272 generates the appropriate DSN or MDN. 274 "Ignore" means the content gateway ignores the disposition of the 275 body part. The content gateway treats the message as if the body 276 part was not present in the message. 278 7. Status Code 280 The critical content indication, in itself, does not guarantee any 281 notification. Notification follows the rules described in [7] and 282 [8]. 284 NOTE: The content of actual DSNs or MDNs are beyond the scope of 285 this document. This document only specifies how to mark a critical 286 body part. On the other hand, we do envision sensible DSN and MDN 287 contents. For example, DSNs should include the appropriate failure 288 code as enumerated in [9]. Likewise, MDNs should include the 289 failure code in the MDN "Failure:" field. 291 If the receiving system is to generate a notification based on its 292 inability to render or store the media type, the notification should 293 use the status code 5.6.1, "Media not supported", from [9]. 295 8. Requirements for Critical Content 297 8.1. Needs 299 The need for a critical content identification mechanism comes about 300 because of the internetworking of Internet mail systems with 301 messaging systems that do not fulfill all of the semantics of 302 Internet mail. Such legacy systems have a limited ability to render 303 or store all parts of a given message. This document will use the 304 case of an Internet mail system exchanging electronic messages with 305 a legacy voice messaging system for illustrative purposes. 307 Electronic mail has historically been text-centric. Extensions such 308 as MIME [10] enable the user agents to send and receive multi-part, 309 multimedia messages. Popular multimedia data types include binary 310 word processing documents, binary business presentation graphics, 311 voice, and video. 313 Voice mail has historically been audio-centric. Many voice- 314 messaging systems only render voice. Extensions such as fax enable 315 the voice mail system to send and receive fax images as well as 316 create multi-part voice and fax messages. A few voice mail systems 317 can render text using text-to-speech or text-to-fax technology. 318 Although theoretically possible, none can today render video. 320 An important aspect of the interchange between voice messaging 321 services and desktop e-mail client applications is that the 322 rendering capability of the voice-messaging platform is often much 323 less than the rendering capability of a desktop e-mail client. In 324 the e-mail case, the sender has the expectation that the recipient 325 receives all components of a multimedia message. This is so even if 326 the recipient cannot render all body parts. In most cases, the 327 recipient can either find the appropriate rendering tool or tell the 328 sender that she cannot read the particular attachment. 330 This is an important issue. By definition, a MIME-enabled user 331 agent, conforming to [11], will present or make available all of the 332 body parts to the recipient. However, a voice mail system may not 333 be capable of storing non-voice objects. Moreover, the voice mail 334 system may not be capable of notifying the recipient that there were 335 undeliverable message parts. 337 The inability of the receiving system to render a body part is 338 usually a permanent failure. Retransmission of the message will not 339 improve the likelihood of a future successful delivery. Contrast 340 this with the case with normal data delivery. Traditional message 341 failures, such as a garbled message or disabled link will benefit 342 from retransmission. 344 This situation is fundamentally different from normal Internet mail. 345 In the Internet mail case, either the system delivered the message, 346 or it didn't. There is no concept of a system partially delivering 347 a message. 349 In addition, there are many situations where the sender would not 350 mind if the system did not deliver non-critical parts of a message. 351 For example, the sender's user agent may add body parts to a message 352 unbeknownst to the sender. If the receiving system rejected the 353 message because it could not render a hidden body part, the sender 354 would be understandably confused and upset. 356 Thus, there is a need for a method of indicating to a Mail Transfer 357 Agent (MTA) or User Agent (UA) that the sender considers parts of a 358 message to be critical. From the sender's perspective, he would not 359 consider the message delivered if the system did not deliver the 360 critical parts. 362 8.2. Current Approaches 364 One method of indicating critical content of a message is to define 365 a profile. The profile defines rules for silently deleting mail 366 body parts based on knowledge of the UA capabilities. Citing the 367 example above, a voice profile can easily declare that MTAs or UAs 368 can silently delete TNEF data and yet consider the message 369 successfully delivered. This is, in fact, the approach taken by 370 VPIMv2 [12]. 372 Since one aspect of the issue is deciding when to notify the sender 373 that the system cannot deliver part of a message, one could use a 374 partial non-delivery notification mechanism to indicate a problem 375 with delivering a given body part. However, this requires the user 376 request a delivery notification. In addition, the sender may not be 377 aware of parts added by the sending user agent. In this case, a 378 failure notice would mystify the sender. 380 A straightforward alternative implementation method for marking a 381 body part critical is to use a Critical-Content MIME entity. This 382 has the benefit that criticality is meta information for the body 383 part. However, IMAP servers in particular would need to either put 384 Critical-Content into the BODYSTRUCTURE method or create a new 385 method to retrieve arbitrary MIME entities. Given the experience of 386 trying to get Content-Location accepted by IMAP vendors, we chose 387 not to go that route. 389 What we need is a way of letting the sender indicate what body-parts 390 he considers to be critical. The mechanism must not burden the 391 sender with failure notifications for non-critical body parts. The 392 mechanism must conform to the general notification status request 393 mechanism for positive or negative notification. When requested, 394 the mechanism must indicate to the sender when a receiving system 395 cannot deliver a critical body part. 397 8.3. Criticality Parameter 399 The criticality marking mechanism satisfies these needs. This 400 document introduces the CRITICALITY parameter to Content- 401 Disposition. Values for this parameter are CRITICAL or IGNORE. 403 9. The Content Gateway 405 In this section, we use the definition of [13] for the term 406 "gateway." 408 A content gateway is a gateway that connects a first network to a 409 second network. The second network often has lesser capability than 410 the first network. The canonical topology follows. The "[MTA]" 411 signifies an optional component. 413 +---------+ 414 +---------+ +-----+ | | +-------+ +-----------+ 415 | Sending |=...=|[MTA]|===| Content |=...=| [MTA] |===| Receiving | 416 | UA | +-----+ | Gateway | +-------+ | UA | 417 +---------+ | | +-----------+ 418 +---------+ 419 First Network Second Network 421 The content gateway can be the last hop before the receiving MTA. 422 The content gateway can be between networks, and thus not the last 423 hop before the receiving MTA. The content gateway can be the first 424 MTA the sending UA contacts. Finally, the content gateway can be an 425 integrated component of the receiving MTA. 427 9.1. Integrated Content Gateway 429 In this situation, the receiving user agent is integrated with the 430 content gateway. The integrated content gateway knows the 431 capabilities of the user agent. The topology is as follows. 433 +---------------------+ 434 +---------+ +-----+ | : | 435 | Sending |=...=|[MTA]|===| Content : Receiving | 436 | UA | +-----+ | Gateway : UA | 437 +---------+ | : | 438 +---------------------+ 439 First Network Second Network 441 9.2. Disaggregated Delivery Network 443 A degenerate case, although one that does occur, is where the 444 content gateway sits behind the final MTA. This happens when one 445 implements the content gateway as a post-processing step to a normal 446 delivery. For example, one could configure a mail handling system 447 to deliver the message to a queue or directory, where the content 448 gateway process picks up the message. If there were any directives 449 for DSN processing, the delivering MTA would execute them. For 450 example, the message could have requested notification on successful 451 delivery. The delivering MTA, having delivered the message to the 452 queue, would consider the message delivered and thus notify the 453 sender of such. However, the content gateway process could then 454 discover that the receiving UA cannot render the message. In this 455 case, the content gateway generates a NDN, as it is the only option 456 available. 458 Delivered 459 | +---------+ 460 +---------+ +-----+ v | | +-----------+ 461 | Sending |=...=| MTA |--> File -->| Content |=...=| Receiving | 462 | UA | +-----+ | Gateway | | UA | 463 +---------+ | | +-----------+ 464 +---------+ 465 First Network Second Network 467 10. Backward Compatibility Considerations 469 DSN requires ESMTP. If MTAs in the path from the sending UA to the 470 receiving UA do not support ESMTP, then that MTA will reject the DSN 471 request. In addition, the message will default to notification on 472 delay or failure. While not ideal, the sender will know that DSN is 473 not available, and that critical content that fails will get 474 notification. 476 11. MIME Interactions 478 11.1. multipart/alternative 480 As is true for all Content-Disposition parameters, criticality is 481 only in effect for the selected alternative. If the selected 482 alternative has the critical content indicator, then the entire 483 alternative takes on the criticality indicated. That is, if the 484 alternative selected has CRITICALITY=IGNORE, then the content 485 gateway MUST NOT generate any delivery notifications. 487 NOTE: This statement explicitly shows that CRITICALITY overrides the 488 DSN and MDN request mechanisms. 490 It is unlikely for a selected alternative to fail, as the content 491 gateway presumably picks the alternative specifically because it can 492 render it. 494 If the selected alternative is a message/rfc822 that encloses a 495 multipart MIME message or the selected alternative is itself a 496 multipart MIME type, the individual top-level body parts follow the 497 CRITICALITY mechanism described in this document. 499 11.2. multipart/related 501 Criticality fits in rather well with the multipart/related 502 construction. For example, consider a multipart/related message 503 consisting of a Macintosh data fork and a Macintosh resource fork. 504 For a Microsoft Word document, the data fork is likely to be 505 critical. The receiving system can safely ignore the resource fork. 507 11.3. message/rfc822 509 Criticality only affects the outermost level of the message or, in 510 the case of multipart/alternative, the outermost level of the 511 selected alternative. Specifically, the receiving system ignores 512 criticality indicators in embedded body parts. This avoids the 513 situation of a forwarded message triggering or suppressing undesired 514 reporting. This simply implements the procedures described in [3]. 516 12. Implementation Examples 518 This section is not a normative part of the definition of 519 Criticality. However, we hope it helps implementers to understand 520 the mechanics of the Criticality mechanism. 522 We will examine two cases. They are how a content gateway processes 523 a message and how a disaggregated content gateway processes a 524 message. 526 12.1. Content Gateways 528 Content gateways examine the contents of a message from a first 529 network before the gateway forwards the message to a second network. 530 For the purposes of this example, we assume the second network has 531 less capability than the first network. In particular, we expect 532 there will be certain message body types that the gateway cannot 533 pass onto the second network. 535 Consider a gateway between the Internet and a text-only short 536 message service. A message comes through the gateway containing a 537 text part and a tnef part. The sender marks the text part CRITICAL. 538 The gateway, knowing the capability of the short message service, 539 silently deletes the non-critical, tnef part, passing the critical 540 content to the short message service network. Any subsequent 541 notifications, such as failure notices or delivery notices, follow 542 the normal rules for notification. 544 Note the gateway, by silently deleting non-critical content, may 545 affect proprietary message correlation schemes. One can envision 546 the sending UA inserting a body part for tracking purposes. By 547 deleting non-critical content, the content gateway will break such a 548 scheme. If a sending UA understands how to mark critical content, 549 it should use Internet standard mechanisms for tracking messages, 550 such as Message-ID [14]. 552 What if no body parts have critical content indicators? In this 553 case, the entire message is critical. Thus, when the gateway sees 554 the tnef part, it will reject the entire message, generating a DSN 555 with a status code 5.6.1, "Media not supported". 557 Likewise, consider a three part message with a text annotation (part 558 1) to a voice message (part 2) with a vCard [15] (part 3). The 559 sender marks the first two parts CRITICAL. Now, let us assume the 560 receiving MTA (gateway) is a voice mail only system, without even 561 the capability to store text. In this case, the gateway, acting as 562 the receiving MTA, will reject the message, generating a DSN with 563 the status code 5.6.1, "Media not supported". 565 12.2. Disaggregated Content Gateway 567 For this example, we will examine the processing of a three-part 568 message. The first part is a text annotation of the second part, an 569 audio message. The third part is the sender's vCard. The sender 570 marks the first and second parts CRITICAL. In addition, the sender 571 marks the message for read receipt. 573 For the purposes of example, the telephone user interface (TUI) does 574 not perform text-to-speech conversion. A TUI is a mail user agent 575 (UA) that uses DTMF touch-tone digits for input and audio for output 576 (display). 578 The TUI is unable to render the first part of the message, the text 579 part. In addition, it is unable to render the third part of the 580 message, the vCard part. Since the sender did not mark the third 581 part of the message CRITICAL, the system ignores the failure of the 582 TUI to render the third part of the message. However, since the 583 sender did mark the first part CRITICAL, and the TUI is unable to 584 render text, the message fails. 586 What happens next is implementation dependent. If the TUI is part 587 of a unified messaging system, a reasonable action is to hold the 588 message for the user. The user can access the message at a later 589 time from a terminal that can render all of the critical body parts. 590 It would be reasonable for the TUI to notify the user about the 591 undeliverable body part. 593 If the TUI is part of a voice messaging system, or if the user does 594 not subscribe to a text-to-speech service, a reasonable action is 595 for the TUI to return a MDN with the disposition "failed" and the 596 failure modifier "5.6.1 (Media not supported)". 598 13. Security Considerations 600 Receiving systems and users should not place any authentication 601 value on the Content-Criticality entity. Just because a message has 602 a particular Content-Criticality value doesn't mean that the message 603 really originated at a given type of system. 605 14. IANA Considerations 607 Per section 9 of [3], here is the IANA registration for Criticality. 609 To: IANA@IANA.ORG 610 Subject: Registration of new Content-Disposition parameter 612 Content-Disposition parameter name: 613 CRITICALITY 615 Allowable values for this parameter: 616 IGNORE 617 CRITICAL 619 Description: 620 Marks the body part as required for delivery (CRITICAL) or can be 621 silently discarded (IGNORE). See RFC . 622 Per RFC 2183, the Content-Disposition parameter name is not case 623 sensitive. Per RFC , the values of the parameter are 624 also not case sensitive. 626 15. References 628 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 629 9, RFC 2026, October 1996. 631 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 632 Levels", BCP 14, RFC 2119, March 1997. 634 3 Troost, R., Dorner, S., Moore, K. (ed), "Communicating 635 Presentation Information in Internet Messages: The Content- 636 Disposition Header Field", RFC 2183, New Century Systems, 637 QUALCOMM, and U. Tennessee, August 1997. 639 4 Moore, K., "SMTP Service Extension for Delivery Status 640 Notifications", RFC 1981, University of Tennessee, January 1996. 642 5 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 643 Specifications: ABNF", RFC 2234, Internet Mail Consortium and 644 Demon Internet Ltd., November 1997. 646 6 Moore, K., "SMTP Service Extension for Delivery Status 647 Notifications", RFC 1981, University of Tennessee, January 1996. 649 7 Moore, K. and Vaudreuil, G., "An Extensible Message Format for 650 Delivery Status Notifications", RFC 1894, University of Tennessee 651 and Octel Network Services, January 1996. 653 8 Fajman, R., "An Extensible Message Format for Message Disposition 654 Notifications", RFC 2298, National Institutes of Health, March 655 1998. 657 9 Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, 658 Octel Network Services, January 1996. 660 10 Freed, N. and Borenstein, N., "Multipurpose Internet Mail 661 Extensions (MIME) Part One: Format of Internet Message Bodies", 662 RFC 2045, Innosoft and First Virtual, November 1996. 664 11 Freed, N. and Borenstein, N., "Multipurpose Internet Mail 665 Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft and 666 First Virtual, November 1996. 668 12 Vaudreuil, G. and Parsons, G., "Voice Profile for Internet Mail 669 - version 2", RFC 2421, Lucent Technologies and Nortel Networks, 670 September 1998. 672 13 Kille, S. "MIXER (Mime Internet X.400 Enhanced Relay): Mapping 673 between X.400 and RFC 822/MIME", RFC 2156, Isode, January 1998. 675 14 Crocker, D., "Standard for the Format of ARPA Internet Text 676 Messages", RFC 822, University of Delaware, August 1982. 678 15 Dawson, F. and Howes, T., "vCard MIME Directory Profile", RFC 679 2426, Lotus Development Corporation and Netscape Communications, 680 September 1998. 682 16 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 683 Specifications: ABNF", RFC 2234, Internet Mail Consortium and 684 Demon Internet Ltd., November 1997. 686 16. Acknowledgments 688 Emily Candell of Comverse Network Systems was instrumental in 689 helping work out the base issues in the �00 draft in Adelaide. 691 Ned Freed pointed out that this mechanism was about criticality, not 692 notification. That insight made the concept and descriptions 693 infinitely more straightforward. If it's still confusing, it's my 694 fault! 696 Keith Moore for helped tighten-up the explanations, and he approved 697 of the use of Content-Disposition. 699 Dropping the IMPORTANT critical content type took away one of the 700 reasons for partial non-delivery notification. That makes Jutta 701 Degener very happy! 703 Harald Alvestrand and Chris Newman suggested some implementation 704 examples. 706 Greg White asked THE key question that let us realize that critical 707 content processing was a gateway function, and not a MTA or UA 708 function. 710 Any errors, omissions, or silliness are my fault. 712 17. Author's Address 714 Eric Burger 715 SnowShore Networks, Inc. 716 285 Billerica Rd. 717 Chelmsford, MA 01824-4120 718 USA 720 Phone: +1 978 367 8403 721 Fax: +1 603 457 5944 722 Email: e.burger@ieee.org 724 Full Copyright Statement 726 The IETF takes no position regarding the validity or scope of any 727 intellectual property or other rights that might be claimed to 728 pertain to the implementation or use of the technology described in 729 this document or the extent to which any license under such rights 730 might or might not be available; neither does it represent that it 731 has made any effort to identify any such rights. Information on the 732 IETF's procedures with respect to rights in standards-track and 733 standards-related documentation can be found in BCP-11. Copies of 734 claims of rights made available for publication and any assurances 735 of licenses to be made available, or the result of an attempt made 736 to obtain a general license or permission for the use of such 737 proprietary rights by implementers or users of this specification 738 can be obtained from the IETF Secretariat. 740 The IETF invites any interested party to bring to its attention any 741 copyrights, patents or patent applications, or other proprietary 742 rights that may cover technology that may be required to practice 743 this standard. Please address the information to the IETF Executive 744 Director. 746 Copyright (C) 2000, 2001 The Internet Society. All Rights Reserved. 748 This document and translations of it may be copied and furnished to 749 others, and derivative works that comment on or otherwise explain it 750 or assist in its implementation may be prepared, copied, published 751 and distributed, in whole or in part, without restriction of any 752 kind, provided that the above copyright notice and this paragraph 753 are included on all such copies and derivative works. However, this 754 document itself may not be modified in any way, such as by removing 755 the copyright notice or references to the Internet Society or other 756 Internet organizations, except as needed for the purpose of 757 developing Internet standards in which case the procedures for 758 copyrights defined in the Internet Standards process must be 759 followed, or as required to translate it into languages other than 760 English. 762 The limited permissions granted above are perpetual and will not be 763 revoked by the Internet Society or its successors or assigns. 765 This document and the information contained herein is provided on an 766 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 767 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 768 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 769 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 770 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.