idnits 2.17.1 draft-ietf-vpim-cc-02.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 634 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 (November 24, 2000) is 8553 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 85 looks like a reference -- Missing reference section? '3' on line 233 looks like a reference -- Missing reference section? '4' on line 132 looks like a reference -- Missing reference section? '5' on line 170 looks like a reference -- Missing reference section? '6' on line 174 looks like a reference -- Missing reference section? '7' on line 340 looks like a reference -- Missing reference section? '8' on line 341 looks like a reference -- Missing reference section? '9' on line 241 looks like a reference -- Missing reference section? '10' on line 352 looks like a reference -- Missing reference section? '11' on line 451 looks like a reference -- Missing reference section? '12' on line 459 looks like a reference -- Missing reference section? '13' on line 509 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 15 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-02.txt E. Candell 4 Category: Standards Track Comverse Network Systems 5 Expires May 2001 November 24, 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 This document is a work product of the IETF Voice Profile for 30 Internet Mail (vpim) Work Group. The URL for the VPIM website is 31 . 33 1. Abstract 35 This document describes a mechanism for identifying the body parts 36 that the sender deems critical in a multi-part Internet mail 37 message. 39 By knowing what parts of a message the sender deems critical, a MTA 40 or UA can intelligently handle multi-part messages when gatewaying 41 (MTA) or presenting (UA) to systems of lesser capability. Critical 42 content can help a smart gateway decide what parts to forward. It 43 can indicate how hard a gateway should try to deliver a body part. 44 It can help an MTA to select body parts to silently delete when a 45 system of lesser capability receives a message. In addition, 46 critical content can help indicate the notification strategy of the 47 receiving system. 49 Table of Contents 51 1. ABSTRACT .........................................................1 52 2. CONVENTIONS USED IN THIS DOCUMENT ................................2 53 3. INTRODUCTION .....................................................3 54 4. CONTENT-CRITICALITY ENTITY .......................................5 55 4.1. CRITICAL .......................................................6 56 4.2. IGNORE .........................................................6 57 4.3. Other Values ...................................................6 58 4.4. Summary ........................................................7 59 5. STATUS CODE ......................................................7 60 6. BACKWARD COMPATIBILITY CONSIDERATIONS ............................8 61 7. MIME INTERACTIONS ................................................8 62 7.1. multipart/alternative ..........................................8 63 7.2. multipart/related ..............................................9 64 7.3. message/rfc822 .................................................9 65 8. IMPLEMENTATION EXAMPLES ..........................................9 66 8.1. Content Gateways ...............................................9 67 8.2. Non-Traditional UA ............................................10 68 9. SECURITY CONSIDERATIONS .........................................11 69 10. COLLECTED SYNTAX ................................................11 70 11. REFERENCES ......................................................11 71 12. ACKNOWLEDGMENTS .................................................12 72 13. AUTHOR'S ADDRESSES ..............................................13 74 2. Conventions used in this document 76 This document refers generically to the sender of a message in the 77 masculine (he/him/his) and the recipient of the message in the 78 feminine (she/her/hers). This convention is purely for convenience 79 and makes no assumption about the gender of a message sender or 80 recipient. 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 84 this document are to be interpreted as described in RFC-2119 [2]. 86 FORMATTING NOTE: Notes, such at this one, provide additional 87 nonessential information that the reader may skip without missing 88 anything essential. The primary purpose of these non-essential 89 notes is to convey information about the rationale of this document, 90 or to place this document in the proper historical or evolutionary 91 context. Readers whose sole purpose is to construct a conformant 92 implementation may skip such information. However, it may be of use 93 to those who wish to understand why we made certain design choices. 95 3. Introduction 97 This document describes the Critical Content identification for 98 multi-part Internet mail. 100 The need for a critical content identification mechanism comes about 101 because of the internetworking of Internet mail systems with legacy 102 messaging systems that do not fulfil all of the semantics of 103 Internet mail. Such legacy systems have a limited ability to render 104 all parts of a given message. This document will use the case of an 105 Internet mail system exchanging electronic messages with a legacy 106 voice messaging system for illustrative purposes. 108 Electronic mail has historically been text-centric. Extensions such 109 as MIME [3] enable the desktop to send and receive multi-part, 110 multimedia messages. Popular multimedia data types include binary 111 word processing documents, binary business presentation graphics, 112 voice, and video. 114 Voice mail has historically been audio-centric. Many voice- 115 messaging systems only render voice. Extensions such as fax enable 116 the voice mail system to send and receive fax images as well as 117 create multi-part voice and fax messages. A few voice mail systems 118 can render text using text-to-speech or text-to-fax technology. 119 Although theoretically possible, none can today render video. 121 An important aspect of the interchange between voice messaging 122 services and desktop e-mail client applications is that the 123 rendering capability of the voice-messaging platform is often much 124 less than the rendering capability of a desktop e-mail client. In 125 the e-mail case, the sender has the expectation that the recipient 126 receives all components of a multimedia message. This is so even if 127 the recipient cannot render all body parts. In most cases, the 128 recipient can either find the appropriate rendering tool or tell the 129 sender that she cannot read the particular attachment. 131 This is an important issue. By definition, a MIME-enabled user 132 agent, conforming to [4] will present or make available all of the 133 body parts to the recipient. However, a voice mail system may not 134 be capable of storing non-voice objects. Moreover, the voice mail 135 system may not be capable of notifying the recipient that there were 136 undeliverable message parts. 138 The inability of the receiving system to render a body part is 139 usually a permanent failure. Retransmission of the message will not 140 improve the likelihood of a future successful delivery. Contrast 141 this to the case with normal data delivery. Traditional message 142 failures, such as a garbled message or disabled link will benefit 143 from retransmission. 145 This situation is fundamentally different from normal Internet mail. 146 In the Internet mail case, either the system delivered the message, 147 or it didn't. There is no concept of a system partially delivering 148 a message. 150 In addition, the sender would not mind if the system did not deliver 151 non-critical parts of a message. In fact, the sender's user agent 152 may be silently adding body parts to a message unbeknownst to the 153 sender. For example, take Microsoft Outlook as a user agent. 154 Outlook often will attach a TNEF section or other body parts. If the 155 receiving system rejected the message because it could not render 156 TNEF, the sender would be understandably confused and upset. 158 Thus, there is a need for a method of indicating to a Mail Transfer 159 Agent (MTA) or User Agent (UA) that the sender considers parts of a 160 message to be critical. From the sender's perspective, he would not 161 consider the message delivered if the system did not deliver the 162 critical parts. 164 One method of indicating critical content of a message is to define 165 a profile. The profile defines discard rules based on knowledge of 166 the user population for silently deleting body parts. Citing the 167 example above, a voice profile can easily declare that MTAs or UAs 168 can silently delete TNEF data and yet consider the message 169 successfully delivered. This is, in fact, the approach taken by 170 VPIMv2 [5]. 172 Since one aspect of the issue is deciding when to notify the sender 173 that the system cannot deliver part of a message, one could use a 174 partial non-delivery notification mechanism [6] to indicate a 175 problem with delivering a given body part. However, this requires 176 the user request a MDN. Moreover, the sender will receive PNDN 177 failures for objects the sender may not be aware he is sending. An 178 example would be the TNEF part. 180 Summarizing the needs, we need a mechanism that will let the sender 181 or sender's UA mark body parts he considers critical to the message 182 that the system must deliver. The mechanism MUST NOT burden the 183 sender with failure notifications for non-critical body parts. The 184 mechanism MUST conform to the general notification status request 185 mechanism for positive or negative notification. When requested, 186 the mechanism MUST indicate to the sender when a receiving system 187 cannot deliver a critical body part. 189 In short, we need a method of letting the sender indicate what body- 190 parts he considers to be critical. 192 This document describes a Critical Content marking mechanism that 193 satisfies these needs. Following the format for Internet message 194 bodies [3], this document introduces the Content-Criticality body 195 part header. Values for this header are CRITICAL, NOTIFY, or 196 IGNORE. The receiving MTA or UA will generate a delivery status 197 notification (DSN) [7] or Message Disposition Notification (MDN) [8] 198 at delivery time or reading time if it receives a request for 199 notification and the (non-)delivery status of the parts marked 200 NOTIFY meet the criteria for notification. 202 NOTE: A straightforward alternative implementation method for 203 marking a body part critical is to use a content-disposition 204 parameter called "criticality". 206 NOTE: We could have made the critical content indicator a parameter 207 to content-disposition. This has the benefit of being very easy for 208 IMAP servers to implement. In particular, IMAP servers 209 automatically present the content-disposition entity when a UA 210 requests information on a message. On the other hand, the UA must 211 explicitly request the presence and value of different entities, 212 such as content-criticality. However, implementing the critical 213 content indicator as a parameter to content-disposition overloads 214 the meaning of the entity. Moreover, IMAP servers can present, in 215 the future, content-criticality by default. Lastly, most UA's that 216 have interest in content-criticality will explicitly request the 217 header in any event. 219 4. Content-Criticality Entity 221 The Content-Criticality field is a MIME body part header inserted by 222 the sending UA to indicate to the receiving MTA or UA whether to 223 consider this body part critical. 225 A CRITICAL body part is one the sender requires the receiving system 226 to deliver for him to consider the message delivered. 228 An IGNORE body part is one the sender doesn't care whether the 229 receiving system delivers it or not. The receiving system can 230 silently delete such body parts if the receiving system cannot 231 deliver the part. 233 The terms "entity" and "body part" have the meanings defined in [3]. 235 One obvious application of critical content is generating a 236 (non-)delivery message. If the value of the field is IGNORE, the 237 receiving MTA or UA MUST NOT generate a notification. If the value 238 of the field is CRTITICAL, the receiving MTA or UA will generate a 239 notification, based on the normal notification request mechanisms. 240 Normal notification request mechanisms include the SMTP RCPT NOTIFY 241 command [9] and the Disposition-Notification-To header [8]. 243 For example, if the sending system requests a notification, and a 244 CRITICAL part fails, the receiving system will generate a NDN for 245 the whole message. Conversely, if only an IGNORE part fails, the 246 receiving system will not generate a NDN. 248 The next sections examine the actions taken by an MTA or UA given 249 the different values of Content-Criticality. 251 NOTE: This implies that the MTA must examine the entire message on 252 receipt to determine whether it needs to generate a notification. 253 However, the MTA need not examine the message if it knows it can 254 store and forward all media types. Said differently, Internet e- 255 mail MTA can, by default, handle any arbitrary MIME-encapsulated 256 type. Some voice mail systems, on the other hand, cannot store 257 binary attachments at all, such as application/ms-word. The voice 258 mail MTA, in this example, would be scanning for non-renderable body 259 parts in any event. 261 4.1. CRITICAL 263 "Content-Criticality: CRITICAL" signifies that this body part is 264 critical to the sender. 266 If the receiving system cannot render or store a body part marked 267 CRITICAL, then the entire message has failed. In this case, the 268 receiving system MUST take the appropriate failure action. 270 NOTE: We say "appropriate action", because the sender may have 271 suppressed all notifications. In this case, the appropriate action 272 is to simply discard the message. 274 4.2. IGNORE 276 "Content-Criticality: IGNORE" signifies that the sender does not 277 care about notification reports for this body part. 279 If the receiving system cannot render or store a body part marked 280 IGNORE, the receiving system may silently delete the body part. The 281 receiving system MUST NOT return a delivery failure, unless parts 282 marked IMPORTANT or CRITICAL have also failed. 284 4.3. Other Values 286 The receiving system MUST treat unrecognized values as CRITICAL. 287 This is to provide backward compatibility with future uses of the 288 Content-Criticality entity. 290 The most likely new value is IMPORTANT. An IMPORTANT body part is 291 something the sender wants the receiver to get, but would not want 292 the message rejected outright if the IMPORTANT body part fails. A 293 receiving system that does not understand IMPORTANT MUST take the 294 default value of CRITICAL. In this case, the MTA or UA MUST take 295 the conservative action of rejecting the message. 297 4.4. Summary 299 The following table summarizes the actions expected of a conforming 300 MTA or UA. 302 NOTE: This section is normative: it suggests what to put into the 303 DSN or MDN. 304 +--------------------------------------+ 305 | Sending UA Has Marked Body Part | 306 |---------------------+----------------| 307 | CRITICAL | IGNORE | 308 +--------------------+---------------------+----------------+ 309 | Body Part is | | | 310 | Deliverable/read | Appropriate Action | ignore | 311 +--------------------+---------------------+----------------+ 312 | Body Part is | | | 313 | Undeliverable / | | | 314 | Unreadable | Fail Entire Message | ignore | 315 +--------------------+--------------------------------------+ 317 The distinction between deliverable/read is as follows. A MTA can 318 determine if a body part is deliverable. If the body part is not 319 deliverable and is critical, the MTA could generate a DSN. An 320 example of such a MTA is a content-converting gateway. 322 An UA can determine if a body part is readable. If the body part is 323 not readable and is critical the UA could generate a MDN. 325 The "Appropriate Action" is the action the MTA or UA would take 326 given the context of execution. For example, if a sender requests 327 return receipt and the receiver reads a CRITICAL body part, the 328 receiving UA must generate the appropriate MDN (following the rules 329 for MDN). Likewise, if the MTA or UA cannot deliver the body part 330 and the body part is critical, the MTA or UA MUST generate the 331 appropriate DSN or MDN. 333 "Ignore" means the MTA or UA MUST ignore the operation on the body 334 part. The MTA or UA MUST treat the message as if the body part was 335 not present in the message. 337 5. Status Code 339 The critical content indication, in itself, does not guarantee any 340 notification. Notification follows the rules described in [7] and 341 [8]. 343 NOTE: The content of actual DSNs or MDNs are beyond the scope of 344 this document. This document only specifies how to mark a critical 345 body part. On the other hand, we do envision sensible DSN and MDN 346 contents. For example, DSNs should include the appropriate failure 347 code as enumerated in [10]. Likewise, MDNs should include the 348 failure code in the MDN "Failure:" field. 350 If the receiving system is to generate a notification based on its 351 inability to render or store the media type, the notification MUST 352 include the status code 5.6.1, "Media not supported", from [10]. 354 6. Backward Compatibility Considerations 356 If there are no Content-Criticality entities in the message, the 357 default value for Content-Criticality is CRITICAL. The standard 358 notification mechanisms work for sending user agents (UA) that do 359 not know about the content notification entity. All body parts are 360 critical, because they have the default marking of CRITICAL. 362 If there is at least one Content-Criticality entity in the message, 363 the default value for unspecified body parts is IGNORE. The 364 philosophy is that UAs, especially manually constructed messages, 365 will explicitly mark the critical body parts. 367 NOTE: We could choose the default value for Content-Criticality to 368 be IGNORE. This would make VPIMv2 automatically compliant with this 369 document, as VPIMv2 has provision to silently delete undeliverable 370 parts. However, VPIMv2 systems should not be receiving arbitrary e- 371 mail from the Internet. If they do, they should be compliant with 372 this series of documents. By defaulting to CRITICAL, this draft is 373 compliant with the rest of the Internet infrastructure. 375 NOTE: Some VPIMv2 implementations can receive arbitrary e-mail from 376 the Internet. However, these systems are really acting in the 377 capacity of an Internet Voice Mail system. In this case, one would 378 expect the implementation to provide Internet Voice Mail semantics 379 to Internet Voice Mail messages. 381 7. MIME Interactions 383 7.1. multipart/alternative 385 Content-Criticality is only in effect for the selected alternative. 386 If the selected alternative has the critical content indicator, then 387 the entire alternative takes on the criticality indicated. That is, 388 if the alternative selected has Content-Criticality: IGNORE, then 389 the receiving system MUST NOT generate any delivery notifications 390 (MDN, NDN, return-receipt, etc.). 392 It is unlikely for a selected alternative to fail, as the receiving 393 UA presumably picks the alternative specifically because it can 394 render it. 396 If the selected alternative is a message/rfc822 that encloses a 397 multipart MIME message or the selected alternative is itself a 398 multipart MIME type, the individual top-level body parts follow the 399 Content-Criticality mechanism described in this document. 401 7.2. multipart/related 403 Content-Criticality fits in rather well with the multipart/related 404 construction. For example, consider a multipart/related message 405 consisting of a Macintosh data fork and a Macintosh resource fork. 406 For a Microsoft Word document, the data fork is likely to be 407 critical. The receiving system can safely ignore the resource fork. 409 7.3. message/rfc822 411 Content-Criticality only affects the outermost level of the message 412 or, in the case of multipart/alternative, the outermost level of the 413 selected alternative. Specifically, the receiving system ignores 414 Content-Criticality indicators in embedded body parts. This avoids 415 the situation of a forwarded message triggering or suppressing 416 undesired or desired reporting. 418 8. Implementation Examples 420 This section is not a normative part of the definition of Content- 421 Criticality. However, we hope it helps implementers to understand 422 the mechanics of the Content-Criticality mechanism. 424 We will examine two cases. They are how a content gateway processes 425 a message and how a UA processes a message. 427 8.1. Content Gateways 429 Content gateways examine the contents of a message from a first 430 network before the gateway forwards the message to a second network. 431 For the purposes of this example, we assume the second network has 432 less capability than the first network. In particular, we expect 433 there will be certain message body types that the gateway cannot 434 pass onto the second network. 436 Consider a gateway between the Internet and a text-only short 437 message service. A message comes through the gateway containing a 438 text part and a tnef part. The sender marks the text part CRITICAL. 439 The gateway, knowing the capability of the short message service, 440 silently deletes the non-critical, tnef part, passing the critical 441 content to the shore message service network. Any subsequent 442 notifications, such as failure notices or delivery notices, follow 443 the normal rules for notification. 445 Note the gateway, by silently deleting non-critical content, may 446 affect proprietary message correlation schemes. One can envision 447 the sending UA inserting a body part for tracking purposes. By 448 deleting non-critical content, the content gateway will break such a 449 scheme. If a sending UA understands how to mark critical content, 450 it should use Internet standard mechanisms for tracking messages, 451 such as Message-ID [11]. 453 What if no body parts have critical content indicators? In this 454 case, the entire message is critical. Thus, when the gateway sees 455 the tnef part, it will reject the entire message, generating a DSN 456 with a status code 5.6.1, "Media not supported". 458 Likewise, consider a three part message with a text annotation (part 459 1) to a voice message (part 2) with a vCard [12] (part 3). The 460 sender marks the first two parts CRITICAL. Now, let us assume the 461 receiving MTA (gateway) is a voice mail only system, without even 462 the capability to store text. In this case, the gateway (receiving 463 MTA) will reject the message, generating a DSN with a status code 464 5.6.1, "Media not supported". 466 8.2. Non-Traditional UA 468 For this example, we will examine the processing of a three-part 469 message. The first part is a text annotation of the second part, an 470 audio message. The third part is the sender's vCard. The sender 471 marks the first and second parts CRITICAL. In addition, the sender 472 marks the message for read receipt. 474 For the purposes of example, the telephone user interface (TUI) does 475 not perform text-to-speech conversion. A TUI is a mail user agent 476 (UA) that uses DTMF touch-tone digits for input and audio for output 477 (display). 479 The TUI is unable to render the first part of the message, the text 480 part. In addition, it is unable to render the third part of the 481 message, the vCard part. Since the sender did not mark the third 482 part of the message CRITICAL, the system ignores the failure of the 483 TUI to render the third part of the message. However, since the 484 sender did mark the first part CRITICAL, and the TUI is unable to 485 render text, the message fails. 487 What happens next is implementation dependent. If the TUI is part 488 of a unified messaging system, a reasonable action is to hold the 489 message for the user. The user can access the message at a later 490 time from a terminal that can render all of the critical body parts. 491 It would be reasonable for the TUI to notify the user about the 492 message. 494 If the TUI is part of a voice messaging system, or if the user does 495 not subscribe to a text-to-speech service, a reasonable action is 496 for the TUI to return a MDN with the disposition "failed" and the 497 failure modifier "5.6.1 (Media not supported)". 499 9. Security Considerations 501 Receiving systems and users should not place any authentication 502 value on the Content-Criticality entity. Just because a message has 503 a particular Content-Criticality value doesn't mean that the message 504 really originated at a given type of system. 506 10. Collected Syntax 508 The format of the collected syntax is in accordance with the ABNF of 509 [13]. Note that per RFC 2045, none of the strings are case 510 sensitive. 512 "Content-Criticality" ":" notification-type CRLF 514 notification-type = "CRITICAL" / "IGNORE" 516 11. References 518 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 519 9, RFC 2026, October 1996. 521 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 522 Levels", BCP 14, RFC 2119, March 1997. 524 3 Freed, N. and Borenstein, N., "Multipurpose Internet Mail 525 Extensions (MIME) Part One: Format of Internet Message Bodies", 526 RFC 2045, Innosoft and First Virtual, November 1996. 528 4 Freed, N. and Borenstein, N., "Multipurpose Internet Mail 529 Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft and 530 First Virtual, November 1996. 532 5 Vaudreuil, G. and Parsons, G., "Voice Profile for Internet Mail - 533 version 2", RFC 2321, Lucent Technologies and Nortel Networks, 534 September 1998. 536 6 Burger, E., "Partial Non-Delivery Notification", Work in 537 Progress, draft-ema-burger-pndn-01.txt, March 2000. 539 7 Moore, K. and Vaudreuil, G., "An Extensible Message Format for 540 Delivery Status Notifications", RFC 1894, University of Tennessee 541 and Octel Network Services, January 1996. 543 8 Fajman, R., "An Extensible Message Format for Message Disposition 544 Notifications", RFC 2298, National Institutes of Health, March 545 1998. 547 9 Moore, K., "SMTP Service Extension for Delivery Status 548 Notifications", RFC 1981, University of Tennessee, January 1996. 550 10 Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, 551 Octel Network Services, January 1996. 553 11 Crocker, D., "Standard for the Format of ARPA Internet Text 554 Messages", RFC 822, University of Delaware, August 1982. 556 12 Dawson, F. and Howes, T., "vCard MIME Directory Profile", RFC 557 2426, Lotus Development Corporation and Netscape Communications, 558 September 1998. 560 13 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 561 Specifications: ABNF", RFC 2234, Internet Mail Consortium and 562 Demon Internet Ltd., November 1997. 564 12. Acknowledgments 566 We'd like to thank Ned Freed for pointing out that this mechanism 567 was about criticality, not notification per se. That insight made 568 the concept and descriptions infinitely more straightforward. If 569 it's still confusing, it's our fault! 571 We'd also like to thank Keith Moore for helping us tighten-up our 572 explanations. 574 Dropping the IMPORTANT critical content type took away one of the 575 reasons for partial non-delivery notification. That makes Jutta 576 Degener very happy! 578 Harald Alvestrand and Chris Newman suggested we add implementation 579 examples, which we did. 581 13. Author's Addresses 583 Eric Burger 584 SnowShore Networks 585 c/o CRV 586 1000 Winter St. 587 Waltham, MA 02451 588 USA 590 Phone: +1 703/304-3883 591 Email: e.burger@ieee.org 593 Emily Candell 594 Comverse Network Systems 595 200 Quannapowitt Pkwy. 596 Wakefield, MA 01880 597 USA 599 Phone: +1 781/213-2324 600 Email: emily@comversens.com 602 Full Copyright Statement 604 The IETF takes no position regarding the validity or scope of any 605 intellectual property or other rights that might be claimed to 606 pertain to the implementation or use of the technology described in 607 this document or the extent to which any license under such rights 608 might or might not be available; neither does it represent that it 609 has made any effort to identify any such rights. Information on the 610 IETF's procedures with respect to rights in standards-track and 611 standards-related documentation can be found in BCP-11. Copies of 612 claims of rights made available for publication and any assurances 613 of licenses to be made available, or the result of an attempt made 614 to obtain a general license or permission for the use of such 615 proprietary rights by implementers or users of this specification 616 can be obtained from the IETF Secretariat. 618 The IETF invites any interested party to bring to its attention any 619 copyrights, patents or patent applications, or other proprietary 620 rights that may cover technology that may be required to practice 621 this standard. Please address the information to the IETF Executive 622 Director. 624 Copyright (C) 2000 The Internet Society. All Rights Reserved. 626 This document and translations of it may be copied and furnished to 627 others, and derivative works that comment on or otherwise explain it 628 or assist in its implementation may be prepared, copied, published 629 and distributed, in whole or in part, without restriction of any 630 kind, provided that the above copyright notice and this paragraph 631 are included on all such copies and derivative works. However, this 632 document itself may not be modified in any way, such as by removing 633 the copyright notice or references to the Internet Society or other 634 Internet organizations, except as needed for the purpose of 635 developing Internet standards in which case the procedures for 636 copyrights defined in the Internet Standards process must be 637 followed, or as required to translate it into languages other than 638 English. 640 The limited permissions granted above are perpetual and will not be 641 revoked by the Internet Society or its successors or assigns. 643 This document and the information contained herein is provided on an 644 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 645 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 646 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 647 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 648 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.