idnits 2.17.1 draft-ietf-fax-goals-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 1 longer page, the longest (page 1) being 780 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 5 characters in excess of 72. ** There are 12 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- 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) == Missing Reference: 'MDN' is mentioned on line 518, but not defined Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 3 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 December 12, 1997 Expires in 6 months 4 draft-ietf-fax-goals-00.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 Table of contents: 27 1. Introduction 28 2. Definitions 29 2.1 User model of fax 30 2.2 Definition of Internet Fax 31 2.3 Internet Fax Service roles 32 2.4 Internet Fax Devices 33 2.5 Operational modes 34 3. Goals for Internet Fax 35 4. Operational Requirements for Internet Fax 36 4.1 Functionality 37 4.2 Interoperability 38 4.3 Confirmation 39 4.4 Quick Delivery 40 4.5 Capabilities 41 4.6 Simplicity 42 4.7 Security 43 4.8 Reliability 44 4.9 Fax-like use 45 4.10 Legal 46 5. Functional Requirements for Internet Fax 47 5.1 Requirements for image data representation 48 5.2 Requirements for transmission 49 5.3 Requirements for addressing 50 5.4 Requirements for security 51 5.5 Requirements for capability exchange 52 6. Security Considerations 53 7. Acknowledgements 54 8. Copyright 55 9. Author's address 56 10. References 58 [[notes: there are still several terms that need clearer definitions, 59 e.g., "image" and "data" and "format", since these are used differently 60 in ITU and Internet contexts.]] 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, where the 66 terminal device consists of a paper input device (scanner), a paper 67 output device (printer), with (a limited amount of) processing power. 68 Communication over the telephone network is accomplished using modems. 69 The transmission of data end-to-end is accompanied by negotiation (to 70 ensure that the scanned data can be rendered at the recipient) and 71 confirmation of delivery (to give the sender assurance that the final 72 data has been received and processed.) Over time, facsimile has been 73 extended to allow for PCs using fax modems to send and receive fax, to 74 send data other than scanned facsimile images. In addition, there have 75 been many extensions to the basic image model, to allow for additional 76 compression methods and for representation of images with grey-scale 77 and color. Other delivery extensions have included sub-addressing 78 (additional signals after the call is established to facilitate 79 automated routing of faxes to desktops or mailboxes), and enhanced 80 features such as fax-back, polling, and even the transfer of binary 81 files. 83 Many mechanisms for sending fax documents over the Internet have been 84 demonstrated and deployed and are currently in use. The general 85 application of using the Internet for the application of facsimile is 86 Internet Fax. 88 This document defines a number of terms useful for the discussion of 89 Internet Fax, as discussed in the IETF Internet Fax working group. In 90 addition, it summarizes the goals for Internet Fax, and establishes a 91 baseline of desired functionality against which any proposal for 92 Internet Fax can be judged. It encompasses the goals for _all_ modes 93 of facsimile delivery, including 'real-time', 'session', and 'store 94 and forward' (terms defined in Section 2 of this document). 96 To establish different levels of desirability, language similar to 97 that in [RFC2119] is used, although the language is intended to apply 98 to the protocol specification itself rather than conformance of a 99 particular implementation. The phrases "REQUIRED", "MUST", "SHOULD", 100 "MAY" and "DESIRABLE" are used to indicate different (decreasing) 101 levels of desirability of attributes of an Internet Fax specification; 102 for example, the terms "MUST" and "REQUIRED" are for those 103 characteristics which are universally acceptable; the term "SHOULD" is 104 used to indicate a characteristic considered essential by most of the 105 working group, while the terms "MAY" and "DESIRABLE" indicate an 106 attribute which is deemed desirable by most, but for which other 107 factors might override. 109 2. Definitions and Operation Modes 111 This section defines some of the basic terms for Internet Fax. 113 2.1 User model of fax and basic operations 115 Facsimile involves sending a document from one system to another. 116 Traditional facsimile has a simple user operational model; the user 118 1) inserts paper into a device 119 2) dials a number corresponding to the destination 120 3) presses the 'start' button on the device 121 4) the sending device connects to the receiving device 122 using the telephone network 123 5) the sending device scans the paper and transmits the 124 image of the paper 125 6) simultaneously, the remote device prints the image on paper 126 7) upon completion of transmission and successful processing 127 by the recipient, the sending user is notified of success 129 The technical operation of facsimile has several components, then: the 130 "sending terminal" ("sender") and the "receiving terminal" 131 ("recipient"). 133 Although not usually visible to the user, the operation (5) of 134 transmission consists of 136 5a) negotiation: the capabilities of the sender and recipient 137 are exchanged, and suitable mutually acceptable parameters 138 for the communication are selected 139 5b) scanning: creating digitized images of pages of a document 140 5c) compression: the image data is encoded using a data compression method 141 5d) transmission: the data is sent from one terminal to the other 143 >From a protocol perspective, the information conveyed in the 144 transmission consists of both "protocol" (control information, 145 capabilities, identification) and also "document content". 147 The document content consists primarily of the "document image" plus 148 additional metadata accompanying the image. The means by which an 149 image of a document is encoded within the fax content is the "image 150 data representation". 152 When the fax has been sucessfully transmitted, the sender receives a 153 "confirmation": an indication that the fax content was delivered, 154 received, and processed. This "confirmation" is an internal signal 155 and is not normally visible to the sending user, although some error 156 messages are visible, to allow a page to be retransmitted. 158 2.2 Definition of Internet Fax 160 "Internet Fax" is the service of providing a related (but not exactly 161 duplicated) user model, but where the Internet is used instead of the 162 telephone network (at least for some part of the transmission.) 164 2.3 Internet Fax Service Roles 166 Internet Fax can be thought of as involving communication among 167 possible service roles. These roles include standard Internet hosts 168 (PC, workstation, etc.), but also new kinds of service elements: 170 * Network scanner 171 A device that can scan a paper document and transmit the scanned 172 image via the Internet 174 * Network printer 175 A device that can accept an image transmission via the Internet 176 and print the received document automatically 178 * Fax onramp gateway 179 A device that can accept a facsimile telephone call and 180 automatically forward it via the Internet 182 * Fax offramp gateway 183 A device that can accept a transmission from the Internet and 184 forward it to a traditional fax terminal 186 2.4 Internet Fax Devices 188 The Internet Fax service roles can be embedded in any a variety 189 of combinations and configurations within devices and larger services. 190 Many different kinds of devices and services SHOULD be able to 191 participate in the transmission of Internet Fax. 193 The phrase "IFax device" is used to indicate any combination of these 194 roles embodied in a single device which is engaged in Internet Fax 195 service. 197 2.4.1 Gateway devices 199 A traditional fax terminal has a telephone line connection (PSTN) with 200 a fax modem used to connect over the telephone network. To connect a 201 fax terminal to the Internet requires a _gateway_: a service which 202 offers connections on one side to the PSTN using standard fax signals, 203 and on the other side to the Internet. 205 The same device MAY function as an onramp and offramp. With these 206 services, the role of Internet Fax is to transport the fax content 207 across the Internet, e.g., with 209 [fax-term]-PSTNfax->[onramp]-Internet Fax->[recipient] 210 [sender]-Internet Fax->[offramp]-PSTNFax->[fax-term] 212 A onramp and/or offramp service MAY be local to a single fax terminal. 213 For example, the gateway service might exist within a small device 214 which has a telephone interface on one side and a network connection 215 on the other. To the fax machine, it looks like a telephone 216 connection, although it MAY shunt some or all connections to Internet 217 Fax instead (Such devices are called "Bump-in-cord.") 219 An onramp or offramp service MAY be a local facility serving many fax 220 terminals. For example, outgoing telephone fax calls through a company 221 telephone PBX could be rerouted through a local onramp. An internet to 222 telephone outbound connection could be part of a "LAN Fax" package. 224 Onramp or offramp services MAY serve a wider area or broader 225 collection of users, e.g., services run by service bureaus, offering 226 subscription services; the telephone sender or the recipient might 227 subscribe to the service. 229 The target of an offramp may be a "hunt group": a set of telephone 230 numbers, each of which have a possibly different fax terminal 231 attached. 233 2.4.2 New "IFax" terminals 235 Manufacturers of traditional facsimile devices may offer new devices 236 built out of similar components (scanner, processor, and printer), 237 which offer a similar functionality to a fax device, but which 238 connects to the Internet. These devices might also offer a traditional 239 fax modem capability, or might send documents exclusively through the 240 Internet. Such devices might have a permanent Internet connection 241 (through a LAN connection) or might have occasional connectivity 242 through a (data) modem to an Internet Service Provider via PPP. 244 2.4.3 Internet hosts 246 Internet users using Internet hosts with standard application suites 247 should be able to exchange faxes with other participants in Internet 248 Fax, with a minimum required enhancements to their operating 249 environment. 251 Internet users might receive faxes over the Internet and display them 252 on their screens, or have them automatically printed when received. 253 Similarly, the Internet Fax messages originating from the user might 254 be the output of a software application which would normally print, or 255 specially constructed fax-sending software, or MAY be input directly 256 from a scanner attached to the user's terminal. 258 The Internet Fax capability might be integrated into existing 259 fax/network fax software or email software, e.g., by the addition of 260 "Ifax Printer Drivers" that would render the document to the 261 appropriate content-type and cause it to be delivered using the 262 Internet Fax protocol. 264 In some cases, the user might have a multi-function peripheral which 265 integrated scanner and printer, and which gave operability similar to 266 that of the stand-alone fax terminal. 268 2.4.4 Universal messaging and Internet messaging 270 Many software vendors are now promoting software packages that support 271 "universal messaging": a combined communication package that combines 272 electronic mail, voice mail, and fax. Interoperability with these 273 environments is desirable for Internet Fax. 275 In Internet mail, there are a number of components that operate in the 276 infrastructure to perform additional services beyond mail 277 store-and-forward. Interoperability with these components is a 278 consideration for the store and forward profile of Internet Fax. For 279 example, mailing list software accepts mail to a single address and 280 forwards it to a distribution list of many users. Mail archive 281 software creates repositories of searchable messages. Mail firewalls 282 operate at organizational boundaries and scan incoming messages for 283 malicious or harmful mail attachments. Vacation programs send return 284 messages to the senders of messages when the recipient is on vacation 285 and not available to respond. 287 2.5 Operational Modes for Internet Fax 289 Facsimile over the Internet can occur in several modes. 291 "Store and forward" Internet Fax is defined as the kind of operation 292 where an intermediate agent or sequence of agents are involved in the 293 communication: the sender connects to an agent, and engages in a 294 communication to send the to the agent. The agent then 295 subsequently contacts the destination (or attempts to, until the 296 destination is available), and delivers the message. 298 "Session" Internet Fax is defined such that delivery notification is 299 provided to the transmitting terminal prior to disconnection. Unlike 300 "store and forward", there is some expection that direct 301 communication, negotiation, and retransmission can take place between 302 the two endpoints. 304 "Real-time" Internet Fax allows for two (ITU-T based) standard 305 facsimile terminals to engage in a document transmission in a way that 306 all (or as much as practical) of the ITU-T communication protocol is 307 preserved. 309 These modes are different in the end-user expectation of immediacy, 310 reliability, and in the ease of total compatibility with legacy or 311 traditional facsimile terminals; the modes differ in the requirements 312 on the operational infrastructure connecting sender and recipient. 314 3. Goals for Internet Fax 316 Facsimile over the Internet must consist of using Internet protocol(s) 317 to transmit the document from a sender to a recipient. The recipient 318 SHOULD be identified by an address. The capabilities of the sender to 319 generate different kinds of image data representations MAY be known to 320 the recipient, and the capabilities, preferences, and characteristics 321 of the recipient MAY be known to the sender. Faxes MAY be 322 authenticated as to their origin, or secured to protect the privacy of 323 the message. In general, an Internet Fax protocol SHOULD specify 324 functional elements for the following; specific requirements for these 325 elements are described in section 5: 327 Data formats: what image data representation(s) are used, appropriate, 328 required? What other data representations must be supported? 329 Transmission protocol: what Internet protocol(s) and extensions are used 330 to transmit the fax content? What options are available in that 331 transmission? 332 Addressing: How are Internet Fax recipients identified? How is that 333 identification represented in user directories? How are traditional 334 fax terminals addressed? 335 Security: How may the authenticity of a fax be determined by 336 the recipient? How may the privacy of a message be guaranteed? 337 Capabilities: How are the capabilities, preferences, and 338 characteristics of senders and recipients expressed, and 339 communicated to each other? 341 4. Operational Requirements for Internet Fax 343 This section lists the required and desirable traits of an Internet 344 Fax protocol. The basic operational requirements are based on the 345 requirements originally identified in [F.Ifax]. 347 4.1 Functionality 349 Traditionally, images sent between fax machines are transmitted over 350 the global switched telephone network. An Internet Fax protocol should 351 provide for a method to accomplish the features of traditional fax, 352 but using Internet protocols. 354 4.2 Interoperability 356 It is desirable that a standard for Internet Fax allow for the 357 interoperability between all of the several devices and services 358 listed in section 2. This means that any and all of the devices or 359 systems might send a document, using the protocol specified, to any of 360 the other kinds of devices or systems, and expect the document to 361 arrive and be processed successfully, with high reliability. Overall 362 interoperability requires interoperability for all of the protocol 363 elements: the image data representations must be understood, the 364 transport protocol must function, it must be possible to address all 365 manner of terminals, the security mechanism must not require manual 366 operations in devices that are intended for unattended operation, etc. 368 Interoperability with Internet mail agents is a consideration only for 369 store and forward facsimile, since such agents would not be applicable 370 to the real-time delivery of Internet Fax. 372 The requirement for interoperability has strong implications for the 373 protocol design. Interoperability doesn't depend on having the same 374 kind of networking equipment at each end, or on the kind of 375 intervening Internet Protocol network: interoperability SHOULD be 376 independent of the nature of the networking link, whether a simple 377 IP-based LAN, an internal private IP networks, or the public 378 Internet. The standard for Internet Fax must be global and have no 379 special features for local operations. (This is normally the case with 380 Internet protocol standards.) 382 If Internet Fax is to use the Internet mail transport mechanisms, it 383 is REQUIRED that it interoperate consistently with the current 384 Internet mail environment, and, in particular, with the non-terminal 385 devices listed in section 3d. If Internet Fax messages might arrive 386 in user's mailboxes, it is REQUIRED that the protocol interoperate 387 successfully with common user practices for mail messages: storing 388 them in databases, retransmission, forwarding, creation of mail 389 digests, replay of old messages at times long after the original 390 receipt, and replying to messages using non-fax equipment. 392 If Internet Fax requires additions to the operational environment 393 (services, firewall support, gateways, quality of service, protocol 394 extensions), then it is preferable if those additions are useful for 395 other applications than Fax. Features shared with other messaging 396 applications (voice mail, short message service, paging, etc.) are 397 DESIRABLE, so as not to require different operational changes for 398 other applications. 400 Many vendors are attempting to build a system of 'universal 401 messaging', in which a user's email, voice mail, facsimile, and other 402 communication mechanisms are integrated, from the user interface point 403 of view, into a single application suite. It is DESIRABLE for the 404 Internet Fax standard to support such applications. 406 4.3 Confirmation 408 Traditional fax applications are often used for important business 409 correspondence, where it is important to get assurance that the 410 transmitted data was actually received by a terminal at the address 411 dialed by the user. 413 In Internet Fax, it SHOULD be possible for a sender to request 414 notification of the completion of transmission of the message, and to 415 receive a determinate response as to whether the message was 416 delivered, not delivered, or that no confirmation of receipt is 417 possible. 419 Traditionally, fax 'confirmation' has indicated that the message was 420 'received', e.g., delivered to the output paper tray of the recipient 421 fax device. This is not the same as a confirmation that the message 422 was 'read': that a human had confirmed that the message was 423 received. Confirmation that the message was read (above and beyond the 424 notification that the message was delivered) is NOT REQUIRED. 426 4.4 Quick Delivery 428 In many (if not most) cases, fax transmission is used for urgent 429 delivery of documents, with some guarantees that if transmission 430 begins at all, it will complete quickly. Email doesn't normally have 431 this characteristic. 433 Internet Fax SHOULD allow the sender of a document to request 434 immediate delivery, if such delivery is possible. 436 It is convenient if the protocol to request quick delivery is the same 437 as, or similar to, the protocol for delayed delivery, so that two 438 separate mechanisms are NOT REQUIRED. 440 It SHOULD be possible for the sender of a message to avoid sending the 441 message at all if quick delivery is not available. 443 For real-time fax delivery, immediate delivery is the norm, since the 444 protocol must guarantee that when the session connecting sender to 445 recipient has terminated, the message has been delivered to the 446 ultimate recipient. 448 4.5 Capabilities: reliable, upgrade possible 450 Traditionally, facsimile has guaranteed interworking between senders 451 and recipients by having a strict method of negotiation of the 452 capabilities between the two devices. The image representation of 453 facsimile originally was a relatively low resolution, but has 454 increasingly offered additional capabilities (higher resolution, 455 color) as options. 457 The use of fax has grown in an evolving world (from 'Group 1' and 458 'Group 2', to 'Group 3' facsimile) because of two elements: (a) a 459 useful baseline of capabilities that all terminals implemented, and 460 (b) the use of capabilities exchange to go beyond that. 462 To accommodate current use as well as future growth, Internet Fax 463 SHOULD have a simple minimum set of required features that will 464 guarantee interoperability, as well as a mechanism by which higher 465 capability devices can be deployed into a network of lower capability 466 devices while ensuring interoperability. If recipients with minimum 467 capabilities were, for example, to merely drop non-minimum messages 468 without warning, the result would be that no non-minimum message could 469 be sent reliably. This situation can be avoided in a variety of ways, 470 e.g., through communication of recipient capabilities or by sending 471 multiple renditions. Even minimum-capability recipients of messages 472 SHOULD be required to provide a capability indication in some reliable 473 way, e.g., through a directory entry, determine the capabilities of 474 the recipient with reasonable reliability in advance of transmission, 475 in a reply to a message with multiple renditions, or as an addition to 476 a negative acknowledgement requiring retransmission. 478 On the other hand, for reliability, senders cannot rely on capability 479 information of recipients before transmission. That is, for 480 reliability, senders SHOULD have an operational mode which can 481 function when capabilities are not present, even when recipients must 482 always provide capabilities. 484 4.6 Simplicity 486 Internet Fax SHOULD NOT require terminals to possess a large amount of 487 processing power, and a base level implementation SHOULD interoperate, 488 even if it does not offer complex processing. 490 Internet Fax SHOULD allow interoperability with fax terminal devices 491 which have limited buffering capabilities and cannot buffer an entire 492 fax message prior to printing, or cannot buffer an entire set of fax 493 pages before beginning transmission of scanned pages. 495 It is possible that different operational modes (real-time, session, 496 store and forward) might use different protocols, in order to preserve 497 the simplicity of each. 499 It is preferable to make as few restrictions and additions to existing 500 protocols as possible while satisfying the other requirements. It is 501 important that it be possible to use Internet Fax end-to-end in the 502 current Internet environment without any changes to the existing 503 infrastucture, although some features MAY require adoption of existing 504 standards. 506 4.7 Security: Cause No Harm, Allow for privacy 508 The widespread introduction of Internet Fax must not cause harm, 509 either to its users or to others. It is important, for example, that 510 no automatic mechanism for returning notification of delivery or 511 capabilities of fax recipients by email SHOULD expose the users or 512 others to mail loops, bombs, or replicated delivery. Automatic 513 capability exchange based on email might not be sufficiently robust 514 and, without sufficient precautions, might expose users to denial of 515 service attacks, or merely the bad effects of errors on the part of 516 system administrators. Similar considerations apply in these areas to 517 those that have been addressed by work on electronic mail receipt 518 acknowledgements [MDN]. 520 Internet Fax SHOULD NOT, by default, release information that the 521 users consider private, e.g., as might be forthcoming in response to a 522 broadcast requests for capabilities to a company's Internet fax 523 devices. Public recipients of Internet Fax (e.g., public agencies 524 which accept facsimile messages) SHOULD NOT be required to broadcast 525 messages with capability statements to all potential senders in order 526 to receive facsimile messages appropriate for the capabilities of 527 their device. 529 The possibility for "causing harm" might be created by a combination 530 of facilities and other features which individually may be viewed as 531 harmless. Thus, the overall operation of a network full of Internet 532 Fax devices MUST be considered. 534 Interoperation with ITU defined T.30 fax security methods, as well as 535 standard Internet e-mail security methods is DESIRABLE. 537 4.8 Reliability: Avoid inconsistent operations 539 Insofar as there is information about the capabilities of recipients 540 in a store-and-forward message environment, the capabilities and 541 preferences of the recipient must be known by the sender prior to the 542 construction and transmission of the message. Because this information 543 must be accessible by the sender even when the recipient cannot be 544 contacted directly, the sender must access capabilities in some kind 545 of storage mechanism. Most commonly these stored capabilities will be 546 in a directory of some kind. This directory of capabilities is, in 547 fact, a distributed database, and is subject to all of the well-known 548 failure modes of distributed databases. For example, update messages 549 with capability descriptions might be delivered out of order, from old 550 archives, might be lost, non-authenticated capability statements might 551 be spoofed or widely distributed by malicious senders. 553 Unfortunately, the mechanisms by which a distributed database of 554 directory information can be maintained and updated reliably are not 555 yet widely deployed in the Internet environment. Establishing a robust 556 protocol for capability information with asynchronous information 557 requires considerable care. 559 4.9 User Experience 561 The primary user experience with fax is: 563 immediate delivery 564 delivery confirmation 565 ease of use 567 The primary user experience with email is: 569 delayed delivery 570 no delivery confirmation 571 ability to reply to sender 572 easy to send to multiple recipients 574 An Internet Fax standard SHOULD attempt to reconcile the differences 575 between the two environments. 577 4.10 Legal 579 An Internet Fax standard SHOULD accomodate the legal requirements for 580 facsimile, and attempt to support functionality similar to that 581 legally required even for devices that do not operate over the public 582 switched telephone network. 584 The United States Federal Communication Commission regulations 585 (applicable only within the USA) state: 587 "Identification Required on Fax Messages 589 The FCC's rules require that any message sent to a fax machine 590 must clearly mark on the first page or on each page of the message: 591 * the date and time the transmission is sent; 592 * the identity of the sender; and 593 * the telephone number of the sender or of the sending fax 594 machine. 595 All fax machines manufactured on or after December 20, 1992 and 596 all facsimile modem boards manufactured on or after December 13, 597 1995 must have the capability to clearly mark such identifying 598 information on the first page or on each page of the transmission." 600 5. Functional Requirements for Internet Fax 602 These requirements for specific elements of Internet Fax follow 603 from the operational requirements described in section 4. 605 5.1 Requirements for image and other data representations 607 Interoperability with Internet Mail or other transmission mechanisms 608 that cause data files to appear in Internet terminal environments 609 implies that Internet Fax should use a format for images that is in 610 wide use. 612 Interoperability with Internet Mail would require that Internet Fax 613 recipients handle those message types that are common in the email 614 environment, including a minimum set of MIME mail formats. 616 Interoperability with traditional fax terminals requires that the data 617 format be capable of representing all of the standard compression and 618 image representations that are defined for traditional facsimile. In 619 addition, interoperability with 'private use' facsimile messages 620 requires that the standard accommodate arbitrary bit sequences. 622 5.2 Requirements for transmission 624 It is useful for Internet Fax to work in the context of the current 625 Internet, Intranet, and the combination across firewalls. 627 A single protocol with various extensions is simpler than multiple 628 separate protocols, if there are devices that might require, at 629 different times and for different recipients, different protocols. 631 5.3 Requirements for addressing 633 Complete interoperability between all of the terminal types in section 634 2 requires that all of the different kinds of terminals can be 635 addressed. The address of a recipient must give sufficient information 636 to allow the sender to initiate communication. 638 Interoperability with offramps to legacy fax terminals requires that 639 the message contain some way of addressing the final destination of 640 facsimile messages, including telephone numbers, various ISDN 641 addressing modes, and facsimile sub-addresses. 643 Interoperability with Internet Mail would require that it be possible 644 to address Internet Fax to any email address. For interworking with 645 the rest of the mail transportation network (section 3d), addressing 646 SHOULD be handled in the envelope of the email layer rather than in 647 the headers or body, so that normal mail processing methods can be 648 used for Internet Fax. 650 Sending devices might not have local storage for directories of 651 addresses, and addresses might be cumbersome for users to type 652 in. Internet Fax devices might require configuration to locate 653 directories of recipients and their capabilities. 655 The source of a fax message SHOULD be clearly identified. The address 656 of the appropriate return message (whether via fax or via email) 657 SHOULD be clearly identified in a way that is visible to all manner of 658 recipients. In the case of Internet Fax delivered by email, it SHOULD 659 be possible to use the normal 'reply' functions for email to return a 660 message to the sender. 662 Traditionally, it is common for the first page of a fax message sent 663 to a facsimile terminal to contain an (image) representation of the 664 name, address, return number, etc. of the sender of the document. 665 Some legal jurisdictions for facsimile require an identification of the 666 sender on every page. The standard for Internet Fax SHOULD cover the 667 issues of sender and recipient identification in the cases where fax 668 messages are re-routed, forwarded, sent through gateways. 670 5.4 Requirements for Security 672 In order to give Internet Fax users the same assurance of privacy and 673 integrity that is common with telephone-based fax, the Internet Fax 674 standard must specify how secure messages can be sent, in an 675 interoperable fashion. The Internet Fax protocol SHOULD encourage 676 the introduction of security features, e.g., by requiring that minimum 677 capability devices still accept signed messages (even if ignoring the 678 signature.) 680 In the case where the sender is responsible for payment for offramp 681 services in a remote location, it may be necessary to provide for 682 authentication of the sender and billing information from the offramp 683 to be negotiated securely. 685 5.5 Requirements for capabilities exchange 687 Traditional fax supports a wide range of devices, including high 688 resolution ("Superfine"); recent enhancements include methods for 689 color. Fax messaging includes the capability for "non-standard frames", 690 which allow vendors to introduce proprietary data formats. In addition, 691 facsimile supports "binary file transfer": a method of sending 692 arbitrary binary data in a fax message. 694 To support interoperability with these mechanisms, it SHOULD be possible 695 to express a wide variety of fax capabilities. 697 Capability support has three elements: expression of the capabilities 698 of the sender (as far as a particular message is concerned), expressing 699 the capabilities of a recipient (in advance of the transmission of the 700 message), and then the protocol by which capabilities are exchanged. 702 The Internet Fax standard must specify a uniform mechanism for 703 capabilities expression. If capabilities are being sent at times 704 other than the time of message transmission, then capabilities 705 SHOULD include sufficient information to allow it to be validated, 706 authenticated, etc. 708 The Internet Fax standard MAY include one or several methods for 709 transmission, storage, or distribution of capabilities. 711 A request for capability information, if sent to a recipient at any 712 time other than the immediate time of delivery of the message, SHOULD 713 clearly identify the sender, the recipient whose capabilities 714 are being requested, and the time of the request. Som kind of 715 signature would be useful, too. 717 A capability assertion (sent from recipient to sender) SHOULD clearly 718 identify the recipient and some indication of the date/time or range 719 of validity of the information inside. To be secure, capability 720 assertions SHOULD be protected against interception and the 721 substitution of valid data by invalid data. 723 6. Security Considerations 725 This document lays out several security considerations for Internet 726 Fax. 728 7. Acknowledgements 730 The author gratefully acknowledges the contributions of Graham Klyne, 731 Vivian Cancio, Dan Wing, Jim Dahmen, Neil Joffe, Mike Lake, Lloyd 732 McIntyre, Richard Shockey, Herman Silbiger, Nadesan Narenthiran, and 733 George Pajari for their valuable comments on this document. 735 8. Copyright 737 Copyright (C) The Internet Society, 1997. All Rights Reserved. 739 This document and translations of it may be copied and furnished to 740 others, and derivative works that comment on or otherwise explain it 741 or assist in its implementation may be prepared, copied, published and 742 distributed, in whole or in part, without restriction of any kind, 743 provided that the above copyright notice and this paragraph are 744 included on all such copies and derivative works. However, this 745 document itself may not be modified in any way, such as by removing 746 the copyright notice or references to the Internet Society or other 747 Internet organizations, except as needed for the purpose of developing 748 Internet standards in which case the procedures for copyrights defined 749 in the Internet Standards process must be followed, or as required to 750 translate it into languages other than English. 752 The limited permissions granted above are perpetual and will not be 753 revoked by the Internet Society or its successors or assigns. 755 This document and the information contained herein is provided on an 756 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 757 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 758 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 759 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 760 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 762 9. Author's address 764 Larry Masinter 765 Xerox Corporation 766 3333 Coyote Hill Road 767 Palo Alto, CA 94304 768 masinter@parc.xerox.com 769 http://www.parc.xerox.com/masinter 770 Fax: (650) 812-4333 772 10. References 774 [T.30] ITU-T, Recommendation T.4, Standardization of Group 3 775 facsimile terminals for document transmission. 777 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 778 Requirement Levels", RFC 2119, Harvard University, March 1997.