idnits 2.17.1 draft-ietf-fax-content-negotiation-03.txt: 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 38 longer pages, the longest (page 1) being 67 lines 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (5 October 2000) is 8603 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) == Unused Reference: '19' is defined on line 1499, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2542 (ref. '3') ** Obsolete normative reference: RFC 2298 (ref. '4') (Obsoleted by RFC 3798) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 2234 (ref. '10') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2301 (ref. '11') (Obsoleted by RFC 3949) ** Obsolete normative reference: RFC 2305 (ref. '12') (Obsoleted by RFC 3965) ** Obsolete normative reference: RFC 2616 (ref. '13') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Downref: Normative reference to an Experimental RFC: RFC 2295 (ref. '14') ** Obsolete normative reference: RFC 2531 (ref. '16') (Obsoleted by RFC 2879) ** Downref: Normative reference to an Informational RFC: RFC 2703 (ref. '17') ** Obsolete normative reference: RFC 1891 (ref. '18') (Obsoleted by RFC 3461) ** Obsolete normative reference: RFC 821 (ref. '19') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (ref. '20') (Obsoleted by RFC 2822) -- Possible downref: Non-RFC (?) normative reference: ref. '21' -- Possible downref: Non-RFC (?) normative reference: ref. '23' Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF fax WG G. Klyne (editor), Content Technologies 3 Internet draft R. Iwazaki, Toshiba TEC 4 D. Crocker, Brandenburg Consulting 5 5 October 2000 6 Expires: April 2001 8 Content Negotiation for Internet Messaging Services 9 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. 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. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts 24 as reference material or to cite them other than as "work in 25 progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 To view the entire list of current Internet-Drafts, please check 34 the "1id-abstracts.txt" listing contained in the Internet-Drafts 35 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 36 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 37 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US 38 West Coast). 40 Copyright Notice 42 Copyright (C) The Internet Society 2000. All Rights Reserved. 44 Abstract 46 This memo describes a content negotiation mechanism for facsimile, 47 voice and other messaging services that use Internet e-mail. 49 Services such as facsimile and voice messaging need to cope with 50 new message content formats, yet need to ensure that the content of 51 any given message is renderable by the receiving agent. The 52 mechanism described here aims to meet these needs in a fashion that 53 is fully compatible with the current behaviour and expectations of 54 Internet e-mail. 56 Content Negotiation for Internet Fax 5 October 2000 57 59 Discussion of this document 61 Please send comments to: . 63 To subscribe: send a message with the body 'subscribe' to . 66 The mailing list archive is at: . 68 Table of contents 70 1. Introduction.............................................3 71 1.1 Structure of this document ...........................4 72 1.2 Document terminology and conventions .................4 73 1.2.1 Terminology......................................4 74 1.2.2 Design goals.....................................5 75 1.2.3 Other document conventions.......................5 76 2. Background and goals.....................................6 77 2.1 Background ...........................................6 78 2.1.1 Fax and e-mail...................................6 79 2.1.2 Current facilities in Internet Fax...............6 80 2.2 Closing the loop .....................................7 81 2.3 Goals for content negotiation ........................8 82 3. Framework for content negotiation........................10 83 3.1 Send data with an indication of alternatives .........11 84 3.1.1 Choice of default data format....................12 85 3.1.2 MDN request indicating alternate data formats....12 86 3.1.3 Information about alternative data formats.......13 87 3.2 Receiver options .....................................14 88 3.2.1 Alternatives not recognized......................14 89 3.2.2 Alternative not desired..........................15 90 3.2.3 Alternative preferred............................15 91 3.3 Send alternative message data ........................17 92 3.4 Confirm receipt of resent message data ...............17 93 4. The Content-alternative header...........................18 94 5. The Original-Message-ID message header...................18 95 6. MDN extension for alternative data.......................19 96 6.1 Indicating readiness to send alternative data ........19 97 6.2 Indicating a preference for alternative data .........20 98 6.3 Indicating alternative data is no longer available ...21 99 6.4 Indicating loss of original data .....................21 100 6.5 Automatic sending of MDN responses ...................22 101 7. Internet Fax Considerations..............................22 102 8. Examples.................................................22 103 8.1 Sending enhanced Internet Fax image ..................22 104 8.2 Internet fax with initial data usable ................26 105 8.3 Other example??? .....................................27 106 8.4 Other example??? .....................................27 107 9. IANA Considerations......................................28 108 Content Negotiation for Internet Fax 5 October 2000 109 111 10. Internationalization considerations.....................28 112 11. Security considerations.................................28 113 12. Acknowledgements........................................28 114 13. References..............................................28 115 14. Authors' addresses......................................31 116 Appendix A: Implementation issues...........................32 117 A.1 Receiver state .......................................32 118 A.2 Receiver buffering of message data ...................33 119 A.x Other issues .........................................34 120 Appendix B: Candidates for further enhancements.............35 121 Appendix C: Amendment history...............................35 122 Full copyright statement....................................37 124 1. Introduction 126 This memo describes a mechanism for e-mail based content 127 negotiation to provide an Internet fax facility comparable to that 128 of traditional facsimile, which may be used by other messaging 129 services that need similar facilities. 131 "Extended Facsimile using Internet Mail" [1] specifies the transfer 132 of image data using Internet e-mail protocols. "Indicating 133 Supported Media Features Using Extensions to DSN and MDN" [2] 134 describes a mechanism for providing the sender with details of a 135 receiver's capabilities. The capability information thus provided, 136 if stored by the sender, can be used in subsequent transfers 137 between the same sender and receiver. 139 Many communications are one-off or infrequent transfers between a 140 given sender and receiver, and cannot benefit from this "do better 141 next time" approach. 143 An alternative facility available in e-mail (though not widely 144 implemented) is for the sender to use 'multipart/alternative' [15] 145 to send a message in several different formats, and allow the 146 receiver to choose. Apart from the obvious drawback of network 147 bandwidth use, this approach does not of itself allow the sender to 148 truly tailor its message to a given receiver, or to obtain 149 confirmation that any of the alternatives sent was usable by the 150 receiver. 152 This memo describes a mechanism that allows better-than-baseline 153 data formats to be sent in the first communication between a sender 154 and receiver. The same mechanism can also achieve a usable message 155 transfer when the sender has stored incorrect information about the 156 receiver's capabilities. It allows the sender of a message to 157 indicate availability of alternative formats, and the receiver to 158 indicate that an alternative format should be provided to replacing 159 the message data originally transmitted. 161 Content Negotiation for Internet Fax 5 October 2000 162 164 When the sender does not have correct information about a 165 receiver's capabilities, the mechanism described here may incur an 166 additional message round trip. An important goal of this mechanism 167 is to allow enough information to be provided to determine whether 168 or not the extra round trip is required. 170 1.1 Structure of this document 172 The main part of this memo addresses the following areas: 174 Section 2 describes some of the background, and sets out some 175 specific goals that are addressed this specification. 177 Section 3 describes the proposed content negotiation framework, 178 indicating the flow of information between a sender and receiver. 180 Section 4 contains a detailed description of the 'Content- 181 alternative' header that is used to convey information about 182 alternative available formats. This description is intended to 183 stand independently of the rest of this specification, with a view 184 to being usable conjunction with other content negotiation 185 protocols. This may be moved to a separate document. 187 Section 5 describes a new mail message header, 'Original-Message- 188 ID', which is used to correlate alternative data sent during 189 negotiation with the original message data, and to distinguish the 190 continuation of an old message transaction from the start of a new 191 transaction. 193 Section 6 describes extensions to the Message Disposition 194 Notification (MDN) framework [4] that support negotiation between 195 the communicating parties. 197 1.2 Document terminology and conventions 199 1.2.1 Terminology 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 203 this document are to be interpreted as described in RFC 2119 [22]. 205 Capability exchange 206 An exchange of information between communicating parties 207 indicating the kinds of information they can generate or 208 consume. 210 Capability identification 211 Provision of information by the a receiving agent that 212 indicates the kinds of message data that it can accept for 213 presentation to a user. 215 Content Negotiation for Internet Fax 5 October 2000 216 218 Content negotiation 219 An exchange of information (negotiation metadata) which leads 220 to selection of the appropriate representation (variant) when 221 transferring a data resource.Content negotiation 223 Message transaction 224 A sequence of exchanges between a message sender and receiver 225 that accomplish the transfer of message data. 227 [[[Others?]]] 229 RFC 2703 [17] introduces several other terms related to content 230 negotiation. 232 1.2.2 Design goals 234 In discussing the goals for content negotiation, {1}, {2}, {3} 235 notation is used, per RFC 2542, "Terminology and Goals for Internet 236 Fax" [3]. The meanings associated with these notations are: 238 {1} there is general agreement that this is a critical 239 characteristic of any definition of content negotiation for 240 Internet Fax. 242 {2} most believe that this is an important characteristic of 243 content negotiation for Internet Fax. 245 {3} there is general belief that this is a useful feature of 246 content negotiation for Internet Fax, but that other factors 247 might override; a definition that does not provide this 248 element is acceptable. 250 1.2.3 Other document conventions 252 NOTE: Comments like this provide additional nonessential 253 information about the rationale behind this document. 254 Such information is not needed for building a conformant 255 implementation, but may help those who wish to understand 256 the design in greater depth. 258 [[[Editorial comments and questions about outstanding issues are 259 provided in triple brackets like this. These working comments 260 should be resolved and removed prior to final publication.]]] 261 Content Negotiation for Internet Fax 5 October 2000 262 264 2. Background and goals 266 2.1 Background 268 2.1.1 Fax and e-mail 270 One of the goals of the work to define a facsimile service using 271 Internet mail has been to deliver benefits of the traditional Group 272 3 Fax service in an e-mail environment. Traditional Group 3 Fax 273 leans heavily on the idea that an online exchange of information 274 discloses a receiver's capabilities to the sender before any 275 message data is transmitted. 277 By contrast, Internet mail has been developed to operate in a 278 different fashion, without any expectation that the sender and 279 receiver will exchange information prior to message transfer. One 280 consequence of this is that all mail messages must contain some 281 kind of meaningful message data: messages that are sent simply to 282 elicit information from a receiving message handling agent are not 283 generally acceptable in the Internet mail environment. 285 To guarantee some level of interoperability, Group 3 Fax and 286 Internet mail rely on all receivers being able to deal with some 287 baseline format (i.e. a basic image format or plain ASCII text, 288 respectively). The role of capability exchange or content 289 negotation is to permit better-than baseline capabilities to be 290 employed where available. 292 One of challenges addressed by this specification is how to adapt 293 the e-mail environment to provide a fax-like service. A sender 294 must not make any a priori assumption that the receiver can 295 recognize anything other than a simple e-mail message. There are 296 some important uses of e-mail that are fundamentally incompatible 297 with the fax model of message passing and content negotiation 298 (notably mailing lists). So we need to have a way of recognizing 299 when content negotiation is possible, without breaking the existing 300 e-mail model. 302 2.1.2 Current facilities in Internet Fax 304 "Extended Facsimile using Internet Mail" [1] provides for limited 305 provision of receiver capability information to the sender of a 306 message, using an extension to Message Disposition Notifications 307 [2,4], employing media feature tags [5] and media feature 308 expressions [6]. 310 This mechanism provides for receiver capabilities to be disclosed 311 after a message has been received and processed. This information 312 can be used for subsequent transmissions to the same receiver. But 313 Content Negotiation for Internet Fax 5 October 2000 314 316 many communications are one-off messages from a given sender to a 317 given receiver, and cannot benefit from this. 319 2.2 Closing the loop 321 Classic Internet mail is an "open loop" process: no information is 322 returned back to the point from which the message is sent. This 323 has been unkindly --but accurately-- characterized as "send and 324 pray", since it lacks confirmation. 326 Sending a message and obtaining confirmation that the message has 327 been received is a "closed loop" process: the confirmation sent 328 back to the sender creates a loop around which information is 329 passed. 331 Many Internet e-mail agents are not designed to participate in a 332 closed loop process, and thus have no responsibility to respond to 333 receipt of a message. Later additions to Internet standards, 334 notably Delivery Service Notification [18] and Message Disposition 335 Notification [4], specify means for certain confirmation responses 336 to be sent back to the sender, thereby closing the loop. However 337 conformance to these enhancements is optional and full deployment 338 is in the future. 340 DSN must be fully implemented by the entire infrastructure; 341 further when support is lacking, the message is still sent on in 342 open-loop fashion. Sometimes, transmission and delivery should, 343 instead, be aborted and the fact be reported to the sender. 345 Due to privacy considerations for end-users, MDN usage is entirely 346 voluntary. 348 Content negotiation is a closed loop function (for the purposes of 349 this proposal -- see section 2.3, item (f)), and requires that the 350 recipient of a message makes some response to the sender. Since 351 content negotiation must retro-fit a closed-loop function over 352 Internet mail's voluntary and high-latency environment, a challenge 353 for content negotiation in e-mail is to establish that consenting 354 parties can recognize a closed loop situation, and hence their 355 responsibilities to close the loop. 357 Content Negotiation for Internet Fax 5 October 2000 358 360 Three different loops can be identified in a content negotiation: 362 Sender Receiver 363 | | 364 Initial message ------>------------ v 365 | | 366 (1) ------------<--- Request alternative data 367 | | 368 Send alternative ------>------------ (2) 369 | | 370 (3) ------------<------ Confirm receipt 371 of usable data 373 (1) Sender receives acknowledgement that negotiable content has 374 been received 376 (2) Receiver receives confirmation that its request for data has 377 been received. 379 (3) Sender receives confirmation that received data is 380 processable, or has been processed. 382 Although the content negotiation process is initiated by the 383 sender, it is not established until loop (1) is closed with an 384 indication that the receiver desires alternative content. 386 If content sent with the original message from the sender is 387 processable by the receiver, and a confirmation is sent, then the 388 entire process is reduced to a simple send/confirm loop: 390 Sender Receiver 391 | | 392 Initial message ------>------------ v 393 | | 394 (3) ------------<------ Confirm receipt 395 of usable data 397 2.3 Goals for content negotiation 399 The primary goal {1} is to provide a mechanism that allows 400 arbitrary enhanced content features to be used with Internet fax 401 systems. The mechanism should {2} support introduction of new 402 features over time, particularly those that are adopted for Group 3 403 fax. 405 Content Negotiation for Internet Fax 5 October 2000 406 408 Further goals are: 410 (a) Must {1} interwork with existing simple mode Internet fax 411 systems. 413 (b) Must {1} interwork with existing e-mail clients. 415 The term "interwork" used above means that the mechansism must 416 be introduced in a way that may be ignored by existing 417 systems, and systems enhanced to use the negotiation 418 mechanisms will behave in a fashion that is expected by 419 existing systems. (I.e. existing clients are not expected in 420 any way to participate in or be aware of content negotiation.) 422 (c) Must {1} avoid transmission of "administrative non messages". 423 (I.e. only messages that contain meaningful content for the 424 end user may be sent unless it is known that the receiving 425 system will interpret them, and not attempt to display them.) 426 This requirement has been stated very strongly by the e-mail 427 community. 429 This means that a sender must not assume that a receiver can 430 understand the capability exchange protocol elements, so must 431 always start by sending some meaningful message data. 433 (d) Avoid {1} multiple renderings of a message. In situations 434 where multiple versions of a message are transferred, the 435 receiver must be able to reliably decide a single version to 436 be displayed. 438 (e) Minimize {2} round trips needed to complete a transmission. 439 Ideally {3} every enhanced trasmission will result in simply 440 sending data that the recipient can process, and receiving a 441 confirmation response. 443 (f) The solution adopted should not {3} transmit multiple versions 444 of the same data. In particular, it must not {1} rely on 445 routinely sending multiple instances of the same data in a 446 single message. 448 This does not prohibit sending multiple versions of the same 449 data, but it must not be a requirement to do so. A sender may 450 choose to send multiple versions together (e.g. TIFF-S and 451 some other format), but the capability exchange mechanism 452 selected must not depend on such behaviour. 454 (g) The solution adopted should {2} be consistemt with and 455 applicable to other Internet e-mail based applications; e.g. 456 regular e-mail, voice messaging, unified messaging, etc. 458 Content Negotiation for Internet Fax 5 October 2000 459 461 (h) Graceful recovery from stale cache information. A sender 462 might use historic information to send non-baseline data with 463 an initial message. If this turns out to be unusable by the 464 recipient, it should still be possible {3} for the baseline 465 data, or some other acceptable format, to be selected and 466 transferred. 468 (i) The mechanism defined should {2} operate cleanly in 469 conjunction with the mechanisms already defined for extended 470 mode Internet fax (extended DSN and MDN [2], etc.). 472 (j) As far as possible, existing e-mail mechanisms should {3} be 473 used rather than inventing new ones. (It is clear that some 474 new mechanisms will be needed, but they should be defined 475 cautiously.) 477 (k) The mechanism should {2} be implementable in low memory 478 devices. That is, it should not depend on any party being 479 able to buffer arbitrary amounts of message data. 481 (It may be not possible to completely satisfy this goal in a 482 sending system. But if the sender does not have enough memory 483 to buffer some given message, it can choose to not offer 484 content negotiation.) 486 3. Framework for content negotiation 488 This section starts with an outline of the negotiation process, and 489 provides greater detail about each stage in following sub-sections. 491 1. Sender sends initial message data with an indication of 492 alternative formats available (section 3.1). Initial data MAY be 493 a baseline or other best guess of what the recipient can handle. 495 2. The receiver has three main options: 497 (a) Does not recognize the optional alternative formats, and 498 passively accepts the data as sent (section 3.2.1). 500 (b) Does recognize the alternatives offered, and actively 501 accepts the data as sent (section 3.2.2). 503 (c) Recognizes the alternatives offered, and determines that it 504 prefers to receive an alternative format. An MDN response 505 is sent (i) indicating that the original data was not 506 processed, and (ii) containing receiver capability 507 information so that the sender may select a suitable 508 alternative (section 3.2.3). 510 Content Negotiation for Internet Fax 5 October 2000 511 513 Note that only recipients named in 'to:', 'cc:' or 'bcc:' 514 headers in the original message may request alternative data 515 formats in this way. Recipients not named in the original 516 message headers MUST NOT attempt to initiate content 517 negotiation. 519 NOTE: the prohibition on initiation of negotiation by 520 recipients other than those explicitly addressed is to 521 avoid the sender having to deal with negotiation requests 522 from unexpected parties. 524 3. On receipt of an MDN response indicating preference for an 525 alternative data format, the sender MUST select and transmit 526 message data matched to the receiver's declared capabilities, or 527 send an indication that the receiver's request cannot be 528 honoured. When sending alternative data, the sender suppresses 529 the indication that alternative data is available, so the 530 negotiation process cannot loop. 532 4. On receipt of final data from the sender, the receiver sends an 533 MDN response indicating acceptance (or otherwise) of the data 534 received. 536 NOTE: the receiver does not choose the particular data 537 format to be received; that choice rests with the 538 sender. We find that this approach is simpler than 539 having the receiver choose an alternative, because it 540 builds upon existing mechanisms in e-mail, and follows 541 the same pattern as traditional Group 3 fax. Further, it 542 deals with situations where the range of alternatives may 543 be difficult to describe. 545 This approach is similar to server driven negotiation in 546 HTTP using "Accept" headers [13]. This is distinct to 547 the agent-driven style of negotiation provided for HTTP 548 as part of Transparent Content Negotiation [14], or which 549 might be constructed in e-mail using 550 "multipart/alternative" and "message/external-body" MIME 551 types [15]. 553 3.1 Send data with an indication of alternatives 555 A sender that is prepared to provide alternative message data 556 formats MUST send the following message elements: 558 (a) a default message data format, 560 (b) message identification, in the form of a Message-ID header. 562 Content Negotiation for Internet Fax 5 October 2000 563 565 (c) appropriate 'Content-features' header(s) [7] describing the 566 default message data sent, 568 (d) a request for Message Disposition Notification [4], 570 (e) an indication that it is prepared to send different message 571 data, using an 'Alternative-available' MDN option field [9], 572 and 574 (f) an indication of the alternative data formats available, in 575 the form of 'Content-alternative' header(s) [8]. Note: more 576 than one Content-alternative' header MAY be specified; see 577 section 3.1.3 for more information. 579 Having indicated the availability of alternative data formats, the 580 sender is expected to hold the necessary information for some time, 581 to allow the receiver an opportunity to request such data. But, 582 unless it so indicates (see [9]), the sender is not expected to 583 hold this information indefinitely; the exact length of time such 584 information should be held is not specified here. Thus, the 585 possibility exists that a request for alternative information may 586 arrive too late, and the sender will then send an indication that 587 the data is no longer avalable. If message transfer is being 588 completed within a predetermined time interval (e.g. using [21]), 589 then the sender should normally maintain the data for at least that 590 period. 592 3.1.1 Choice of default data format 594 Choice of the default format sent is essentially the same as that 595 available to a simple mode Internet Fax sender per RFC 2305 [12]. 596 This essentially requires that TIFF Profile S [11] be sent unless 597 the sender has prior knowledge of other TIFF fields or values 598 supported by the recipient. 600 "Extended Facsimile Using Internet Mail" [1] and "Indicating 601 Supported Media Features Using Extensions to DSN and MDN" [2] 602 indicate a possible mechanism for a sender to have prior knowledge 603 of receiver capabilities. This specification builds upon the 604 mechanism described there. 606 As always, the sender may gather information about the receiver in 607 other ways beyond the scope of this document (e.g. a directory 608 service or the suggested RESCAP protocol). 610 3.1.2 MDN request indicating alternate data formats 612 When a sender is indicating preparedness to send alternative 613 message data, it MUST request a Message Disposition Notification 614 (MDN) [4]. 616 Content Negotiation for Internet Fax 5 October 2000 617 619 It indicates its readiness to send alternative message data by 620 including the MDN option 'Alternative-available' [9] with the MDN 621 request. Presence of this MDN request option simply indicates that 622 the sender is prepared to send some different data format if it has 623 more accurate or up-to-date information about the receiver's 624 capabilities. Of itself, this option does not indicate whether the 625 alternatives are likely to be better or worse than the default data 626 sent -- that information is provided by the "Content-alternative" 627 header(s) [8]. 629 When using the 'Alternative-available' option in an MDN request, 630 the message MUST also contain a 'Message-ID:' header with a unique 631 message identifier. 633 3.1.3 Information about alternative data formats 635 A sender can provide information about the alternative message data 636 available by applying one or more 'Content-alternative' headers to 637 message body parts for which alternative data is available, each 638 indicating media features [5,6] of an available alternative. 640 The purpose of this information to allow a receiver to decide 641 whether any of the available alternatives are preferable, or likely 642 to be preferable, to the default message data provided. 644 Not every available alternative is required to be described in this 645 way, but the sender should include enough information to allow a 646 receiver to determine whether or not it can expect more useful 647 message data if it chooses to indicate a preference for some 648 alternative that matches its capabilities. 650 NOTE: the sender is not necessarily expected to describe 651 every single alternative format that is avalable -- 652 indeed, in cases where content is generated on-the-fly 653 rather than simply selected from an enumeration of 654 possibilities, this may be infeasible. The sender is 655 expected to use one or more 'Content-alternative' headers 656 to reasonably indicate the range of alternative formats 657 avalable. 659 The final format actually sent will always be selected by 660 the sender, based on the receiver's capabilities. The 661 'Content-alternative' headers are provided here simply to 662 allow the receiver to make a reasonable decision about 663 whether to request an alternative format that better 664 matches its capabilities. 666 Content Negotiation for Internet Fax 5 October 2000 667 669 ALSO NOTE: this header is intended to be usable 670 independently of the MDN extension that indicates the 671 sender is prepared to send alternative formats. It might 672 be used with some completely different content 673 negototiation protocol that is nothing to do with e-mail 674 or MDN. 676 Thus, the 'Content-alternative' header provides 677 information about alternative data formats without 678 actually indicating if or how they might be obtained. 680 Further, the 'Content-alternative' header applies to a 681 MIME body part, where the MDN 'Alternative-available' 682 option applies to the message as a whole. 684 The example sections of this memo show how the 'Content-features:' 685 and 'Content-alternative:' MIME headers may be used to describe the 686 content provided and available alternatives. 688 3.2 Receiver options 690 A negotiation-aware system receiving message data without an 691 indication of alternative data formats MUST process that message in 692 the same way as a standard Internet fax system or e-mail user 693 agent. 695 Given an indication of alternative data format options, the 696 receiver has three primary options: 698 (a) do not recognize the alternatives: passively accept what is 699 provided, 701 (b) do not prefer the alternatives: actively accept what is 702 provided, or 704 (c) prefer some alternative format. 706 3.2.1 Alternatives not recognized 708 This corresponds to the case that the receiver is a simple mode 709 Internet fax recipient [12], or a traditional e-mail user agent. 711 The receiver does not recognize the alternatives offered, or 712 chooses not to recognize them, and simply accepts the data as sent. 713 A standard MDN response [4] or an extended MDN response [2] MAY be 714 generated at the receiver's option. 716 Content Negotiation for Internet Fax 5 October 2000 717 719 3.2.2 Alternative not desired 721 The receiver does recognize the alternatives offered, but 722 specifically chooses to accept the data originally offered. An MDN 723 response SHOULD be sent indicating acceptance of the data and also 724 containing the receiver's capabilities. 726 This is the same as the defined behaviour of an Extended Internet 727 Fax receiver [1,2]. 729 3.2.3 Alternative preferred 731 This case extends the behaviour of Extended Internet Fax [1,2] to 732 allow an alternative form of data for the current message to be 733 transferred. This option may be followed ONLY if the original 734 message contains an 'Alternative-available' MDN option (alternative 735 data resends may not use this option). Further, this option may be 736 followed ONLY if the receipient is explicitly addressed in the 737 message headers ('to:', 'cc:' or 'bcc:'). 739 The receiver recognizes that alternative data is available, and 740 based on the information provided determines that an alternative 741 format would be preferable. An MDN response [4] is sent, which 742 MUST contain the following: 744 o an 'Alternative-preferred' disposition modifier [9] indicating 745 that some data format other than that originally sent is 746 preferred, 748 o an 'Original-Message-ID:' field [4] with the message identifier 749 from the received message, and 751 o receiver capabilities, per RFC 2530 [2]. 753 On sending such an MDN response, the receiver MAY discard the 754 message data provided, in the expectation that some alternative 755 will be sent. But if the sender has indicated a limited lifetime 756 for the alternative data, and the original data received is within 757 the receiver's capability to display, the receiver SHOULD NOT 758 discard it. Lacking sufficient memory to hold the original data 759 for a period of time within which alternative data would reasonably 760 be received, the receiver SHOULD accept and display the original 761 data. In the case that the original data is not within the 762 receiver's capability to display then it SHOULD discard the 763 original data and request an alternative format. 765 NOTE: the above rules are meant to ensure that the 766 content negotiation framework does not result in the loss 767 of data that would otherwise be received and displayed. 769 Content Negotiation for Internet Fax 5 October 2000 770 772 Having requested alternative data and not displayed the original 773 data, the receiver MUST remember this fact and be prepared to take 774 corrective action if alternative data is not received within a 775 reasonable time (e.g. if the MDN response or transmission of 776 alternative data is lost in transit). 778 Corrective action might be any of the following: 780 (a) resend the MDN response, and continue waiting for an 781 alternative, 783 (b) present the data originally supplied (if it is still 784 available), or 786 (c) generate an error response indicating loss of data. 788 On concluding that alternative data is not forthcoming, the 789 preferred option is (b), but this may not be possible for receivers 790 with limited memory. 792 See Appendix A for further discussion of receiver behaviour 793 options. 795 NOTE: A cache control indicator on recipient 796 capabilities has been considered, but is not included in 797 this specification. (Sometimes, a recipient may want to 798 offer certain capabilities only under certain 799 circumstances, and does not wish them to be remembered 800 for future use; e.g. not wanting to receive colour 801 images for routine communications.) 803 NOTE: the receiver does not actually get to select any 804 specific data format offered by the sender. The final 805 choice of data format is always made by the sender, based 806 on the receiver's eclared capabilities. This approach: 808 (a) more closely matches the style of T.30 content 809 negotiation, 811 (b) provides for clean integration with the current 812 extended mode Internet fax specification, 814 (c) builds upon existing e-mail mechanisms in a 815 consistent fashion, and 817 (d) allows for cases (e.g. dynamically generated content) 818 where it is not feasible for the sender to enumerate 819 the alternatives available. 821 Content Negotiation for Internet Fax 5 October 2000 822 824 3.3 Send alternative message data 826 Having offered to provide alternative data by including an 827 'Alternative-available' option with the original MDN request, and 828 on receipt of an MDN response indicating 'Alternative-preferred', 829 the sender SHOULD transmit alternative message data that best 830 matches the receiver's declared capabilities. 832 If any part of the best available message data matching the 833 receiver capabilities is the same as that originally sent, it MUST 834 still be retransmitted because the receiver may have discarded the 835 original data. Any data sent as a result of receiving an 836 'Alternative-preferred' response should include an MDN request but 837 SHOULD NOT include an 'Alternative-available' disposition 838 notification modifier. 840 If the sender is no longer able to send message data for any 841 reason, it MUST send a message to the receiver indicating a failed 842 transfer. It SHOULD also generate a report for the sender 843 indicating the failure, containing an MDN request and including an 844 'Alternative-not-available' disposition notification modifier. 846 Any message sent to a receiver in response to a request for 847 alternative data MUST include an 'Original-Message-ID:' header [23] 848 containg the Original-message-ID value from the received 849 disposition notification message (which is the 'Message-ID:' from 850 the original message). This header serves to correlate the resend 851 (or failure message) with the original message, and also to 852 distinguish a resend from an original message. 854 3.4 Confirm receipt of resent message data 856 When resent data is received (indicated by presence of an 857 'original-message-ID:' header field), the receiver processes that 858 data and generates an MDN response indicating the final disposition 859 of the data received. 861 If the resend indicates that alternative data is no longer 862 available (by including an 'Alternative-not-available' disposition 863 notification modifier), and the receiver still holds the original 864 data sent, it should display or process the original data and send 865 an MDN response indicating the final disposition of that data. 866 Thus, the response to an 'Alternative-not-available' indication may 867 be a successful disposition notification. 869 If the resend indicates that alternative data is no longer 870 available (by including an 'Alternative-not-available' disposition 871 notification modifier), and the receiver still holds the original 872 data sent, it SHOULD: 874 Content Negotiation for Internet Fax 5 October 2000 875 877 (a) display or process the failure message received, OR 879 (b) construct and display a message indicating that message data 880 has been lost, preferably indicating the sender, time, 881 subject, message identifier and other information that may 882 help the recipient user to identify the missing message. 884 and send a message disposition response indicating a final message 885 disposition of "deleted". 887 [[[Is this the correct final disposition value here?]]] 889 4. The Content-alternative header 891 [[[May be moved to a separate document.]]] 893 The 'Content-alternative:' header is a MIME header that can be 894 attached to a MIME body part to indicate availability of some 895 alternative form of the data it contains. This header does not, of 896 itself, indicate how the alternative form of data may be accessed. 898 Using the ABNF notation of RFC 2234 [10], the syntax of a 'Content- 899 alternative' header is defined as: 901 Content-alternative-header = 902 "Content-alternative" ":" Alternative-feature-expression 904 Alternative-feature-expression = 905 907 More than one 'Content-alternative:' header may be applied to a 908 MIME body part, in which case each one is taken to describe a 909 separate alternative data format that is available. 911 5. The Original-Message-ID message header 913 [[[Used to indicate message-ID for which the current message is a 914 resend.]]] 916 [[[May be moved to a separate document]]] 917 Content Negotiation for Internet Fax 5 October 2000 918 920 6. MDN extension for alternative data 922 [[[May be moved to a separate document]]] 924 Here, we define two extensions to the Message Disposition 925 Notification (MDN) protocol [4] to allow a sender to indicate 926 readiness to send alternative message data formats, and to allow a 927 receiver to indicate a preference for some alternative format. 929 Indication of what alternatives may be available or preferred are 930 not covered here. This functionality is provided by the 'Content- 931 alternative' MIME header [8] and "Indicating Supported Media 932 Features Using Extensions to DSN and MDN" [2]. 934 6.1 Indicating readiness to send alternative data 936 A sender wishing to indicate its readiness to send alternative 937 message data formats must request an MDN response using the MDN 938 'Disposition-Notification-To:' header [4]. 940 The MDN request is accompanied by a 'Disposition-Notification- 941 Options:' header containing the parameter 'Alternative-available' 942 with an importance value of 'optional'. (The significance of 943 'optional' is that receiving agents unaware of this option do not 944 generate inappropriate failure responses.) 946 This specification defines a value for 'attribute' to be used in an 947 MDN 'Disposition-Notification-Options:' header [4]: 949 attribute =/ "Alternative-available" 951 Thus, a sender includes the following headers to indicate that 952 alternative message data is available: 954 Disposition-Notification-To: 955 956 Disposition-Notification-Options: 957 Alternative-available=optional, 959 where is "transient" or "permanent", indicating whether 960 the alternative data will be made available for just a short while, 961 or for an indefinite period. A value of "permanent" indicates that 962 the data is held on long term storage and can be expected to be 963 available for at least several days, and probably weeks or months. 964 A value of "transient" indicates that the alternative data may be 965 discarded at any time, though it would normally be held for the 966 expected duration of a message transaction. 968 NOTE: the parameter is provided to help low- 969 memory receivers (which are unable to store received 970 Content Negotiation for Internet Fax 5 October 2000 971 973 data) avoid loss of information through requesting an 974 alternative data format that may become unavailable. 976 A message sent with a request for an MDN with an 'Alternative- 977 available' option MUST also contain a 'Message-ID:' header field 978 [20]. 980 6.2 Indicating a preference for alternative data 982 The MDN specification [4] defines a number of message disposition 983 options that may be reported by the receiver of a message: 985 disposition-type = "displayed" 986 / "dispatched" 987 / "processed" 988 / "deleted" 989 / "denied" 990 / "failed" 992 disposition-modifier = ( "error" / "warning" ) 993 / ( "superseded" / "expired" / 994 "mailbox-terminated" ) 995 / disposition-modifier-extension 997 This specification defines an additional value for 'disposition- 998 modifier-extension': 1000 disposition-modifier-extension =/ 1001 "Alternative-preferred" 1003 When a receiver requests that an alternative format be sent, it 1004 sends a message disposition notification message containing the 1005 following disposition field: 1007 Disposition: 1008 / 1009 deleted/alternative-preferred 1011 For example, an automatically generated response might contain: 1013 Disposition: 1014 automatic-action/MDN-sent-automatically, 1015 deleted/alternative-preferred 1017 An MDN response containing an 'alternative-preferred' disposition 1018 modifier MUST also contain an 'Original-message-ID:' field [4] with 1019 the 'Message-ID:' value from the original message. 1021 Content Negotiation for Internet Fax 5 October 2000 1022 1024 6.3 Indicating alternative data is no longer available 1026 A sender that receives a request for alternative data that is no 1027 longer available MUST respond with an indication of this fact, 1028 sending a message containing data describing the failure. 1030 Such a message MUST specify the MDN 'Disposition-Notification-To:' 1031 header [4], accompanied by a 'Disposition-Notification-Options:' 1032 header containing the parameter 'Alternative-not-available' with an 1033 importance value of 'required'. 1035 This specification defines a value for 'attribute' to be used in an 1036 MDN 'Disposition-Notification-Options:' header [4]: 1038 attribute =/ "Alternative-not-available" 1040 Thus, a sender includes the following headers to indicate that 1041 alternative message data previously offered is no longer available: 1043 Disposition-Notification-To: 1044 1045 Disposition-Notification-Options: 1046 Alternative-not-available=required,(TRUE) 1048 A message sent with a request for an MDN with an 'Alternative-not- 1049 available' option MUST also contain an 'Original-message-ID:' 1050 header [23] containg the value from the 'Message-ID:' header of the 1051 original message. 1053 6.4 Indicating loss of original data 1055 This specification defines an additional value for 'disposition- 1056 modifier-extension': 1058 disposition-modifier-extension =/ 1059 "original-lost" 1061 When a receiver loses message data because it lack memory to store 1062 the original while waiting for an alternative to be sent, it sends 1063 a message disposition notification containing the following field: 1065 Disposition: 1066 / 1067 deleted/original-lost 1069 For example, an automatically generated response might contain: 1071 Disposition: 1072 automatic-action/MDN-sent-automatically, 1073 deleted/original-lost 1074 Content Negotiation for Internet Fax 5 October 2000 1075 1077 An MDN response containing an 'original-lost' disposition modifier 1078 MUST also contain an 'Original-message-ID:' field [4] with the 1079 'Message-ID:' value from the resent message, or from the original 1080 message (if no resend has been received). 1082 6.5 Automatic sending of MDN responses 1084 In sending an MDN response that requests alternative data, the 1085 security concerns stated in RFC 2298 [4] (sections 2.1 and 6.2) 1086 regarding automatic MDN responses must be respected. In 1087 particular, a system capable of performing content negotiation MUST 1088 have an option for its user to disable negotiation responses, 1089 either generally, on a per-message basis, or both. 1091 7. Internet Fax Considerations 1093 Both sender and receiver parts of this specification involve the 1094 use of media feature expressions. In the context of Internet fax, 1095 any such expressions SHOULD employ feature tags defined by "Content 1096 feature schema for Internet fax" [16]. In a wider e-mail context, 1097 any valid media features MAY be used. 1099 8. Examples 1101 8.1 Sending enhanced Internet Fax image 1103 An Internet fax sender has a profile-F (A4, 400x400dpi, MMR) image 1104 to send to a receiver. The baseline for Internet fax is 200x200dpi 1105 and MH image compression. 1107 Sender's initial message: 1109 Date: Wed,20 Sep 1995 00:18:00 (EDT)-0400 1110 From: Jane Sender 1111 Message-Id: <199509200019.12345@huge.com> 1112 Subject: Internet FAX Full Mode Content Negotiation 1113 To: Tom Recipient 1114 Disposition-Notification-To: Jane_Sender@huge.com 1115 Disposition-Notification-Options: 1116 Alternative-available=optional,permanent 1117 MIME-Version: 1.0 1118 Content-Type: multipart/mixed; 1119 boundary="RAA14128.773615765/ huge.com" 1120 Content Negotiation for Internet Fax 5 October 2000 1121 1123 --RAA14128.773615765/ huge.com 1124 Content-type: image/tiff; application=faxbw 1125 Content-Transfer-Encoding: base64 1126 Content-features: 1127 (& (color=Binary) 1128 (image-file-structure=TIFF-minimal) 1129 (dpi=200) 1130 (dpi-xyratio=1) 1131 (paper-size=A4) 1132 (image-coding=MH) 1133 (MRC-mode=0) 1134 (ua-media=stationery) ) 1135 Content-alternative: 1136 (& (color=Binary) 1137 (image-file-structure=TIFF-limited) 1138 (dpi=400) 1139 (dpi-xyratio=1) 1140 (paper-size=A4) 1141 (image-coding=MMR) 1142 (MRC-mode=0) 1143 (ua-media=stationery) ) 1145 [TIFF-FX Profile-S message goes here] 1147 --RAA14128.773615765/ huge.com-- 1149 Receiver sends MDN response to initial message: 1151 Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400 1152 From: Tom Recipient 1153 Message-Id: <199509200020.12345@mega.edu> 1154 Subject: Re: Internet FAX Full Mode Content Negotiation 1155 To: Jane Sender 1156 MIME-Version: 1.0 1157 Content-Type: multipart/report; 1158 report-type=disposition-notification; 1159 boundary="RAA14128.773615766/mega.edu" 1161 --RAA14128.773615766/mega.edu 1163 The message sent on 1995 Sep 20 at 00:18:00 (EDT) -0400 to 1164 Tom Recipient with subject "Internet FAX 1165 Full Mode Content Negotiation" has been received. An alternative 1166 form of the message data is requested. 1168 --RAA14128.773615766/mega.edu 1169 Content-Type: message/disposition-notification 1170 Content Negotiation for Internet Fax 5 October 2000 1171 1173 Reporting-UA: Toms-pc.cs.mega.edu; IFAX-FullMode 1174 Original-Recipient: rfc822;Tom-Recipient@mega.edu 1175 Final-Recipient: rfc822;Tom-Recipient@mega.edu 1176 Original-Message-ID: <199509200019.12345@huge.com> 1177 Disposition: automatic-action/MDN-sent-automatically; 1178 deleted/alternative-preferred 1179 Media-Accept-Features: 1180 (& (color=Binary) 1181 (image-file-structure=TIFF) 1182 (| (& (dpi=200) (dpi-xyratio=200/100) ) 1183 (& (dpi=200) (dpi-xyratio=1) ) 1184 (& (dpi=400) (dpi-xyratio=1) ) ) 1185 (| (image-coding=[MH,MR,MMR]) 1186 (& (image-coding=JBIG) 1187 (image-coding-constraint=JBIG-T85) 1188 (JBIG-stripe-size=128) ) ) 1189 (MRC-mode=0) 1190 (paper-size=[A4,B4]) 1191 (ua-media=stationery) ) 1193 --RAA14128.773615766/mega.edu-- 1195 Sender's message with enhanced content: 1197 Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400 1198 From: Jane Sender 1199 Message-Id: <199509200021.12345@huge.com> 1200 Original-Message-Id: <199509200019.12345@huge.com> 1201 Subject: Internet FAX Full Mode Image Transmission 1202 To: Tom Recipient 1203 Disposition-Notification-To: Jane_Sender@huge.com 1204 MIME-Version: 1.0 1205 Content-Type: multipart/mixed; 1206 boundary="RAA14128.773615768/ huge.com" 1208 --RAA14128.773615768/ huge.com 1209 Content-type: image/tiff; application=faxbw 1210 Content-Transfer-Encoding: base64 1212 [TIFF-FX profile-F message goes here] 1214 --RAA14128.773615768/ huge.com-- 1215 Content Negotiation for Internet Fax 5 October 2000 1216 1218 Receiver sends MDN confirmation of enhanced message content: 1220 Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400 1221 From: Tom Recipient 1222 Message-Id: <199509200022.12345@mega.edu> 1223 Subject: Re: Internet FAX Full Mode Image Transmission 1224 To: Jane Sender 1225 MIME-Version: 1.0 1226 Content-Type: multipart/report; 1227 report-type=disposition-notification; 1228 boundary="RAA14128.773615769/mega.edu" 1230 --RAA14128.773615769/mega.edu 1232 The message sent on 1995 Sep 20 at 00:21:00 (EDT) -0400 to Tom 1233 Recipient with subject " Internet FAX 1234 Full Mode Image Transmission" has been processed in Internet FAX 1235 Full Mode. 1237 --RAA14128.773615769/mega.edu 1238 Content-Type: message/disposition-notification 1240 Reporting-UA: Toms-pc.cs.mega.edu; IFAX-FullMode 1241 Original-Recipient: rfc822;Tom-Recipient@mega.edu 1242 Final-Recipient: rfc822;Tom-Recipient@mega.edu 1243 Original-Message-ID: <199509200021.12345@huge.com> 1244 Disposition: automatic-action/MDN-sent-automatically; processed 1245 Media-Accept-Features: 1246 (& (color=Binary) 1247 (image-file-structure=TIFF) 1248 (| (& (dpi=200) (dpi-xyratio=200/100) ) 1249 (& (dpi=200) (dpi-xyratio=1) ) 1250 (& (dpi=400) (dpi-xyratio=1) ) ) 1251 (| (image-coding=[MH,MR,MMR]) 1252 (& (image-coding=JBIG) 1253 (image-coding-constraint=JBIG-T85) 1254 (JBIG-stripe-size=128) ) ) 1255 (MRC-mode=0) 1256 (paper-size=[A4,B4]) 1257 (ua-media=stationery) ) 1259 --RAA14128.773615769/mega.edu-- 1260 Content Negotiation for Internet Fax 5 October 2000 1261 1263 8.2 Internet fax with initial data usable 1265 This example shows how the second and subsequent transfers between 1266 the systems in the previous example might be conducted. Using 1267 knowledge gained from the previous exchange, the sender includes 1268 profile-F data with its first contact. 1270 Sender's initial message: 1272 Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400 1273 From: Jane Sender 1274 Message-Id: <199509200019.12345@huge.com> 1275 Subject: Internet FAX Full Mode Content Negotiation 1276 To: Tom Recipient 1277 Disposition-Notification-To: Jane_Sender@huge.com 1278 Disposition-Notification-Options: 1279 Alternative-available=optional,permanent 1280 MIME-Version: 1.0 1281 Content-Type: multipart/mixed; 1282 boundary="RAA14128.773615765/ huge.com" 1284 --RAA14128.773615765/ huge.com 1285 Content-type: image/tiff; application=faxbw 1286 Content-Transfer-Encoding: base64 1287 Content-features: 1288 (& (color=Binary) 1289 (image-file-structure=TIFF-limited) 1290 (dpi=400) 1291 (dpi-xyratio=1) 1292 (paper-size=A4) 1293 (image-coding=MMR) 1294 (MRC-mode=0) 1295 (ua-media=stationery) ) 1296 Content-alternative: 1297 (& (color=Binary) 1298 (image-file-structure=TIFF-minimal) 1299 (dpi=200) 1300 (dpi-xyratio=1) 1301 (paper-size=A4) 1302 (image-coding=MH) 1303 (MRC-mode=0) 1304 (ua-media=stationery) ) 1306 [TIFF-FX Profile-F message goes here] 1308 --RAA14128.773615765/ huge.com-- 1309 Content Negotiation for Internet Fax 5 October 2000 1310 1312 Receiver sends MDN confirmation of received message content: 1314 Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400 1315 From: Tom Recipient 1316 Message-Id: <199509200022.12345@mega.edu> 1317 Subject: Re: Internet FAX Full Mode Image Transmission 1318 To: Jane Sender 1319 MIME-Version: 1.0 1320 Content-Type: multipart/report; 1321 report-type=disposition-notification; 1322 boundary="RAA14128.773615769/mega.edu" 1324 --RAA14128.773615769/mega.edu 1326 The message sent on 1995 Sep 20 at 00:19:00 (EDT) -0400 to Tom 1327 Recipient with subject "Internet FAX 1328 Full Mode Image Transmission" has been processed in Internet FAX 1329 Full Mode. 1331 --RAA14128.773615769/mega.edu 1332 Content-Type: message/disposition-notification 1334 Reporting-UA: Toms-pc.cs.mega.edu; IFAX-FullMode 1335 Original-Recipient: rfc822;Tom-Recipient@mega.edu 1336 Final-Recipient: rfc822;Tom-Recipient@mega.edu 1337 Original-Message-ID: <199509200021.12345@huge.com> 1338 Disposition: automatic-action/MDN-sent-automatically; processed 1339 Media-Accept-Features: 1340 (& (color=Binary) 1341 (image-file-structure=TIFF) 1342 (| (& (dpi=200) (dpi-xyratio=200/100) ) 1343 (& (dpi=200) (dpi-xyratio=1) ) 1344 (& (dpi=400) (dpi-xyratio=1) ) ) 1345 (| (image-coding=[MH,MR,MMR]) 1346 (& (image-coding=JBIG) 1347 (image-coding-constraint=JBIG-T85) 1348 (JBIG-stripe-size=128) ) ) 1349 (MRC-mode=0) 1350 (paper-size=[A4,B4]) 1351 (ua-media=stationery) ) 1353 --RAA14128.773615769/mega.edu-- 1355 8.3 Other example??? 1357 [[[Showing negotiate-down]]] 1359 8.4 Other example??? 1361 [[[Showing fallback to original data]]] 1362 Content Negotiation for Internet Fax 5 October 2000 1363 1365 9. IANA Considerations 1367 [[[TBD: MIME header and MDN extension registrations]]] 1369 [[[See RFC 2298, section 10]]] 1371 10. Internationalization considerations 1373 [[[Failure message.]]] 1375 [[[TBD?]]] 1377 11. Security considerations 1379 [[[Note sending of automated MDN response: cross-ref text in RFC 1380 2532. and section 6.5]]] 1382 [[[TBD]]] 1384 12. Acknowledgements 1386 The basic structure of the negotiation described here was first 1387 documented in a draft by Mr. Toru Maeda of Canon. 1389 Helpful comments on earlier drafts were provided by Mr Hiroshi 1390 Tamura and Ted Hardie. 1392 13. References 1394 [1] RFC 2532, "Extended Facsimile using Internet Mail" 1395 L. Masinter, Xerox Corporation 1396 D. Wing, Cisco Systems 1397 March 1999. 1399 [2] RFC 2530, "Indicating Supported Media Features Using Extensions 1400 to DSN and MDN" 1401 D. Wing, Cisco Systems 1402 March 1999. 1404 [3] RFC 2542, "Terminology and Goals for Internet Fax" 1405 L. Masinter, Xerox Corporation 1406 March 1999. 1408 Content Negotiation for Internet Fax 5 October 2000 1409 1411 [4] RFC 2298, "An Extensible Message Format for Message Disposition 1412 Notifications" 1413 R. Fajman, National Institutes of Health 1414 March 1998. 1416 [5] RFC 2506, "Media Feature Tag Registration Procedure" 1417 Koen Holtman, TUE 1418 Andrew Mutz, Hewlett-Packard 1419 Ted Hardie, NASA 1420 March 1999. 1422 [6] RFC 2533, "A syntax for describing media feature sets" 1423 Graham Klyne, 5GM/Content Technologies 1424 March 1999. 1426 [7] "Indicating media features for MIME content" 1427 Graham Klyne, Content Technologies 1428 Internet draft: 1429 Work in progress, April 1999. 1431 [8] 'Content-alternative' header (this memo, section 4) 1433 [9] MDN extension for alternative data (this memo, section 6) 1435 [10] RFC 2234, "Augmented BNF for Syntax Specifications: ABNF" 1436 D. Crocker (editor), Internet Mail Consortium 1437 P. Overell, Demon Internet Ltd. 1438 November 1997. 1440 [11] RFC 2301, "File format for Internet fax" 1441 L. McIntyre, 1442 R. Buckley, 1443 D. Venable, Xerox Corporation 1444 S. Zilles, Adobe Systems, Inc. 1445 G. Parsons, Northern Telecom 1446 J. Rafferty, Human Communications 1447 March 1998. 1449 [12] RFC 2305, "A Simple Mode of Facsimile Using Internet Mail" 1450 K. Toyoda 1451 H. Ohno 1452 J. Murai, WIDE Project 1453 D. Wing, Cisco Systems 1454 March 1998. 1456 Content Negotiation for Internet Fax 5 October 2000 1457 1459 [13] RFC 2616, "Hypertext Transfer Protocol -- HTTP/1.1" 1460 R. Fielding, UC Irvine 1461 J. Gettys, Compaq/W3C 1462 J. Mogul, Compaq 1463 H. Frystyk, W3C/MIT 1464 L. Masinter, Xerox 1465 P. Leach, Microsoft 1466 T. Berners-Lee, W3C/MIT 1467 June 1999. 1468 (Accept headers are described in section 14.1; section 12 1469 discusses content negotiation possibilities in HTTP.) 1471 [14] RFC 2295, "Transparent Content Negotiation in HTTP" 1472 Koen Holtman, TUE 1473 Andrew Mutz, Hewlett Packard 1474 March 1998. 1476 [15] RFC 2046, "Multipurpose Internet Mail Extensions (MIME) 1477 Part 2: Media types" 1478 N. Freed, Innosoft 1479 N. Borenstein, First Virtual 1480 November 1996. 1482 [16] RFC 2531, "Content feature schema for Internet fax" 1483 Graham Klyne, 5GM/Content Technologies 1484 Lloyd McIntyre, Xerox Corporation 1485 March 1998. 1487 [17] RFC 2703, "Protocol-independent Content Negotiation Framework" 1488 Graham Klyne, 5GM/Content Technologies 1489 September 1999. 1490 (This memo indicates terminology, framework and goals for content 1491 negotiation independent of any particular transfer protocol with 1492 which it may be deployed.) 1494 [18] RFC 1891, "SMTP Service Extension for Delivery Status 1495 Notifications" 1496 K. Moore, University of Tennessee 1497 January 1996. 1499 [19] RFC 821, "Simple Mail Transfer Protocol" 1500 Jonathan B. Postel, ISI/USC 1501 August 1982. 1503 [20] RFC 822, "Standard for the Format of ARPA Internet Text Messages" 1504 David H. Crocker, University of Delaware 1505 August 1982. 1507 Content Negotiation for Internet Fax 5 October 2000 1508 1510 [21] "Timely Delivery for Facsimile Using Internet Mail" 1511 Graham Klyne, Content Technologies 1512 Internet draft: 1513 Work in progress, October 1999. 1515 [22] RFC 2119, "Key words for use in RFCs to Indicate Requirement 1516 Levels" 1517 S. Bradner, Harvard University 1518 March 1997. 1520 [23] 'Original-Message-ID' header for mail messages (this memo, 1521 section 5) 1523 14. Authors' addresses 1525 Graham Klyne (editor) 1526 Content Technologies Ltd. 1527 1220 Parkview, 1528 Arlington Business Park 1529 Theale 1530 Reading, RG7 4SA 1531 United Kingdom. 1532 Telephone: +44 118 930 1300 1533 Facsimile: +44 118 930 1301 1534 E-mail: GK@ACM.ORG 1536 Ryuji Iwazaki 1537 TOSHIBA TEC CORPORATION 1538 2-4-1, Shibakoen, Minato-ku, 1539 Tokyo, 105-8524 Japan 1540 Tel: +81 3 3438 6866 1541 Fax: +81 3 3438 6861 1542 E-mail: iwa@rdl.toshibatec.co.jp 1544 D. Crocker 1545 Brandenburg Consulting 1546 675 Spruce Dr. 1547 Sunnyvale, CA 94086 USA 1548 Phone: +1 408 246 8253 1549 Fax: +1 408 249 6205 1550 EMail: dcrocker@brandenburg.com 1551 Content Negotiation for Internet Fax 5 October 2000 1552 1554 Appendix A: Implementation issues 1556 This section is not a normative part of this specification. 1557 Rather, it discusses some of the issues that were considered during 1558 its design in a way that we hope will be useful to implementers. 1560 A.1 Receiver state 1562 Probably the biggest implication for implementers of this proposal 1563 compared with standard SMTP is the need to maintain some kind of 1564 state information at the receiver while content is being 1565 negotiated. 1567 By "receiver state", we mean that a receiver needs to remember that 1568 it has received an initial message AND that it has requested an 1569 alternative form of data. Without this, when a receiver responds 1570 with a request for an alternative data format there is a 1571 possibility (if the response does not reach the sender) that the 1572 message will be silently lost, despite its having been delivered to 1573 the receiving MTA. 1575 The matter of maintaining receiver state is particularly germane 1576 because of the requirement to allow low-memory systems to 1577 participate in the content negotiation. Unlike traditional T.30 1578 facsimile, where the negotiation takes place within the duration of 1579 a single connection, an extended time may be taken to complete a 1580 negotiation in e-mail. State information must be maintained for 1581 all negotiations outstanding at any time, and there is no 1582 theoretical upper bound on how many there may be. 1584 Keeping receiver state is probably not a problem for systems with 1585 high capacity storage devices to hold message data and state 1586 information. The remainder of this section discusses strategies 1587 that small-system designers might employ to place an upper bound on 1588 memory that must be reserved for this information. When a receiver 1589 is really memory constrained then message loss remains a 1590 possibility, but the mechanisms described here should ensure that 1591 it never happens silently. 1593 So what is this "receiver state"? It must contain, as a minimum: 1595 o the fact that message data was received, and alternative data has 1596 been requested, 1598 o a unique message identifier, and 1600 o the time at which an alternative format request was sent. 1602 Content Negotiation for Internet Fax 5 October 2000 1603 1605 This allows the receiver to re-issue a request, or to report an 1606 error, if requested alternative data does not arrive in a 1607 reasonable time. 1609 Receiver state may also include: 1611 o a copy of the data originally received. This allows the receiver 1612 to display the original data if an alternative is not received. 1614 o details of the data format supplied, and alternatives offered. 1615 This permits improved diagnostics if alternative data is not 1616 received. 1618 If a receiver of a message with alternative content available does 1619 not have enough memory to hold new negotiation state information, 1620 it may fall back to non-negotiation behaviour, accept the data 1621 received and send an MDN indicating disposition of that data (see 1622 sections 3.2.1, 3.2.2). 1624 If a receiving system runs low on memory after entering into a 1625 negotiation, a number of options may be possible: 1627 o display or print buffered data, if available, and complete the 1628 transaction. If alternative data arrives subsequently, it may be 1629 ignored or possibly also displayed or printed. A successful 1630 completion MDN may be sent to the sender. 1632 o discard any buffered data, and continue waiting for alternative 1633 data. If alternative data does not subsequently arrive, a 1634 message transfer failure should be declared. 1636 o abort the transfer and declare a message transfer failure: a 1637 diagnostic message must be displayed to the local user, and a 1638 failure notification sent to the sender. 1640 A.2 Receiver buffering of message data 1642 If a receiver is capable of buffering received message data while 1643 waiting for an alternative, this is to be prefered because it 1644 retains the option to display that data if an alternative is not 1645 received (see above). 1647 Partial message data should not be buffered for this purpose: 1648 displaying part of the original message is not an allowable 1649 substitute for displaying all of the received data. (There may be 1650 some value in keeping some of the original message data for 1651 diagnostic purposes.) 1653 If a receiver starts to buffer message data pending negotiation, 1654 then finds that the entire message is too large to buffer, it may 1655 Content Negotiation for Internet Fax 5 October 2000 1656 1658 choose to fall back to "extended mode" and display the incoming 1659 data as it is received. 1661 When a sender indicates availability of alternative data, it also 1662 indicates whether it is permanently or transiently available. The 1663 intent of this is that if alternative data is transient, a receiver 1664 should not discard original data received. If necessary, it should 1665 simply display the original data without requesting an alternative. 1667 A.x Other issues 1669 -- Sender state 1671 [[[Maintenance of information about outsanding offers of 1672 alternative data formats.]]] 1674 -- Timeout of offer of alternatives 1676 [[[Expand on note at end of section 3.1. Sender alternatives and 1677 choices? Consider facility to indicate expiry of alternatives.]]] 1679 -- Timeout of receiver capabilities 1681 [[[Consider facility to indicate expiry of receiver capabilities. 1682 Also, cache-control options, for temporary capabilities.]]] 1684 -- Relationship to timely delivery 1686 [[[What optimizations are possible (if any) when delivery and 1687 response is known to take no more than a few seconds?]]] 1689 -- Ephemeral capabilities 1691 [[[Consider the case of selection of a particular variant which may 1692 depend on an ephemeral setting. Imagine someone sending a basic 1693 fax to a color fax machine and indicating that a color alternative 1694 is available. The color fax discards the content and sends an MDN 1695 which says "deleted/alternative-preferred" to the originator. It 1696 then runs out of colored ink. The originating fax then sends a new 1697 message which the colored fax cannot print. (This may sound 1698 stretched, but consider it from the email client in a phone with 1699 sound on/off as a related problem).]]] 1701 -- Recipient is fax machine vs e-mail UA 1703 -- Reinforce situations where MDNs must not be auto-generated 1705 -- Fax offramp issues 1706 Content Negotiation for Internet Fax 5 October 2000 1707 1709 Appendix B: Candidates for further enhancements 1711 This appendix lists some possible features of content negotiation 1712 that were considered, but not included in the current 1713 specification. In most cases the reasons for exclusion were (a) 1714 that they could introduce unanticipated additional complexities, 1715 and (b) no compelling requirement was recognized. 1717 o Cache control indicator for recipient capabilities. This would 1718 instruct the sender, or other message system component, that 1719 capability information in the current message is for the current 1720 transaction only, and should NOT be remembered for future 1721 transactions. E.g. a recipient may not wish colour capability to 1722 be used for routine communications. 1724 o Use of q-values [6] in media feature expressions for indicating 1725 preference among alternatives available and/or receiver 1726 preferences. 1728 o Partial resends. There are proposals being developed for 1729 "partial MDN" responses that can indicate disposition status on a 1730 per-message-part basis. This opens the possibility of partial 1731 resends when alternative formats are requested for only some of 1732 the message body parts. The current specification assumes that 1733 either none or all of message is re-sent when content negotiation 1734 is used. 1736 o Allow negotiation with parties other than originally addressed 1737 recipients of a message. 1739 Appendix C: Amendment history 1741 00a 30-Sep-1999 Memo initially created. 1743 00b 15-Oct-1999 Incorporated co-author material. Added examples. 1744 Added background section about open- and closed- 1745 loop operations. Cleaned up some text. Develop 1746 section describing the MDN extensions. Complete 1747 reference details. 1749 00c 19-Oct-1999 Acknowledgement and editorial changes. Re-written 1750 abstract and revised introductory text. 1752 01a 12-Nov-1999 Make consistent date and time values in the 1753 examples. Fix mailing list description. 1755 Content Negotiation for Internet Fax 5 October 2000 1756 1758 01b 09-Mar-2000 Add text clarifying the role of sender and 1759 receiver in selecting alternative formats, the use 1760 of multiple 'Content-alternative' headers. Also 1761 add some notes about sender behaviour when sending 1762 an alternative data format. Updated author 1763 contact information. Added reference to 1764 multipart/alternative in the introduction. Added 1765 text in section 3.1 about retention of data by the 1766 sender. Added some comments to the implementation 1767 notes section. Added emphemeral capability 1768 scenario suggested by Ted Hardie for consideration 1769 under implementation notes. 1771 02a 11-Jul-2000 Change title of memo. Re-work abstract and 1772 introduction. Add some text to the terminology 1773 section; also cite RFC 2703 here. Minor 1774 editorial changes. Remove suggestion of allowing 1775 comma separated list for 'Content-alternative' 1776 header (following style of Content-features' 1777 defined separately). 1779 02b 14-Jul-2000 Added revisions arising from comments by Tamura- 1780 san: text about receiver state issues; note 1781 about distinguishing initial message from resend 1782 of alternative data; added requirement for 1783 message-ID header; add discussion of receiver 1784 options in case of insufficient memory. 1786 03a 12-Sep-2000 Incorporate review comments. Move implementation 1787 issues to appendix. 1789 03b 03-Oct-2000 Limit negotiation response to original addressees 1790 (for now). Add use of Original-message-ID: header 1791 to link resend of alternative data to original 1792 message. Add new disposition modifier option to 1793 indicate alternatives previously offered are no 1794 longer available. Add description of final 1795 confirmation following resend. Resolve many small 1796 outstanding design decisions. 1798 03c 05-Oct-2000 Include 'Original-Message-ID:' header in resend of 1799 first example. 1801 TODO: 1803 o Complete terminology (1.2.1) 1805 o Describe Original-Message-ID message header (5) 1807 o Negotiate-down example? (8.3) 1808 Content Negotiation for Internet Fax 5 October 2000 1809 1811 o Fallback to original data example? (8.4) 1813 o IANA considerations. (9) 1815 o Internationalization considerations. (10) 1817 o Security considerations. (11) 1819 o Write up "implementation issues" -- when outstanding issues are 1820 decided. (A) 1822 REVIEW CHECKLIST: 1824 (Points to be checked more widely on or before final review) 1826 o Cache-control for recipient features? (e.g. colour offered for 1827 selected senders only). (3.2.3) 1829 o Check the correct final disposition for lost message data (3.4) 1831 o Define Content-alternative in a separate document? (Possibly, 1832 because it might be used separately from the content negotiation 1833 framework; e.g. in a fashion similar to the HTTP vary: header.) 1834 (4) 1836 o Describe interaction between Content-alternative and 1837 message/partial. Is the discussion in RFC 2298 section 2.5 1838 sufficient? (4) 1840 o Special considerations for defining composite document 1841 characteristics (e.g. MRC) in Content-alternative headers? (4) 1843 o Add E164 address type for reporting fax offramp disposal? (6.2) 1844 Content Negotiation for Internet Fax 5 October 2000 1845 1847 Full copyright statement 1849 Copyright (C) The Internet Society 2000. All Rights Reserved. 1851 This document and translations of it may be copied and furnished to 1852 others, and derivative works that comment on or otherwise explain 1853 it or assist in its implementation may be prepared, copied, 1854 published and distributed, in whole or in part, without restriction 1855 of any kind, provided that the above copyright notice and this 1856 paragraph are included on all such copies and derivative works. 1857 However, this document itself may not be modified in any way, such 1858 as by removing the copyright notice or references to the Internet 1859 Society or other Internet organizations, except as needed for the 1860 purpose of developing Internet standards in which case the 1861 procedures for copyrights defined in the Internet Standards process 1862 must be followed, or as required to translate it into languages 1863 other than English. 1865 The limited permissions granted above are perpetual and will not be 1866 revoked by the Internet Society or its successors or assigns. 1868 This document and the information contained herein is provided on 1869 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1870 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1871 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1872 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1873 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.