idnits 2.17.1 draft-ietf-fax-confirmation-scenarios-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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 1) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (2 April 1998) is 9514 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) ** Obsolete normative reference: RFC 2305 (ref. '1') (Obsoleted by RFC 3965) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 821 (ref. '7') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (ref. '8') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1891 (ref. '9') (Obsoleted by RFC 3461) ** Obsolete normative reference: RFC 2298 (ref. '10') (Obsoleted by RFC 3798) -- Possible downref: Non-RFC (?) normative reference: ref. '12' ** Obsolete normative reference: RFC 974 (ref. '13') (Obsoleted by RFC 2821) ** Downref: Normative reference to an Unknown state RFC: RFC 1047 (ref. '14') Summary: 16 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Internet fax WG Graham Klyne 3 Internet draft Integralis Technology Ltd. 4 2 April 1998 5 Expires: 2 October 1998 7 Scenarios for Internet fax message confirmation 8 10 Status of this memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or made obsolete by other 19 documents at any time. It is inappropriate to use Internet-Drafts 20 as reference material or to cite them other than as ``work in 21 progress''. 23 To view the entire list of current Internet-Drafts, please check 24 the "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 26 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 27 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 28 (US West Coast). 30 Copyright (C) 1998, The Internet Society 32 Abstract 34 The simple mode for Internet fax described in [1] does not provide 35 positive confirmation of message delivery or disposition. There is 36 a widespread view that an important benefit of traditional fax [2] 37 is the fact that it provides a delivery confirmation which is 38 trusted by fax system users. 40 This memo describes some of the options for message confirmation in 41 Internet fax, taking account of the particular nature and goals of 42 the application [3], with a view to informing the debate over what 43 mechanisms should be used for this purpose. 45 Scenarios for Internet fax message confirmation 47 Table of contents 49 1. Introduction.............................................2 50 1.1 Terminology ..........................................3 51 1.2 Structure of this document ...........................3 52 1.3 Discussion of this document ..........................3 53 1.4 Amendment history ....................................4 54 2. Message confirmation issues in Internet fax..............4 55 3. Current message confirmation mechanisms..................6 56 3.1 Group 3 facsimile confirmation .......................6 57 3.2 Internet e-mail confirmations ........................6 58 3.2.1 Delivery Status Notifications (DSN)..............6 59 3.2.2 Message Disposition Notifications (MDN)..........7 60 3.2.2 Negative confirmations...........................8 61 4. Confirmation options and scenarios.......................8 62 4.1 Internet e-mail to e-mail ............................8 63 4.2 Internet e-mail to fax machine .......................9 64 4.3 Fax machine to Internet e-mail .......................9 65 4.4 Summary of scenarios .................................10 66 4.5 Other mechanisms .....................................12 67 4.5.1 Direct delivery..................................12 68 4.5.2 Session mode SMTP extension......................12 69 4.5.3 Real-time fax image transfer.....................13 70 5. Security considerations..................................14 71 6. Copyright................................................14 72 7. Acknowledgements.........................................15 73 8. References...............................................15 74 9. Author's address.........................................17 76 1. Introduction 78 The simple mode for Internet fax described in [1] does not provide 79 positive confirmation of message delivery or disposition. There is 80 a widespread view that an important benefit of traditional 81 facsimile [2] is the fact that it provides a delivery confirmation 82 which is trusted by fax system users. 84 Proposals for extended Internet fax [4,5,6] aim to provide for both 85 positive and negative confirmation of transmission of fax messages 86 which go beyond the limited negative acknowledgement capabilities 87 of SMTP [7]. 89 This memo describes some of the options for message confirmation in 90 Internet fax, taking account of the particular nature and goals of 91 the application [3], with a view to informing the debate over what 92 mechanisms should be used for this purpose. 94 Scenarios for Internet fax message confirmation 96 1.1 Terminology 98 Terminology used in this document that is specific to Internet fax 99 is taken from [3]. 101 1.2 Structure of this document 103 The main part of this draft addresses four main areas: 105 Section 2 discusses some of the technical issues that make 106 provision of traditional facsimile confirmation somewhat 107 problematic in Internet e-mail, and contrasts the features of 108 traditional fax transport mechanisms with Internet e-mail that make 109 this so. 111 Section 3 discusses some general concepts and mechanisms that might 112 have a bearing on how capability identification might be 113 implemented for Internet fax. 115 Section 4 describes some options for message confirmations in 116 Internet fax. 118 1.3 Discussion of this document 120 Discussion of this document should take place on the Internet fax 121 mailing list hosted by the Internet Mail Consortium (IMC): 123 Please send comments regarding this document to: 125 ietf-fax@imc.org 127 To subscribe to this list, send a message with the body 'subscribe' 128 to "ietf-fax-request@imc.org". 130 To see what has gone on before you subscribed, please see the 131 mailing list archive at: 133 http://www.imc.org/ietf-fax/ 135 To unsubscribe from the ietf-fax mailing list, send a message to 136 "ietf-fax-request@imc.org" containing the message 'unsubscribe'. 138 1.4 Amendment history 140 00a 01-Apr-1998 141 Document initially created. 143 00b 03-Apr-1998 144 Add material from IETF meeting discussions. Section 4.4 145 is new and helps to draw together some key ideas. 147 Scenarios for Internet fax message confirmation 149 2. Message confirmation issues in Internet fax 151 Technical differences between the Internet e-mail SMTP transport 152 [7] and the facsimile T.30 transmission protocol [2] that tend to 153 dictate different approaches to capability exchange are: 155 . SMTP separates the functions of message transmission from message 156 preparation and message display. Message transmission is 157 performed by Message Transfer Agents (MTAs), and message 158 preparation and display is handled by Message User Agents (MUAs). 160 The MTA and MUA components of Internet e-mail deal with separate 161 protocol elements: MTAs work with the SMTP protocol [7], where 162 MUAs deal with construction and processing of RFC822 e-mail 163 messages [8]. (MUAs also operate as SMTP clients for the purpose 164 of initiating a message transfer) 166 This separation of message transmission from message processing 167 has a distinct bearing on the forms that a message confirmation 168 can take: one form handled by MTAs is DSN [9], another form 169 handled by MUAs is MDN [10]. Further discussion of these appears 170 later. 172 A receiving MTA can be either a Message Store (MS) or a Gateway 173 to some other kind of messaging system (GW). 175 . SMTP is a store-and-forward protocol, which means that the sender 176 of a message is generally disengaged from the message transfer 177 process at the time final delivery is accomplished. T.30, on the 178 other hand, is a session mode protocol in which the transmitter 179 of a message is directly involved in the process until final 180 delivery is accomplished and signalled back to the sender. 182 (There is a proposal to provide a session mode capability in 183 SMTP, but in its present form even this may be forced to fall 184 back to store-and-forward mode in some circumstances.) 186 Because SMTP is a store-and-forward protocol, there may be 187 arbitrary delays in the transfer of a message, and it is not 188 generally possible to provide any kind of confirmation during the 189 protocol session that sends a message. 191 . In traditional facsimile, message delivery and disposition 192 (printing) are often handled at the same time and place: with 193 SMTP, the processes of delivery (e.g. to a POP mailbox) and 194 disposition (e.g. collection and display of message) may be 195 separated in time and space. 197 Scenarios for Internet fax message confirmation 199 There are exceptions to this, such as fax machines that receive 200 into memory, and print later. But it is widely held that the 201 "user model" of fax that it is printed as soon as it has been 202 sent. 204 . Being a store-and-forward Internet protocol, SMTP can service 205 occasionally connected correspondents; thus there is no 206 requirement or expectation for the ultimate recipient to be 207 accessible at the time a message is sent. Traditional facsimile, 208 on the other hand, relies on the fact that telephone devices are 209 always physically connected to the network and available to 210 receive calls (except when they are busy). 212 A related consideration is that SMTP senders do not have to be 213 concerned with the possibility that the recipient is busy at the 214 time a message is sent, but the next-hop MTA may be unavailable 215 for a variety of reasons so some system of retries is required. 217 . In T.30, the sender of a message connects directly to and 218 interacts with the receiver. Using SMTP, this is not generally 219 the case and an indeterminate number of intermediate relays 220 (MTAs) may be involved in the transmission process. The 221 capabilities of these intermediate systems to handle confirmation 222 mechanisms is not generally known. 224 . In general, there are significant per-message call setup and 225 volume-related transmission costs associated with traditional 226 facsimile. When using SMTP, there are generally no per-message 227 or volume-related transmission costs. (This is a simplification, 228 and there are exceptions in both cases, but this holds widely 229 enough to be a good working model.) 231 3. Current message confirmation mechanisms 233 There are two mechanisms currently defined for providing message 234 confirmations in Internet e-mail, neither of which exactly match 235 the traditional Group 3 facsimile confirmation mechanism. 237 3.1 Group 3 facsimile confirmation 239 Group 3 fax confirmation relies upon a real-time connection from 240 the sender to receiver. As each page of image data is transmitted, 241 a real-time protocol exchange occurs during which the receiver 242 indicates that the page has been received OK. 244 The confirmation generated by the receiving system often, but not 245 always, indicates that the received data has been printed. What it 246 does always indicate is that the data has been received and that 247 the receiving system has all information needed to process and 249 Scenarios for Internet fax message confirmation 251 print the data; i.e. that it has accepted responsibility for 252 further processing of the data. 254 There may always be circumstances when a G3 fax confirmation does 255 not guarantee that the intended recipient will see the message. A 256 power failure may destroy the message data stored in the receiving 257 facsimile machine; a printed message may be removed and lost 258 before the intended recipient can see it. But these are unlikely 259 events, and a Group 3 confirmation of receipt is generally a good 260 indication that the recipient will see the message. 262 3.2 Internet e-mail confirmations 264 It should be noted that, in the Internet e-mail environment, 265 message confirmations are generated only when explicitly requested 266 by the sender of a message. This rule is necessary to ensure that 267 message confirmation loops to not occur. 269 3.2.1 Delivery Status Notifications (DSN) 271 The request for DSN [9] is carried by the SMTP protocol, and is 272 processed by MTAs. 274 Advantages are: 276 . The sender is guaranteed some kind of response (unless the status 277 notification itself is lost in transit). 279 . The generation of DSN notifications does not depend upon the 280 capabilities of the receiving MUA. 282 Disadvantages are: 284 . End-to-end DSN requires the support of every MTA along the 285 transmission path from sender to recipient. If any one of these 286 MTAs does not support DSN then a notification response is 287 generated at that point which tells the sender how far the 288 message had progressed up to that point, but cannot provide 289 information about its further progress 291 Thus, the information provided by DSN may be of limited value. 293 . Even when DSN is fully supported by all MTAs, the final 294 notification might still not indicate that the message has been 295 delivered to the recipients receiving terminal. When the 296 recipient uses a mailbox protocol (e.g. POP3 [11]) to collect 297 message, MTA delivery is achieved on receipt of the message into 298 a message store serviced by the POP3 server. The recipient still 299 has to collect the message from the mailbox server before he can 300 process it. 302 Scenarios for Internet fax message confirmation 304 3.2.2 Message Disposition Notifications (MDN) 306 A request for MDN [10] is carried in the message body where it is 307 hidden from the activities of MTA. The receiving MUA (or gateway) 308 is responsible for generating all responses to an MDN request. 310 Advantages are: 312 . End-to-end confirmation does not depend upon the capabilities of 313 any MTA used to transmit the message. 315 Disadvantages are: 317 . Generation of a response to MDN depends upon the capabilities of 318 the receiving MUA. If it does not recognize the MDN request then 319 no MDN can be generated. 321 . There are a number of important security considerations 322 associated with the use of MDNs, and they may not be generated 323 without the receiving user's consent. For normal e-mail MUAs, 324 this means that a receiving user may prohibit generation of an 325 MDN with no indication of this fact passed back to the sender. 327 The security concerns are with possible disclosure of private 328 information about a user (e.g. an MDN request in a message to a 329 mailing list might be used to gather addresses for spamming), or 330 with disclosure of information about the activities of a user 331 (e.g. the response to an MDN might disclose that the user was 332 connected to the Internet or reading e-mail at a particular 333 time). 335 3.2.2 Negative confirmations 337 The discussions above address mechanisms for positive message 338 confirmation. 340 For negiative confirmation (reporting of errors on the transmission 341 path), Delivery Status Notifications are required, because there 342 can be no guarantee that an Message Disposition Notification will 343 ever be generated. If a message is lost at any point along the 344 path from sender to delivery point, there is no way for generation 345 of an MDN to be triggered. 347 Thus, in all cases, DSNs must are required for negative message 348 confirmation. 350 Scenarios for Internet fax message confirmation 352 4. Confirmation options and scenarios 354 In this section, some options and message confirmation scenarios 355 are suggested. 357 4.1 Internet e-mail to e-mail 359 (1) (2) (3) (4) 360 +----------+ +---------+ +-----------+ +-----------+ 361 |Sender-MUA|-->--|Relay-MTA|-->--|Receive-MTA|-->--|Receive-MUA| 362 +----------+ +---------+ +-----------+ +-----------+ 364 . DSN end-to-end: with DSN implemented at (2) and (3), provides 365 notification of delivery to (3). If (3) is a mailbox server, no 366 indication of collection by (4) will be returned. 368 . DSN part-way: with DSN implemented at (2) but not at (3), 369 provides indication that the message was delivered to (3), but 370 that no information about any further MTA hops will be provided. 372 . DSN not implemented: with DSN not implemented at (2), the 373 sending MUA knows only that the message was accepted at (2) for 374 onward delivery. 376 . MDN implemented: if (4) implements MDN then an MDN might be 377 generated when the message is received and displayed at (4). But 378 the user at (4) may choose to prohibit generation of MDN. 380 . MDN implemented at receiving Internet Fax (IFAX) device: in this 381 case, it might be possible to relax the conditions regarding 382 automatic generation of MDN, since the security concerns about 383 user privacy may not apply, to provide a dependably confirmation 384 of receipt. 386 4.2 Internet e-mail to fax machine 388 (1) (2) (3) (4) 389 +----------+ +---------+ +-----------+ +-----------+ 390 |Sender-MUA|-->--|Relay-MTA|-->--|offramp-MTA|-->--|Receive-fax| 391 +----------+ +---------+ +-----------+ +-----------+ 393 . DSN end-to-end: with DSN implemented at (2) and (3), can 394 provides notification of delivery to (4), assuming the offramp 395 uses the T.30 confirmation from (4) to generate a DSN response. 397 . DSN part-way: with DSN implemented at (2) but not at (3), 398 provides indication that the message was delivered to the offramp 399 (3), but that no information about receipt by (4) will be 400 forthcoming. 402 Scenarios for Internet fax message confirmation 404 . DSN not implemented: with DSN not implemented at (2), the 405 sending MUA knows only that the message was accepted at (2) for 406 onward delivery, (just like corresponding the e-mail to e-mail 407 case). 409 . MDN implemented: if (3) implements MDN then an MDN can be 410 generated when the fax is delivered to (4), triggered by the T.30 411 confirmation from (4). 413 This is a situation where the prohibition of automatic MDNs can 414 be relaxed, because they would not disclose information about the 415 recipient which is not available by calling the receiving fax 416 machine directly. 418 4.3 Fax machine to Internet e-mail 420 (1) (2) (3) (4) 421 +----------+ +----------+ +---------+ +-----------+ 422 |Sender-fax|-->--|Onramp-MTA|-->--|Relay-MTA|-->--|Receive-MUA| 423 +----------+ +----------+ +---------+ +-----------+ 425 . DSN end-to-end: with DSN implemented at (2) and (3), provides 426 notification of delivery to (3). If (3) is a mailbox server, no 427 indication of collection by (4) will be returned. 429 But, the confirmation of delivery received at (2) will be too 430 late to provide a normal T.30 message confirmation back to (1). 431 Confirmation of receipt would have to be provided by a separate 432 out-dial by (2) and fax transmission of a confirmation slip. 433 (The out-dial might be avoided by having the sender-fax poll for 434 confirmation, but this would require a change of behaviour in the 435 installed fax base, so is considered impractical.) 437 The T.30 confirmation received at (1) will indicate only that the 438 fax was received by the onramp, and no more. To do better than 439 this, it will be necessary to find ways of delivering the fax 440 message to (3) within the time constraints imposed by the T.30 441 protocol. 443 . DSN not implemented: with DSN not implemented at (2), the 444 sending fax machine receives an indication meaning only that the 445 message was accepted at (2) for onward delivery. 447 . MDN implemented: if (2) and (4) implement MDN then an MDN might 448 be generated when the message is received and displayed at (4). 449 But the user at (4) may choose to prohibit generation of MDN. 450 Also, the timing of any confirmation is subject to the same 451 considerations as the end-to-end DSN case described above. 453 Scenarios for Internet fax message confirmation 455 . MDN implemented at (2) and a receiving Internet Fax (IFAX) device 456 at (4): in this case, it might be possible to relax the 457 conditions regarding automatic generation of MDN, since the 458 security concerns about user privacy may not apply, to provide a 459 dependably confirmation of receipt. But timing considerations 460 still apply. 462 4.4 Summary of scenarios 464 The various scenarios touched in the preceding sections can be 465 summarized in four basic scanarios (not including onramp cases): 467 (1) (2) (3) 468 +------+ +----------+ +------------+ 469 |Sender|->-(SMTP)->-|Receive-MS|->-(collect)->-|Receive-USER| 470 +------+ +----------+ +------------+ 472 (A) This is the standard e-mail case where a receiving user 473 collects messages from a message store, using a mailbox protocol 474 such as POP or IMAP, or using some other local collection 475 mechanism. 477 (1) (2) (3) 478 +------+ +----------+ (auto- ) +------------+ 479 |Sender|->-(SMTP)->-|Receive-MS|->-(collect)->-|Receive-IFAX| 480 +------+ +----------+ +------------+ 482 (B) This is an IFAX-to-IFAX case, where the receiving IFAX device 483 collects from a message store using POP or IMAP. 485 In protocol terms this is identical to the case above, but differs 486 in its security implications because the collection of messages is 487 presumed to be done automatically (e.g. on a regular timed basis). 489 (1) (2) 490 +------+ +------------+ 491 |Sender|->-(SMTP)->-|Receive-IFAX| 492 +------+ +------------+ 494 (C) This is a simple IFAX-to-IFAX case using just SMTP. 496 (1) (2) (3) 497 +------+ +----------+ +-----------+ 498 |Sender|->-(SMTP)->-|Receive-GW|->-(GSTN,T.30)->-|Receive-FAX| 499 +------+ +----------+ +-----------+ 501 (D) This case has SMTP delivery to an offramp gateway which in turn 502 delivers to a receiving traditional facsimile machine via GSTN. 504 Scenarios for Internet fax message confirmation 506 Analysis of these cases suggests: 508 (A) needs DSN. 510 (B) needs automatically generated MDNs, or an enhanced DSN which 511 can trigger notifcation when a message is collected from the 512 store. 514 (C) can use DSN or automated MDN. 516 (D) can use DSN or automated MDN. 518 Analysis of these cases suggests a possible interpetation of DSN 519 which is very similar to the meaning of Group 3 facsimile 520 coinfirmation, which might be made appropriate to all cases: 522 A positive DSN response means that the message has 523 been delieved to a point from which it requires 524 action on the part of the recipient to collect. 526 4.5 Other mechanisms 528 This section introduces some additional options which might be used 529 to extend the various scenarios described above. 531 The combination of session mode and direct delivery might be used 532 to provide the closest possible approximation to traditional fax 533 confirmation that can b achieved using MTA-based mechanisms. 535 4.5.1 Direct delivery 537 If the sending MUA implements direct mail routing, following the 538 procedures described in RFC 974 [13], the problems of intervening 539 MTAs that do not implement required features may be avoided. 541 This approach may be subject to difficulties when trying to cross 542 corporate firewalls, etc. 544 [[QUESTION: can this approach guarantee direct delivery? I 545 understand that DNS MX records may be used to direct all mail to, 546 say, a corporate MTA for content analysis, etc., before it is 547 delivered to the receiving MTA.]] 549 Scenarios for Internet fax message confirmation 551 4.5.2 Session mode SMTP extension 553 An SMTP extension for immediate delivery is proposed in [12]. This 554 proposal operates at the MTA level (like DSN), and provides for 555 immediate delivery and confirmation of delivery within a single 556 SMTP protocol session between the sender MUA and first-hop MTA. 557 The immediate delivery and confirmation semantics may be maintained 558 through relay MTAs which support this extension. 560 If the timing constraints of T.30 can be satisfied by the 561 underlying transport mechanisms, this approach offers a possibility 562 for providing a T.30 confirmation which indicates receipt at the 563 receiving MTA. 565 In its present form the overall message transfer may be forced to 566 fall back to store-and-forward delivery if an intervening MTA 567 cannot complete a transfer in session mode, due to the way that 568 SMTP handles responsibility for message delivery. RFC 1047 [14] 569 contains a useful analysis of some of the issues involved. 571 4.5.3 Real-time fax image transfer 573 If a mechanism other than Internet e-mail is used to transfer fax 574 messages across the Internet, that mechanism can be defined with a 575 confirmation mechanism which mimics the T.30 mechanism. 577 The disadvantage of this approach is that interoperability with 578 Internet e-mail users may be sacrificed. 580 It is conceivable that SMTP and real-time fax transfer mechanisms 581 may be combined to provide mechanisms which provide 582 interoperability with Internet e-mail, but allow message 583 confirmation semantics to more closely match those of T.30. 585 It involves moving the fax gateway functions away from the 586 Internet/GSTN boundary. The simple onramp/offramp scenario is: 588 +---+ +------+ +------+ 589 |G3 |<--(A)-->|On/Off|<--(B)-->|e-mail| 590 |fax| | ramp | |system| 591 +---+ +------+ +------+ 592 || 593 <......GSTN.....>||<.....TCP/IP.......> 594 || 596 where protocol (A) is T.30 over GSTN, and protocol (B) is SMTP- 597 over-TCP/IP (and friends). 599 Scenarios for Internet fax message confirmation 601 If the Onramp/Offramp fax gateway functions are separated from the 602 GSTN-TCP/IP boundary, an extended version of this can be envisaged: 604 +---+ +---------+ +-------+ +------+ 605 |G3 |<--(A)-->|Transport|<--(C)-->| Fax |<--(B)-->|e-mail| 606 |fax| |converter| |gateway| |system| 607 +---+ +---------+ +-------+ +------+ 608 || 609 <......GSTN......>||<.....TCP/IP...........................> 610 || 612 In this case, protocol (C) is some form of real-time fax transfer 613 (e.g. tunnelling of T.30 in TCP/IP), and (A)and (B) are as before. 615 5. Security considerations 617 The following are primary security concerns for message 618 confirmation mechanisms: 620 . Unintentional disclosure of private information, including 621 possible information about a recipient's activity at the time of 622 receipt, caused by automated generation of confirmations. 624 . Disruption to system operation (e.g. message loss), or 625 inappropriate actions taken by the sender, caused by accidental 626 or malicious provision of incorrect message confirmations. 628 . In a mixed Internet/GSTN environment, meeting the costs of any 629 additional telephone calls that might be required to return a 630 message confirmation. 632 Some of the options for message confirmation that are discussed are 633 very much coloured by the concerns for user privacy. 635 Security considerations relevant to Internet fax are discussed 636 further in [1,3]. 638 Scenarios for Internet fax message confirmation 640 6. Copyright 642 Copyright (C) The Internet Society 1998. All Rights Reserved. 644 This document and translations of it may be copied and furnished to 645 others, and derivative works that comment on or otherwise explain 646 it or assist in its implementation may be prepared, copied, 647 published and distributed, in whole or in part, without restriction 648 of any kind, provided that the above copyright notice and this 649 paragraph are included on all such copies and derivative works. 650 However, this document itself may not be modified in any way, such 651 as by removing the copyright notice or references to the Internet 652 Society or other Internet organizations, except as needed for the 653 purpose of developing Internet standards in which case the 654 procedures for copyrights defined in the Internet Standards process 655 must be followed, or as required to translate it into languages 656 other than English. 658 The limited permissions granted above are perpetual and will not be 659 revoked by the Internet Society or its successors or assigns. 661 This document and the information contained herein is provided on 662 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 663 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 664 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 665 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 666 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 668 7. Acknowledgements 670 The ideas in this document came from a meeting with particular 671 contributions from James Rafferty, Larry Masinter, Dan Wing and 672 Dave Crocker. 674 The summary of scenarios section is from a presentation by Larry 675 Masinter. 677 Further ideas have been taken from postings to the IETF-FAX mailing 678 list, and various of the Internet drafts cited below. 680 Scenarios for Internet fax message confirmation 682 8. References 684 [1] "A Simple Mode of Facsimile Using Internet Mail" 685 K. Toyoda, 686 H. Ohno 687 J. Murai, WIDE Project 688 D. Wing, Cisco 689 RFC 2305 690 March 1998 692 [2] ITU Recommendation T.30: 693 "Procedures for document facsimile transmission in the General 694 Switched Telephone Network" 695 International Telecommunications Union, 1996 697 [3] "Terminology and Goals for Internet Fax" 698 Larry Masinter, Xerox Corporation 699 Internet draft: 700 Work in progress, March 1998 702 [4] "Extended Facsimile Using Internet Mail" 703 Larry Masinter, Xerox Corporation 704 Dan Wing, Cisco Systems 705 Internet draft: 706 Work in progress, March 1998 708 [5] "Extended MDN for IFAX full mode" 709 Mr Maeda, Canon Inc 710 Internet draft: 711 Work in progress, March 1998 713 [6] "Procedures for the Transfer of Facsimile Data via Internet Mail" 714 D. Crocker, Internet Mail Consortium 715 Internet draft: 716 Work in progress, October 1997 718 [7] RFC 821, "Simple Mail Transfer Protocol" 719 J. Postel, Information Sciences Institute, 720 University of Southern California 721 August 1982. 723 [8] RFC 822, "Standard for the format of ARPA Internet text messages" 724 D. Crocker, Department of Electrical Engineering, 725 University of Delaware 726 August 1982. 728 [9] RFC 1891, "SMTP service extension for delivery status 729 notification" 730 K. Moore, University of Tennessee 731 January 1996. 733 Scenarios for Internet fax message confirmation 735 [10] RFC 2298, "An Extensible Message Format for Message Disposition 736 Notifications" 737 R Fajman, National Institutes of Health 738 March 1998. 740 [11] RFC 1939: "Post Office Protocol - Version 3" 741 J. Myers, Carnegie Mellon 742 M. Rose, Dover Beach Consulting, Inc. 743 May 1996 745 [12] "SMTP Service Extension for Immediate Delivery" 746 Dan Wing, 747 Neil Joffe, Cisco Systems 748 Larry Masinter, Xerox Corporation 749 Internet draft: 750 Work in progress, February 1998 752 [13] RFC 974, "Mail Routing and the Domain System" 753 Craig Partridge, CSNET CIC BBN Laboratories Inc 754 January 1986. 756 [14] RFC 1047, "Duplicate Messages and SMTP" 757 Craig Partridge, CIC at BBN Laboratories 758 February 1988. 760 9. Author's address 762 Graham Klyne 763 Integralis Technology Ltd 764 Brewery Court 765 43-45 High Street 766 Theale 767 Reading, RG7 5AH 768 United Kingdom 770 Telephone: +44 118 930 6060 772 Facsimile: +44 118 930 2143 774 E-mail: GK@ACM.ORG