idnits 2.17.1 draft-ietf-vpim-cc-05.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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 861 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 (February 26, 2002) is 8067 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 15 looks like a reference -- Missing reference section? '2' on line 102 looks like a reference -- Missing reference section? '3' on line 357 looks like a reference -- Missing reference section? '4' on line 527 looks like a reference -- Missing reference section? '5' on line 708 looks like a reference -- Missing reference section? '11' on line 390 looks like a reference -- Missing reference section? '6' on line 257 looks like a reference -- Missing reference section? '7' on line 278 looks like a reference -- Missing reference section? '9' on line 358 looks like a reference -- Missing reference section? '8' on line 357 looks like a reference -- Missing reference section? '10' on line 371 looks like a reference -- Missing reference section? '12' on line 413 looks like a reference -- Missing reference section? '13' on line 454 looks like a reference -- Missing reference section? '14' on line 485 looks like a reference -- Missing reference section? 'MTA' on line 495 looks like a reference -- Missing reference section? '15' on line 646 looks like a reference -- Missing reference section? '16' on line 654 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 19 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-05.txt 5 Category: Standards Track 6 Updates: RFC 3204 7 Expires August 2002 February 26, 2002 9 Critical Content MIME Parameter 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC 2026 [1]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. Internet-Drafts are draft documents valid for a maximum of 20 six months and may be updated, replaced, and other documents may 21 obsolete this one at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as "work in 23 progress." 25 One can access the list of current Internet-Drafts at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 One can access the list of Internet-Draft Shadow Directories at 29 http://www.ietf.org/shadow.html. 31 This document is a work product of the IETF Voice Profile for 32 Internet Mail (VPIM) Work Group. 34 1. Abstract 36 This document describes the use of a mechanism for identifying body 37 parts that a sender deems critical in a multi-part Internet mail 38 message. The mechanism described is a parameter to Content- 39 Disposition, as described by RFC 3204. 41 By knowing what parts of a message the sender deems critical, a 42 content gateway can intelligently handle multi-part messages when 43 providing gateway services to systems of lesser capability. 44 Critical content can help a content gateway to decide what parts to 45 forward. It can indicate how hard a gateway should try to deliver a 46 body part. It can help the gateway to pick body parts that are safe 47 to silently delete when a system of lesser capability receives a 48 message. In addition, critical content can help the gateway chose 49 the notification strategy for the receiving system. Likewise, if 50 the sender expects the destination to do some processing on a body 51 part, critical content allows the sender to mark body parts that the 52 receiver must process. 54 Critical Content of Internet Mail February 2002 56 Table of Contents 58 1. Abstract...........................................................1 59 2. Conventions used in this document..................................2 60 3. Introduction.......................................................3 61 4. Handling Parameter.................................................4 62 4.1. REQUIRED.........................................................4 63 4.2. OPTIONAL.........................................................4 64 4.3. Default Values...................................................5 65 4.4. Other Values.....................................................5 66 5. Collected Syntax...................................................5 67 6. Notification.......................................................6 68 6.1. DSN vs. MDN Generation...........................................6 69 6.2. Summary..........................................................7 70 7. Status Code........................................................7 71 8. Requirements for Critical Content..................................8 72 8.1. Needs............................................................8 73 8.2. Current Approaches...............................................9 74 9. The Content Gateway...............................................10 75 9.1. Integrated Content Gateway......................................10 76 9.2. Disaggregated Delivery Network..................................11 77 10. Backward Compatibility Considerations............................11 78 11. MIME Interactions................................................12 79 11.1. multipart/alternative..........................................12 80 11.2. multipart/related..............................................12 81 11.3. message/rfc822.................................................12 82 12. Implementation Examples..........................................12 83 12.1. Content Gateways...............................................13 84 12.2. Disaggregated Content Gateway..................................13 85 13. Security Considerations..........................................14 86 14. IANA Considerations..............................................14 87 15. References.......................................................15 88 16. Acknowledgments..................................................16 89 17. Author's Address.................................................17 91 2. Conventions used in this document 93 This document refers generically to the sender of a message in the 94 masculine (he/him/his) and the recipient of the message in the 95 feminine (she/her/hers). This convention is purely for convenience 96 and makes no assumption about the gender of a message sender or 97 recipient. 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 101 this document are to be interpreted as described in RFC 2119 [2]. 103 Critical Content of Internet Mail February 2002 105 NOTE: Notes, such as this one, provide additional nonessential 106 information that the reader may skip without missing anything 107 essential. The primary purpose of these non-essential notes is to 108 convey information about the rationale of this document, or to place 109 this document in the proper historical or evolutionary context. 110 Readers whose sole purpose is to construct a conformant 111 implementation may skip such information. However, it may be of use 112 to those who wish to understand why we made certain design choices. 114 EDITOR'S NOTE: Editor's notes, such as this one, provide commentary 115 the editor will most likely remove from the document before 116 publication. 118 3. Introduction 120 The specification of Critical Content is small and compact. For the 121 benefit of developers, the specification comes first, the rationale 122 after. 124 One concept that an implementer must understand is the content 125 gateway. Section 9 describes the content gateway. In brief, a 126 content gateway has knowledge of the receiving system's 127 capabilities. The content gateway passes messages the receiving 128 system can process, render or store. The content gateway can modify 129 a message, for example by deleting unrenderable or storable body 130 parts, for delivery to the receiving system. Finally, the content 131 gateway can reject a message that the receiving system cannot 132 handle. 134 In this document, the "sending agent" is the originator of the 135 message. It could be a mail user agent (MUA) for an Internet 136 message, or a SIP User Agent Client (UAC) for a SIP [3] message. 138 EDITOR'S NOTE: The major change to this version of the draft is the 139 labels used. This is because RFC 3204 [4] defined identical 140 functionality but with different names. The major contribution of 141 this draft is to explain how to use the Handling parameter in a 142 messaging context. Moreover, it should be easier for a developer of 143 Internet messaging systems or systems that use MIME to find this 144 draft than to find a draft about ISUP or QSIG that tangentially 145 defines the Handling parameter. 147 NOTE: This document updates RFC 3204 to separate the Handling 148 parameter from the ISUP/QSIG transport mechanism. Future versions 149 of RFC 3204 should reference this document for the Handling 150 parameter, as it is orthogonal to the tunneling of signaling. 152 EDITOR'S NOTE: There is an interesting issue with the handling of 153 REQUIRE in RFC 3204 in a SIP environment. If the SIP UAS cannot 154 process a REQUIREd part, it is not clear that the sending UA will be 155 Critical Content of Internet Mail February 2002 157 able to determine that it was the ISUP part that failed, rather than 158 the SDP part. The SIP UAC might be able to infer it from noting 159 that an offered codec is acceptable, but then again, it might not. 160 Thus the sending UA may decide to negotiate a new codec. Procedures 161 for the failure case need to be revisited and codified. 163 4. Handling Parameter 165 The Handling parameter is a Content-Disposition [5] parameter 166 inserted by the sending agent to indicate to the content gateway 167 whether to consider the marked body part critical. 169 A REQUIRED body part is one the sender requires the receiving system 170 to deliver for him to consider the message delivered. 172 An OPTIONAL body part is one the sender doesn't care whether the 173 receiving system delivers it or not. A content gateway can silently 174 delete such body parts if the receiving system cannot deliver the 175 part. 177 The terms "entity" and "body part" have the meanings defined in 178 [11]. 180 4.1. REQUIRED 182 "Handling=REQUIRED" signifies that this body part is critical to the 183 sender. 185 If the content gateway cannot pass a body part marked REQUIRED, then 186 the entire message has failed. In this case, the content gateway 187 MUST take the appropriate failure action. 189 NOTE: We say "appropriate action", because the sender may have 190 suppressed all notifications. In this case, the appropriate action 191 is to silently discard the message. In addition, as a general MIME 192 parameter, the MIME body part may not be in an Internet Mail 193 message. Moreover, in the SIP case, the appropriate notification is 194 a status return code, not a delivery notification. 196 4.2. OPTIONAL 198 "Handling=OPTIONAL" signifies that the sender does not care about 199 notification reports for this body part. 201 If the content gateway cannot pass a body part marked OPTIONAL, the 202 receiving system may silently delete the body part. The receiving 203 system MUST NOT return a delivery failure, unless parts marked 204 REQUIRED have also failed. 206 Critical Content of Internet Mail February 2002 208 4.3. Default Values 210 The default value for Handling for a given body part is REQUIRED. 211 This enables the existing notification mechanisms to work for 212 sending agents that do not know about the content notification 213 entity. All body parts are critical, because they have the default 214 marking of REQUIRED. 216 NOTE: In the case of Internet mail, remember that critical content 217 processing is a function of the content gateway, and not the mail 218 transfer agent (MTA) or user agent (UA). Often, the entity 219 performing content gateway processing is the receiving UA. However, 220 in this case the UA is acting as a content gateway. Thus the 221 default action for any Content-Disposition [5]-compliant user agent 222 to ignore unrecognized disposition parameters ensures that this 223 mechanism is compatible with the Internet architecture. 225 EDITOR'S NOTE: This parameter is fully backwards compatible and 226 works as expected for Internet mail. However, it does not work for 227 SIP interoperation. Interestingly, in the SIP case, the sense of 228 failure is opposite. When a SIP UAC issues a request with a MIME 229 body part marked OPTIONAL, it does not expect the SIP UAS to fail 230 the message if the UAS cannot process the body part. However, only 231 a RFC 3204-complient UAS will understand the Handling parameter. 232 Non-RFC 3204-complient UAS will return a 415 if it does not 233 understand the MIME body part. 235 NOTE: Some VPIMv2 implementations can receive arbitrary e-mail from 236 the Internet. However, these systems are really acting in the 237 capacity of an Internet Voice Mail system. In this case, one would 238 expect the implementation to provide Internet Voice Mail semantics 239 to Internet Voice Mail messages. 241 4.4. Other Values 243 The content gateway MUST treat unrecognized values as REQUIRED. 244 This is to provide backward compatibility with future uses of the 245 Content-Criticality entity. 247 NOTE: A possible new value is IMPORTANT. An IMPORTANT body part is 248 something the sender wants the receiver to get, but would not want 249 the message rejected outright if the IMPORTANT body part fails, but 250 they do want notification of the failure. However, as no 251 implementations do IMPORTANT, it is not important to this version of 252 this document. 254 5. Collected Syntax 256 The format of the collected syntax is in accordance with the ABNF of 257 [6]. Note that per RFC 2183 [5], the HANDLING Content-Disposition 258 Critical Content of Internet Mail February 2002 260 parameter is not case sensitive. In addition, the notification-type 261 is not case sensitive. 263 "handling" "=" notification-type CRLF 265 notification-type = "REQUIRED" / "OPTIONAL" / 266 other-handling / generic-param 268 other-handling = token 270 6. Notification 272 One obvious application of critical content is generating a 273 (non-)delivery notification in the Internet mail environment. If 274 the value of the field is OPTIONAL, the content gateway MUST NOT 275 generate a notification. If the value of the field is REQUIRED, the 276 content gateway MAY generate a notification, based on the normal 277 notification request mechanisms. Normal notification request 278 mechanisms include the SMTP RCPT NOTIFY command [7] and the 279 Disposition-Notification-To header [9]. 281 In SIP, all requests have responses. These responses provide 282 notification in the status code of the response. For the RFC 3204 283 case, a content gateway generates a 415 (Unsupported Media Type) 284 response if the field is REQURED. 286 If the sending system requests a notification, and a REQUIRED part 287 fails, the content gateway will generate a notification for the 288 whole message. Conversely, if the gateway cannot pass on a body 289 part marked OPTIONAL, the gateway will not generate a notification. 291 NOTE: This implies that the content gateway must examine the entire 292 message to determine whether it needs to generate a notification. 293 However, the content gateway need not examine the message if it 294 knows it can store and forward all media types. Said differently, 295 Internet e-mail MTAs or gateways can, by default, handle any 296 arbitrary MIME-encapsulated type. Some voice mail systems, on the 297 other hand, cannot store binary attachments at all, such as 298 application/ms-word. The voice mail content gateway, in this 299 example, would be scanning for non-renderable body parts in any 300 event. 302 6.1. DSN vs. MDN Generation 304 The content gateway generates a delivery status notification (DSN) 305 [8] if it operates as a gateway. The content gateway generates a 306 Message Disposition Notification (MDN) [9] if it operates as a mail 307 user agent. Section 7 describes the operating modes of a content 308 gateway. In short, if there is a MTA that "delivers" the message to 309 the content gateway for processing, the MTA takes responsibility for 310 Critical Content of Internet Mail February 2002 312 DSN processing. In this case, the only option available to the 313 content gateway is to generate MDNs. If the content gateway 314 operates as a MTA, then it generates DSNs. DSN generation is the 315 preferred option. 317 If the content gateway is part of a SIP endpoint, then it generates 318 the appropriate success or error response code. 320 6.2. Summary 322 The following table summarizes the actions expected of a conforming 323 content gateway. 325 NOTE: This section is normative: it suggests what to put into the 326 DSN or MDN. 328 NOTE: In the case of SIP, this section is informative. See RFC 3204 329 for the normative set of actions on failure. 330 +--------------------------------------+ 331 | Sending UA Has Marked Body Part | 332 |---------------------+----------------| 333 | REQUIRED | OPTIONAL | 334 +--------------------+---------------------+----------------+ 335 | Body Part is | | | 336 | Deliverable | Appropriate Action | ignore | 337 +--------------------+---------------------+----------------+ 338 | Body Part is | | | 339 | Undeliverable | Fail Entire Message | ignore | 340 +--------------------+--------------------------------------+ 342 The "Appropriate Action" is the action the content gateway would 343 take given the context of execution. For example, if a sender 344 requests return receipt and the receiver reads a HANDLING body part, 345 the receiving UA must generate the appropriate MDN (following the 346 rules for MDN). Likewise, if the content gateway cannot deliver the 347 body part and the body part is critical, the content gateway 348 generates the appropriate DSN or MDN. 350 "Optional" means the content gateway ignores the disposition of the 351 body part. The content gateway treats the message as if the body 352 part was not present in the message. 354 7. Status Code 356 The critical content indication, in itself, does not guarantee any 357 notification. Notification follows the rules described in [3], [8], 358 and [9]. 360 Critical Content of Internet Mail February 2002 362 NOTE: The content of actual DSNs or MDNs are beyond the scope of 363 this document. This document only specifies how to mark a critical 364 body part. On the other hand, we do envision sensible DSN and MDN 365 contents. For example, DSNs should include the appropriate failure 366 code as enumerated in [10]. Likewise, MDNs should include the 367 failure code in the MDN "Failure:" field. 369 If the receiving system is to generate a notification based on its 370 inability to render or store the media type, the notification should 371 use the status code 5.6.1, "Media not supported", from [10]. 373 For the SIP case, all requests have notification provided by the 374 status response message. Per RFC 3204, a content gateway generates 375 a 415 (Unsupported Media Type) response. 377 8. Requirements for Critical Content 379 8.1. Needs 381 The need for a critical content identification mechanism comes about 382 because of the internetworking of Internet mail systems with 383 messaging systems that do not fulfill all of the semantics of 384 Internet mail. Such legacy systems have a limited ability to render 385 or store all parts of a given message. This document will use the 386 case of an Internet mail system exchanging electronic messages with 387 a legacy voice messaging system for illustrative purposes. 389 Electronic mail has historically been text-centric. Extensions such 390 as MIME [11] enable the user agents to send and receive multi-part, 391 multimedia messages. Popular multimedia data types include binary 392 word processing documents, binary business presentation graphics, 393 voice, and video. 395 Voice mail has historically been audio-centric. Many voice- 396 messaging systems only render voice. Extensions such as fax enable 397 the voice mail system to send and receive fax images as well as 398 create multi-part voice and fax messages. A few voice mail systems 399 can render text using text-to-speech or text-to-fax technology. 400 Although theoretically possible, none can today render video. 402 An important aspect of the interchange between voice messaging 403 services and desktop e-mail client applications is that the 404 rendering capability of the voice-messaging platform is often much 405 less than the rendering capability of a desktop e-mail client. In 406 the e-mail case, the sender has the expectation that the recipient 407 receives all components of a multimedia message. This is so even if 408 the recipient cannot render all body parts. In most cases, the 409 recipient can either find the appropriate rendering tool or tell the 410 sender that she cannot read the particular attachment. 412 This is an important issue. By definition, a MIME-enabled user 413 agent, conforming to [12], will present or make available all of the 414 Critical Content of Internet Mail February 2002 416 body parts to the recipient. However, a voice mail system may not 417 be capable of storing non-voice objects. Moreover, the voice mail 418 system may not be capable of notifying the recipient that there were 419 undeliverable message parts. 421 The inability of the receiving system to render a body part is 422 usually a permanent failure. Retransmission of the message will not 423 improve the likelihood of a future successful delivery. Contrast 424 this with the case with normal data delivery. Traditional message 425 failures, such as a garbled message or disabled link will benefit 426 from retransmission. 428 This situation is fundamentally different from normal Internet mail. 429 In the Internet mail case, either the system delivered the message, 430 or it didn't. There is no concept of a system partially delivering 431 a message. 433 In addition, there are many situations where the sender would not 434 mind if the system did not deliver non-critical parts of a message. 435 For example, the sender's user agent may add body parts to a message 436 unbeknownst to the sender. If the receiving system rejected the 437 message because it could not render a hidden body part, the sender 438 would be understandably confused and upset. 440 Thus, there is a need for a method of indicating to a Mail Transfer 441 Agent (MTA) or User Agent (UA) that the sender considers parts of a 442 message to be critical. From the sender's perspective, he would not 443 consider the message delivered if the system did not deliver the 444 critical parts. 446 8.2. Current Approaches 448 One method of indicating critical content of a message is to define 449 a profile. The profile defines rules for silently deleting mail 450 body parts based on knowledge of the UA capabilities. Citing the 451 example above, a voice profile can easily declare that MTAs or UAs 452 can silently delete TNEF data and yet consider the message 453 successfully delivered. This is, in fact, the approach taken by 454 VPIMv2 [13]. 456 Since one aspect of the issue is deciding when to notify the sender 457 that the system cannot deliver part of a message, one could use a 458 partial non-delivery notification mechanism to indicate a problem 459 with delivering a given body part. However, this requires the user 460 request a delivery notification. In addition, the sender may not be 461 aware of parts added by the sending user agent. In this case, a 462 failure notice would mystify the sender. 464 A straightforward alternative implementation method for marking a 465 body part critical is to use a Critical-Content MIME entity. This 466 has the benefit that criticality is meta information for the body 467 part. However, IMAP servers in particular would need to either put 468 Critical Content of Internet Mail February 2002 470 Critical-Content into the BODYSTRUCTURE method or create a new 471 method to retrieve arbitrary MIME entities. Given the experience of 472 trying to get Content-Location accepted by IMAP vendors, we chose 473 not to go that route. 475 What we need is a way of letting the sender indicate what body-parts 476 he considers to be critical. The mechanism must not burden the 477 sender with failure notifications for non-critical body parts. The 478 mechanism must conform to the general notification status request 479 mechanism for positive or negative notification. When requested, 480 the mechanism must indicate to the sender when a receiving system 481 cannot deliver a critical body part. 483 9. The Content Gateway 485 In this section, we use the definition of [14] for the term 486 "gateway." 488 A content gateway is a gateway that connects a first network to a 489 second network. The second network often has lesser capability than 490 the first network. The canonical topology follows. "[MTA]", with 491 square brackets, signifies an optional component. 493 +---------+ 494 +---------+ +-----+ | | +-------+ +-----------+ 495 | Sending |=...=|[MTA]|===| Content |=...=| [MTA] |===| Receiving | 496 | UA | +-----+ | Gateway | +-------+ | UA | 497 +---------+ | | +-----------+ 498 +---------+ 499 First Network Second Network 501 The content gateway can be the last hop before the receiving MTA. 502 The content gateway can be between networks, and thus not the last 503 hop before the receiving MTA. The content gateway can be the first 504 MTA the sending UA contacts. Finally, the content gateway can be an 505 integrated component of the receiving MTA. 507 For the SIP case, consider each MTA as a SIP Proxy, the Sending UA 508 as a SIP User Agent Client, and the Receiving UA as a SIP User Agent 509 Server. 511 9.1. Integrated Content Gateway 513 In this situation, the receiving user agent is integrated with the 514 content gateway. The integrated content gateway knows the 515 capabilities of the user agent. The topology is as follows. 517 Critical Content of Internet Mail February 2002 519 +---------------------+ 520 +---------+ +-----+ | : | 521 | Sending |=...=|[MTA]|===| Content : Receiving | 522 | UA | +-----+ | Gateway : UA | 523 +---------+ | : | 524 +---------------------+ 525 First Network Second Network 527 The processing of ISUP and QSIG objects, as described in [4], is an 528 example of an integrated gateway. 530 9.2. Disaggregated Delivery Network 532 A degenerate case, although one that does occur, is where the 533 content gateway sits behind the final MTA. This happens when one 534 implements the content gateway as a post-processing step to a normal 535 delivery. For example, one could configure a mail handling system 536 to deliver the message to a queue or directory, where the content 537 gateway process picks up the message. If there were any directives 538 for DSN processing, the delivering MTA would execute them. For 539 example, the message could have requested notification on successful 540 delivery. The delivering MTA, having delivered the message to the 541 queue, would consider the message delivered and thus notify the 542 sender of such. However, the content gateway process could then 543 discover that the receiving UA cannot render the message. In this 544 case, the content gateway generates a NDN, as it is the only option 545 available. 547 Delivered 548 | +---------+ 549 +---------+ +-----+ v | | +-----------+ 550 | Sending |=...=| MTA |--> File -->| Content |=...=| Receiving | 551 | UA | +-----+ | Gateway | | UA | 552 +---------+ | | +-----------+ 553 +---------+ 554 First Network Second Network 556 10. Backward Compatibility Considerations 558 DSN requires ESMTP. If MTAs in the path from the sending UA to the 559 receiving UA do not support ESMTP, then that MTA will reject the DSN 560 request. In addition, the message will default to notification on 561 delay or failure. While not ideal, the sender will know that DSN is 562 not available, and that critical content that fails will get 563 notification. 565 Critical Content of Internet Mail February 2002 567 11. MIME Interactions 569 11.1. multipart/alternative 571 As is true for all Content-Disposition parameters, handling is only 572 in effect for the selected alternative. If the selected alternative 573 has the critical content indicator, then the entire alternative 574 takes on the criticality indicated. That is, if the alternative 575 selected has HANDLING=OPTIONAL, then the content gateway MUST NOT 576 generate any delivery notifications. 578 NOTE: This statement explicitly shows that HANDLING overrides the 579 DSN and MDN request mechanisms. 581 It is unlikely for a selected alternative to fail, as the content 582 gateway presumably picks the alternative specifically because it can 583 render it. 585 If the selected alternative is a message/rfc822 that encloses a 586 multipart MIME message or the selected alternative is itself a 587 multipart MIME type, the individual top-level body parts follow the 588 HANDLING mechanism described in this document. 590 NOTE: This means that a forwarded message's criticality will not 591 affect the forwarding agent's intentions. 593 11.2. multipart/related 595 Criticality fits in rather well with the multipart/related 596 construction. For example, consider a multipart/related message 597 consisting of a Macintosh data fork and a Macintosh resource fork. 598 For a Microsoft Word document, the data fork is likely to be 599 critical. The receiving system can safely ignore the resource fork. 601 11.3. message/rfc822 603 Criticality only affects the outermost level of the message or, in 604 the case of multipart/alternative, the outermost level of the 605 selected alternative. Specifically, the receiving system ignores 606 criticality indicators in embedded body parts. This avoids the 607 situation of a forwarded message triggering or suppressing undesired 608 reporting. This simply implements the procedures described in [5]. 610 12. Implementation Examples 612 This section is not a normative part of the definition of 613 Criticality. However, we hope it helps implementers to understand 614 the mechanics of the Handling mechanism. 616 Critical Content of Internet Mail February 2002 618 We will examine two cases. They are how a content gateway processes 619 a message and how a disaggregated content gateway processes a 620 message. 622 12.1. Content Gateways 624 Content gateways examine the contents of a message from a first 625 network before the gateway forwards the message to a second network. 626 For the purposes of this example, we assume the second network has 627 less capability than the first network. In particular, we expect 628 there will be certain message body types that the gateway cannot 629 pass onto the second network. 631 Consider a gateway between the Internet and a text-only short 632 message service. A message comes through the gateway containing a 633 text part and a tnef part. The sender marks the text part REQUIRED. 634 The gateway, knowing the capability of the short message service, 635 silently deletes the non-critical, tnef part, passing the critical 636 content to the short message service network. Any subsequent 637 notifications, such as failure notices or delivery notices, follow 638 the normal rules for notification. 640 Note the gateway, by silently deleting non-critical content, may 641 affect proprietary message correlation schemes. One can envision 642 the sending UA inserting a body part for tracking purposes. By 643 deleting non-critical content, the content gateway will break such a 644 scheme. If a sending UA understands how to mark critical content, 645 it should use Internet standard mechanisms for tracking messages, 646 such as Message-ID [15]. 648 What if no body parts have critical content indicators? In this 649 case, the entire message is critical. Thus, when the gateway sees 650 the tnef part, it will reject the entire message, generating a DSN 651 with a status code 5.6.1, "Media not supported". 653 Likewise, consider a three part message with a text annotation (part 654 1) to a voice message (part 2) with a vCard [16] (part 3). The 655 sender marks the first two parts REQUIRED. Now, let us assume the 656 receiving MTA (gateway) is a voice mail only system, without even 657 the capability to store text. In this case, the gateway, acting as 658 the receiving MTA, will reject the message, generating a DSN with 659 the status code 5.6.1, "Media not supported". 661 12.2. Disaggregated Content Gateway 663 For this example, we will examine the processing of a three-part 664 message. The first part is a text annotation of the second part, an 665 audio message. The third part is the sender's vCard. The sender 666 marks the first and second parts REQUIRED. In addition, the sender 667 marks the message for read receipt. 669 Critical Content of Internet Mail February 2002 671 For the purposes of example, the telephone user interface (TUI) does 672 not perform text-to-speech conversion. A TUI is a mail user agent 673 (UA) that uses DTMF touch-tone digits for input and audio for output 674 (display). 676 The TUI is unable to render the first part of the message, the text 677 part. In addition, it is unable to render the third part of the 678 message, the vCard part. Since the sender did not mark the third 679 part of the message REQUIRED, the system ignores the failure of the 680 TUI to render the third part of the message. However, since the 681 sender did mark the first part REQUIRED, and the TUI is unable to 682 render text, the message fails. 684 What happens next is implementation dependent. If the TUI is part 685 of a unified messaging system, a reasonable action is to hold the 686 message for the user. The user can access the message at a later 687 time from a terminal that can render all of the critical body parts. 688 It would be reasonable for the TUI to notify the user about the 689 undeliverable body part. 691 If the TUI is part of a voice messaging system, or if the user does 692 not subscribe to a text-to-speech service, a reasonable action is 693 for the TUI to return a MDN with the disposition "failed" and the 694 failure modifier "5.6.1 (Media not supported)". 696 13. Security Considerations 698 Receiving systems and users should not place any authentication 699 value on the Handling parameter. 701 14. IANA Considerations 703 RFC 3204 already registered the Handling parameter. It is collected 704 here only for reference and as a placeholder for use both for 705 further expansion in the future and as the normative reference for 706 other documents that need to reference the Handling parameter. 708 Per section 9 of [5], here is the IANA registration for Handling. 710 To: IANA@IANA.ORG 711 Subject: Registration of new Content-Disposition parameter 713 Content-Disposition parameter name: 714 HANDLING 716 Allowable values for this parameter: 717 REQUIRED 718 OPTIONAL 719 Critical Content of Internet Mail February 2002 721 Description: 722 Marks the body part as required for delivery (REQUIRED) or can be 723 silently discarded (OPTIONAL). See RFC and RFC 3204. 724 Per RFC 2183, the Content-Disposition parameter name is not case 725 sensitive. Per RFC , the values of the parameter are 726 also not case sensitive. 728 15. References 730 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 731 9, RFC 2026, October 1996. 733 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 734 Levels", BCP 14, RFC 2119, March 1997. 736 3 Handley, M., Schulzrinne, H., Schooler, E., and Rosenberg, J., 737 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 739 4 Zimmerer, E., et. al., "MIME media types for ISUP and QSIG 740 Objects", RFC 3204, December 2001. 742 5 Troost, R., Dorner, S., Moore, K. (ed), "Communicating 743 Presentation Information in Internet Messages: The Content- 744 Disposition Header Field", RFC 2183, August 1997. 746 6 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 747 Specifications: ABNF", RFC 2234, November 1997. 749 7 Moore, K., "SMTP Service Extension for Delivery Status 750 Notifications", RFC 1981, January 1996. 752 8 Moore, K. and Vaudreuil, G., "An Extensible Message Format for 753 Delivery Status Notifications", RFC 1894, January 1996. 755 9 Fajman, R., "An Extensible Message Format for Message Disposition 756 Notifications", RFC 2298, March 1998. 758 10 Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, 759 January 1996. 761 11 Freed, N. and Borenstein, N., "Multipurpose Internet Mail 762 Extensions (MIME) Part One: Format of Internet Message Bodies", 763 RFC 2045, November 1996. 765 12 Freed, N. and Borenstein, N., "Multipurpose Internet Mail 766 Extensions (MIME) Part Two: Media Types", RFC 2046, November 767 1996. 769 Critical Content of Internet Mail February 2002 771 13 Vaudreuil, G. and Parsons, G., "Voice Profile for Internet Mail - 772 version 2", RFC 2421, September 1998. 774 14 Kille, S. "MIXER (Mime Internet X.400 Enhanced Relay): Mapping 775 between X.400 and RFC 822/MIME", RFC 2156, January 1998. 777 15 Crocker, D., "Standard for the Format of ARPA Internet Text 778 Messages", RFC 822, August 1982. 780 16 Dawson, F. and Howes, T., "vCard MIME Directory Profile", RFC 781 2426, September 1998. 783 16. Acknowledgments 785 Emily Candell of Comverse Network Systems was instrumental in 786 helping work out the base issues in the �00 draft in Adelaide. 788 Ned Freed pointed out that this mechanism was about criticality, not 789 notification. That insight made the concept and descriptions 790 infinitely more straightforward. If it's still confusing, it's my 791 fault! 793 Keith Moore for helped tighten-up the explanations, and he approved 794 of the use of Content-Disposition. 796 Dropping the IMPORTANT critical content type took away one of the 797 reasons for partial non-delivery notification. That makes Jutta 798 Degener very happy! 800 Harald Alvestrand and Chris Newman suggested some implementation 801 examples. 803 Greg White asked THE key question that let us realize that critical 804 content processing was a gateway function, and not a MTA or UA 805 function. 807 An enormous thank you to Michelle S. Cotton at IANA for helping me 808 craft the original IANA Considerations section in late 2000, and for 809 catching the functional overlap with RFC 3204 this January. 811 Any errors, omissions, or silliness are my fault. 813 Critical Content of Internet Mail February 2002 815 17. Author's Address 817 Eric Burger 818 SnowShore Networks, Inc. 819 285 Billerica Rd. 820 Chelmsford, MA 01824-4120 821 USA 823 Phone: +1 978 367 8403 824 Fax: +1 603 457 5944 825 Email: e.burger@ieee.org 826 Critical Content of Internet Mail February 2002 828 Full Copyright Statement 830 The IETF takes no position regarding the validity or scope of any 831 intellectual property or other rights that might be claimed to 832 pertain to the implementation or use of the technology described in 833 this document or the extent to which any license under such rights 834 might or might not be available; neither does it represent that it 835 has made any effort to identify any such rights. Information on the 836 IETF's procedures with respect to rights in standards-track and 837 standards-related documentation can be found in BCP-11. Copies of 838 claims of rights made available for publication and any assurances 839 of licenses to be made available, or the result of an attempt made 840 to obtain a general license or permission for the use of such 841 proprietary rights by implementers or users of this specification 842 can be obtained from the IETF Secretariat. 844 The IETF invites any interested party to bring to its attention any 845 copyrights, patents or patent applications, or other proprietary 846 rights that may cover technology that may be required to practice 847 this standard. Please address the information to the IETF Executive 848 Director. 850 Copyright (C) 2000, 2001, 2002, The Internet Society. All Rights 851 Reserved. 853 This document and translations of it may be copied and furnished to 854 others, and derivative works that comment on or otherwise explain it 855 or assist in its implementation may be prepared, copied, published 856 and distributed, in whole or in part, without restriction of any 857 kind, provided that the above copyright notice and this paragraph 858 are included on all such copies and derivative works. However, this 859 document itself may not be modified in any way, such as by removing 860 the copyright notice or references to the Internet Society or other 861 Internet organizations, except as needed for the purpose of 862 developing Internet standards in which case the procedures for 863 copyrights defined in the Internet Standards process must be 864 followed, or as required to translate it into languages other than 865 English. 867 The limited permissions granted above are perpetual and will not be 868 revoked by the Internet Society or its successors or assigns. 870 This document and the information contained herein is provided on an 871 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 872 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 873 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 874 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 875 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.