INTERNET DRAFT Richard Shockey November 12, 1998 Shockey Consulting LLC Expires April 1999 draft-shockey-ipp2ifax-01.txt The Use of the Internet Print Protocol [IPP] as a Facsimile Service [FAX] STATUS OF THIS MEMO This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), unnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. ABSTRACT This memorandum discusses the use of the Internet Print Protocol [IPP] as a facsimile service. IPP has most of the functional attributes necessary to be a successful real time facsimile service on the Internet with little or no modification to the core IPP V 1.0 protocols [IPP-MOD] [IPP-PRO]. IPP compliance with the legal and general custom and practice surrounding General Switched Telephone Network [FAX] will require some modification to the behavior of IPP clients and the common usage of time/date stamping on local IPP device transactions and logs. SHOCKEY Expires April 1999 [Page 1] INTERNET DRAFT IPP as a Facsimile Service November 1998 1.0 INTRODUCTION Facsimile [FAX] has a long and successful tradition as a telephony application for sending a document from one client/terminal device to another. At a sufficient level of abstraction, the concept of FAX could be considered a "remote printing" technology. Therefore, it is worth reviewing the various aspects of what work has been done to date to define service objectives for facsimile over IP networks and specifically identify those elements of IPP that match those needs. 2.0 OVERVIEW OF FACSIMILE SERVICES 2.1 TRADITIONAL FAX Traditional facsimile as defined by the ITU [T.30] is a connection oriented technology between two client/terminal devices over the GSTN (Global Switched Telephone Network). It is specifically a "point to point" service where the end point is an address defined by an ITU [E.164] telephone number. The content types specified by T.30 are highly restricted due to the lack of available bandwidth available on the analog GSTN, typically limited to 14.4Kpbs, but standards do exist to support up to 28.8Kpbs. 2.2 IETF FAX SERVICE For Information on IETF-FAX work group: http://www.imc.org/ietf-fax The Internet Fax service [IFAX][RFC 2305] has developed within the IETF as using SMTP. With SMTP there are two functional elements, a Message Transfer Agent (MTA) and a Message User Agent (MUA). The MTA's and MUA's are operating in a Client-Server / Store and Forward. IFAX adds significant functionality to facsimile services by integrating with other SMTP services, such as the Voice Profile for Internet Mail [VPIM2], in a concept often referred to as "Universal Messaging". [RFC 2301] introduces several advanced content types, including higher resolution Black & White and several types of color files that, for practical reasons, would be impossible to transmit over the GSTN. Current work within the IETF-FAX work group [EIFAX] defines some essential features for SHOCKEY Expires April 1999 [Page 2] INTERNET DRAFT IPP as a Facsimile Service November 1998 reporting and receipt notification using Disposition Service Notification - Message Disposition Notification [DSN-MDN], as well as some outlines for client/device capabilities negotiation. 2.3 ITU FAX The ITU (International Telecommunications Union) has taken two approaches to defining an Internet Fax service. 2.3.1 ITU STORE-AND-FORWARD FAX In the first instance it has adopted the body of IETF IFAX work [RFC 2301-2306 inclusive] and defined it as [T.37]. 2.3.2 ITU REALTIME FAX The ITU has also defined a "real time" Internet fax standard as well, now documented as [T.38]. T.38 tunnels under [H.323] to establish capabilities exchange and reporting, then uses RTP (Real Time Protocol) to deliver the content payload. Though a discussion of the merits of H.323 is beyond the scope of this document, H.323 was originally designed for real time voice and video and could be considered overkill for a relatively simple application such as real time confirmed document transmission (facsimile). In addition T.38 does not define a destination addressing scheme for transactions, such as a phone number or a URL. The scope of T.38 is limited only to the transport of supported fax content over IP networks. T.38 is gaining acceptance specifically in the IP Telephony Gateway market oriented towards carriers. The requirements for H.323 in the Voice over IP market allows T.38 to be easily implemented as an "add on" to VoIP at very little incremental cost. 3.0 END USER REQUIREMENTS FOR A FACSIMILIE SERVICE 3.1 IETF-FAX GOALS The document "Terminology and Goals for Internet Fax" [GOALS] describes the general system functional requirements for an Internet Fax service. To Quote directly from GOALS: SHOCKEY Expires April 1999 [Page 3] INTERNET DRAFT IPP as a Facsimile Service November 1998 {Begin Quote} Traditional facsimile has a simple user operational model; the user 1) inserts paper into a device 2) dials a number corresponding to the destination 3) presses the 'start' button on the device 4) the sending device connects to the receiving device using the telephone network 5) the sending device scans the paper and transmits the image of the paper 6) simultaneously, the remote device receives the transmission and prints the image on paper 7) upon completion of transmission and successful processing by the recipient, the sending user is notified of success Although not usually visible to the user, the operation (5) of transmission consists of 5a) negotiation: the capabilities of the sender and recipient are exchanged, and suitable mutually acceptable parameters for the communication are selected 5b) scanning: creating digitized images of pages of a document 5c) compression: the image data is encoded using a data compression method 5d) transmission: the data is sent from one terminal to the other In addition, the termination of operations (5d) and (6) may be characterized as consisting of: 6a) completed delivery: the message has completed transmission 6b) completed receipt: the message has been accepted by the recipient 6c) processing and disposition: the message has been processed {End Quote} SHOCKEY Expires April 1999 [Page 4] INTERNET DRAFT IPP as a Facsimile Service November 1998 3.1 GENERAL REQUIREMENTS FOR FAX In addition to the above specifications there are additional requirements for Sender/Recipient Identification Exchange, time/date stamping, and optional "watermarking" of each page of the FAX transmission required by law in the United States and several other countries (see LEGAL ISSUES below). Of these specifications, there is a substantial body of market survey research (Pitney-Bowes/Gallup) that indicates that Confirmation/Receipt is considered the most useful feature of traditional fax. 3.1.1 CONFIRMATION REQUIREMENTS FOR FAX The end user requirements for confirmation and receipt must contain the information you typically find in the transaction report from a conventional fax machine or fax server. This includes, but is not limited to: 1. MUST record status of transaction (success, failure, cause of failure) 2. MUST record date and time of all attempts (log files recorded at each end by client and server locally) 3. MAY record Duration of call(s) 4. MAY record number of pages transferred 5. MUST exchange and record client or server identification As a general rule, end user expectations for an Internet Facsimile service are driven by the perceptions of, if not necessarily the reality of, traditional GSTN FAX. 3.2 IPP GOALS For Information on the IETF-IPP work group: http://www.pwg.org/ipp The document "Design Goals for an Internet Printing Protocol", draft-ietf-ipp-req-02.txt, June, 1998 [IPP-REQ] outlines the design goals for IPP and identifies some specific end user requirements. {quote} END-USER SHOCKEY Expires April 1999 [Page 5] INTERNET DRAFT IPP as a Facsimile Service November 1998 An end-user of a printer accepting jobs through the Internet is one of the roles in which humans act. The end- user is the person that will submit a job to be printed on the printer. The wants and needs of the end-user are broken down into six categories: finding/locating a printer, creating a local instance of a printer, viewing printer status, viewing printer capabilities, submitting a print job, viewing print job status, {end quote} 3.3 IPP - FAX - IFAX Based on the requirements of both an Internet Fax Service and the Internet Print Protocol it seems that on the most basic level their are significant similarities from the perspective of the end user. FAX/IFAX Message Addressing = IPP Finding/Locating a printer [URL Addressing] FAX/IFAX Message Creation = IPP Creating the Print File [Supported MIME Content Type or "Payload"] FAX/IFAX Message Transmission = IPP Submitting a Print-Job FAX/IFAX Message Confirmation (Receipt) = IPP Client Poll for Print-Job Status 4.0 OBSERVATIONS ON THE DIFFERENCES BETWEEN IPP and FAX/IFAX SERVICES 4.1 INTEROPERABILITY IPP has developed interoperability mappings to other print services, such as TLS, but it currently has no explicit methodology to allow supported IPP MIME Content-Types to interoperate with different fax services, such as SMTP or GSTN FAX. It is assumed that URL's could be devised to facilitate interoperability between these services. (see IPP TO GSTN GATEWAY CONCEPTS). An IPP transaction destined for a GSTN gateway might be addressed as: http://domain.com/ipp/FAX=13149189015 Where the number is a fully qualified ITU E.164 number conforming to the IFAX gateway specifications outlined in [RFC2304] and [RFC2305]. SHOCKEY Expires April 1999 [Page 6] INTERNET DRAFT IPP as a Facsimile Service November 1998 Further study will be necessary to investigate proper schemes for the addressing of gateways in an IPP environment. 4.2 DATA FORMATS (CONTENT PAYLOAD) IPP and FAX/IFAX take two fundamentally different approaches to the content payload of a message. FAX limits its content to the image files specified by the [T.30] protocol. IFAX limits its Content-Type to a highly defined set of TIFF images specified in RFC2301 and specifically limits Content-Type to a subset of TIFF defined in RFC2306 in the event that the capabilities of the recipient is not known in advance. The rational for this has been that TIFF has historically been used in the GSTN-FAX and that by defining a similar type of content for IFAX, the goal of service interoperability is advanced. IPP has none of these restrictions. IPP is limited only to Registered MIME Content-Types supported by of the output device or service preformed by the IPP server for the recipient. This is facilitated by content negotiation during the IPP session setup. IPP may wish to consider the mandated support of RFC2306 by both clients and servers as a Least Common Denominator to facilitate interoperability in a Facsimile Service Mode. 4.3 ADDRESSING Both IPP and IFAX use commonly understood addressing schemes well known among Internet users. IFAX uses SMTP addressing. IPP uses URL's. IPP has the ability to allow multiple URL's to access a single output resource such as: http://domain.com/ipp/rshockey http://domain.com/ipp/mickey_mouse http://domain.com/ipp/printer42 These separate addresses might output to a single printer in much the same way a single FAX number is available to several individuals. This capability is purely dependent on the implementation of the IPP server. SHOCKEY Expires April 1999 [Page 7] INTERNET DRAFT IPP as a Facsimile Service November 1998 4.5 CAPABILITIES EXCHANGE FAX devices negotiate and exchange capabilities during the call setup of T.30. Information is passed between devices through the use of highly defined "frames" of data. Such data exchange includes such attributes as page size, resolution, speed of transmission and identity of terminal devices (T.30-CSID). A severe limitation of the current IFAX service is the lack of any method by which Message User Agents can exchange capabilities in advance of sending a message. In such circumstances, the use of Least Common Denominators [RFC 2306] has been recommended in RFC 2305. Further work [EIFAX] is addressing those issues. IPP Protocols for reliable negotiation and download of unavailable printer drivers in IPP are currently out of scope for IPP V1.0, but it is assumed that subsequent versions of IPP will address this problem. The IETF and World Wide Web Consortium [www.w3.org] are looking at a variety of schemes to permit clients and servers to exchange data on capabilities. Work in the IETF is continuing in the CONNEG WG. 4.6 IDENTITY EXCHANGE The identity of senders and recipients in traditional FAX are achieved through the legal requirements for fax (see LEGAL ISSUES below) and the exchange of T.30 CSID frames between terminal devices "on the wire" during T.30 session negotiation. IFAX uses E-Mail header information to identify the sender to the recipient. The recipient has no requirement to exchange data. IPP has no formal capability to exchange identity data between sender and recipient, beyond the IPP URL. The use of [vCARD] in IPP to facilitate this should be considered. 4.7 TRACKING AND CONFIRMATION Traditional FAX uses In-Band monitoring to signal the sender when a document transmission has completed or report on any errors encountered. SHOCKEY Expires April 1999 [Page 8] INTERNET DRAFT IPP as a Facsimile Service November 1998 Both FAX sender and receiver have internal clocks that monitor the progress of that transaction and log the data in an appropriate manner. IFAX is currently developing a variety of options for tracking the progress and delivery of a document using standard Internet Mail methodologies such as Message Disposition Notification [MDN- RFC2289] and Disposition Service Notification [DSN-RFC 1891, RFC1894] IPP offers a comprehensive suite of attribute options for monitoring the success or failure of a Job-Submission. IPP Clients track and confirm the success or failure of Job-Submission by polling the IPP server for the status of a transaction, however polling the server for status by the IPP client is not mandated. The IPP work group is proceeding on a more advanced suite of Notification Attributes [IPP-NOT] to permit notification by a variety of means, such as E-Mail, on success or failure of Output of IPP Job after successful submission. 4.8 TIME/DATE INFORMATION FAX terminal devices all have internal clock devices for recording the time/date of transactions. Actual time information is not exchanged "on the wire". Each device notes when it sends and receives documents and logs those transactions locally. All E-Mail transactions have time/date information located in the E-Mail headers. IPP does suffer from the lack of an explicit requirement for time/date stamping of transactions by either client or server. This will severely limit its use as a facsimile service and transmissions will not meet the legal requirement [see LEGAL ISSUES below] for a "fax". It will be necessary for IPP implementers to consider the installation of real time clocks in their devices or use of Time Protocol or Daytime Protocol [RFC 867/868] to implement time/date stamping. 4.9 SECURITY, AUTHORIZATION AND AUTHENTICATION On the surface, it would seem that no one would want to make his or her printer available on the Internet. SHOCKEY Expires April 1999 [Page 9] INTERNET DRAFT IPP as a Facsimile Service November 1998 It should be noted, however, that we have globally accessible printers available now. They are just called fax machines. The use of IPP as both a Remote Printer application and as a Facsimile Delivery Service, may cause some confusion in the mind of end users on what is and what is not "acceptable use". IPP can use the security service available in Digest Authorization within in HTTP 1.1 [RFC2069] to authorize a client log in to a IPP server. Additional study on the behavior of IPP clients/servers is may be needed on what types of IPP transactions should be available to all outside users vs authorized users only. 5.0 IPP and FAX/IFAX PROTOCOL MAPPINGS NECESSARY FOR GATEWAY INTEROPERABILITY Though IPP has the functional attributes to be a facsimile service it may be necessary to consider interoperating with the existing GSTN FAX or IFAX service in the future. Detailed mapping of the various attributes and structures will be necessary. Fortunately considerable groundwork is being undertaken in the IETF FAX WG to describe and detail those attributes. Among the attributes that will need to be mapped: Architecture Data Formats (MIME Content-Types): Such as RFC 2301-RFC2306 Print Resolution: 100x200, 200x200, 400x400 etc Compression: MH, MR, MMR, JBIG, JPEG Page Counts Capabilities Discovery Error Codes The following documents describe ongoing work in the IETF-FAX work group that should be of considerable assistance in FAX/IPP attribute and syntax mapping: [CONNEG-FEATURE-SYNTAX] draft-ietf-conneg-feature-syntax-XX.txt. [FAX-SCHEMA] draft-ietf-fax-feature-schema-XX.txt. SHOCKEY Expires April 1999 [Page 10] INTERNET DRAFT IPP as a Facsimile Service November 1998 6.0 IPP ADVANTAGES AS A FACSIMILE SERVICE 6.1 CONTENT IPP offers the end user a rich set of options for the creation and delivery of documents. Essentially any Page Description Language [Printer Driver] supported by the recipients' server could process the transaction and output the document. Though there is no mandated Least Common Denominator for IPP Clients and Servers , there is also no functional limitation on IPP output. Were future versions of IPP to support the legal requirements for identification and time/date marking [see LEGAL ISSUES below] IPP would be perceived a facsimile service by end users. Once end users transmit documents across domains, the obvious similarity to traditional FAX should become self-evident. 6.2 NOTIFICATION AND RECIEPT [IPP-MOD] and [IPP-PRO] contain the basic facilities to be able to monitor the submission of an IPP-Job in real time. The current state of IPP Notification is not dissimilar to the function of [DSN] and [MDN]. Currently IPP V1.0 can monitor the submission of an IPP Job but it cannot notify the sender whether the job was actually processed. This is similar to the function of DSN in the SMTP service where notification takes place when the message reaches the "last hop" server but cannot notify the sender if or when the recipient picks up their mail via a MUA. MDN does provide actual notification when a message was viewed by the recipient and could be considered similar to current IPP work on notification of output status. IPP V.1 does not mandate the client polling of the server for status, however since notification and receipt are central requirements of any facsimile service, such polling would be a requirement for IPP when used in a Facsimile Service Mode. 6.3 POINT TO POINT ORIENTATION IPP has the advantage of being an "end to end" protocol. The end user experience, as well as the real time nature of IPP, is very similar to GSTN-FAX. SHOCKEY Expires April 1999 [Page 11] INTERNET DRAFT IPP as a Facsimile Service November 1998 6.4 ECONOMIC CONSIDERATIONS The use of IPP as a facsimile service offers end users significant economic advantages. Though GSTN Long Distance charges are continuing to drop, one of the most significant costs in FAX is the necessity to maintain dedicated and often expensive local lines. These charges, which average nearly US $30.00 per month [$360.00 yearly], and are significantly higher in Europe and Asia for business customers. These costs now represent one of the highest factors in calculating the Total Cost of Ownership of Fax. The attraction of IPP is that once the fixed cost of an IP Network have been implemented within an enterprise the incremental cost of adding additional IP application services to the Network is marginal. 7.0 IPP SHORTCOMINGS AS A FACSIMILIE SERVICE 7.1.1 IFAX GATEWAY CONCEPTS The concepts for gateways in IFAX are described in GOALS: a)Fax onramp gateway A device that can accept a facsimile telephone call and automatically forward it via the Internet b)Fax offramp gateway A device that can accept a transmission from the Internet and forward it to a traditional fax terminal [sender]-IPP->[offramp]-PSTNFax->[fax-term] With these concepts in mind, there is a potential role for IPP as a Gateway protocol to transport the documents across the Internet to multiple services. a)IPP onramp gateway A device or server that can accept an IPP document transaction from either a facsimile telephone call or an IFAX SMTP transaction. b)IPP offramp gateway A device or server than can accept an IPP transaction and forward it to either a GSTN FAX device or an IFAX SMTP transaction. SHOCKEY Expires April 1999 [Page 12] INTERNET DRAFT IPP as a Facsimile Service November 1998 c)IPP disconnected gateway A device or server that can accept an IPP transaction and forward it to an IPP output device that is periodically disconnected from the Internet 7.1.2 IPP GATEWAY SCENERIOS There could be several scenarios for the role of IPP in Gateways. [fax-term]-PSTNfax->[onramp]-IPP->[recipient] [fax-term]-PSTNfax->[onramp]-IPP->[offramp]-PSTNFax->[fax- term] [POP3Client]-SMTP-IPP_onramp->recipient [sender]-IPP_offramp->SMTP-[POP3Client] [sender]-IPP>IPP server>SMTP_offramp>[recipient] [sender]-IPP>IPP server>PSTN_offramp>[recipient] 7.2 TIME/DATE RECORDING IPP does not have explicit requirements or attributes to express time/date information within transactions or transaction logs. The time/date of FAX transactions are locally recorded by each FAX client/terminal. IPP clients and servers will have to begin recording such transactions. 7.3 IPP AUTOMATIC DRIVER DISTRIBUTION Currently there is lack of support for automatic printer driver distribution during an IPP transaction. Though no minimum printer driver format is specified in IPP, it would not be unreasonable for implementers to consider mandating support of standard RFC 2301 or RFC 2306 MIME Content-Types to facilitate universal interoperability as well as facilitate the use of IPP as a gateway to GSTN FAX or redirect job output to the SMTP IFAX service. SHOCKEY Expires April 1999 [Page 13] INTERNET DRAFT IPP as a Facsimile Service November 1998 7.4 INSTALLATION AND CONFIGURATION ISSUES The installation and configuration of an IPP service will require significant knowledge and expertise on the part of system administrators. It will be necessary to configure figure network firewalls to support the standard IPP port of 631. 8.0 LEGAL ISSUES The use of IPP as an Internet Facsimile Service must attempt to accommodate the legal requirements for GSTN facsimile. The legal use of FAX for document transmission and receipt is well understood in US Case Law. There is some evidence to suggest that Courts in the United States view the transmission of information and documents independently of the protocols and methodology used to achieve those means. The US Courts recognize that new technology is introduced very rapidly and that in many cases procedural rules have not kept pace. There is every reason to believe that if IPP is used in the context of a facsimile service and "best efforts" are taken to duplicate the "look and feel" of GSTN FAX and satisfy the legal requirements customary in FAX, IPP transactions will be accorded the full support and protection of law. 8.1 UNITED STATES LAW The United States Federal Communication Commission regulations and US Federal Law (47 USC 227) state: {quote} "Identification Required on Fax Messages The FCC's rules require that any message sent to a fax machine must clearly mark on the first page or on each page of the message: - the date and time the transmission is sent; - the identity of the sender; and - the telephone number of the sender or of the sending fax machine. SHOCKEY Expires April 1999 [Page 14] INTERNET DRAFT IPP as a Facsimile Service November 1998 All fax machines manufactured on or after December 20, 1992 and all facsimile modem boards manufactured on or after December 13,1995 must have the capability to clearly mark such identifying Information on the first page or on each page of the Transmission." {end quote} Of particular note is that there is no requirement that the marks for identifying information be placed on every page. The legal requirement is only for the first page, though it has become custom and practice among all FAX device manufacturers to include the "watermark" on each page transmitted. 8.2 WATERMARKING OF PAGES This marking of the pages in FAX is commonly referred to as "watermarking" of the transmission. These marks are typically placed at the top of each page of the fax transmission and contain time/date information, sender identification [typically T.30 CSID frame data] and page number information. The sender's device creates this data at the moment the transaction begins. The recipient output device does not modify the document once it is received. Though this requirement, and similar ones in many countries, applies only when the transmission occurs over the GSTN, it seems reasonable to assume that various national authorities will extend this requirement to the Internet as facsimile traffic is taken off the GSTN. IPP Facsimile Mode implementations will have to insert these watermarks into the supported PDL MIME Content-Type. 9.0 COVER PAGES Closely associated with the legal issues are the formats and requirements for cover pages. 9.1 TYPICIAL DATA Cover pages on facsimile transmissions typically contain the following data: SHOCKEY Expires April 1999 [Page 15] INTERNET DRAFT IPP as a Facsimile Service November 1998 Identification of Sender: Identification of Recipient: Time/Date of Transmission: Number of pages in Transmission: Comment Field: 9.2 IPP JOB SEPERATOR SHEETS IPP currently has a facility for the automatic generation of pages by the IPP server to separate Job-Submissions, however there are currently no IPP attributes that would permit IPP client definitions of the Job-Seperator sheets to conform to either the legal or general custom and practice of facsimile cover sheets. 10.0 COMMON FACSIMILIE CLIENT INTERFACE MODELS Most end user FAX interfaces fall within two categories. A client workstation device, typically a personal computer with a modem or attached to a LAN Fax server and appropriate software, or a client terminal device with some form of scanner imput. These terminal devices would be the typical fax machine or multifunction peripheral.However, the options available on these client interfaces have evolved in different ways because of the unique nature of the facsimile service. 10.1 CLASSIC FAX DEVICES Classic FAX terminal devices offer only a limited number of options for end users. Typically, these functions are for higher or lower resolution, gray scaling etc. It is assumed that the document to be faxed is already in paper form. In addition, they usually offer no options for automatic cover page generation since it is assumed that the end user will manually fill out some form of fax cover page and simply add it to the pages to be transmitted. The Classic FAX terminal device adds the legal "watermarks" to the top of each of the pages transmitted but in no other way alters the document. 10.2 FAX SOFTWARE Fax software has evolved differently. In addition to the usual options provided for resolution and gray scaling and the SHOCKEY Expires April 1999 [Page 16] INTERNET DRAFT IPP as a Facsimile Service November 1998 watermarking of pages, workstation fax software has traditionally offered options for automatic cover page generation, document management, alternate transmission times and a variety of other useful functions. The document transmitted is directly converted to fax form by the workstation application through the use of a special printer driver in much the same manner as IPP. It should be noted that there has been a substantial and active Computer Fax Industry for nearly 10 years. Market survey research has consistently shown that only 15% of total pages transmitted in North America are generated by workstations, and an even smaller percentage of faxes are received by workstations or LAN Fax Servers. 11.0 IPP CLIENT BEHAIVOR IN A FACSIMILE SERVICE MODE 11.1 IPP CLIENT BEHAIVOR IPP clients, in a facsimile service mode, need only duplicate the essential "look and feel" of GSTN FAX client/devices . IPP terminal devices with scanner input options could offer the option of watermarking each page of the document as is currently customary in FAX. IPP Client software could optionally offer Cover Page Generation and other features, as the market deems appropriate. No additional protocol requirement or burdens are necessary in IPP [IPP-MOD/IPP-PRO] itself. 11.2 IPP SERVER BEHAVIOR IPP attributes for time/date should be developed in order to permit IPP servers to properly log transactions in a facsimile service mode. Time/date recording is an essential part of notification. 12.0 CONCLUSIONS IPP has all of the functional elements to be a superior facsimile service over the Internet. It is superior to IFAX fax-over-SMTP [RFC2505] and superior to fax-over-H.323 [T.38] for both the end user and for the device implementor. It is a better FAX than GSTN FAX. It is my judgement that IPP transactions, once they cross domains, will be perceived by end users as a "facsimile service" irrespective of what the goals and objectives of the IPP protocol designers were. SHOCKEY Expires April 1999 [Page 17] INTERNET DRAFT IPP as a Facsimile Service November 1998 Getting a document from "here to there" over the wire will be perceived as "fax". It will not make any difference whether the transaction is GSTN FAX, SMTP, or IPP protocols. IPP can achieve the "look and feel" of FAX with the additions of time/date stamping of sender/recipient transaction logs by each local IPP device, IPP Client watermarking of each page of the transmission in the customary manner of FAX and cover page creation options in future IPP Client software or firmware. IPP has most of the functional specifications, as well as attributes necessary to successfully map to the existing RFC 2305 Internet Fax service through, at the very least support of RFC 2306 and optionally RFC 2301 Content-Types. 13.0 ACTION RECOMMENDATIONS Based on the concepts and conclusions discussed in this memorandum, work could commence to define IPP as a facsimile service and outline protocols for interoperability between IPP and GSTN FAX, as well as RFC2305 and its successors [EIFAX]. Several work items are recommended. A. Document Goals and Objective for the use of Internet Print Protocol as a facsimile service. B. Document IPP Client/Server Profile when used in a Facsimile Service Mode especially IPP enhancements necessary to support time/date stamping of all transactions. C. Document Gateway Protocol Mapping between IPP and FAX/IFAX for Onramps and Offramps. D. Document IPP to FAX/IFAX URL gateway syntax. E. Investigate possible requirement to support RFC2306 as a Least Common Denominator by IPP clients and servers when operating in a Facsimile Service Mode. F. Continue established work in IPP Notification enhancements. SHOCKEY Expires April 1999 [Page 18] INTERNET DRAFT IPP as a Facsimile Service November 1998 14.0 ACKNOWLEDGEMENTS The author would like to acknowledge the assistance of members of both the IETF FAX and IETF IPP work groups who have provided invaluable assistance and imput during the development of this document: Larry Masinter, Dan Wing, Carl-Uno Manros, Graham Klyne, Ron Bergman, and Brian Stafford. 15.0 REFERENCES [CONNEG-FEATURE-SYNTAX] G. Klyne, "A syntax for describing media feature sets", Internet Draft, Work in Progress, draft-ietf-conneg-feature-syntax-XX.txt. [FAX-SCHEMA] L. McIntyre, G. Klyne, "Content feature schema for Internet fax", Internet Draft, Work in Progress, draft-ietf-fax-feature-schema-XX.txt. [GOALS] L. Masinter, "Terminology and Goals for Internet Fax", Internet Draft, Work in Progress, draft-ietf-fax-goals-XX.txt. [EIFAX] L.Masinter, D.Wing, "Extended Facsimile Using Internet Mail" Work in Progress draft-ietf-fax-eifax-0X.txt October 1998 [FAX] [T.30] ITU-T, "Procedures for Document Facsimile Transmission in the General Switched Telephone Network", ITU-T, Recommendation T.30, July, 1996. [T.38] ITU-T, "Procedures for real time Group 3 facsimile communications over IP networks"" ITU-T Recommendation T.38, July 1998 [T.37] ITU-T, "Procedures for the transfer of facsimile data via store and forward on the internet", ITU-T Recommendation T.37, July 1998 [H.323] ITU-T, "Visual Telephone systems and equipment for local area networks which provide a non guaranteed quality of service", Recommendation H.323, November 1996 [E.164] ITU-T, "The international public telecommunications numbering plan"" Recommendation E.164/I.331, June 1997 [RFC 867/868] J. Postel, K. Harrenstien, "Daytime Protocol" RFC867, "Time Protocol" RF868, May 1983 SHOCKEY Expires April 1999 [Page 19] INTERNET DRAFT IPP as a Facsimile Service November 1998 [RFC1891] [DSN] K. Moore, "SMTP Service Extensions for Delivery Status Notifications", RFC 1891, January 1996. [RFC1893bis] [DSN] G. Vaudreuil, "Enhanced Mail System Status Codes",Internet Draft, Work in Progress, (update to RFC 1893). [RFC1894] [DSN] K. Moore, G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996. [RFC2298] [MDN] R. Fajman, "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998. [RFC2301] L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, J. Rafferty, "File Format for Internet Fax", RFC 2301, March 1998. [RFC2303] C. Allocchio, "Minimal PSTN address format in Internet Mail", RFC 3203, March 1998 [RFC2304] C. Allocchio, "Minimal FAX address format in Internet Mail", RFC 2304, March 1998 [IFAX] [RFC2305] K.Toyoda, H. Ohno, J. Murai, D. Wing, "A Simple Mode of Facsimile Using Internet Mail", RFC 2305, March 1998. [RFC2306] G. Parsons, J. Rafferty "Tag Image File Format (TIFF) - F Profile for Facsimile", RFC 2306 Status: Informational, March 1998 [RFC2069] J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A.Luotonen, E. Sink, L. Stewart, "An Extension to HTTP: Digest Access Authentication", RFC-2069, Jan 1997. [VPIM2] Vaudreuil, G., and G. Parsons, "Voice Profile for Internet Mail - version 2", RFC 2421, September 1998. [IPP-MOD] Isaacson, S., deBry, R., Hastings, T., Herriot, R., Powell, P. "Internet Printing Protocol/1.0: Model and Semantics" draft-ietf-ipp-mod-10.txt, Work In Progress, June, 1998. [IPP-PRO] Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing Protocol/1.0: Encoding and Transport", draft- ietf-ipp-pro-06.txt, Work In Progress, June, 1998. SHOCKEY Expires April 1999 [Page 20] INTERNET DRAFT IPP as a Facsimile Service November 1998 [IPP-REQ] Wright, D., "Design Goals for an Internet Printing Protocol", draft-ietf-ipp-req-02.txt, Work In Progress, June, 1998. [IPP-RAT] Zilles, S., "Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol", Work In Progress, draft-ietf-ipp-rat-03.txt, June, 1998 [IPP-NOT] deBry, R., "Requirements for IPP Notifications", Work in Progress, draft-ietf-ipp-not-01.txt, March 1998 [VCARD] M. Smith, F. Dawson, T. Howes, "A MIME Content-Type for Directory Information", RFC2425, September 1998. F. Dawson, T. Howes, rfc2426.txt - "vCard MIME Directory Profile", RFC2426, September 1998. Additional information at : http://www.imc.org/pdi/ 16.0 AUTHOR'S ADDRESS Richard Shockey Shockey Consulting LLC 8045 Big Bend Blvd Suite 100 St. Louis, MO 63119 Voice: 314.918.9020 Fax: 314.918.9015 Email/IFAX : rshockey@ix.netcom.com 17.0 COPYRIGHT Copyright (C) The Internet Society 1998. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet SHOCKEY Expires April 1999 [Page 21] INTERNET DRAFT IPP as a Facsimile Service November 1998 Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. SHOCKEY Expires April 1999 [Page 22]