idnits 2.17.1 draft-ietf-fax-goals-02.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 1 longer page, the longest (page 1) being 839 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for draft-ietf-receipt-mdn- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MDN' Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Fax Working Group Larry Masinter 2 INTERNET-DRAFT Xerox Corporation 3 March 10, 1998 Expires in 6 months 4 draft-ietf-fax-goals-02.txt 6 Terminology and Goals for Internet Fax 8 Status of this memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 This document is being discussed in the IETF Fax working group. 27 Comments should be sent to ietf-fax@imc.org. The working group status 28 and web pages may be found at "http://www.imc.org/ietf-fax". 30 Table of contents: 31 1. Introduction 32 2. Definitions 33 2.1 User model of fax 34 2.2 Definition of Internet Fax 35 2.3 Internet Fax Service roles 36 2.4 Internet Fax Devices 37 2.5 Operational modes 38 3. Goals for Internet Fax 39 4. Operational Requirements for Internet Fax 40 4.1 Functionality 41 4.2 Interoperability 42 4.3 Confirmation 43 4.4 Quick Delivery 44 4.5 Capabilities 45 4.6 Simplicity 46 4.7 Security 47 4.8 Reliability 48 4.9 Fax-like use 49 4.10 Legal 50 5. Functional Requirements for Internet Fax 51 5.1 Requirements for image data representation 52 5.2 Requirements for transmission 53 5.3 Requirements for addressing 54 5.4 Requirements for security 55 5.5 Requirements for capability exchange 56 6. Security Considerations 57 7. Acknowledgements 58 8. Copyright 59 9. Author's address 60 10. References 62 1. Introduction 64 Facsimile (Fax) has a long tradition as a telephony application for 65 sending a document from one terminal device to another. 67 Many mechanisms for sending fax documents over the Internet have been 68 demonstrated and deployed and are currently in use. The general 69 application of using the Internet for facsimile is called "Internet 70 Fax". 72 This document defines a number of terms useful for the discussion of 73 Internet Fax. In addition, it describes the goals for Internet Fax and 74 establishes a baseline of desired functionality against which 75 protocols for Internet Fax can be judged. It encompasses the goals for 76 all modes of facsimile delivery, including "real-time", "session", and 77 "store and forward" (terms defined in Section 2 of this document). 79 [[EDITOR'S NOTE: It is intended that this document be modified 80 to use consistent terminology with the ITU-T document "F.IFax". 81 Such realignment has not been done in this version. ]] 83 Within this document, different levels of desirability for a protocol 84 for Internet Fax are indicated by different priorities, indicated in 85 {braces}: 87 {1} there is general agreement that this is a critical 88 characteristic of any definition of Internet Fax 89 {2} most believe that this is an important characteristic 90 of Internet Fax 91 {3} there is general belief that this is a useful feature 92 of Internet Fax, but that other factors might override. 94 2. Definitions and Operation Modes 96 This section defines some of the basic terms for Internet Fax. 98 2.1 User model of fax and basic operations 100 The phrase "traditional facsimile" or "G3Fax" is used to denote 101 implementations of [T.30]. Facsimile (fax) is a telephony application 102 for sending a document from one terminal device to another. 104 The telephone network is often referred to as the Public Switched 105 Telephone Network (PSTN) or Global Switched Telephone Network (GSTN). 107 Communication over the telephone network is accomplished using modems. 108 The transmission of data end-to-end is accompanied by negotiation (to 109 ensure that the scanned data can be rendered at the recipient) and 110 confirmation of delivery (to give the sender assurance that the final 111 data has been received and processed.) Over time, facsimile has been 112 extended to allow for PCs using fax modems to send and receive fax, to 113 send data other than scanned facsimile images. In addition, there have 114 been many extensions to the basic image model, to allow for additional 115 compression methods and for representation of images with grey-scale 116 and color. Other delivery extensions have included sub-addressing 117 (additional signals after the call is established to facilitate 118 automated routing of faxes to desktops or mailboxes), and enhanced 119 features such as fax-back and polling. 121 Typically, the terminal device consists of a paper input device 122 (scanner), a paper output device (printer), with (a limited amount of) 123 processing power. Traditional facsimile has a simple user operational 124 model; the user 126 1) inserts paper into a device 127 2) dials a number corresponding to the destination 128 3) presses the 'start' button on the device 129 4) the sending device connects to the receiving device 130 using the telephone network 131 5) the sending device scans the paper and transmits the image 132 of the paper 133 6) simultaneously, the remote device receives the transmission 134 and prints the image on paper 135 7) upon completion of transmission and successful processing 136 by the recipient, the sending user is notified of success 138 Although not usually visible to the user, the operation (5) of 139 transmission consists of 141 5a) negotiation: the capabilities of the sender and recipient 142 are exchanged, and suitable mutually acceptable parameters 143 for the communication are selected 144 5b) scanning: creating digitized images of pages of a document 145 5c) compression: the image data is encoded using a data compression 146 method 147 5d) transmission: the data is sent from one terminal to the other 149 In addition, the terminiation of operations (5d) and (6) may be 150 characterized as consisting of: 152 6a) completed delivery: the message has completed transmission 153 6b) completed receipt: the message has been accepted by the recipient 154 6c) processing and disposition: the message has been processed 156 >From a protocol perspective, the information conveyed in the 157 transmission consists of both "protocol" (control information, 158 capabilities, identification) and also "document content". 160 The document content consists primarily of the "document image" plus 161 additional metadata accompanying the image. The means by which an 162 image of a document is encoded within the fax content is the "image 163 data representation". 165 When the fax has been sucessfully transmitted, the sender receives a 166 "confirmation": an indication that the fax content was delivered, 167 received, and processed. This "confirmation" is an internal signal 168 and is not normally visible to the sending user, although some error 169 messages are visible, to allow a page to be retransmitted. 171 2.2 Definition of Internet Fax 173 The phrase "Internet Fax" is used to denote an application which 174 supports an approximation to the user model of fax (Section 2.1), but 175 where Internet protocols are used instead of the telephone network for 176 (some portion of) the transmission. The exact modes and operations of 177 traditional facsimile need not be duplicated exactly. 179 2.3 Internet Fax Application Roles 181 Internet Fax is a document transmission mechanism between various 182 different devices and services. However, those devices and services 183 might come in a wide variety of configurations. To allow for a wide 184 variety of configurations, it is useful to separate out these roles, 185 as they may be made available separately or in combination. These 186 roles are: 188 * Network scanner 189 A device that can scan a paper document and transmit the scanned 190 image via the Internet 192 * Network printer 193 A device that can accept an image transmission via the Internet 194 and print the received document automatically 196 * Fax onramp gateway 197 A device that can accept a facsimile telephone call and 198 automatically forward it via the Internet 200 * Fax offramp gateway 201 A device that can accept a transmission from the Internet and 202 forward it to a traditional fax terminal 204 In addition, other traditional Internet services might also 205 participate in Internet Fax, including Internet mail users, Web 206 browsers, Internet printing hosts. 208 2.4 Internet Fax Devices 210 The Internet Fax roles may be embedded in a variety of combinations 211 and configurations within devices and larger services. They may be 212 combined with other elements, e.g., a traditional T.30 fax 213 device. Many different configurations of services should {2} be able 214 to participate in Internet Fax; the specification should not 215 unnecessarily restrict the range of devices and services that can 216 participate. 218 The phrase "IFax device" is used to indicate a device which supports 219 any combination of the roles defined in 2.3, as embodied in a single 220 device which is engaged in Internet Fax service. 222 2.4.1 Gateway devices 224 A traditional fax terminal has a telephone line connection (PSTN) with 225 a fax modem used to connect over the telephone network. To connect a 226 fax terminal to the Internet requires a service which offers 227 connections on one side to the PSTN using standard fax signals, and on 228 the other side to the Internet. This role might be performed by a 229 _relay_ (e.g., transmitting T.30 signals over real-time controlled TCP 230 connections) or a _gateway_ (e.g., translating T.30 to TIFF/email). 232 With these services, the role of Internet Fax is to transport the fax 233 content across the Internet, e.g., with 235 [fax-term]-PSTNfax->[onramp]-Internet Fax->[recipient] 236 [sender]-Internet Fax->[offramp]-PSTNFax->[fax-term] 238 A onramp and/or offramp service may be local to a single fax terminal. 239 For example, the gateway service might exist within a small device 240 which has a telephone interface on one side and a network connection 241 on the other. To the fax machine, it looks like a telephone 242 connection, although it might shunt some or all connections to 243 Internet Fax instead (Such devices are called "Bump-in-cord.") 245 An onramp or offramp service may be a local facility serving many fax 246 terminals. For example, outgoing telephone fax calls through a company 247 telephone PBX could be rerouted through a local onramp. An internet to 248 telephone outbound connection could be part of a "LAN Fax" package. 250 Onramp or offramp services may serve a wider area or broader 251 collection of users, e.g., services run by service bureaus, offering 252 subscription services; the telephone sender or the recipient might 253 subscribe to the service. 255 The target of an offramp may be a "hunt group": a set of telephone 256 numbers, each of which have a possibly different fax terminal 257 attached. 259 2.4.2 New "IFax" terminals 261 Manufacturers of traditional facsimile devices may offer new devices 262 built out of similar components (scanner, processor, and printer), 263 which offer a similar functionality to a fax device, but which 264 connects to the Internet. These devices might also offer a traditional 265 fax modem capability, or might send documents exclusively through the 266 Internet. Such devices might have a permanent Internet connection 267 (through a LAN connection) or might have occasional connectivity 268 through a (data) modem to an Internet Service Provider. 270 2.4.3 Internet hosts 272 Internet users using Internet hosts with standard application suites 273 must {1} be able to exchange faxes with other participants in Internet 274 Fax, with minimum required enhancements to their operating 275 environment. 277 Interoperability with Internet mail users, either as Internet Fax 278 senders or recipients, is highly desirable {2}. 280 Internet users might receive faxes over the Internet and display them 281 on their screens, or have them automatically printed when received. 282 Similarly, the Internet Fax messages originating from the user might 283 be the output of a software application which would normally print, or 284 specially constructed fax-sending software, or may be input directly 285 from a scanner attached to the user's terminal. 287 The Internet Fax capability might be integrated into existing 288 fax/network fax software or email software, e.g., by the addition of 289 "Ifax Printer Drivers" that would render the document to the 290 appropriate content-type and cause it to be delivered using the 291 Internet Fax protocol. 293 In some cases, the user might have a multi-function peripheral which 294 integrated a scanner and printer and which gave operability similar to 295 that of the stand-alone fax terminal. 297 2.4.4 Internet messaging 299 In Internet mail, there are a number of components that operate in the 300 infrastructure to perform additional services beyond mail 301 store-and-forward. Interoperability with these components is a 302 consideration for the store and forward profile of Internet Fax. For 303 example, mailing list software accepts mail to a single address and 304 forwards it to a distribution list of many users. Mail archive 305 software creates repositories of searchable messages. Mail firewalls 306 operate at organizational boundaries and scan incoming messages for 307 malicious or harmful mail attachments. Vacation programs send return 308 messages to the senders of messages when the recipient is on vacation 309 and not available to respond. 311 2.4.5 Universal messaging 313 Many software vendors are now promoting software packages that support 314 "universal messaging": a combined communication package that combines 315 electronic mail, voice mail, and fax. 317 2.5 Operational Modes for Internet Fax 319 Facsimile over the Internet can occur in several modes. 321 "Store and forward" Internet Fax entails a process of storing the 322 entire document at a staging point, prior to transmitting it to the 323 next staging point. Store and forward can be directly between sender 324 and recipient or can have a series of intermediary staging points. 325 The intermediate storage may involve an intermediate agent or sequence 326 of agents in the communication. 328 "Session" Internet Fax is defined such that delivery notification is 329 provided to the transmitting terminal prior to disconnection. Unlike 330 "store and forward", there is an expection that direct communication, 331 negotiation, and retransmission can take place between the two 332 endpoints. 334 "Real-time" Internet Fax allows for two [T.30] standard facsimile 335 terminals to engage in a document transmission in a way that all of 336 the [T.30] communication protocol is preserved. 338 These modes are different in the end-user expectation of immediacy, 339 reliability, and in the ease of total compatibility with legacy or 340 traditional facsimile terminals; the modes differ in the requirements 341 on the operational infrastructure connecting sender and recipient. 343 3. Goals for Internet Fax 345 Facsimile over the Internet must define the mechanisms by which 346 a document is transmitted from a sender to a recipient, and must {1} 347 specify the following elements: 349 - Transmission protocol: what Internet protocol(s) and extensions are 350 used? What options are available in that transmission? 352 - Data formats: what image data representation(s) are used, 353 appropriate, required, within the transmission protocol? What other 354 data representations are supported? 356 - Addressing: How are Internet Fax recipients identified? How may 357 recipient identification be represented in user directories? How are 358 traditional fax terminals addressed? 360 - Capabilities: The capabilities of the sender to generate different 361 kinds of image data representations may be known to the recipient, 362 and the capabilities, preferences, and characteristics of the 363 recipient may be known to the sender. How are the capabilities, 364 preferences, and characteristics of senders and recipients 365 expressed, and communicated to each other? 367 - Security: Faxes may be authenticated as to their origin, or secured 368 to protect the privacy of the message. How may the authenticity of 369 a fax be determined by the recipient? How may the privacy of a 370 message be guaranteed? 372 Specific requirements for these elements are described in section 5. 374 4. Operational Requirements for Internet Fax 376 This section lists the required and desirable traits of an Internet 377 Fax protocol. 379 4.1 Functionality 381 Traditionally, images sent between fax machines are transmitted over 382 the global switched telephone network. An Internet Fax protocol must 383 {1} provide for a method to accomplish the most commonly used features 384 of traditional fax using only Internet protocols. It is desirable {3} 385 for Internet Fax to support all standard features and modes of 386 standard facsimile. 388 4.2 Interoperability 390 It is essential {1} that Internet Fax support interoperability between 391 most of the devices and services listed in section 2, and desirable 392 {3} to support all of them. To "support interoperability" means that a 393 compliant sender attempting to send to a compliant recipient will not 394 fail because of incompatibility. 396 Overall interoperability requires {1} interoperability for all of the 397 protocol elements: the image data representations must be understood, 398 the transport protocol must function, it must be possible to address 399 all manner of terminals, the security mechanism must not require 400 manual operations in devices that are intended for unattended 401 operation, and so forth. 403 Interoperability with Internet mail user agents is a requirement {1} 404 only for the "store-and-forward" facsimile, although it would be 405 useful {3} for "session" and "real-time" modes of delivery of Internet 406 Fax. 408 The requirement for interoperability has strong implications for the 409 protocol design. Interoperability must not {1} depend on having the 410 same kind of networking equipment at each end. 412 As with most Internet application protocols, interoperability must {1} 413 be independent of the nature of the networking link, whether a simple 414 IP-based LAN, an internal private IP networks, or the public 415 Internet. The standard for Internet Fax must {1} be global and have no 416 special features for local operations. 418 If Internet Fax is to use the Internet mail transport mechanisms, it 419 must {1} interoperate consistently with the current Internet mail 420 environment, and, in particular, with the non-terminal devices listed 421 in section 2.4.4. If Internet Fax messages might arrive in user's 422 mailboxes, it is required {1} that the protocol interoperate 423 successfully with common user practices for mail messages: storing 424 them in databases, retransmission, forwarding, creation of mail 425 digests, replay of old messages at times long after the original 426 receipt, and replying to messages using non-fax equipment. 428 It is desirable {3} that the Internet Fax standard support and 429 facilitate universal messaging systems described in section 2.4.5. 431 If Internet Fax requires additions to the operational environment 432 (services, firewall support, gateways, quality of service, protocol 433 extensions), then it is preferable {3} if those additions are useful for 434 other applications than Fax. Features shared with other messaging 435 applications (voice mail, short message service, paging, etc.) are 436 desirable {3}, so as not to require different operational changes for 437 other applications. 439 4.3 Confirmation 441 In almost all applications of traditional fax, it is considered very 442 important that the user can get an assurance that the transmitted data 443 was received by a terminal at the address dialed by the user. 445 In the Internet environment, this requirement is still very strong. 446 The 'Internet Fax' service must {1} define the mechanisms by which a 447 sender may request notification of the completion of transmission of 448 the message, and receive a determinate response as to whether the 449 message was delivered, not delivered, or that no confirmation of 450 delivery is possible. 452 Traditionally, fax 'confirmation' has indicated that the message was 453 'received', e.g., delivered to the output paper tray of the recipient 454 fax device. This is not the same as a confirmation that the message 455 was 'read': that a human had confirmed that the message was 456 received. Confirmation that the message was read (above and beyond the 457 notification that the message was delivered) may be desirable {3}, but 458 not required. 460 4.4 Quick Delivery 462 In many cases, fax transmission is used for delivery of documents 463 where there is a strong requirement for timeliness, with some 464 guarantees that if transmission begins at all, it will complete 465 quickly. For example, it is a common practice to fax documents for 466 discussion to other participants in a telephone conference call 467 prior to the call. 469 Internet Fax should {2} allow the sender of a document to request 470 immediate delivery, if such delivery is possible. In such cases, it 471 should {2} be possible for the sender of a message to avoid sending 472 the message at all, if quick delivery is not available for a 473 particular recipient. 475 It is desirable {3} if the protocol to request quick delivery is the 476 same as, or similar to, the protocol for delayed delivery, so that two 477 separate mechanisms are not required. 479 For real-time fax delivery, immediate delivery is the norm, since the 480 protocol must guarantee that when the session connecting sender to 481 recipient has terminated, the message has been delivered to the 482 ultimate recipient. 484 4.5 Capabilities: reliable, upgrade possible 486 Traditionally, facsimile has guaranteed interworking between senders 487 and recipients by having a strict method of negotiation of the 488 capabilities between the two devices. The image representation of 489 facsimile originally was a relatively low resolution, but has 490 increasingly offered additional capabilities (higher resolution, 491 color) as options. 493 The use of fax has grown in an evolving world (from 'Group 1' and 494 'Group 2', to 'Group 3' facsimile) because of two elements: (a) a 495 useful baseline of capabilities that all terminals implemented, and 496 (b) the use of capabilities exchange to go beyond that. 498 To accommodate current use as well as future growth, Internet Fax 499 should {2} have a simple minimum set of required features that will 500 guarantee interoperability, as well as a mechanism by which higher 501 capability devices can be deployed into a network of lower capability 502 devices while ensuring interoperability. If recipients with minimum 503 capabilities were, for example, to merely drop non-minimum messages 504 without warning, the result would be that no non-minimum message could 505 be sent reliably. This situation can be avoided in a variety of ways, 506 e.g., through communication of recipient capabilities or by sending 507 multiple renditions. 509 The exchange of capabilities in Internet Fax should {2} be robust. To 510 accomplish this, recipients should {2} be encouraged to provide 511 capabilities, even while senders must {1} have a way to send messages 512 to recipients whose capabilities are unknown. 514 Even minimum-capability recipients of messages should {2} be required 515 to provide a capability indication in some reliable way. This might be 516 accomplished by providing an entry in a directory service, by offering 517 automatic or semi-automatic replies, or by sending some indication of 518 in a reply to a message with multiple renditions, or as an addition to 519 a negative acknowledgement requiring retransmission. 521 On the other hand, for reliability, senders cannot rely on capability 522 information of recipients before transmission. That is, for 523 reliability, senders should {2} have an operational mode which can 524 function when capabilities are not present, even when recipients must 525 always provide capabilities. 527 4.6 Simplicity 529 Internet Fax should {1} not require terminals to possess a large 530 amount of processing power, and a base level implementation must {1} 531 interoperate, even if it does not offer complex processing. 533 Internet Fax should {2} allow interoperability with recipient devices 534 which have limited buffering capabilities and cannot buffer an entire 535 fax message prior to printing, or cannot buffer an entire set of fax 536 pages before beginning transmission of scanned pages. 538 Different operational modes (real-time, session, store and forward) 539 might use different protocols, in order to preserve the simplicity of 540 each. 542 It is preferable {3} to make as few restrictions and additions to 543 existing protocols as possible while satisfying the other 544 requirements. It is important {2} that it be possible to use Internet 545 Fax end-to-end in the current Internet environment without any changes 546 to the existing infrastucture, although some features may require 547 adoption of existing standards. 549 4.7 Security: Cause No Harm, Allow for privacy 551 The widespread introduction of Internet Fax must {1} not cause harm, 552 either to its users or to others. For example, an automatic mechanism 553 for returning notification of delivery or capabilities of fax 554 recipients by email must {1} not expose the users or others to mail 555 loops, bombs, or replicated delivery. Automatic capability exchange 556 based on email might not be sufficiently robust and, without 557 sufficient precautions, might expose users to denial of service 558 attacks, or merely the bad effects of errors on the part of system 559 administrators. Similar considerations apply in these areas to those 560 that have been addressed by work on electronic mail receipt 561 acknowledgements [MDN]. 563 Internet Fax should {2} not, by default, release information that the 564 users consider private, e.g., as might be forthcoming in response to a 565 broadcast requests for capabilities to a company's Internet fax 566 devices. Public recipients of Internet Fax (e.g., public agencies 567 which accept facsimile messages) should {2} not be required to 568 broadcast messages with capability statements to all potential senders 569 in order to receive facsimile messages appropriate for the 570 capabilities of their device. 572 The possibility for "causing harm" might be created by a combination 573 of facilities and other features which individually may be viewed as 574 harmless. Thus, the overall operation of a network full of Internet 575 Fax devices must {1} be considered. 577 Interoperation with ITU defined T.30 fax security methods, as well as 578 standard Internet e-mail security methods is desirable {3}. 580 4.8 Reliability 582 The Internet Fax protocol should {2} operate reliably over a variety 583 of configurations and situations. 585 In particular, operations which rely on time-delayed information might 586 result in inconsistent information, and the protocol should be robust 587 even in such situations. 589 For example, in a store-and-forward message environment, the 590 capabilities and preferences of a fax recipient might be used by the 591 sender to construct an appropriate message, e.g., sending a color fax 592 to a color device but a black and white fax to a device that does not 593 have color capability. However, the information about recipient 594 capabilities must be accessible to the sender even when the recipient 595 cannot be contacted directly. Thus, the sender must access recipient 596 capabilities in some kind of storage mechanism, e.g., a directory. A 597 directory of recipient capabilities is a kind of distributed database, 598 and would be subject to all of the well-known failure modes of 599 distributed databases. For example, update messages with capability 600 descriptions might be delivered out of order, from old archives, might 601 be lost, non-authenticated capability statements might be spoofed or 602 widely distributed by malicious senders. The Internet Fax protocol 603 should {2} be robust in these situations; messages should {2} not be 604 lost or misprocessed even when the sender's knowledge of recipient 605 capabilities are wrong, and robust mechanisms for delivery of 606 recipient capabilities should {2} be used. 608 4.9 User Experience 610 The primary user experience with fax is: 612 immediate delivery 613 delivery confirmation 614 ease of use 616 The primary user experience with email is: 618 delayed delivery 619 no delivery confirmation 620 ability to reply to sender 621 easy to send to multiple recipients 623 An Internet Fax standard should {2} attempt to reconcile the 624 differences between the two environments. 626 4.10 Legal 628 An Internet Fax standard should {2} accomodate the legal requirements 629 for facsimile, and attempt to support functionality similar to that 630 legally required even for devices that do not operate over the public 631 switched telephone network. 633 The United States Federal Communication Commission regulations 634 (applicable only within the USA) state: 636 "Identification Required on Fax Messages 638 The FCC's rules require that any message sent to a fax machine 639 must clearly mark on the first page or on each page of the message: 640 * the date and time the transmission is sent; 641 * the identity of the sender; and 642 * the telephone number of the sender or of the sending fax 643 machine. 644 All fax machines manufactured on or after December 20, 1992 and 645 all facsimile modem boards manufactured on or after December 13, 646 1995 must have the capability to clearly mark such identifying 647 information on the first page or on each page of the transmission." 649 5. Functional Requirements for Internet Fax 651 These requirements for specific elements of Internet Fax follow from 652 the operational goals described in section 4. 654 5.1 Requirements for image and other data representations 656 Interoperability with Internet Mail or other transmission mechanisms 657 that cause data files to appear in Internet terminal environments 658 requires {1} that Internet Fax use a format for images that is in wide 659 use. 661 Interoperability with Internet Mail requires {2} that Internet Fax 662 recipients handle those message types that are common in the email 663 environment, including a minimum set of MIME mail formats. 665 Interoperability with traditional fax terminals requires {1} that the 666 data format be capable of representing the commonly used compression 667 mechanisms defined for traditional facsimile; support for _all_ 668 standard formats defined for traditional facsimile is highly desirable 669 {2}. In addition, interoperability with 'private use' facsimile 670 messages suggests {3} that the standard accommodate arbitrary bit 671 sequences. 673 5.2 Requirements for transmission 675 It is necessary {1} that Internet Fax to work in the context of the 676 current Internet, Intranet, and the combination across firewalls. 678 A single protocol with various extensions is preferable {3} to 679 multiple separate protocols, if there are devices that might require, 680 at different times and for different recipients, different protocols. 682 5.3 Requirements for addressing 684 Interoperability with the terminal types in section 2 requires {1} the 685 ability to address each of the kinds of recipient devices. The 686 address of a recipient must give sufficient information to allow the 687 sender to initiate communication. 689 Interoperability with offramps to legacy fax terminals requires {1} 690 that the message contain some way of addressing the final destination 691 of facsimile messages, including telephone numbers, various ISDN 692 addressing modes, and facsimile sub-addresses. 694 Interoperability with Internet Mail requires {1} that it be possible 695 to address Internet Fax to any email address. Interworking with 696 Internet mail also requires {1} that the addressing is in the email 697 addressing headers, including mail transport envelope [RFC1123] and 698 RFC822 headers, as appropriate. The information must {1} appear 699 nowhere else. 701 Sending devices might not have local storage for directories of 702 addresses, and addresses might be cumbersome for users to type in. For 703 these reasons, Internet Fax devices may require configuration to 704 locate directories of recipients and their capabilities. 706 The source of a fax message must {1} be clearly identified. The 707 address of the appropriate return message (whether via fax or via 708 email) should {2} be clearly identified in a way that is visible to 709 all manner of recipients. In the case of Internet Fax delivered by 710 email, it should {2} be possible to use the normal 'reply' functions 711 for email to return a message to the sender. 713 Traditionally, it is common for the first page of a fax message sent 714 to a facsimile terminal to contain an (image) representation of the 715 name, address, return number, etc. of the sender of the document. 716 Some legal jurisdictions for facsimile require an identification of 717 the sender on every page. The standard for Internet Fax should {2} 718 cover the issues of sender and recipient identification in the cases 719 where fax messages are re-routed, forwarded, sent through gateways. 721 5.4 Requirements for Security 723 In order to give Internet Fax users the same assurance of privacy and 724 integrity that is common with telephone-based fax, the Internet Fax 725 standard must specify how secure messages can be sent, in an 726 interoperable fashion. The Internet Fax protocol should {2} encourage 727 the introduction of security features, e.g., by requiring that minimum 728 capability devices still accept signed messages (even if ignoring the 729 signature.) 731 In the case where the sender is responsible for payment for offramp 732 services in a remote location, it is desirable {3} to provide for 733 authentication of the sender and billing information from the offramp 734 to be negotiated securely. 736 5.5 Requirements for capabilities exchange 738 Traditional fax supports a wide range of devices, including high 739 resolution ("Superfine"); recent enhancements include methods for 740 color. Fax messaging includes the capability for "non-standard frames", 741 which allow vendors to introduce proprietary data formats. In addition, 742 facsimile supports "binary file transfer": a method of sending 743 arbitrary binary data in a fax message. 745 To support interoperability with these mechanisms, it should {2} be 746 possible to express a wide variety of fax capabilities. 748 Capability support has three elements: expression of the capabilities 749 of the sender (as far as a particular message is concerned), 750 expressing the capabilities of a recipient (in advance of the 751 transmission of the message), and then the protocol by which 752 capabilities are exchanged. 754 The Internet Fax standard should {2} specify a uniform mechanism for 755 capabilities expression. If capabilities are being sent at times other 756 than the time of message transmission, then capabilities should {2} 757 include sufficient information to allow it to be validated, 758 authenticated, etc. 760 The Internet Fax standard may {3} include one or several methods for 761 transmission, storage, or distribution of capabilities. 763 A request for capability information, if sent to a recipient at any 764 time other than the immediate time of delivery of the message, should {2} 765 clearly identify the sender, the recipient whose capabilities 766 are being requested, and the time of the request. Som kind of 767 signature would be useful, too. 769 A capability assertion (sent from recipient to sender) should {2} 770 clearly identify the recipient and some indication of the date/time or 771 range of validity of the information inside. To be secure, capability 772 assertions should {2} be protected against interception and the 773 substitution of valid data by invalid data. 775 6. Security Considerations 777 This document lays out several security considerations for Internet 778 Fax. 780 7. Acknowledgements 782 The author gratefully acknowledges the contributions of Graham Klyne, 783 Vivian Cancio, Dan Wing, Jim Dahmen, Neil Joffe, Mike Lake, Lloyd 784 McIntyre, Richard Shockey, Herman Silbiger, Nadesan Narenthiran, 785 George Pajari and Dave Crocker for their valuable comments on this 786 document. 788 8. Copyright 790 Copyright (C) The Internet Society, 1997. All Rights Reserved. 792 This document and translations of it may be copied and furnished to 793 others, and derivative works that comment on or otherwise explain it 794 or assist in its implementation may be prepared, copied, published and 795 distributed, in whole or in part, without restriction of any kind, 796 provided that the above copyright notice and this paragraph are 797 included on all such copies and derivative works. However, this 798 document itself may not be modified in any way, such as by removing 799 the copyright notice or references to the Internet Society or other 800 Internet organizations, except as needed for the purpose of developing 801 Internet standards in which case the procedures for copyrights defined 802 in the Internet Standards process must be followed, or as required to 803 translate it into languages other than English. 805 The limited permissions granted above are perpetual and will not be 806 revoked by the Internet Society or its successors or assigns. 808 This document and the information contained herein is provided on an 809 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 810 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 811 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 812 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 813 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 815 9. Author's address 817 Larry Masinter 818 Xerox Corporation 819 3333 Coyote Hill Road 820 Palo Alto, CA 94304 821 masinter@parc.xerox.com 822 http://www.parc.xerox.com/masinter 823 Fax: (650) 812-4333 825 10. References 827 [T.30] ITU-T (CCITT), "Procedures for Document Facsimile Transmission 828 in the General Switched Telephone Network", ITU-T (CCITT), 829 Recommendation T.30, July, 1996. 831 [MDN] R. Fajman, "An Extensible Message Format for Message Disposition 832 Notifications", Internet Draft, draft-ietf-receipt-mdn-??.txt. 834 [RFC1123] R. Braden, "Requirements for Internet hosts - application 835 and support", RFC 1123, October 1989. 837 [F.IFax]