idnits 2.17.1 draft-ietf-vpim-cc-01.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. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 506 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 (October 18, 2000) is 8590 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 13 looks like a reference -- Missing reference section? '2' on line 79 looks like a reference -- Missing reference section? '3' on line 226 looks like a reference -- Missing reference section? '4' on line 126 looks like a reference -- Missing reference section? '5' on line 164 looks like a reference -- Missing reference section? '6' on line 168 looks like a reference -- Missing reference section? '7' on line 234 looks like a reference -- Missing reference section? '8' on line 234 looks like a reference -- Missing reference section? '9' on line 398 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group E. Burger 2 Internet Draft SnowShore Networks 3 Document: draft-ietf-vpim-cc-01.txt E. Candell 4 Category: Standards Track Comverse Network Systems 5 Expires February 2001 October 18, 2000 7 Critical Content of Internet Mail 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 [1]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. Internet-Drafts are draft documents valid for a maximum of 18 six months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- Drafts 20 as reference material or to cite them other than as "work in 21 progress." 23 One can access the list of current Internet-Drafts at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 One can access the list of Internet-Draft Shadow Directories at 27 http://www.ietf.org/shadow.html. 29 1. Abstract 31 This document describes a mechanism for identifying the body parts 32 that the sender deems critical in a multi-part Internet mail 33 message. 35 By knowing what parts of a message the sender deems critical, a MTA 36 or UA can intelligently handle multi-part messages when gatewaying 37 (MTA) or presenting (UA) to systems of lesser capability. Critical 38 content can help a smart gateway decide what parts to forward. It 39 can indicate how hard a gateway should try to deliver a body part. 40 It can help an MTA to select body parts to silently delete when a 41 system of lesser capability receives a message. In addition, 42 critical content can help indicate the notification strategy of the 43 receiving system. 45 Table of Contents 47 1. ABSTRACT .........................................................1 48 2. CONVENTIONS USED IN THIS DOCUMENT ................................2 49 3. INTRODUCTION .....................................................2 50 4. CONTENT-CRITICALITY ENTITY .......................................5 52 4.1. CRITICAL .......................................................6 53 4.2. IGNORE .........................................................6 54 4.3. Other Values ...................................................6 55 4.4. Summary ........................................................6 56 5. BACKWARD COMPATIBILITY CONSIDERATIONS ............................7 57 6. MIME INTERACTIONS ................................................8 58 6.1. multipart/alternative ..........................................8 59 6.2. multipart/related ..............................................8 61 6.3. message/rfc822 .................................................8 62 7. SECURITY CONSIDERATIONS ..........................................8 63 8. COLLECTED SYNTAX .................................................9 64 9. REFERENCES .......................................................9 65 10. ACKNOWLEDGMENTS .................................................10 66 11. AUTHOR'S ADDRESSES ..............................................10 68 2. Conventions used in this document 70 This document refers generically to the sender of a message in the 71 masculine (he/him/his) and the recipient of the message in the 72 feminine (she/her/hers). This convention is purely for convenience 73 and makes no assumption about the gender of a message sender or 74 recipient. 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 78 this document are to be interpreted as described in RFC-2119 [2]. 80 FORMATTING NOTE: Notes, such at this one, provide additional 81 nonessential information that the reader may skip without missing 82 anything essential. The primary purpose of these non-essential 83 notes is to convey information about the rationale of this document, 84 or to place this document in the proper historical or evolutionary 85 context. Readers whose sole purpose is to construct a conformant 86 implementation may skip such information. However, it may be of use 87 to those who wish to understand why we made certain design choices. 89 3. Introduction 91 This document describes the Critical Content identification for 92 multi-part Internet mail. 94 The need for a critical content identification mechanism comes about 95 because of the internetworking of Internet mail systems with legacy 96 messaging systems that do not fulfil all of the semantics of 97 Internet mail. Such legacy systems have a limited ability to render 98 all parts of a given message. This document will use the case of an 99 Internet mail system exchanging electronic messages with a legacy 100 voice messaging system for illustrative purposes. 102 Electronic mail has historically been text-centric. Extensions such 103 as MIME [3] enable the desktop to send and receive multi-part, 104 multimedia messages. Popular multimedia data types include binary 105 word processing documents, binary business presentation graphics, 106 voice, and video. 108 Voice mail has historically been audio-centric. Many voice 109 messaging systems only render voice. Extensions such as fax enable 110 the voice mail system to send and receive fax images as well as 111 create multi-part voice and fax messages. A few voice mail systems 112 can render text using text-to-speech or text-to-fax technology. 113 Although theoretically possible, none can today render video. 115 An important aspect of the interchange between voice messaging 116 services and desktop e-mail client applications is that the 117 rendering capability of the voice messaging platform is often much 118 less than the rendering capability of a desktop e-mail client. In 119 the e-mail case, the sender has the expectation that the recipient 120 receives all components of a multimedia message. This is so even if 121 the recipient cannot render all body parts. In most cases, the 122 recipient can either find the appropriate rendering tool or tell the 123 sender that she cannot read the particular attachment. 125 This is an important issue. By definition, a MIME-enabled user 126 agent, conforming to [4] will present or make available all of the 127 body parts to the recipient. However, a voice mail system may not 128 be capable of storing non-voice objects. Moreover, the voice mail 129 system may not be capable of notifying the recipient that there were 130 undeliverable message parts. 132 The inability of the receiving system to render a body part is 133 usually a permanent failure. Retransmission of the message will not 134 improve the likelihood of a future successful delivery. Contrast 135 this to the case with normal data delivery. Traditional message 136 failures, such as a garbled message or disabled link will benefit 137 from retransmission. 139 This situation is fundamentally different from normal Internet mail. 140 In the Internet mail case, either the system delivered the message, 141 or it didn't. There is no concept of a system partially delivering 142 a message. 144 In addition, the sender would not mind if the system did not deliver 145 non-critical parts of a message. In fact, the sender's user agent 146 may be silently adding body parts to a message unbeknownst to the 147 sender. For example, take Microsoft Outlook as a user agent. 148 Outlook often will attach a TNEF section or other body parts. If the 149 receiving system rejected the message because it could not render 150 TNEF, the sender would be understandably confused and upset. 152 Thus, there is a need for a method of indicating to a Mail Transfer 153 Agent (MTA) or User Agent (UA) that the sender considers parts of a 154 message to be critical. From the sender's perspective, he would not 155 consider the message delivered if the system did not deliver the 156 critical parts. 158 One method of indicating critical content of a message is to define 159 a profile. The profile defines discard rules based on knowledge of 160 the user population for silently deleting body parts. Citing the 161 example above, a voice profile can easily declare that MTAs or UAs 162 can silently delete TNEF data and yet consider the message 163 successfully delivered. This is, in fact, the approach taken by 164 VPIMv2 [5]. 166 Since one aspect of the issue is deciding when to notify the sender 167 that the system cannot deliver part of a message, one could use a 168 partial non-delivery notification mechanism [6] to indicate a 169 problem with delivering a given body part. However, this requires 170 the user request a MDN. Moreover, the sender will receive PNDN 171 failures for objects the sender may not be aware he is sending. An 172 example would be the TNEF part. 174 Summarizing the needs, we need a mechanism that will let the sender 175 or sender's UA mark body parts he considers critical to the message 176 that the system must deliver. The mechanism MUST NOT burden the 177 sender with failure notifications for non-critical body parts. The 178 mechanism MUST conform to the general notification status request 179 mechanism for positive or negative notification. When requested, 180 the mechanism MUST indicate to the sender when a receiving system 181 cannot deliver a critical body part. 183 In short, we need a method of letting the sender indicate what body- 184 parts he considers to be critical. 186 This document describes a Critical Content marking mechanism that 187 satisfies these needs. Following the format for Internet message 188 bodies [3], this document introduces the Content-Criticality body 189 part header. Values for this header are CRITICAL, NOTIFY, or 190 IGNORE. The receiving MTA or UA will generate a DSN or MDN at 191 delivery time or reading time if it receives a request for 192 notification and the (non-)delivery status of the parts marked 193 NOTIFY meet the criteria for notification. 195 NOTE: A straight-forward alternative implementation method for 196 marking a body part critical is to use a content-disposition 197 parameter called "criticality". 199 NOTE: We could have made the critical content indicator a parameter 200 to content-disposition. This has the benefit of being very easy for 201 IMAP servers to implement. In particular, IMAP servers 202 automatically present the content-disposition entity when a UA 203 requests information on a message. On the other hand, the UA must 204 explicitly request the presence and value of different entities, 205 such as content-criticality. However, implementing the critical 206 content indicator as a parameter to content-disposition overloads 207 the meaning of the entity. Moreover, IMAP servers can present, in 208 the future, content-criticality by default. Lastly, most UA's that 209 have interest in content-criticality will explicitly request the 210 header in any event. 212 4. Content-Criticality Entity 214 The Content-Criticality field is a MIME body part header inserted by 215 the sending UA to indicate to the receiving MTA or UA whether to 216 consider this body part critical. 218 A CRITICAL body part is one the sender requires the receiving system 219 to deliver for him to consider the message delivered. 221 An IGNORE body part is one the sender doesn't care whether the 222 receiving system delivers it or not. The receiving system can 223 silently delete such body parts if the receiving system cannot 224 deliver the part. 226 The terms "entity" and "body part" have the meanings defined in [3]. 228 One obvious application of critical content is generating a 229 (non-)delivery message. If the value of the field is IGNORE, the 230 receiving MTA or UA MUST NOT generate a notification. If the value 231 of the field is CRTITICAL, the receiving MTA or UA will generate a 232 notification, based on the normal notification request mechanisms. 233 Normal notification request mechanisms include the SMTP RCPT NOTIFY 234 command [7] and the Disposition-Notification-To header [8]. 236 For example, if the sending system requests a notification, and a 237 CRITICAL part fails, the receiving system will generate a NDN for 238 the whole message. Conversely, if only an IGNORE part fails, the 239 receiving system will not generate a NDN. 241 The next sections examine the actions taken by an MTA or UA given 242 the different values of Content-Criticality. 244 NOTE: This implies that the MTA must examine the entire message on 245 receipt to determine whether it needs to generate a notification. 246 However, the MTA need not examine the message if it knows it can 247 store and forward all media types. Said differently, an Internet e- 248 mail MTA can, by default, handle any arbitrary MIME-encapsulated 249 type. Some voice mail systems, on the other hand, cannot store 250 binary attachments at all, such as application/ms-word. The voice 251 mail MTA, in this example, would be scanning for non-renderable body 252 parts in any event. 254 4.1. CRITICAL 256 "Content-Criticality: CRITICAL" signifies that this body part is 257 critical to the sender. 259 If the receiving system cannot render or store a body part marked 260 CRITICAL, then the entire message has failed. In this case, the 261 receiving system MUST take the appropriate failure action. 263 NOTE: We say "appropriate action", because the sender may have 264 suppressed all notifications. In this case, the appropriate action 265 is to simply discard the message. 267 4.2. IGNORE 269 "Content-Criticality: IGNORE" signifies that the sender does not 270 care about notification reports for this body part. 272 If the receiving system cannot render or store a body part marked 273 IGNORE, the receiving system may silently delete the body part. The 274 receiving system MUST NOT return a delivery failure, unless parts 275 marked IMPORTANT or CRITICAL have also failed. 277 4.3. Other Values 279 The receiving system MUST treat unrecognized values as CRITICAL. 280 This is to provide backward compatibility with future uses of the 281 Content-Criticality entity. 283 The most likely new value is IMPORTANT. An IMPORTANT body part is 284 something the sender wants the receiver to get, but would not want 285 the message rejected outright if the IMPORTANT body part fails. A 286 receiving system that does not understand IMPORTANT MUST take the 287 default value of CRITICAL. In this case, the MTA or UA MUST take 288 the conservative action of rejecting the message. 290 4.4. Summary 292 The following table summarizes the actions expected of a conforming 293 MTA or UA. 295 +--------------------------------------+ 296 | Sending UA Has Marked Body Part | 297 |---------------------+----------------| 298 | CRITICAL | IGNORE | 299 +--------------------+---------------------+----------------+ 300 | Body Part is | | | 301 | Deliverable/read | Appropriate Action | ignore | 302 +--------------------+---------------------+----------------+ 303 | Body Part is | | | 304 | Undeliverable / | | | 305 | Unreadable | Fail Entire Message | ignore | 306 +--------------------+--------------------------------------+ 308 The distinction between deliverable/read is as follows. A MTA can 309 determine if a body part is deliverable. Sample actions a MTA can 310 take are generating a NDN or DSN. An UA can determine if a body 311 part is readable. A sample action an UA can take is generating a 312 MDN. 314 The "Appropriate Action" is the action the MTA or UA would take 315 given the context of execution. For example, if a sender requests 316 return receipt and the receiver reads a CRITICAL body part, the 317 receiving UA must generate the appropriate MDN (following the rules 318 for MDN). 320 "Ignore" means the MTA or UA MUST ignore the operation on the body 321 part. The MTA or UA MUST treat the message as if the body part was 322 not present in the message. 324 5. Backward Compatibility Considerations 326 If there are no Content-Criticality entities in the message, the 327 default value for Content-Criticality is CRITICAL. The standard 328 notification mechanisms work for sending user agents (UA) that do 329 not know about the content notification entity. All body parts are 330 critical, because they have the default marking of CRITICAL. 332 If there is at least one Content-Criticality entity in the message, 333 the default value for unspecified body parts is IGNORE. The 334 philosophy is that UAs, especially manually constructed messages, 335 will explicitly mark the critical body parts. 337 NOTE: We could choose the default value for Content-Criticality to 338 be IGNORE. This would make VPIMv2 automatically compliant with this 339 document, as VPIMv2 has provision to silently delete undeliverable 340 parts. However, VPIMv2 systems should not be receiving arbitrary e- 341 mail from the Internet. If they do, they should be compliant with 342 this series of documents. By defaulting to CRITICAL, this draft is 343 compliant with the rest of the Internet infrastructure. 345 NOTE: Some VPIMv2 implementations can receive arbitrary e-mail from 346 the Internet. However, these systems are really acting in the 347 capacity of an Internet Voice Mail system. In this case, one would 348 expect the implementation to provide Internet Voice Mail semantics 349 to Internet Voice Mail messages. 351 6. MIME Interactions 353 6.1. multipart/alternative 355 Content-Criticality is only in effect for the selected alternative. 356 If the selected alternative has the critical content indicator, then 357 the entire alternative takes on the criticality indicated. That is, 358 if the alternative selected has Content-Criticality: IGNORE, then 359 the receiving system MUST NOT generate any delivery notifications 360 (MDN, NDN, return-receipt, etc.). 362 It is unlikely for a selected alternative to fail, as the receiving 363 UA presumably picks the alternative specifically because it can 364 render it. 366 If the selected alternative is a message/rfc822 that encloses a 367 multipart MIME message or the selected alternative is itself a 368 multipart MIME type, the individual top-level body parts follow the 369 Content-Criticality mechanism described in this document. 371 6.2. multipart/related 373 Content-Criticality fits in rather well with the multipart/related 374 construction. For example, consider a multipart/related message 375 consisting of a Macintosh data fork and a Macintosh resource fork. 376 For a Microsoft Word document, the data fork is likely to be 377 critical. The receiving system can safely ignore the resource fork. 379 6.3. message/rfc822 381 Content-Criticality only affects the outermost level of the message 382 or, in the case of multipart/alternative, the outermost level of the 383 selected alternative. Specifically, the receiving system ignores 384 Content-Criticality indicators in embedded body parts. This avoids 385 the situation of a forwarded message triggering or suppressing 386 undesired or desired reporting. 388 7. Security Considerations 390 Receiving systems and users should not place any authentication 391 value on the Content-Criticality entity. Just because a message has 392 a particular Content-Criticality value doesn't mean that the message 393 really originated at a given type of system. 395 8. Collected Syntax 397 The format of the collected syntax is in accordance with the ABNF of 398 [9]. Note that per RFC 2045, none of the strings are case 399 sensitive. 401 "Content-Criticality" ":" notification-type CRLF 403 notification-type = "CRITICAL" / "IGNORE" 405 9. References 407 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 408 9, RFC 2026, October 1996. 410 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 411 Levels", BCP 14, RFC 2119, March 1997. 413 3 Freed, N. and Borenstein, N., "Multipurpose Internet Mail 414 Extensions (MIME) Part One: Format of Internet Message Bodies", 415 RFC 2045, Innosoft and First Virtual, November 1996. 417 4 Freed, N. and Borenstein, N., "Multipurpose Internet Mail 418 Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft and 419 First Virtual, November 1996. 421 5 Vaudreuil, G. and Parsons, G., "Voice Profile for Internet Mail - 422 version 2", RFC 2321, Lucent Technologies and Nortel Networks, 423 September 1998. 425 6 Burger, E., "Partial Non-Delivery Notification", Work in 426 Progress, draft-ema-burger-pndn-01.txt, March 2000. 428 7 Moore, K., "SMTP Service Extension for Delivery Status 429 Notifications", RFC 1981, University of Tennessee, January 1996. 431 8 Fajman, R., "An Extensible Message Format for Message Disposition 432 Notifications", RFC 2298, National Institutes of Health, March 433 1998. 435 9 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 436 Specifications: ABNF", RFC 2234, Internet Mail Consortium and 437 Demon Internet Ltd., November 1997. 439 10. Acknowledgments 441 We'd like to thank Ned Freed for pointing out that this mechanism 442 was about criticality, not notification per se. That insight made 443 the concept and descriptions infinitely more straight forward. If 444 it's still confusing, it's our fault! 446 We'd also like to thank Keith Moore for helping us tighten-up our 447 explanations. 449 Dropping the IMPORTANT critical content type took away one of the 450 reasons for partial non-delivery notification. That makes Jutta 451 Degener very happy! 453 11. Author's Addresses 455 Eric Burger 456 SnowShore Networks 457 c/o CRV 458 1000 Winter St. 459 Waltham, MA 02451 460 USA 462 Phone: +1 703/304-3883 463 Email: e.burger@ieee.org 465 Emily Candell 466 Comverse Network Systems 467 200 Quannapowitt Pkwy. 468 Wakefield, MA 01880 469 USA 471 Phone: +1 781/213-2324 472 Email: emily@comversens.com 474 Full Copyright Statement 476 The IETF takes no position regarding the validity or scope of any 477 intellectual property or other rights that might be claimed to 478 pertain to the implementation or use of the technology described in 479 this document or the extent to which any license under such rights 480 might or might not be available; neither does it represent that it 481 has made any effort to identify any such rights. Information on the 482 IETF's procedures with respect to rights in standards-track and 483 standards-related documentation can be found in BCP-11. Copies of 484 claims of rights made available for publication and any assurances 485 of licenses to be made available, or the result of an attempt made 486 to obtain a general license or permission for the use of such 487 proprietary rights by implementers or users of this specification 488 can be obtained from the IETF Secretariat. 490 The IETF invites any interested party to bring to its attention any 491 copyrights, patents or patent applications, or other proprietary 492 rights which may cover technology that may be required to practice 493 this standard. Please address the information to the IETF Executive 494 Director. 496 Copyright (C) 2000 The Internet Society. All Rights Reserved. 498 This document and translations of it may be copied and furnished to 499 others, and derivative works that comment on or otherwise explain it 500 or assist in its implementation may be prepared, copied, published 501 and distributed, in whole or in part, without restriction of any 502 kind, provided that the above copyright notice and this paragraph 503 are included on all such copies and derivative works. However, this 504 document itself may not be modified in any way, such as by removing 505 the copyright notice or references to the Internet Society or other 506 Internet organizations, except as needed for the purpose of 507 developing Internet standards in which case the procedures for 508 copyrights defined in the Internet Standards process must be 509 followed, or as required to translate it into languages other than 510 English. 512 The limited permissions granted above are perpetual and will not be 513 revoked by the Internet Society or its successors or assigns. 515 This document and the information contained herein is provided on an 516 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 517 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 518 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 519 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 520 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.