idnits 2.17.1 draft-ietf-fax-goals-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 867 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 4 instances of too long lines in the document, the longest one being 2 characters 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) == Missing Reference: 'RFC 2298' is mentioned on line 576, but not defined ** Obsolete undefined reference: RFC 2298 (Obsoleted by RFC 3798) == Unused Reference: 'RFC2298' is defined on line 861, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2298 (Obsoleted by RFC 3798) Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 2 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 August 27, 1998 Expires in 6 months 4 draft-ietf-fax-goals-03.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 view the entire list of current Internet-Drafts, please check 21 the "1id-abstracts.txt" listing contained in the Internet-Drafts 22 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 23 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 24 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 25 (US West Coast). 27 This draft is being discussed by the IETF FAX working group. To 28 subscribe to the mailing list, send a message to 29 ietf-fax-request@imc.org with the line "subscribe" in the body of the 30 message. Archives are available from http://www.imc.org/ietf-fax. 32 Table of contents: 33 1. Introduction 34 2. Definitions and Operational Modes 35 2.1 User model of fax 36 2.2 Definition of Internet Fax 37 2.3 Internet Fax Roles 38 2.4 Internet Fax Devices 39 2.5 Operational modes 40 3. Goals for Internet Fax 41 4. Operational Goals for Internet Fax 42 4.1 Functionality 43 4.2 Interoperability 44 4.3 Confirmation 45 4.4 Quick Delivery 46 4.5 Capabilities 47 4.6 Simplicity 48 4.7 Security 49 4.8 Reliability 50 4.9 Fax-like use 51 4.10 Legal 52 5. Functional Goals for Internet Fax 53 5.1 Goals for image data representation 54 5.2 Goals for transmission 55 5.3 Goals for addressing 56 5.4 Goals for security 57 5.5 Goals for capability exchange 58 6. Security Considerations 59 7. Acknowledgements 60 8. Copyright 61 9. Author's address 62 10. References 64 1. Introduction 66 Facsimile (Fax) has a long tradition as a telephony application for 67 sending a document from one terminal device to another. 69 Many mechanisms for sending fax documents over the Internet have been 70 demonstrated and deployed and are currently in use. The general 71 application of using the Internet for facsimile is called "Internet 72 Fax". 74 This document defines a number of terms useful for the discussion of 75 Internet Fax. In addition, it describes the goals for Internet Fax and 76 establishes a baseline of desired functionality against which 77 protocols for Internet Fax can be judged. It encompasses the goals for 78 all modes of facsimile delivery, including "real-time", "session", and 79 "store and forward" (terms defined in Section 2 of this document). 81 1.1 Terminology used within this document 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; 93 a definition that does not provide this element is 94 acceptable. 96 In addition, the following terms are used: 98 "service" An operational service offered by a service provider. 99 "application" A use of systems to perform a particular function. 100 "terminal" The endpoint of a communication application. 101 "goal" An objective of the standarization 103 2. Definitions and Operation Modes 105 This section defines some of the basic terms for Internet Fax. 107 2.1 User model of fax and basic operations 109 The phrase "traditional facsimile" or "G3Fax" is used to denote 110 implementations of [T.30]. Facsimile (fax) is a telephony application 111 for sending a document from one terminal device to another. 113 The telephone network is often referred to as the Public Switched 114 Telephone Network (PSTN) or Global Switched Telephone Network (GSTN). 116 Communication over the telephone network is accomplished using modems. 117 The transmission of data end-to-end is accompanied by negotiation (to 118 ensure that the scanned data can be rendered at the recipient) and 119 confirmation of delivery (to give the sender assurance that the final 120 data has been received and processed.) Over time, facsimile has been 121 extended to allow for PCs using fax modems to send and receive fax, to 122 send data other than scanned facsimile images. In addition, there have 123 been many extensions to the basic image model, to allow for additional 124 compression methods and for representation of images with grey-scale 125 and color. Other delivery extensions have included sub-addressing 126 (additional signals after the call is established to facilitate 127 automated routing of faxes to desktops or mailboxes), and enhanced 128 features such as fax-back and polling. 130 Typically, the terminal device consists of a paper input device 131 (scanner), a paper output device (printer), with (a limited amount of) 132 processing power. Traditional facsimile has a simple user operational 133 model; the user 135 1) inserts paper into a device 136 2) dials a number corresponding to the destination 137 3) presses the 'start' button on the device 138 4) the sending device connects to the receiving device 139 using the telephone network 140 5) the sending device scans the paper and transmits the image 141 of the paper 142 6) simultaneously, the remote device receives the transmission 143 and prints the image on paper 144 7) upon completion of transmission and successful processing 145 by the recipient, the sending user is notified of success 147 Although not usually visible to the user, the operation (5) of 148 transmission consists of 150 5a) negotiation: the capabilities of the sender and recipient 151 are exchanged, and suitable mutually acceptable parameters 152 for the communication are selected 153 5b) scanning: creating digitized images of pages of a document 154 5c) compression: the image data is encoded using a data compression 155 method 156 5d) transmission: the data is sent from one terminal to the other 158 In addition, the terminiation of operations (5d) and (6) may be 159 characterized as consisting of: 161 6a) completed delivery: the message has completed transmission 162 6b) completed receipt: the message has been accepted by the recipient 163 6c) processing and disposition: the message has been processed 165 >From a protocol perspective, the information conveyed in the 166 transmission consists of both "protocol" (control information, 167 capabilities, identification) and also "document content". 169 The document content consists primarily of the "document image" plus 170 additional metadata accompanying the image. The means by which an 171 image of a document is encoded within the fax content is the "image 172 data representation". 174 When the fax has been sucessfully transmitted, the sender receives a 175 "confirmation": an indication that the fax content was delivered, 176 received, and processed. This "confirmation" is an internal signal 177 and is not normally visible to the sending user, although some error 178 messages are visible, to allow a page to be retransmitted. 180 2.2 Definition of Internet Fax 182 The phrase "Internet Fax" is used to denote an application which 183 supports an approximation to the user model of fax (Section 2.1), but 184 where Internet protocols are used instead of the telephone network for 185 (some portion of) the transmission. The exact modes and operations of 186 traditional facsimile need not be duplicated exactly. 188 2.3 Internet Fax Roles 190 Internet Fax is a document transmission mechanism between various 191 different devices and roles. Those devices and roles might come in a 192 wide variety of configurations. To allow for a wide variety of 193 configurations, it is useful to separate out the roles, as they may 194 be made available separately or in combination. These roles are: 196 * Network scanner 197 A device that can scan a paper document and transmit the scanned 198 image via the Internet 200 * Network printer 201 A device that can accept an image transmission via the Internet 202 and print the received document automatically 204 * Fax onramp gateway 205 A device that can accept a facsimile telephone call and 206 automatically forward it via the Internet 208 * Fax offramp gateway 209 A device that can accept a transmission from the Internet and 210 forward it to a traditional fax terminal 212 In addition, other traditional Internet applications might also 213 participate in Internet Fax, including Internet mail users, Web 214 browsers, Internet printing hosts. 216 2.4 Internet Fax Devices 218 The Internet Fax roles may be embedded in a variety of combinations 219 and configurations within devices and larger applications. They may 220 be combined with other elements, e.g., a traditional T.30 fax 221 device. Many different configurations of applications should {2} be 222 able to participate in Internet Fax; the specification should not 223 unnecessarily restrict the range of devices, applications and services 224 that can participate. 226 The phrase "IFax device" is used to indicate a device which supports 227 any combination of the roles defined in 2.3, as embodied in a single 228 device which is engaged in an Internet Fax application. 230 2.4.1 Gateway devices 232 A traditional fax terminal has a telephone line connection (PSTN) with 233 a fax modem used to connect over the telephone network. To connect a 234 fax terminal to the Internet requires a service which offers 235 connections on one side to the PSTN using standard fax signals, and on 236 the other side to the Internet. This role might be performed by a 237 "relay" (e.g., transmitting T.30 signals over real-time controlled TCP 238 connections) or a "gateway" (e.g., translating T.30 to TIFF/email). 240 With these applications, the role of Internet Fax is to transport the 241 fax content across the Internet, e.g., with 243 [fax-term]-PSTNfax->[onramp]-Internet Fax->[recipient] 244 [sender]-Internet Fax->[offramp]-PSTNFax->[fax-term] 246 A onramp and/or offramp application may be local to a single fax 247 terminal. For example, the gateway application might exist within a small 248 device which has a telephone interface on one side and a network 249 connection on the other. To the fax machine, it looks like a telephone 250 connection, although it might shunt some or all connections to 251 Internet Fax instead (Such devices are called "Bump-in-cord.") 253 An onramp or offramp application may be a local facility serving many fax 254 terminals. For example, outgoing telephone fax calls through a company 255 telephone PBX could be rerouted through a local onramp. An internet to 256 telephone outbound connection could be part of a "LAN Fax" package. 258 Onramps and offramps may serve a wider area or broader collection of 259 users, e.g., services run by service bureaus, offering subscription 260 services; the telephone sender or the recipient might subscribe to the 261 service. 263 The target of an offramp may be a "hunt group": a set of telephone 264 numbers, each of which have a possibly different fax terminal 265 attached. 267 2.4.2 New "IFax" terminals 269 Manufacturers of traditional facsimile devices may offer new devices 270 built out of similar components (scanner, processor, and printer), 271 which offer a similar functionality to a fax device, but which 272 connects to the Internet. These devices might also offer a traditional 273 fax modem capability, or might send documents exclusively through the 274 Internet. Such devices might have a permanent Internet connection 275 (through a LAN connection) or might have occasional connectivity 276 through a (data) modem to an Internet Service Provider. 278 2.4.3 Internet hosts 280 Internet users using Internet hosts with standard application suites 281 must {1} be able to exchange faxes with other participants in Internet 282 Fax, with minimum required enhancements to their operating 283 environment. 285 Interoperability with Internet mail users, either as Internet Fax 286 senders or recipients, is highly desirable {2}. 288 Internet users might receive faxes over the Internet and display them 289 on their screens, or have them automatically printed when received. 290 Similarly, the Internet Fax messages originating from the user might 291 be the output of a software application which would normally print, or 292 specially constructed fax-sending software, or may be input directly 293 from a scanner attached to the user's terminal. 295 The Internet Fax capability might be integrated into existing 296 fax/network fax software or email software, e.g., by the addition of 297 "Ifax Printer Drivers" that would render the document to the 298 appropriate content-type and cause it to be delivered using an 299 Internet Fax protocol. 301 In some cases, the user might have a multi-function peripheral which 302 integrated a scanner and printer and which gave operability similar to 303 that of the stand-alone fax terminal. 305 2.4.4 Internet messaging 307 In Internet mail, there are a number of components that operate in the 308 infrastructure to perform additional functions beyond mail 309 store-and-forward. Interoperability with these components is a 310 consideration for the store and forward profile of Internet Fax. For 311 example, mailing list software accepts mail to a single address and 312 forwards it to a distribution list of many users. Mail archive 313 software creates repositories of searchable messages. Mail firewalls 314 operate at organizational boundaries and scan incoming messages for 315 malicious or harmful mail attachments. Vacation programs send return 316 messages to the senders of messages when the recipient is on vacation 317 and not available to respond. 319 2.4.5 Universal messaging 321 Many software vendors are now promoting software packages that support 322 "universal messaging": a combined communication package that combines 323 electronic mail, voice mail, and fax. 325 2.5 Operational Modes for Internet Fax 327 Facsimile over the Internet can occur in several modes. 329 "Store and forward" Internet Fax entails a process of storing the 330 entire document at a staging point, prior to transmitting it to the 331 next staging point. Store and forward can be directly between sender 332 and recipient or can have a series of intermediary staging points. 333 The intermediate storage may involve an intermediate agent or sequence 334 of agents in the communication. 336 "Session" Internet Fax is defined such that delivery notification is 337 provided to the transmitting terminal prior to disconnection. Unlike 338 "store and forward", there is an expection that direct communication, 339 negotiation, and retransmission can take place between the two 340 endpoints. 342 "Real-time" Internet Fax allows for two [T.30] standard facsimile 343 terminals to engage in a document transmission in a way that all of 344 the [T.30] communication protocol is preserved. 346 These modes are different in the end-user expectation of immediacy, 347 reliability, and in the ease of total compatibility with legacy or 348 traditional facsimile terminals; the modes may have different 349 requirements on operational infrastructure connecting sender and 350 recipient. 352 3. Goals for Internet Fax 354 Facsimile over the Internet must define the mechanisms by which a 355 document is transmitted from a sender to a recipient, and must {1} 356 specify the following elements: 358 - Transmission protocol: what Internet protocol(s) and extensions are 359 used? What options are available in that transmission? 361 - Data formats: what image data representation(s) are used, 362 appropriate, required, within the transmission protocol? What other 363 data representations are supported? 365 - Addressing: How are Internet Fax recipients identified? How may 366 recipient identification be represented in user directories? How are 367 traditional fax terminals addressed? 369 - Capabilities: The capabilities of the sender to generate different 370 kinds of image data representations may be known to the recipient, 371 and the capabilities, preferences, and characteristics of the 372 recipient may be known to the sender. How are the capabilities, 373 preferences, and characteristics of senders and recipients 374 expressed, and communicated to each other? 376 - Security: Faxes may be authenticated as to their origin, or secured 377 to protect the privacy of the message. How may the authenticity of 378 a fax be determined by the recipient? How may the privacy of a 379 message be guaranteed? 381 Specific goals for these elements are described in section 5. 383 4. Operational Goals for Internet Fax 385 This section lists the necessary and desirable traits of an Internet 386 Fax protocol. 388 4.1 Functionality 390 Traditionally, images sent between fax machines are transmitted over 391 the global switched telephone network. An Internet Fax protocol must 392 {1} provide for a method to accomplish the most commonly used features 393 of traditional fax using only Internet protocols. It is desirable {3} 394 for Internet Fax to support all standard features and modes of 395 standard facsimile. 397 4.2 Interoperability 399 It is essential {1} that Internet Fax support interoperability between 400 most of the devices and applications listed in section 2, and desirable 401 {3} to support all of them. To "support interoperability" means that a 402 compliant sender attempting to send to a compliant recipient will not 403 fail because of incompatibility. 405 Overall interoperability requires {1} interoperability for all of the 406 protocol elements: the image data representations must be understood, 407 the transport protocol must function, it must be possible to address 408 all manner of terminals, the security mechanism must not require 409 manual operations in devices that are intended for unattended 410 operation, and so forth. 412 Interoperability with Internet mail user agents is a requirement {1} 413 only for the "store-and-forward" facsimile, although it would be 414 useful {3} for "session" and "real-time" modes of delivery of Internet 415 Fax. 417 The requirement for interoperability has strong implications for the 418 protocol design. Interoperability must not {1} depend on having the 419 same kind of networking equipment at each end. 421 As with most Internet application protocols, interoperability must {1} 422 be independent of the nature of the networking link, whether a simple 423 IP-based LAN, an internal private IP networks, or the public 424 Internet. The standard for Internet Fax must {1} be global and have no 425 special features for local operations. 427 If Internet Fax is to use the Internet mail transport mechanisms, it 428 must {1} interoperate consistently with the current Internet mail 429 environment, and, in particular, with the non-terminal devices listed 430 in section 2.4.4. If Internet Fax messages might arrive in user's 431 mailboxes, it is required {1} that the protocol interoperate 432 successfully with common user practices for mail messages: storing 433 them in databases, retransmission, forwarding, creation of mail 434 digests, replay of old messages at times long after the original 435 receipt, and replying to messages using non-fax equipment. 437 It is desirable {3} that the Internet Fax standard support and 438 facilitate universal messaging systems described in section 2.4.5. 440 If Internet Fax requires additions to the operational environment 441 (services, firewall support, gateways, quality of service, protocol 442 extensions), then it is preferable {3} if those additions are useful 443 for other applications than Fax. Features shared with other messaging 444 applications (voice mail, short message service, paging, etc.) are 445 desirable {3}, so as not to require different operational changes for 446 other applications. 448 4.3 Confirmation 450 In almost all applications of traditional fax, it is considered very 451 important that the user can get an assurance that the transmitted data 452 was received by a terminal at the address dialed by the user. 454 This goal translates to the Internet environment. The 'Internet Fax' 455 application must {1} define the mechanisms by which a sender may 456 request notification of the completion of transmission of the message, 457 and receive a determinate response as to whether the message was 458 delivered, not delivered, or that no confirmation of delivery is 459 possible. 461 Originally, fax "confirmation" indicated that the message was recieved 462 and processed, e.g., delivered to the output paper tray of the 463 recipient fax device. With the addition of memory buffering and 464 PC-based fax modems, traditional fax confirmation still indicated some 465 assurance of processability; e.g., a fax modem would not confirm 466 receipt of an incoming fax if it required compression mechanisms that 467 were not supported. 469 Still, this is not the same as a confirmation that the message was 470 "read": that a human had confirmed that the message was 471 received. Confirmation that the message was read (above and beyond the 472 notification that the message was delivered) is desirable {3}, but not 473 required. 475 4.4 Quick Delivery 477 In many cases, fax transmission is used for delivery of documents 478 where there is a strong user requirement for timeliness, with some 479 guarantees that if transmission begins at all, it will complete 480 quickly. For example, it is a common practice to fax documents for 481 discussion to other participants in a telephone conference call prior 482 to the call. 484 Internet Fax should {2} allow the sender of a document to request 485 immediate delivery, if such delivery is possible. In such cases, it 486 should {2} be possible for the sender of a message to avoid sending 487 the message at all, if quick delivery is not available for a 488 particular recipient. 490 It is desirable {3} to have the protocol for requesting quick delivery 491 be the same as, or similar to, the protocol for delayed delivery, so 492 that two separate mechanisms are not required. 494 For real-time fax delivery, immediate delivery is the norm, since the 495 protocol must guarantee that when the session connecting sender to 496 recipient has terminated, the message has been delivered to the 497 ultimate recipient. 499 4.5 Capabilities: reliable, upgrade possible 501 Traditionally, facsimile has guaranteed interworking between senders 502 and recipients by having a strict method of negotiation of the 503 capabilities between the two devices. The image representation of 504 facsimile originally was a relatively low resolution, but has 505 increasingly offered additional capabilities (higher resolution, 506 color) as options. 508 The use of fax has grown in an evolving world (from 'Group 1' and 509 'Group 2', to 'Group 3' facsimile) because of two elements: (a) a 510 useful baseline of capabilities that all terminals implemented, and 511 (b) the use of capabilities exchange to go beyond that. 513 To accommodate current use as well as future growth, Internet Fax 514 should {2} have a simple minimum set of required features that will 515 guarantee interoperability, as well as a mechanism by which higher 516 capability devices can be deployed into a network of lower capability 517 devices while ensuring interoperability. If recipients with minimum 518 capabilities were, for example, to merely drop non-minimum messages 519 without warning, the result would be that no non-minimum message could 520 be sent reliably. This situation can be avoided in a variety of ways, 521 e.g., through communication of recipient capabilities or by sending 522 multiple renditions. 524 The exchange of capabilities in Internet Fax should {2} be robust. To 525 accomplish this, recipients should {2} be encouraged to provide 526 capabilities, even while senders must {1} have a way to send messages 527 to recipients whose capabilities are unknown. 529 Even minimum-capability recipients of messages should {2} be required 530 to provide a capability indication in some reliable way. This might be 531 accomplished by providing an entry in a directory service, by offering 532 automatic or semi-automatic replies, or by sending some indication of 533 in a reply to a message with multiple renditions, or as an addition to 534 a negative acknowledgement requiring retransmission. 536 On the other hand, for reliability, senders cannot rely on capability 537 information of recipients before transmission. That is, for 538 reliability, senders should {2} have an operational mode which can 539 function when capabilities are not present, even when recipients must 540 always provide capabilities. 542 4.6 Simplicity 544 Internet Fax should not {2} require terminals to possess a large 545 amount of processing power, and a base level implementation must {1} 546 interoperate, even if it does not offer complex processing. 548 Internet Fax should {2} allow interoperability with recipient devices 549 which have limited buffering capabilities and cannot buffer an entire 550 fax message prior to printing, or cannot buffer an entire set of fax 551 pages before beginning transmission of scanned pages. 553 Different operational modes (real-time, session, store and forward) 554 might use different protocols, in order to preserve the simplicity of 555 each. 557 It is preferable {3} to make as few restrictions and additions to 558 existing protocols as possible while satisfying the other 559 requirements. It is important {2} that it be possible to use Internet 560 Fax end-to-end in the current Internet environment without any changes 561 to the existing infrastucture, although some features may require 562 adoption of existing standards. 564 4.7 Security: Cause No Harm, Allow for privacy 566 The widespread introduction of Internet Fax must {1} not cause harm, 567 either to its users or to others. For example, an automatic mechanism 568 for returning notification of delivery or capabilities of fax 569 recipients by email must {1} not expose the users or others to mail 570 loops, bombs, or replicated delivery. Automatic capability exchange 571 based on email might not be sufficiently robust and, without 572 sufficient precautions, might expose users to denial of service 573 attacks, or merely the bad effects of errors on the part of system 574 administrators. Similar considerations apply in these areas to those 575 that have been addressed by work on electronic mail receipt 576 acknowledgements [RFC 2298]. 578 Internet Fax should {2} not, by default, release information that the 579 users consider private, e.g., as might be forthcoming in response to a 580 broadcast requests for capabilities to a company's Internet fax 581 devices. Public recipients of Internet Fax (e.g., public agencies 582 which accept facsimile messages) should {2} not be required to 583 broadcast messages with capability statements to all potential senders 584 in order to receive facsimile messages appropriate for the 585 capabilities of their device. 587 The possibility for "causing harm" might be created by a combination 588 of facilities and other features which individually may be viewed as 589 harmless. Thus, the overall operation of a network full of Internet 590 Fax devices must {1} be considered. 592 Interoperation with ITU defined T.30 fax security methods, as well as 593 standard Internet e-mail security methods is desirable {3}. 595 4.8 Reliability 597 The Internet Fax protocol should {2} operate reliably over a variety 598 of configurations and situations. 600 In particular, operations which rely on time-delayed information might 601 result in inconsistent information, and the protocol should be robust 602 even in such situations. 604 For example, in a store-and-forward message environment, the 605 capabilities and preferences of a fax recipient might be used by the 606 sender to construct an appropriate message, e.g., sending a color fax 607 to a color device but a black and white fax to a device that does not 608 have color capability. However, the information about recipient 609 capabilities must be accessible to the sender even when the recipient 610 cannot be contacted directly. Thus, the sender must access recipient 611 capabilities in some kind of storage mechanism, e.g., a directory. A 612 directory of recipient capabilities is a kind of distributed database, 613 and would be subject to all of the well-known failure modes of 614 distributed databases. For example, update messages with capability 615 descriptions might be delivered out of order, from old archives, might 616 be lost, non-authenticated capability statements might be spoofed or 617 widely distributed by malicious senders. The Internet Fax protocol 618 should {2} be robust in these situations; messages should {2} not be 619 lost or misprocessed even when the sender's knowledge of recipient 620 capabilities are wrong, and robust mechanisms for delivery of 621 recipient capabilities should {2} be used. 623 4.9 User Experience 625 The primary user experience with fax is: 627 immediate delivery 628 delivery confirmation 629 ease of use 631 The primary user experience with email is: 633 delayed delivery 634 no delivery confirmation 635 ability to reply to sender 636 easy to send to multiple recipients 638 An Internet Fax standard should {2} attempt to reconcile the 639 differences between the two environments. 641 4.10 Legal 643 An Internet Fax standard should {2} accomodate the legal requirements 644 for facsimile, and attempt to support functionality similar to that 645 legally required even for devices that do not operate over the public 646 switched telephone network. 648 The United States Federal Communication Commission regulations 649 (applicable only within the USA) state: 651 "Identification Required on Fax Messages 653 The FCC's rules require that any message sent to a fax machine 654 must clearly mark on the first page or on each page of the message: 655 * the date and time the transmission is sent; 656 * the identity of the sender; and 657 * the telephone number of the sender or of the sending fax 658 machine. 659 All fax machines manufactured on or after December 20, 1992 and 660 all facsimile modem boards manufactured on or after December 13, 661 1995 must have the capability to clearly mark such identifying 662 information on the first page or on each page of the transmission." 664 5. Functional Goals for Internet Fax 666 These goals for specific elements of Internet Fax follow from the 667 operational goals described in section 4. 669 5.1 Goals for image and other data representations 671 Interoperability with Internet Mail or other transmission mechanisms 672 that cause data files to appear in Internet terminal environments 673 requires {1} that Internet Fax use a format for images that is in wide 674 use. 676 Interoperability with Internet Mail requires {2} that Internet Fax 677 recipients handle those message types that are common in the email 678 environment, including a minimum set of MIME mail formats. 680 Interoperability with traditional fax terminals requires {1} that the 681 data format be capable of representing the commonly used compression 682 mechanisms defined for traditional facsimile; support for _all_ 683 standard formats defined for traditional facsimile is highly desirable 684 {2}. In addition, interoperability with 'private use' facsimile 685 messages suggests {3} that the standard accommodate arbitrary bit 686 sequences. 688 5.2 Goals for transmission 690 It is necessary {1} that Internet Fax to work in the context of the 691 current Internet, Intranet, and the combination across firewalls. 693 A single protocol with various extensions is preferable {3} to 694 multiple separate protocols, if there are devices that might require, 695 at different times and for different recipients, different protocols. 697 5.3 Goals for addressing 699 Interoperability with the terminal types in section 2 requires {1} the 700 ability to address each of the kinds of recipient devices. The 701 address of a recipient must give sufficient information to allow the 702 sender to initiate communication. 704 Interoperability with offramps to legacy fax terminals requires {1} 705 that the message contain some way of addressing the final destination 706 of facsimile messages, including telephone numbers, various ISDN 707 addressing modes, and facsimile sub-addresses. 709 Interoperability with Internet Mail requires {1} that it be possible 710 to address Internet Fax to any email address. Interworking with 711 Internet mail also requires {1} that the addressing is in the email 712 addressing headers, including mail transport envelope [RFC1123] and 713 RFC822 headers, as appropriate. The information must {1} appear 714 nowhere else. 716 Sending devices might not have local storage for directories of 717 addresses, and addresses might be cumbersome for users to type in. For 718 these reasons, Internet Fax devices may require configuration to 719 locate directories of recipients and their capabilities. 721 The source of a fax message must {1} be clearly identified. The 722 address of the appropriate return message (whether via fax or via 723 email) should {2} be clearly identified in a way that is visible to 724 all manner of recipients. In the case of Internet Fax delivered by 725 email, it should {2} be possible to use the normal 'reply' functions 726 for email to return a message to the sender. 728 Traditionally, it is common for the first page of a fax message sent 729 to a facsimile terminal to contain an (image) representation of the 730 name, address, return number, etc. of the sender of the document. 731 Some legal jurisdictions for facsimile require an identification of 732 the sender on every page. The standard for Internet Fax should {2} 733 cover the issues of sender and recipient identification in the cases 734 where fax messages are re-routed, forwarded, sent through gateways. 736 5.4 Goals for Security 738 Users typically use GSTN-based fax for confidential document 739 transmission, assuming a similar or higher level of confidentiality 740 and protection from both deliberate and inadvertent eavesdropping as 741 holds for telephone conversations; the higher level of confidentiality 742 arising from the requirement for non-standard equipment to intercept 743 and interpret an overheard fax transmission. 745 Similarly, in traditional fax there is an expectation (and, in some 746 contexts, a legally recognized assurance) that the received fax is 747 unaltered from the document originally transmitted. 749 It is important {2} that Internet Fax give users a level of assurance 750 for privacy and integrity that is as good or better than that 751 available for telephone-based fax. The Internet Fax standard should 752 {2} specify how secure messages can be sent, in an interoperable 753 fashion. The Internet Fax protocol should {2} encourage the 754 introduction of security features, e.g., by requiring that minimum 755 capability devices still accept signed messages (even if ignoring the 756 signature.) 758 In the case where the sender is responsible for payment for offramp 759 services in a remote location, it is desirable {3} to provide for 760 authentication of the sender and billing information from the offramp 761 to be negotiated securely. 763 5.5 Goals for capabilities exchange 765 Traditional fax supports a wide range of devices, including high 766 resolution ("Superfine"); recent enhancements include methods for 767 color and a variety of compression mechanisms. Fax messaging includes 768 the capability for "non-standard frames", which allow vendors to 769 introduce proprietary data formats. In addition, facsimile supports 770 "binary file transfer": a method of sending arbitrary binary data in a 771 fax message. 773 To support interoperability with these mechanisms, it should {2} be 774 possible to express a wide variety of fax capabilities. 776 Capability support has three elements: expression of the capabilities 777 of the sender (as far as a particular message is concerned), 778 expressing the capabilities of a recipient (in advance of the 779 transmission of the message), and then the protocol by which 780 capabilities are exchanged. 782 The Internet Fax standard should {2} specify a uniform mechanism for 783 capabilities expression. If capabilities are being sent at times other 784 than the time of message transmission, then capabilities should {2} 785 include sufficient information to allow it to be validated, 786 authenticated, etc. 788 The Internet Fax standard may {3} include one or several methods for 789 transmission, storage, or distribution of capabilities. 791 A request for capability information, if sent to a recipient at any 792 time other than the immediate time of delivery of the message, should 793 {2} clearly identify the sender, the recipient whose capabilities are 794 being requested, and the time of the request. Som kind of signature 795 would be useful, too. 797 A capability assertion (sent from recipient to sender) should {2} 798 clearly identify the recipient and some indication of the date/time or 799 range of validity of the information inside. To be secure, capability 800 assertions should {2} be protected against interception and the 801 substitution of valid data by invalid data. 803 6. Security Considerations 805 This document describes the goals for the Internet Fax protocol, 806 including the security goals. An Internet Fax protocol must {1} 807 address the security goals and provide adequate measures to 808 provide users with expected security features. 810 7. Acknowledgements 812 The author gratefully acknowledges the contributions of Graham Klyne, 813 Vivian Cancio, Dan Wing, Jim Dahmen, Neil Joffe, Mike Lake, Lloyd 814 McIntyre, Richard Shockey, Herman Silbiger, Nadesan Narenthiran, 815 George Pajari and Dave Crocker for their valuable comments on this 816 document. 818 8. Copyright 820 Copyright (C) The Internet Society, 1997. All Rights Reserved. 822 This document and translations of it may be copied and furnished to 823 others, and derivative works that comment on or otherwise explain it 824 or assist in its implementation may be prepared, copied, published and 825 distributed, in whole or in part, without restriction of any kind, 826 provided that the above copyright notice and this paragraph are 827 included on all such copies and derivative works. However, this 828 document itself may not be modified in any way, such as by removing 829 the copyright notice or references to the Internet Society or other 830 Internet organizations, except as needed for the purpose of developing 831 Internet standards in which case the procedures for copyrights defined 832 in the Internet Standards process must be followed, or as required to 833 translate it into languages other than English. 835 The limited permissions granted above are perpetual and will not be 836 revoked by the Internet Society or its successors or assigns. 838 This document and the information contained herein is provided on an 839 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 840 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 841 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 842 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 843 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 845 9. Author's address 847 Larry Masinter 848 Xerox Corporation 849 3333 Coyote Hill Road 850 Palo Alto, CA 94304 851 masinter@parc.xerox.com 852 http://www.parc.xerox.com/masinter 853 Fax: (650) 812-4333 855 10. References 857 [T.30] ITU-T (CCITT), "Procedures for Document Facsimile Transmission 858 in the General Switched Telephone Network", ITU-T (CCITT), 859 Recommendation T.30, July, 1996. 861 [RFC2298] R. Fajman, "An Extensible Message Format for Message Disposition 862 Notifications", RFC 2298, March 1998. 864 [RFC1123] R. Braden, "Requirements for Internet hosts - application 865 pand support", RFC 1123, October 1989.