idnits 2.17.1 draft-ietf-fax-content-negotiation-00.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 28 longer pages, the longest (page 1) being 63 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 477: '...rmat, the sender MUST select and trans...' RFC 2119 keyword, line 618: '...ive data formats MUST process that mes...' RFC 2119 keyword, line 640: '... A standard MDN response [4] or an extended MDN response [2] MAY be...' RFC 2119 keyword, line 647: '... response SHOULD be sent indicating a...' RFC 2119 keyword, line 664: '...ferable. An MDN response MUST be sent...' (9 more instances...) 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 (19 October 1999) is 8954 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: '17' is defined on line 1275, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 1290, 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) Summary: 15 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF fax WG G. Klyne (editor), Content Technologies 2 Internet draft R. Iwazaki, Toshiba TEC 3 D. Crocker, Brandenburg Consulting 4 19 October 1999 5 Expires: April 2000 7 Content Negotiation for Facsimile Using Internet Mail 8 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 To view the entire list of current Internet-Drafts, please check 33 the "1id-abstracts.txt" listing contained in the Internet-Drafts 34 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 35 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 36 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US 37 West Coast). 39 Copyright Notice 41 Copyright (C) The Internet Society 1999. All Rights Reserved. 43 Abstract 45 This memo describes a mechanism for e-mail content negotiation that 46 allows Internet fax to transfer enhanced image data in a fashion 47 comparable with traditional facsimile. 49 It allows the sender of a message to indicate availability of 50 alternative formats, and the receiver to indicate that an 51 alternative format should be provided to replace the message data 52 originally transmitted. 54 Content Negotiation for Internet Fax 19 October 1999 55 57 Table of contents 59 1. Introduction.............................................3 60 1.1 Structure of this document ...........................3 61 1.2 Document terminology and conventions .................4 62 1.2.1 Terminology......................................4 63 1.2.2 Design goals.....................................4 64 1.2.3 Other document conventions.......................4 65 1.3 Discussion of this document ..........................5 66 2. Background and goals.....................................5 67 2.1 Background ...........................................5 68 2.1.1 Fax and e-mail...................................5 69 2.1.2 Current facilities in Internet Fax...............6 70 2.2 Closing the loop .....................................6 71 2.3 Goals for content negotiation ........................8 72 3. Framework for content negotiation........................9 73 3.1 Send data with an indication of alternatives .........11 74 3.1.1 Choice of default data format....................11 75 3.1.2 MDN request indicating alternate data formats....11 76 3.1.3 Information about alternative data formats.......12 77 3.2 Receiver options .....................................13 78 3.2.1 Alternatives not recognized......................13 79 3.2.2 Alternative not desired..........................13 80 3.2.3 Alternative preferred............................14 81 3.3 Send alternative message data ........................14 82 3.4 Implementation issues ................................15 83 4. The Content-alternative header...........................15 84 5. MDN extension for alternative data.......................16 85 5.1 Indicating readiness to send alternative data ........17 86 5.2 Indicating a preference for alternative data .........18 87 6. Internet Fax Considerations..............................19 88 7. Examples.................................................19 89 7.1 Sending enhanced Internet Fax image ..................19 90 7.2 Internet fax with initial data usable ................22 91 7.3 Other example??? .....................................24 92 8. IANA Considerations......................................24 93 9. Internationalization considerations......................24 94 10. Security considerations.................................24 95 11. Acknowledgements........................................24 96 12. References..............................................25 97 13. Authors' addresses......................................27 98 Appendix A: Amendment history...............................28 99 Full copyright statement....................................28 100 Content Negotiation for Internet Fax 19 October 1999 101 103 1. Introduction 105 This memo describes a mechanism for e-mail content negotiation to 106 provide an Internet fax facility comparable to that of traditional 107 facsimile. 109 "Extended Facsimile using Internet Mail" [1] specifies the transfer 110 of image data using Internet e-mail protocols. "Indicating 111 Supported Media Features Using Extensions to DSN and MDN" [2] 112 describes a mechanism for providing the sender with details of a 113 receiver's capabilities. The capability information thus provided, 114 if stored by the sender, can be used in subsequent transfers 115 between the same sender and receiver. 117 Many communications are one-off or infrequent transfers between a 118 given sender and receiver, and cannot benefit from this "do better 119 next time" approach. 121 This memo describes a mechanism that allows better-than-baseline 122 data formats to be sent in the first communication between a sender 123 and receiver. The same mechanism can also achieve a usable message 124 transfer when the sender has stored incorrect information about the 125 receiver's capabilities. It allows the sender of a message to 126 indicate availability of alternative formats, and the receiver to 127 indicate that an alternative format should be provided to replacing 128 the message data originally transmitted. 130 When the sender does not have correct information about a 131 receiver's capabilities, the mechanism described here may incur an 132 additional message round trip. An important goal of this mechanism 133 is to allow enough information to be provided to determine whether 134 or not the extra round trip is required. 136 1.1 Structure of this document 138 The main part of this memo addresses the following areas: 140 Section 2 describes some of the background, and sets out some 141 specific goals that are addressed this specification. 143 Section 3 describes the proposed content negotiation framework, 144 indicating the flow of information between a sender and receiver. 146 Section 4 contains a detailed description of the 'Content- 147 alternative' header that is used to convey information about 148 alternative available formats. This description is intended to 149 stand independently of the rest of this specification, with a view 150 to being usable conjunction with other content negotiation 151 protocols. This may be moved to a separate document. 153 Content Negotiation for Internet Fax 19 October 1999 154 156 Section 5 describes extensions to the Message Disposition 157 Notification (MDN) framework [4] that are used to allow negotiation 158 between the communicating parties. 160 1.2 Document terminology and conventions 162 1.2.1 Terminology 164 Content negotiation 166 Capability exchange 168 Capability identification 170 [[[FROM RFC 2703]]] 172 [[[Others?]]] 174 1.2.2 Design goals 176 In discussing the goals for content negotiation, {1}, {2}, {3} 177 notation is used, per RFC 2542, "Terminology and Goals for Internet 178 Fax" [3]. The meanings associated with these notations are: 180 {1} there is general agreement that this is a critical 181 characteristic of any definition of content negotiation for 182 Internet Fax. 184 {2} most believe that this is an important characteristic of 185 content negotiation for Internet Fax. 187 {3} there is general belief that this is a useful feature of 188 content negotiation for Internet Fax, but that other factors 189 might override; a definition that does not provide this 190 element is acceptable. 192 1.2.3 Other document conventions 194 NOTE: Comments like this provide additional nonessential 195 information about the rationale behind this document. 196 Such information is not needed for building a conformant 197 implementation, but may help those who wish to understand 198 the design in greater depth. 200 [[[Editorial comments and questions about outstanding issues are 201 provided in triple brackets like this. These working comments 202 should be resolved and removed prior to final publication.]]] 204 Content Negotiation for Internet Fax 19 October 1999 205 207 1.3 Discussion of this document 209 Discussion of this document should take place on the content 210 negotiation and media feature registration mailing list hosted by 211 the Internet Mail Consortium (IMC): 213 Please send comments regarding this document to: 215 ietf-fax@imc.org 217 To subscribe to this list, send a message with the body 'subscribe' 218 to "ietf-fax-request@imc.org". 220 To see what has gone on before you subscribed, please see the 221 mailing list archive at: 223 http://www.imc.org/ietf-fax/ 225 2. Background and goals 227 2.1 Background 229 2.1.1 Fax and e-mail 231 One of the goals of the work to define a facsimile service using 232 Internet mail has been to deliver benefits of the traditional Group 233 3 Fax service in an e-mail environment. Traditional Group 3 Fax 234 leans heavily on the idea that an online exchange of information 235 discloses a receiver's capabilities to the sender before any 236 message data is transmitted. 238 By contrast, Internet mail has been developed to operate in a less 239 constrained fashion, without any expectation that the sender and 240 receiver will exchange information prior to message transfer. One 241 consequence of this is that all mail messages must contain some 242 kind of meaningful message data: messages that are sent simply to 243 elicit information from a receiving message handling agent are not 244 generally acceptable in the Internet mail environment. 246 To guarantee some level of interoperability, Group 3 Fax and 247 Internet mail rely on all receivers being able to deal with some 248 baseline format (i.e. a basic image format or plain ASCII text, 249 respectively). The role of capability exchange or content 250 negotation is to permit better-than baseline capabilities to be 251 employed where available. 253 Content Negotiation for Internet Fax 19 October 1999 254 256 One of challenges addressed by this specification is how to adapt 257 the e-mail environment to provide a fax-like service. A sender 258 must not make any a priori assumption that the receiver can 259 recognize anything other than a simple e-mail message. There are 260 some important uses of e-mail that are fundamentally incompatible 261 with the fax model of message passing and content negotiation 262 (notably mailing lists). So we need to have a way of recognizing 263 when content negotiation is possible, without breaking the existing 264 e-mail model. 266 2.1.2 Current facilities in Internet Fax 268 "Extended Facsimile using Internet Mail" [1] provides for limited 269 provision of receiver capability information to the sender of a 270 message, using an extension to Message Disposition Notifications 271 [2,4], employing media feature tags [5] and media feature 272 expressions [6]. 274 This mechanism provides for receiver capabilities to be disclosed 275 after a message has been received and processed. This information 276 can be used for subsequent transmissions to the same receiver. But 277 many communications are one-off messages from a given sender to a 278 given receiver, and cannot benefit from this mechanism. 280 2.2 Closing the loop 282 Classic Internet mail is an "open loop" process: no information is 283 returned back to the point from which the message is sent. This 284 has been unkindly --but accurately-- characterized as "send and 285 pray", since it lacks confirmation. 287 Sending a message and obtaining confirmation that the message has 288 been received is a "closed loop" process: the confirmation sent 289 back to the sender creates a loop around which information is 290 passed. 292 Many Internet e-mail agents are not designed to participate in a 293 closed loop process, and thus have no responsibility to respond to 294 receipt of a message. Later additions to Internet standards, 295 notably Delivery Service Notification [18] and Message Disposition 296 Notification [4], specify means for certain confirmation responses 297 to be sent back to the sender, thereby closing the loop. However 298 conformance to these enhancements is optional and full deployment 299 is in the future. 301 DSN must be fully implemented by the entire infrastructure; 302 further when support is lacking, the message is still sent on in 303 open-loop fashion. Sometimes, transmission and delivery should, 304 instead, be aborted and the fact be reported to the sender. 306 Content Negotiation for Internet Fax 19 October 1999 307 309 Due to privacy considerations for end-users, MDN usage is entirely 310 voluntary. 312 Content negotiation is a closed loop function, and requires that 313 the recipient of a message makes some response to the sender. 314 Since content negotiation must retro-fit a closed-loop environment 315 over Internet mail's voluntary and high-latency environment, a 316 challenge for content negotiation in e-mail is to establish that 317 consenting parties can recognize a closed loop situation, and hence 318 their responsibilities to close the loop. 320 Three different loops can be identified in a content negotiation: 322 Sender Receiver 323 | | 324 Initial message ------>------------ v 325 | | 326 (1) ------------<--- Request alternative data 327 | | 328 Send alternative ------>------------ (2) 329 | | 330 (3) ------------<------ Confirm receipt 331 of usable data 333 (1) Sender receives acknowledgement that negotable content has 334 been received 336 (2) Receiver receives confirmation that its request for data has 337 been received. 339 (3) Sender receives confirmation that received data is 340 processable, or has been processed. 342 Although the content negotiation process is initiated by the 343 sender, it is not established until loop (1) is closed with an 344 indication that the receiver desires alternative content. 346 If content sent with the original message from the sender is 347 processable by the receiver, and a confirmation is sent, then the 348 entire process is reduced to a simple send/confirm loop: 350 Sender Receiver 351 | | 352 Initial message ------>------------ v 353 | | 354 (3) ------------<------ Confirm receipt 355 of usable data 357 Content Negotiation for Internet Fax 19 October 1999 358 360 2.3 Goals for content negotiation 362 The primary goal {1} is to provide a mechanism that allows 363 arbitrary enhanced content features to be used with Internet fax 364 systems. The mechanism should {2} support introduction of new 365 features over time, particularly those that are adopted for Group 3 366 fax. 368 Further goals are: 370 (a) Must {1} interwork with existing simple mode Internet fax 371 systems. 373 (b) Must {1} interwork with existing e-mail clients. 375 The term "interwork" used above means that the mechansism must 376 be introduced in a way that may be ignored by existing 377 systems, and systems enhanced to use the negotiation 378 mechanisms will behave in a fashion that is expected by 379 existing systems. (I.e. existing clients are not expected in 380 any way to participate in or be aware of content negotiation.) 382 (c) Must {1} avoid transmission of "administrative non messages". 383 (I.e. only messages that contain content for the end user may 384 be sent unless it is known that the receiving system will 385 interpret them, and not attempt to display them.) This 386 requirement has been stated very strongly by the e-mail 387 community. 389 This means that a sender must not assume that a receiver can 390 understand the capability exchange protocol elements, so must 391 always start by sending some meaningful message data. 393 (d) Avoid {1} multiple renderings of a message. In situations 394 where multiple versions of a message are transferred, the 395 receiver must be able to reliably decide a single version to 396 be displayed. 398 (e) Minimize {2} round trips needed to complete a transmission. 399 Ideally {3} every enhanced trasmission will result in simply 400 sending data that the recipient can process, and receiving a 401 confirmation response. 403 (f) The solution adopted should not {3} transmit multiple versions 404 of the same data. In particular, it must not {1} rely on 405 routinely sending multiple instances of the same data in a 406 single message. 408 Content Negotiation for Internet Fax 19 October 1999 409 411 This does not prohibit sending multiple versions of the same 412 data, but it must not be a requirement to do so. A sender may 413 choose to send multiple versions together (e.g. TIFF-S and 414 some other format), but the capability exchange mechanism 415 selected must not depend on such behaviour. 417 (g) The solution adopted should {2} be applicable to other 418 Internet e-mail based applications; e.g. regular e-mail, 419 VPIM, unified messaging, etc. 421 (h) Graceful recovery from stale cache information. A sender 422 might use historic information to send non-baseline data with 423 an initial message. If this turns out to be unusable by the 424 recipient, it should still be possible {3} for the baseline 425 data, or some other acceptable format, to be selected and 426 transferred. 428 (i) The mechanism defined should {2} operate cleanly in 429 conjunction with the mechanisms already defined for extended 430 mode Internet fax (extended DSN and MDN [2], etc.). 432 (j) As far as possible, existing e-mail mechanisms should {3} be 433 used rather than inventing new ones. (It is clear that some 434 new mechanisms will be needed, but they should be defined 435 cautiously.) 437 (k) The mechanism should {2} be implementable in low memory 438 devices. That is, it should not depend on any party being 439 able to buffer arbitrary amounts of message data. 441 (It may not be possible to completely satisfy this goal in a 442 sending system. But if the sender does not have enough memory 443 to buffer some given message, it can choose to not offer 444 content negotiation.) 446 3. Framework for content negotiation 448 This section starts with an outline of the negotiation process, and 449 provides greater detail about each stage in following sub-sections. 451 1. Sender sends initial message data with an indication of 452 alternative formats available (section 3.1). Initial data may be 453 a baseline or other best guess of what the recipient can handle. 455 Content Negotiation for Internet Fax 19 October 1999 456 458 2. The receiver has three main options: 460 (a) Does not recognize the optional alternative formats, and 461 passively accepts the data as sent (section 3.2.1). 463 (b) Does recognize the alternatives offered, and actively 464 accepts the data as sent (section 3.2.2). 466 (c) Recognizes the alternatives offered, and determines that it 467 prefers to receive an alternative format. An MDN response 468 is sent (i) indicating that the original data was not 469 processed, and (ii) containing receiver capability 470 information so that the sender may select a suitable 471 alternative (section 3.2.3). 473 [[[Discuss concept of "receiver request" (response 474 retransmission) -- is it a "request" or a "declaration"?]]] 476 3. On receipt of an MDN response indicating preference for an 477 alternative data format, the sender MUST select and transmit 478 message data matched to the receiver's declared capabilities, or 479 send an indication that the [[[receiver's request]]] cannot be 480 honoured. 482 NOTE: the receiver does not choose the particular data 483 format to be received; that choice rests with the 484 sender. We find that this approach is simpler than 485 having the receiver choose an alternative, because it 486 builds upon existing mechanisms in e-mail, and follows 487 the same pattern as traditional Group 3 fax. Further, it 488 deals with situations where the range of alternatives may 489 be difficult to describe. 491 This approach is similar to server driven negotiation in 492 HTTP using "Accept" headers [13]. This is distinct to 493 the agent-driven style of negotiation provided for HTTP 494 as part of Transparent Content Negotiation [14], or which 495 might be constructed in e-mail using 496 "multipart/alternative" and "message/external-body" MIME 497 types [15]. 499 [[[?Require use of Original-recipient header. Only receivers that 500 match this may request alternative data formats. This reinforces 501 the 1:1 nature of a negotiation transaction? (This is spec.ed for 502 gateways and may be inappropriate here.)]]] 504 [[[?Consider whether to handle case of forwarded message?]]] 506 Content Negotiation for Internet Fax 19 October 1999 507 509 [[[?To ensure consistency of results, require content-id with body 510 part to which alternative capabilities are attached, to be noted in 511 MDN response?]]] 513 3.1 Send data with an indication of alternatives 515 A sender that is prepared to provide alternative message data 516 formats sends: 518 (a) a default message data format, 520 (b) appropriate 'Content-features' header(s) [7] describing the 521 default message data sent, 523 (c) a request for Message Disposition Notification [4], 525 (d) an indication that it is prepared to send different message 526 data, using an 'Alternative-available' MDN option field [9], 527 and 529 (e) an indication of the alternative data formats available, in 530 the form of 'Content-alternative' header(s) [8]. 532 3.1.1 Choice of default data format 534 Choice of the default format sent is essentially the same as that 535 available to a simple mode Internet Fax sender, per RFC 2305 [12]. 536 This essentially requires that TIFF Profile S [11] be sent unless 537 the sender has prior knowledge of other TIFF fields or values 538 supported by the recipient. 540 "Extended Facsimile Using Internet Mail" [1] and "Indicating 541 Supported Media Features Using Extensions to DSN and MDN" [2] 542 indicate a possible mechanism for a sender to have prior knowledge 543 of receiver capabilities. This specification builds upon the 544 mechanism described there. 546 As always, the sender may gather information about the receiver in 547 other ways beyond the scope of this document (e.g. a directory 548 service or the proposed RESCAP protocol). 550 3.1.2 MDN request indicating alternate data formats 552 When a sender is indicating preparedness to send alternative 553 message data, it must request a Message Disposition Notification 554 (MDN) [4]. 556 Content Negotiation for Internet Fax 19 October 1999 557 559 It indicates its readiness to send alternative message data by 560 including the MDN option 'Alternative-available' [9] with the MDN 561 request. Presence of this MDN request option simply indicates that 562 the sender is prepared to send some different data format if it has 563 more accurate or up-to-date information about the receiver's 564 capabilities. Of itself, this option does not indicate whether the 565 alternatives are likely to be better or worse than the default data 566 sent -- that information is provided by the "Content-alternative" 567 header(s) [8]. 569 3.1.3 Information about alternative data formats 571 A sender can provide information about the alternative message data 572 available by applying one or more 'Content-alternative' headers to 573 message body parts for which alternative data is available, each 574 indicating media features [5,6] of an available alternative. 576 The purpose of this information to allow a receiver to decide 577 whether any of the available alternatives are preferable, or likely 578 to be preferable, to the default message data provided. 580 Not every available alternative is required to be described in this 581 way, but the sender should include enough information to allow a 582 receiver to determine whether or not it can expect more useful 583 message data if it chooses to indicate a preference for some 584 alternative that matches its capabilities. 586 NOTE: this header is intended to be usable independently 587 of the MDN extension that indicates the sender is 588 prepared to send alternative formats. It might be used 589 with some completely different content negototiation 590 protocol that is nothing to do with e-mail or MDN. 592 Thus, the 'Content-alternative' header provides 593 information about alternative data formats without 594 actually indicating if and how they might be obtained. 596 Further, the 'Content-alternative' header applies to a 597 MIME body part, where the MDN 'Alternative-available' 598 option applies to the message as a whole. 600 The example sections of this memo shows how the 'Content-features:' 601 and 'Content-alternative:' MIME headers may be used to describe the 602 content provided and available alternatives. 604 [[[Q-factor values, per RFC 2533, in the 'Content-alternative:' 605 expressions might be used to distinguish between "definitive" and 606 "approximate" alternatives.]]] 608 Content Negotiation for Internet Fax 19 October 1999 609 611 [[[Expiration time on alternatives list. Else recipient is in non- 612 deterministic position. Also, cache control on recipient 613 capabilities?]]] 615 3.2 Receiver options 617 A negotiation-aware system receiving message data without an 618 indication of alternative data formats MUST process that message in 619 the same way as a standard Internet fax system or e-mail user 620 agent. 622 Given an indication of alternative data format options, the 623 receiver has three primary options: 625 (a) do not recognize the alternatives: passively accept what is 626 provided, 628 (b) do not prefer the alternatives: actively accept what is 629 provided, or 631 (c) prefer some alternative format. 633 3.2.1 Alternatives not recognized 635 This corresponds to the case that the receiver is a simple mode 636 Internet fax recipient [12], or a traditional e-mail user agent. 638 The receiver does not recognize the alternatives offered, or 639 chooses not to recognize them, and simply accepts the data as sent. 640 A standard MDN response [4] or an extended MDN response [2] MAY be 641 generated at the receiver's option. 643 3.2.2 Alternative not desired 645 The receiver does recognize the alternatives offered, but 646 specifically chooses to accept the data originally offered. An MDN 647 response SHOULD be sent indicating acceptance of the data and also 648 containing the receiver's capabilities. 650 This is similar to the defined behaviour of an Extended Internet 651 Fax receiver [1,2]. 653 Content Negotiation for Internet Fax 19 October 1999 654 656 3.2.3 Alternative preferred 658 This case extends the behaviour of Extended Internet Fax [1,2] to 659 allow an alternative form of data for the current message to be 660 transferred. 662 The receiver recognizes that alternative data is available, and 663 based on the information provided determines that an alternative 664 format would be preferable. An MDN response MUST be sent 665 containing: 667 o an 'Alternative-preferred' disposition modifier [9] indicating 668 that some data format other than that originally sent is 669 preferred, and 671 o receiver capabilities, per RFC 2530 [2]. 673 On sending such an MDN response, the receiver MAY discard the 674 message data provided, in the expectation that some alternative 675 will be sent. 677 [[[Need to address issues of receiver maintaining state; 678 specifically, what happens if the MDN response is lost in transit? 679 If the receiver does not maintain state then the original message 680 data is effectively lost, but the sender cannot infer this from the 681 lack of response. If the receiver does maintain state, it can (a) 682 resend the MDN response, (b) generate an error response indicating 683 loss of data, (c) present the data originally supplied (if it is 684 still available). Option (c) is incompatible with a low-memory 685 receiver.]]] 687 3.3 Send alternative message data 689 Having offered to provide alternative data by including an 690 'Alternative-available' option with the original MDN request, and 691 on receipt of an MDN response indicating 'Alternative-preferred', 692 the sender SHOULD transmit alternative message data that best 693 matches the receiver's declared capabilities. 695 If the alternative message data is the same as that originally 696 sent, it SHOULD still be retransmitted because the receiver may 697 have discarded the original data. Any data sent as a result of 698 receiving an 'Alternative-preferred' response should include an MDN 699 request but not an 'Alternative-available' option. 701 If the sender is no longer able to send message data for any 702 reason, it MUST send a message to the receiver indicating a failed 703 transfer. It SHOULD also generate a report for the sender 704 indicating the failure. 706 Content Negotiation for Internet Fax 19 October 1999 707 709 [[[Discuss this last paragraph.]]] 711 [[[The mechanisms are described above in terms of the entire 712 message. With MDN extensions that are being considered for finer- 713 grained disposition notification at the level of individual message 714 body parts (e.g. the separate parts of a MIME multipart/mixed), 715 this mechanism can be extended to provide independent negotiation 716 for each body part, because the 'Content-features:' and 'Content- 717 alternative:' can be applied to inner body parts.]]] 719 [[[Does it make sense to do a partial retransmission? I think this 720 would be a receiver option, based on which message parts it 721 indicates have been discarded. If it can buffer then partial 722 retransmission is sensible.]]] 724 3.4 Implementation issues 726 [[[TBD]]] 728 -- Sender state 730 -- Receiver state 732 -- Timeout of offer of alternatives 734 -- Partial vs whole-message resend 736 -- Recipient is fax machine vs e-mail UA 738 -- Reinforce situations where MDNs must not be auto-generated 740 -- Fax offramp issues 742 4. The Content-alternative header 744 [[[May be moved to a separate document.]]] 746 The 'Content-alternative:' header is a MIME header that can be 747 attached to a MIME body part to indicate availability of some 748 alternative form of the data it contains. This header does not, of 749 itself, indicate how the alternative form of data may be accessed. 751 Content Negotiation for Internet Fax 19 October 1999 752 754 Using the ABNF notation of RFC 2234 [10], the syntax of a 'Content- 755 alternative' header is defined as: 757 Content-alternative-header = 758 "Content-alternative" ":" Alternative-feature-expression 760 Alternative-feature-expression = 761 763 More than one 'Content-alternative:' header may be applied to a 764 MIME body part, in which case each one is taken to describe a 765 separate alternative data format that is available. 767 [[[Define 'ext-param' for feature cache control?]]] 769 [[[Should this be defined as comma-separated list, to allow 770 multiple values on a single header?]]] 772 [[[Need to consider how to express composite document capabilities, 773 specifically to assert a number of feature expressions that must be 774 simultaneously satisfied for a document to be processed, as in the 775 case of an MRC containing hi-res B/W and low-res colour. The 776 approach currently under consideration is a metalogic level 777 encapsulating media feature expressions]]] 779 [[[Discuss use with 'message/partial'?]]] 781 5. MDN extension for alternative data 783 [[[May be moved to a separate document]]] 785 Here, we define two extensions to the Message Disposition 786 Notification (MDN) protocol [4] to allow a sender to indicate 787 readiness to send alternative message data formats, and to allow a 788 receiver to indicate a preference for some alternative format. 790 Indication of what alternatives may be available or preferred are 791 not covered here. This functionality is provided by the 'Content- 792 alternative' MIME header [8] and "Indicating Supported Media 793 Features Using Extensions to DSN and MDN" [2]. 795 Content Negotiation for Internet Fax 19 October 1999 796 798 5.1 Indicating readiness to send alternative data 800 A sender wishing to indicate its readiness to send alternative 801 message data formats must request an MDN response using the MDN 802 'Disposition-Notification-To:' header [4]. 804 The MDN request is accompanied by a 'Disposition-Notification- 805 Options:' header containing the parameter 'Alternative-available' 806 with an importance value of 'optional'. (The significance of 807 'optional' is that receiving agents unaware of this option do not 808 generate inappropriate failure responses.) 810 This specification defines a value for 'attribute' to be used in an 811 MDN 'Message-Disposition-Options:' header [4]: 813 attribute =/ "Alternative-available" 815 Thus, a sender includes the following headers to indicate that 816 alternative message data is available: 818 Disposition-Notification-To: 819 820 Disposition-Notification-Options: 821 Alternative-available=optional,(TRUE) 823 [[[Is the parameter value really mandatory? RFC2298 syntax says 824 so. If so, what value should be used (what variations might be 825 required). Think carefully, this is a solution looking for a 826 problem. For now, I would prefer the option value to be optional. 827 If the value is required, its syntax should not preclude useful 828 extensions later. Use parameter to indicate return mailbox? Note 829 that RFC2298 allows auto-response to a single mailbox only.]]] 831 A message sent with a request for an MDN with an 'Alternative- 832 available' option MUST also contain a 'Message-ID:' header field 833 [20]. 835 Content Negotiation for Internet Fax 19 October 1999 836 838 5.2 Indicating a preference for alternative data 840 The MDN specification [4] defines a number of message disposition 841 options that may be reported by the receiver of a message: 843 disposition-type = "displayed" 844 / "dispatched" 845 / "processed" 846 / "deleted" 847 / "denied" 848 / "failed" 850 disposition-modifier = ( "error" / "warning" ) 851 / ( "superseded" / "expired" / 852 "mailbox-terminated" ) 853 / disposition-modifier-extension 855 This specification defines an additional value for 'disposition- 856 modifier-extension': 858 disposition-modifier-extension =/ 859 "Alternative-preferred" 861 When a receiver discards message data because it prefers that an 862 alternative format be sent, it sends a message disposition 863 notification message containing the following disposition field: 865 Disposition: 866 / 867 deleted/alternative-preferred 869 For example, an automatically generated response might contain: 871 Disposition: 872 automatic-action/MDN-sent-automatically, 873 deleted/alternative-preferred 875 An MDN response containing an 'alternative-preferred' disposition 876 modifier MUST also contain an 'Original-message-ID:' field [4] with 877 the 'Message-ID:' value from the original message. 879 [[[Discuss constraints on sending this response automatically.]]] 881 [[[Add E164 address type for fax offramp to fax machine as final 882 recipient?]]] 884 Content Negotiation for Internet Fax 19 October 1999 885 887 6. Internet Fax Considerations 889 Both sender and receiver parts of this specification involve the 890 use of media feature expressions. In the context of Internet fax, 891 any such expressions SHOULD employ feature tags defined by "Content 892 feature schema for Internet fax" [16]. In a wider e-mail context, 893 any valid media features MAY be used. 895 7. Examples 897 7.1 Sending enhanced Internet Fax image 899 An Internet fax sender has a profile-F (A4, 400x400dpi, MMR) image 900 to send to a receiver. The baseline for Internet fax is 200x200dpi 901 and MH image compression. 903 Sender's initial message: 905 Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400 906 From: Jane Sender 907 Message-Id: <199509200019.12345@huge.com> 908 Subject: Internet FAX Full Mode Content Negotiation 909 To: Tom Recipient 910 Disposition-Notification-To: Jane_Sender@huge.com 911 Disposition-Notification-Options: 912 Alternative-available=optional,[[[xxx]]] 913 MIME-Version: 1.0 914 Content-Type: multipart/mixed; 915 boundary="RAA14128.773615765/ huge.com" 917 --RAA14128.773615765/ huge.com 918 Content-type: image/tiff; application=faxbw 919 Content-Transfer-Encoding: base64 920 Content-features: 921 (& (color=Binary) 922 (image-file-structure=TIFF-minimal) 923 (dpi=200) 924 (dpi-xyratio=1) 925 (paper-size=A4) 926 (image-coding=MH) 927 (MRC-mode=0) 928 (ua-media=stationery) ) 930 Content Negotiation for Internet Fax 19 October 1999 931 933 Content-alternative: 934 (& (color=Binary) 935 (image-file-structure=TIFF-limited) 936 (dpi=400) 937 (dpi-xyratio=1) 938 (paper-size=A4) 939 (image-coding=MMR) 940 (MRC-mode=0) 941 (ua-media=stationery) ) 943 [TIFF-FX Profile-S message goes here] 945 --RAA14128.773615765/ huge.com-- 947 Receiver sends MDN response to initial message: 949 Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400 950 From: Tom Recipient 951 Message-Id: <199509200020.12345@mega.edu> 952 Subject: Re: Internet FAX Full Mode Content Negotiation 953 To: Jane Sender 954 MIME-Version: 1.0 955 Content-Type: multipart/report; 956 report-type=disposition-notification; 957 boundary="RAA14128.773615766/mega.edu" 959 --RAA14128.773615766/mega.edu 961 The message sent on 1995 Sep 19 at 00:18:00 (EDT) -0400 to 962 Tom Recipient with subject "Internet FAX 963 Full Mode Content Negotiation" has been received. An alternative 964 form of the message data is requested. 966 --RAA14128.773615766/mega.edu 967 Content-Type: message/disposition-notification 969 Reporting-UA: Toms-pc.cs.mega.edu; IFAX-FullMode 970 Original-Recipient: rfc822;Tom-Recipient@mega.edu 971 Final-Recipient: rfc822;Tom-Recipient@mega.edu 972 Original-Message-ID: <199509200019.12345@huge.com> 973 Disposition: automatic-action/MDN-sent-automatically; 974 deleted/alternative-preferred 976 Content Negotiation for Internet Fax 19 October 1999 977 979 Media-Accept-Features: 980 (& (color=Binary) 981 (image-file-structure=TIFF) 982 (| (& (dpi=200) (dpi-xyratio=200/100) ) 983 (& (dpi=200) (dpi-xyratio=1) ) 984 (& (dpi=400) (dpi-xyratio=1) ) ) 985 (| (image-coding=[MH,MR,MMR]) 986 (& (image-coding=JBIG) 987 (image-coding-constraint=JBIG-T85) 988 (JBIG-stripe-size=128) ) ) 989 (MRC-mode=0) 990 (paper-size=[A4,B4]) 991 (ua-media=stationery) ) 993 --RAA14128.773615766/mega.edu-- 995 Sender's message with enhanced content: 997 Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400 998 From: Jane Sender 999 Message-Id: <199509200021.12345@huge.com> 1000 Subject: Internet FAX Full Mode Image Transmission 1001 To: Tom Recipient 1002 Disposition-Notification-To: Jane_Sender@huge.com 1003 MIME-Version: 1.0 1004 Content-Type: multipart/mixed; 1005 boundary="RAA14128.773615768/ huge.com" 1007 --RAA14128.773615768/ huge.com 1008 Content-type: image/tiff; application=faxbw 1009 Content-Transfer-Encoding: base64 1011 [TIFF-FX profile-F message goes here] 1013 --RAA14128.773615768/ huge.com-- 1015 Receiver sends MDN confirmation of enhanced message content: 1017 Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400 1018 From: Tom Recipient 1019 Message-Id: <199509200022.12345@mega.edu> 1020 Subject: Re: Internet FAX Full Mode Image Transmission 1021 To: Jane Sender 1022 MIME-Version: 1.0 1023 Content-Type: multipart/report; 1024 report-type=disposition-notification; 1025 boundary="RAA14128.773615769/mega.edu" 1027 --RAA14128.773615769/mega.edu 1029 Content Negotiation for Internet Fax 19 October 1999 1030 1032 The message sent on 1995 Sep 19 at 00:21:00 (EDT) -0400 to Tom 1033 Recipient with subject " Internet FAX 1034 Full Mode Image Transmission" has been processed in Internet FAX 1035 Full Mode. 1037 --RAA14128.773615769/mega.edu 1038 Content-Type: message/disposition-notification 1040 Reporting-UA: Toms-pc.cs.mega.edu; IFAX-FullMode 1041 Original-Recipient: rfc822;Tom-Recipient@mega.edu 1042 Final-Recipient: rfc822;Tom-Recipient@mega.edu 1043 Original-Message-ID: <199509200021.12345@huge.com> 1044 Disposition: automatic-action/MDN-sent-automatically; processed 1045 Media-Accept-Features: 1046 (& (color=Binary) 1047 (image-file-structure=TIFF) 1048 (| (& (dpi=200) (dpi-xyratio=200/100) ) 1049 (& (dpi=200) (dpi-xyratio=1) ) 1050 (& (dpi=400) (dpi-xyratio=1) ) ) 1051 (| (image-coding=[MH,MR,MMR]) 1052 (& (image-coding=JBIG) 1053 (image-coding-constraint=JBIG-T85) 1054 (JBIG-stripe-size=128) ) ) 1055 (MRC-mode=0) 1056 (paper-size=[A4,B4]) 1057 (ua-media=stationery) ) 1059 --RAA14128.773615769/mega.edu-- 1061 7.2 Internet fax with initial data usable 1063 This example shows how the second and subsequent transfers between 1064 the systems in the previous example might be conducted. Using 1065 knowledge gained from the previous exchange, the sender includes 1066 profile-F data with its first contact. 1068 Sender's initial message: 1070 Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400 1071 From: Jane Sender 1072 Message-Id: <199509200019.12345@huge.com> 1073 Subject: Internet FAX Full Mode Content Negotiation 1074 To: Tom Recipient 1075 Disposition-Notification-To: Jane_Sender@huge.com 1076 Disposition-Notification-Options: 1077 Alternative-available=optional,[[[xxx]]] 1078 MIME-Version: 1.0 1079 Content-Type: multipart/mixed; 1080 boundary="RAA14128.773615765/ huge.com" 1082 Content Negotiation for Internet Fax 19 October 1999 1083 1085 --RAA14128.773615765/ huge.com 1086 Content-type: image/tiff; application=faxbw 1087 Content-Transfer-Encoding: base64 1088 Content-features: 1089 (& (color=Binary) 1090 (image-file-structure=TIFF-limited) 1091 (dpi=400) 1092 (dpi-xyratio=1) 1093 (paper-size=A4) 1094 (image-coding=MMR) 1095 (MRC-mode=0) 1096 (ua-media=stationery) ) 1097 Content-alternative: 1098 (& (color=Binary) 1099 (image-file-structure=TIFF-minimal) 1100 (dpi=200) 1101 (dpi-xyratio=1) 1102 (paper-size=A4) 1103 (image-coding=MH) 1104 (MRC-mode=0) 1105 (ua-media=stationery) ) 1107 [TIFF-FX Profile-F message goes here] 1109 --RAA14128.773615765/ huge.com-- 1111 Receiver sends MDN confirmation of received message content: 1113 Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400 1114 From: Tom Recipient 1115 Message-Id: <199509200022.12345@mega.edu> 1116 Subject: Re: Internet FAX Full Mode Image Transmission 1117 To: Jane Sender 1118 MIME-Version: 1.0 1119 Content-Type: multipart/report; 1120 report-type=disposition-notification; 1121 boundary="RAA14128.773615769/mega.edu" 1123 --RAA14128.773615769/mega.edu 1125 The message sent on 1995 Sep 19 at 00:21:00 (EDT) -0400 to Tom 1126 Recipient with subject "Internet FAX 1127 Full Mode Image Transmission" has been processed in Internet FAX 1128 Full Mode. 1130 --RAA14128.773615769/mega.edu 1131 Content-Type: message/disposition-notification 1133 Content Negotiation for Internet Fax 19 October 1999 1134 1136 Reporting-UA: Toms-pc.cs.mega.edu; IFAX-FullMode 1137 Original-Recipient: rfc822;Tom-Recipient@mega.edu 1138 Final-Recipient: rfc822;Tom-Recipient@mega.edu 1139 Original-Message-ID: <199509200021.12345@huge.com> 1140 Disposition: automatic-action/MDN-sent-automatically; processed 1141 Media-Accept-Features: 1142 (& (color=Binary) 1143 (image-file-structure=TIFF) 1144 (| (& (dpi=200) (dpi-xyratio=200/100) ) 1145 (& (dpi=200) (dpi-xyratio=1) ) 1146 (& (dpi=400) (dpi-xyratio=1) ) ) 1147 (| (image-coding=[MH,MR,MMR]) 1148 (& (image-coding=JBIG) 1149 (image-coding-constraint=JBIG-T85) 1150 (JBIG-stripe-size=128) ) ) 1151 (MRC-mode=0) 1152 (paper-size=[A4,B4]) 1153 (ua-media=stationery) ) 1155 --RAA14128.773615769/mega.edu-- 1157 7.3 Other example??? 1159 [[[Showing negotiate-down]]] 1161 8. IANA Considerations 1163 [[[TBD: MIME header and MDN extension registrations]]] 1165 [[[See RFC 2298, section 10]]] 1167 9. Internationalization considerations 1169 [[[TBD?]]] 1171 10. Security considerations 1173 [[[TBD]]] 1175 11. Acknowledgements 1177 The basic structure of the negotiation described here was first 1178 documented in an Internet Draft by Mr. Toru Maeda of Canon. 1180 Content Negotiation for Internet Fax 19 October 1999 1181 1183 12. References 1185 [1] RFC 2532, "Extended Facsimile using Internet Mail" 1186 L. Masinter, Xerox Corporation 1187 D. Wing, Cisco Systems 1188 March 1999. 1190 [2] RFC 2530, "Indicating Supported Media Features Using Extensions 1191 to DSN and MDN" 1192 D. Wing, Cisco Systems 1193 March 1999. 1195 [3] RFC 2542, "Terminology and Goals for Internet Fax" 1196 L. Masinter, Xerox Corporation 1197 March 1999. 1199 [4] RFC 2298, "An Extensible Message Format for Message Disposition 1200 Notifications" 1201 R. Fajman, National Institutes of Health 1202 March 1998. 1204 [5] RFC 2506, "Media Feature Tag Registration Procedure" 1205 Koen Holtman, TUE 1206 Andrew Mutz, Hewlett-Packard 1207 Ted Hardie, NASA 1208 March 1999. 1210 [6] RFC 2533, "A syntax for describing media feature sets" 1211 Graham Klyne, 5GM/Content Technologies 1212 March 1999. 1214 [7] "Indicating media features for MIME content" 1215 Graham Klyne, 5GM/Content Technologies 1216 Internet draft: 1217 Work in progress, April 1999. 1219 [8] 'Content-alternative' header (this memo, section 4) 1221 [9] MDN extension for alternative data (this memo, section 5) 1223 [10] RFC 2234, "Augmented BNF for Syntax Specifications: ABNF" 1224 D. Crocker (editor), Internet Mail Consortium 1225 P. Overell, Demon Internet Ltd. 1226 November 1997. 1228 Content Negotiation for Internet Fax 19 October 1999 1229 1231 [11] RFC 2301, "File format for Internet fax" 1232 L. McIntyre, 1233 R. Buckley, 1234 D. Venable, Xerox Corporation 1235 S. Zilles, Adobe Systems, Inc. 1236 G. Parsons, Northern Telecom 1237 J. Rafferty, Human Communications 1238 March 1998. 1240 [12] RFC 2305, "A Simple Mode of Facsimile Using Internet Mail" 1241 K. Toyoda 1242 H. Ohno 1243 J. Murai, WIDE Project 1244 D. Wing, Cisco Systems 1245 March 1998. 1247 [13] RFC 2616, "Hypertext Transfer Protocol -- HTTP/1.1" 1248 R. Fielding, UC Irvine 1249 J. Gettys, Compaq/W3C 1250 J. Mogul, Compaq 1251 H. Frystyk, W3C/MIT 1252 L. Masinter, Xerox 1253 P. Leach, Microsoft 1254 T. Berners-Lee, W3C/MIT 1255 June 1999. 1256 (Accept headers are described in section 14.1; section 12 1257 discusses content negotiation possibilities in HTTP.) 1259 [14] RFC 2295, "Transparent Content Negotiation in HTTP" 1260 Koen Holtman, TUE 1261 Andrew Mutz, Hewlett Packard 1262 March 1998. 1264 [15] RFC 2046, "Multipurpose Internet Mail Extensions (MIME) 1265 Part 2: Media types" 1266 N. Freed, Innosoft 1267 N. Borenstein, First Virtual 1268 November 1996. 1270 [16] RFC 2531, "Content feature schema for Internet fax" 1271 Graham Klyne, 5GM/Content Technologies 1272 Lloyd McIntyre, Xerox Corporation 1273 March 1998. 1275 [17] RFC 2703, "Protocol-independent Content Negotiation Framework" 1276 Graham Klyne, 5GM/Content Technologies 1277 September 1999. 1278 (This memo indicates terminology, framework and goals for content 1279 negotiation independent of any particular transfer protocol with 1280 which it may be deployed.) 1282 Content Negotiation for Internet Fax 19 October 1999 1283 1285 [18] RFC 1891, "SMTP Service Extension for Delivery Status 1286 Notifications" 1287 K. Moore, University of Tennessee 1288 January 1996. 1290 [19] RFC 821, "Simple Mail Transfer Protocol" 1291 Jonathan B. Postel, ISI/USC 1292 August 1982. 1294 [20] RFC 822, "Standard for the Format of ARPA Internet Text Messages" 1295 David H. Crocker, University of Delaware 1296 August 1982. 1298 13. Authors' addresses 1300 Graham Klyne (editor) 1301 Content Technologies Ltd. 1302 1220 Parkview, 1303 Arlington Business Park 1304 Theale 1305 Reading, RG7 4SA 1306 United Kingdom. 1307 Telephone: +44 118 930 1300 1308 Facsimile: +44 118 930 1301 1309 E-mail: GK@ACM.ORG 1311 Ryuji Iwazaki 1312 TOSHIBA TEC CORPORATION 1313 6-78, Minami-cho, Mishima-shi, 1314 Shizuoka, 411-8520 Japan 1315 Tel: +81 559 76 7507 1316 Fax: +81 559 76 7725 1317 E-mail: iwa@rdl.toshibatec.co.jp 1319 D. Crocker 1320 Brandenburg Consulting 1321 675 Spruce Dr. 1322 Sunnyvale, CA 94086 USA 1323 Phone: +1 408 246 8253 1324 Fax: +1 408 249 6205 1325 EMail: dcrocker@brandenburg.com 1327 Content Negotiation for Internet Fax 19 October 1999 1328 1330 Appendix A: Amendment history 1332 00a 30-Sep-1999 Memo initially created. 1334 00b 15-Oct-1999 Incorporated co-author material. Added examples. 1335 Added background section about open- and closed- 1336 loop operations. Cleaned up some text. Develop 1337 section describing the MDN extensions. Complete 1338 reference details. 1340 00c 19-Oct-1999 Acknowledgement and editorial changes. Re-written 1341 abstract and revised introductory text. 1343 TODO: 1345 o Review use of RFC 2119 language 1347 Full copyright statement 1349 Copyright (C) The Internet Society 1999. All Rights Reserved. 1351 This document and translations of it may be copied and furnished to 1352 others, and derivative works that comment on or otherwise explain 1353 it or assist in its implementation may be prepared, copied, 1354 published and distributed, in whole or in part, without restriction 1355 of any kind, provided that the above copyright notice and this 1356 paragraph are included on all such copies and derivative works. 1357 However, this document itself may not be modified in any way, such 1358 as by removing the copyright notice or references to the Internet 1359 Society or other Internet organizations, except as needed for the 1360 purpose of developing Internet standards in which case the 1361 procedures for copyrights defined in the Internet Standards process 1362 must be followed, or as required to translate it into languages 1363 other than English. 1365 The limited permissions granted above are perpetual and will not be 1366 revoked by the Internet Society or its successors or assigns. 1368 This document and the information contained herein is provided on 1369 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1370 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1371 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1372 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1373 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.