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