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 Draft Date : Tuesday, October 20, 1998 Memorandum on the Use of IPP as a Facsimile Service ABSTRACT This memorandum discusses the use of the Internet Print Protocol as a facsimile service. IPP has all of the functional attributes necessary to be a successful realtime facsimile service on the Internet with little or no modification to the core IPP V 1.0 protocols. IPP compliance with the legal and general custom and practice surrounding GSTN fax will require some modification to the behavior of IPP clients and the common usage of time/date stamping on IPP transactions and logs. Interoperability with the current GSTN fax service and the IETF-FAX service can easily be achieved through support of RFC2306 and/or RFC2301 Content-Types and the use of commonly accepted addressing schemes for GSTN numbers in URL’s. IPP has the opportunity to support two major applications, remote printing and facsimile service delivery, in common usage within organizations and enterprises globally. GENERAL THOUGHTS Based on Larry Masinter’s presentation at the IPP [Internet Printing Protocol] WG meeting at IETF 42 I’ve taken the liberty of reporting and expanding upon his comments. The question raised was could IPP used as a facsimile service and is there reason to investigate what the functional and protocol mappings between IPP, traditional analog fax and current work in IETF Fax [RFC 2305] and its successors [EIFAX] might be. It is pretty clear that there is substantial overlap among the individuals and companies involved. After all most, fax machine vendors are also involved in printers, copiers and other MFP devices. I would be delighted to receive comments, additions, corrections, or flames etc on the thoughts contained herein. Facsimile (FAX) has a long 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 what elements of IPP which match those needs. This memorandum is a personal view of the current state of protocol development for facsimile services drafted in the hope that it might be useful to authors of further work in this area. It is my opinion that this work is NOT competitive to existing work in the IETF-FAX Work Group. It is quite complimentary. The IETF-FAX work is concentrated on store-and-forward fax using SMTP while IPP is realtime in nature. There is a need now and there will always be a need for two distinct types of facsimile service on the Internet. One that integrates with the existing E-Mail infrastructure in a Store and Forward model as well as a specific realtime point to point service. 1.0 OVERVIEW 1.1 TRADITIONAL FAX Traditional facsimile as defined by the ITU [T.30] as 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 a 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. 1.2 IETF FAX SERVICE For Information on IETF-Fax work: 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 model where MUA’s may often be disconnected from the network. The MUA may therefore be mobile and not specifically tied to a particular geographic location. IFAX adds significant functionality to facsimile services by integrating with other SMTP services, such as voice mail, 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 FAX WG defines some essential features for reporting and receipt notification using Disposition Service Notification – Message Disposition Notification [DSN-MDN], as well as some outlines for client/device capabilities negotiation. Future work within the IETF FAX WG will look at the behavior of IFAX Onramps and Offramps to the GSTN. 1.3 ITU FAX The ITU (International Telecommunications Union) has taken two approaches to defining an Internet Fax service. 1.3.1 ITU STORE-AND-FORWARD FAX In the first instance it has essentially adopted the body of IETF IFAX work [RFC 2301-2306 inclusive] and defined it as T.37. This is a highly significant achievement in that it represents the first time the ITU has directly referenced IETF documents and it established a procedural model for further IETF –ITU cooperation. This cooperation is continuing on the Store and Forward model. 1.3.2 ITU REALTIME FAX The ITU has also defined a “realtime” Internet fax standard as well, now documented as T.38. T.38 tunneles 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 realtime voice and video and is, in my judgement, overkill for a relatively simple application such as realtime confirmed document transmission (facsimile). Based on a considerable knowledge of the Computer Facsimile Industry it is my observation that 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 a “add on” to VoIP at very little incremental cost. 1.4 IS IPP A FAX SERVICE? For Information on IPP: http://www.pwg.org/ipp On the surface the Internet Printing Protocol seems to meet the minimal system functional specifications for a facsimile service. A. Creation B. Addressing C. Transmission D. Transmission Monitoring, Confirmation (Receipt) I will discuss in more detail below potential advantages and shortcomings of IPP as a facsimile service. 2.0 END USER REQUIREMENTS 2.1 IETF-FAX GOALS The document "Terminology and Goals for Internet Fax" [GOALS] produced by the IFAX WG provides a general system functional requirements for an Internet Fax service. To Quote directly from GOALS: {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} In addition to the above specifications there is an additional requirement for Sender Identification, time/date stamping and optional “watermarking” of each page of the transmission currently required by law in United States and several other countries (see LEGAL) Of the these specifications there is a substantial body of market survey research (Pitney-Bowes/Gallup) that indicates that Confirmation or Receipt are considered the most useful features of traditional fax. However what constitutes a “destination”, a specific individual or location where the recipient is known to accept messages, is subject to a debate over terminology. There are similar questions about what constitutes receipt or acknowledgement in a facsimile service. Is receipt simply the confirmation of transmission from end point to end point, or is it the physical delivery of the message to the intended recipient. If the message is successfully transmitted but could not be processed by the end point, has the message been successfully sent? There are a variety of other perceptions of what constitutes a facsimile service that must be taken into consideration. Many end users assume, for instance, that is you put a sheet of paper into a fax machine and begin transmission that that sheet of paper received at the other end at exactly the same time. In other words as one raster run is scanned it is coming out the recipients machine. The reality is, however, that with many fax machines there is momentary storage before printing or in the case of LAN Fax servers printing does not occur until the entire file is received and delivered to a network print queue. In any event, it is my judgement that end user expectations for an Internet Facsimile service are driven by the perceptions of, if not necessarily the reality of, traditional GSTN FAX. 2.2 IPP GOALS 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 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} 2.3 IPP – FAX - IFAX Based on the functional goals of both an Internet Fax Service and a Internet Print Protocol it seems that on the most basic level there is functional equivalence from the perspective of the end user. FAX/IFAX Message Addressing = IPP Finding/Locating a printer FAX/IFAX Message Creation = IPP Creating a Instance for a Printer FAX/IFAX Message Transmission = IPP Submitting a Print-Job FAX/IFAX Message Confirmation (Receipt) = IPP Viewing Print-Job Status 3.0 FUNCTIONAL MATRIX OF FAX – IFAX – T.38 – IPP PROTOCOLS The following table attempts to map the specific operational protocols of the four models of facsimile transmission. GSTN- FAX IFAX ITU –T.38 IPP Addressing E.164 E-Mail address IP Server Name IPP - URL Protocol T.30 SMTP H.323 – and RTP HTTP 1.1 “POST” Negotiation Capabilities T.30 (DIS>DCS) TBD – Directory Services? T.30 (DIS>DCS) IPP Get- Printer- Attributes or Validate- Job Allowable Content T.30 Specified RFC 2301 TIFF-FX T.30 Specified Any MIME format supported by printer or output option Minimum Supported Content Image TIFF T.30 Specified RFC 2306 TIFF Profile F Image TIFF T.30 Specified None Specified Sender ID T.30 CSID or Cover Page Legally REQ E-Mail addresses T.30 CSID Job- Originating- User-Name (Operation Attribute)? Compression MH-MR-MMR Supported InBand Negotiated MH-MR-MMR Supported MH-MR-MMR Supported InBand Negotiated Printer Supported (Printer Description Attribute) Security Circuit Network Unspecified Any Supported Mechanism ???? TLS,DAA, SSL3 Transmission Direct Point to Point 2 hops from sender to recipient Direct Point to Point Network Point to Point Status Reporting - Tracking InBand T.30 Monitoring MDN – DSN (support forthcoming) InBand T.30 Monitoring Notification -Work in Progress Gateway Addressing N/A RFC 2303 RFC 2304 Somewhere in H.323 URL Notification & Confirmation InBand T.30 Monitoring (EOM)End of Message MDN - DSN InBand T.30 Monitoring Notification Time Date Stamp (needs work) Error Coding T.30 SMTP T.30 IPP-HTTP Specific Codes 4.0 DESCRIPTIVE MAPPING OF IPP and IFAX SERVICES 4.1 FUNCTIONALITY The essential functionality of an Internet Fax service and IPP are the same. Both attempt to describe a service that uses Internet protocols to transport document content from point to point in a manner that can be easily and transparently printed to paper. By restricting the allowable set of Content-Types available IFAX facilitates display as well as output to paper. 4.2 INTEROPERABILITY IPP and the requirements for an Internet Fax both specify the independence of the protocols on the underlying operating system of either the client or server. As the document GOALS recommends: “As with most Internet application protocols, interoperability must {1} be independent of the nature of the networking link, whether a simple IP-based LAN, an internal private IP networks, or the public Internet. The standard for Internet Fax must {1} be global and have no special features for local operations.” What is lacking in both IFAX and IPP is a clear and explicit method of service interoperability that would allow for the content payloads to be transported from the IFAX service to the IPP service or from the IPP service to FAX and or IFAX.(see IPP TO GSTN GATEWAY CONCEPTS). 4.3 RELIABILITY The current IFAX service suffers from the inability of a sender to accurately predict the capabilities or preferences of the recipient in advance of sending the message. This deficiency is inherent in the SMTP service. For IFAX to be come truly reliable it will be necessary for senders to access some form of stored information about a recipient. Typically this would be some form of directory. IPP on the other hand suffers from the difficulty that the sender may not have the appropriate printer driver necessary to create the payload to the IPP server and that it be must be down loaded prior to transmission. In the future, this could potentially expose the sender’s device to corrupted or corruptible printer driver. In addition the sender device may not have sufficient local storage available to handle multiple printer driver’s and consequently must reload the driver every time transmission is attempted. 4.4 DATA FORMATS (CONTENT PAYLOAD) IPP and IFAX take two fundamentally different approaches to the actual content payload of a message. IFAX limits its Content-Type to a highly defined set of TIFF images specified in RFC 2301 and specifically limits Content-Type to a subset of TIFF defined in RFC 2306 in the event that the capabilities of the recipient is not known in advanced. The rational for this has been that TIFF has historically been used in the GSTN-FAX and by defining a similar type of content for IFAX the goal of service interoperability is advanced. The limitation of this approach is that it arbitrarily defines a series of attributes for that content type which may or may not meet end user expectations for a facsimile service. In addition since the IFAX service has explicit means by which it can operate with Gateways to the PSTN it must have a means of accepting some form of Least Common Denominator Content-Type [RFC 2306] acceptable to legacy fax machines. IPP has none of these restrictions. IPP is limited only by the capabilities 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 could be characterized as a recipient driven technology. The recipient ultimately decides how the document is to be rendered for output. Were directory services implemented in a IPP environment senders could optionally search for printers that matched specific output requirements. 4.5 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. 4.6 ROUTING (IPP REDIRECTION?) No formal capability now exists in IPP to interoperate with different services whether it is SMTP or GSTN FAX. It is assumed that URI’s could be devised to facilitate interoperability between these services. For instance 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 Further study will be necessary to investigate proper schemes for the addressing of gateways in an IPP environment. 4.7 CAPABILITIES The traditional GSTN-FAX service and IFAX suffer from the severe restraint of limited content types available for transmission [RFC2301 and RFC 2306]which limit the quality of potential output. 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. http://www.ietf.org/html.charters/conneg-charter.html W3 Document: TITLE: “Composite Capability/Preference Profiles (CC/PP): A user side framework for content negotiation” 4.8 TRACKING CONFIRMATION Traditional FAX uses In-Band monitoring to signal the sender when a document transmission has completed or report on any errors encountered. 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 Message Disposition Notification [MDN-RFC xx] and Disposition Service Notification [DSN-RFCxx] IPP offers a comprehensive suite of attribute options for monitoring the document transaction both in its “Job Queue” and during actual processing. Included is the ability to cancel or modify the transaction at any point. 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] for a “fax”. It will be necessary for IPP implementers to consider the installation of realtime clocks in their devices or use of RFC 867/868 to implement time/date stamping. 4.9 SECURITY In the entire IPP document [IPP-MOD] there is one reference to IPP as a possible model as a facsimile service. {begin quote} 8.1.2 Client and Server in Different Security Domains Examples of this environment include printing a document created by the client on a publicly available printer, such as at a commercial print shop; or printing a document remotely on a business associate's printer. This latter operation is functionally equivalent to sending the document to the business associate as a facsimile. Printing sensitive information on a Printer in a different security domain requires strong security measures. In this environment authentication of the printer is required as well as protection against unauthorized use of print resources. Since the document crosses security domains, protection against eavesdropping and document tampering are also required. It will also be important in this environment to protect Printers against "spamming" and malicious document content. {end quote} It would be very easy to rewrite this paragraph for both the GSTN- FAX and the IFAX service. It could easily apply to the whole of the SMTP mail service. The transmission of sensitive information requires a variety of security measures for it to be reliable, however there is the expatiation that should IPP be used as a facsimile service there will be public access to these resources. We put fax numbers on business cards and general correspondence in the expatiation (or hope) that senders will use the resource that is made available to them. If you put an IPP URL on your business card, then people will, in theory, use it. 4.10 AUTHORIZATION AND AUTHENTICATION On the surface it would seem that no one would want to make his or her printer available on the Internet. A general discussion of IPP transaction authentication is beyond the scope of this document. 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”. What types of IPP transactions should be available to all outside users? Some study and discussion on the behavior of IPP servers in these environments is needed. It may also be possible to extend the various national laws on unauthorized “Junk Fax” to IPP transactions. 4.11 IPP Firewall Access [MORE WORK] 5.0 DESCRIPTIVE MAPPING OF SELECTED IPP and IFAX PROTOCOL MECHANISMS 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. The following documents describe ongoing work in this area that is due for completion before the end of the year. ftp://ftp.ietf.org/internet-drafts/draft-ietf-fax-reporting-extensions-03.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-fax-feature-T30-mapping-00.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-fax-feature-schema-00.txt Attributes that will need to be mapped include: Architecture Data Formats (Content Payload) Document Format: Print Resolution: Compression: Page Counts: Tracking Confirmation: Capabilities Discovery Error Codes 6.0 IPP ADVANTAGES AS A FACSIMILIE SERVICE - IMHO 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. Were future versions of IPP to support the legal requirements for identification and time/date marking [see LEGAL] it is my belief that IPP would be perceived a facsimile service by end users. Once IPP end users commonly cross domains with transactions the obvious similarity to traditional FAX should become self evident. Though no minimum printer driver format is specified in IPP it would not be unreasonable for implementers to consider or the development of a standard RFC 2301 or RFC 2306 printer driver as a feature should there be a need for IPP to act as a gateway to GSTN FAX or redirect job output to the SMTP IFAX service. In this case the server would notify the IPP client that this is as IFAX transaction and specify the particular type of output to file rather than to a physical printer. Once the file was on the server it would be available for redirection to some other form of Internet Fax service or displayed to screen etc. 6.2 FEATURE NEGOTIATION IPP excels in feature negotiation over all other forms of facsimile services with the eventual benefit of the ability to download during the transaction a non available printer. 6.3 OUTPUT OPTIONS Though the default minimum output options would be for one copy of the document the added ability to ask for copies is certainly an added plus. 6.4 NOTIFICATION AND RECIEPT Based on a simple reading of [IPP-MOD] and [IPP-PRO] all the facilities exist for being able to both monitors the IPP-Job in real time as well as report on the status of the IPP-Job upon completion. It seems clear that an implementor could specify the means of output for such a report or “receipt of Job Completion” that could include display, stored for future reference as well as hard copy output similar to the functionality of many GSTN-FAX machines. 6.5 DEVICE POINT TO POINT ORIENTATION IPP also has the advantage of being an end to end protocol. The end user experience as well as expatiation of IPP is very similar to GSTN-FAX in that you experience something like “ Well it goes in here and comes out there.” 6.6 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, 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 - IMHO 7.1 IPP GATEWAY CONCEPTS IPP does not currently specify any form or function that might allow it to be used as a gateway to either the IFAX or GSTN FAX service. 7.1.1 The concepts for gateways in IFAX are quite simple as GOALS describes: Fax onramp gateway A device that can accept a facsimile telephone call and automatically forward it via the Internet 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. IPP onramp gateway A device or server that can accept a IPP document transaction from either a facsimile telephone call or a IFAX SMTP transaction. IPP offramp gateway A device or server than can accept a IPP transaction and forward it to either via a facsimile telephone call or a IFAX SMTP transaction. IPP disconnected gateway A device or server that can accept a IPP transaction and forward it to a IPP output device that is periodically disconnected from the Internet 7.1.2 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] Etc. Etc. [NEEDS WORK] 7.2 LOGS – RECIEPT – ACKNOLEDGEMENT Requirements for detailed receipt and acknowledgement logs needs to be explored and the means and methodology by which those protocol acknowledgements are time/date stamped. The necessity for maintaining such accurate records by IPP senders and recipients is heightened since there will be no 3rd party telephone records available to confirm the transaction 7.3 IPP AUTOMATIC DRIVER DISTRIBUTION Currently there is lack of support for automatic printer driver distribution during a IPP transaction. It is assumed that this will be IPP V.2 issue. 7.4 INSTALLATION AND CONFIGURATION ISSUES The installation and configuration of an IPP service will require significant knowledge and expertise of the part of system administrators. In addition there is evidence that large percentages of enterprises under 50 employees do not have direct connections to the internet. 7.5 FALL BACK OPTIONS If IPP service unavailable, what do you do then? Does client “fall back” to SMTP, GSTN? [NEEDS WORK] 7.6 DISCONNECTED IPP SERVICE BUREAUS One of the interesting ways IPP could use the SMTP service is to facilitate IPP transactions to disconnected service bureaus. In this scenario a centralized IPP server could receive IPP transactions for a series of service bureaus that do not have direct connections to the Internet. The IPP onramp could accept the transaction and the print stream including any payment or output options and store the print stream and output instructions in a Multi-Part MIME attachment scheme. There have been suggestions that IETF draft-freed-bsmtp-02.txt might be useful in this context. The designated service bureau would then periodically poll for “Jobs”, download the print stream, output options and then execute appropriately. 8.0 LEGAL ISSUES The use of IPP as an Internet Facsimile Service must attempt to accommodate the legal requirements for facsimile, and attempt to support functionality similar to that legally required even for devices that do not operate over the GSTN. The legal use of FAX for document transmission and receipt is well understood in U.S. Case law. To my knowledge there has never been a case litigated in North America that established the validity of either MDN, DSN or any other IETF message protocol as being legally acceptable. This should be of concern to those considering IFAX, T.38 as well as IPP for document transmission. 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. 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 place 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 refered 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. This data is created by the sender 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. There is some evidence to suggest that in 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 appropriate care is taken to duplicate the “look and feel” of GSTN FAX and that “best efforts” have been taken to satisify the legal requirements, IPP transactions will be accorded the full support and protection of the law. 8.3 FUTURE OPTIONS - IDENTIFICATION Though not a specific legal requirement, future IPP work might consider extensions to the protocol for the transmission of Advanced Sender Identification to the recipient such as a VCARD. For more information on VCARD see: http://www.imc.org/pdi/ 9.0 COVER PAGES Closely associated with the legal issues are the format and requirements for cover pages and the time date stamping of transactions in a facsimile service. Perhaps a cover page might be data contained in Operation Attribute “job-media-sheets” 9.1 TYPICIAL DATA Cover pages on facsimile transmissions typically contain the following data: Identification of Sender: Identification of Recipient: Time/Date of Transmission: Number of pages in Transmission: Comment Field: 9.2 DECLARATIONS AND ADMONITIONS While universally used as a practical separation of transmissions Cover pages are also used to declare various admonitions, warnings and disclaimers that have serious legal implications in the transmission of documents from point to point. A typical warning common on many fax transmissions in the legal profession would be: “The information contained in this facsimile is confidential and intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copy of this communication is strictly prohibited. Dewey, Dickem & Howe, LLC will accept no responsibility or liability in respect to this facsimile other than to the addressee. If you have received this communication in error, please notify us immediately by telephone at 777 231-4567 or by email. Thank you.” 9.3 RECOMMENDATION FOR FUTURE IPP CLIENTS In my judgement, cover sheet generation as well as the customary “watermarking” of fax pages with time/data and page number information could be undertaken by advanced IPP client software. In this environment a end user could optionally select “facsimile service” as an IPP client option and the client could then offer a selection of options for cover page generation or watermarking similar to the functional operation of fax software in wide use today. 10.0 COMMON CLIENT INTERFACE MODELS All forms of facsimile service FAX/IFAX do not specify a particular type of User Agent or Client. The same is the case with IPP. 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 of these client interfaces have evolved in different ways because of the unique nature of the facsimile service. 10.1 CLASSIC FAX 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 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 PC’s or LAN Fax Servers. The reasons for this are numerous, but it should indicate the enormous strength and positive perceptions surrounding traditional FAX terminal devices. 10.3 IPP CLIENT BEHAIVOR IN A FACSIMILIE SERVICE MODE There is no reason to assume that IPP clients, workstations or terminal devices should behave any differently when used in a facsimile service mode. IPP clients need only duplicate the essential “look and feel” of FAX. IPP terminal devices with scanners input options would 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 [MOD/PRO] itself. Should IPP be used as a gateway to either the GSTN FAX or IFAX services, additional protocol requirements would be necessary. 11.0 IFAX SHORTCOMINGS AS A FACSIMILIE SERVICE The most obvious shortcoming of the IFAX as a facsimile service is that it is essentially a Store & Forward service and does not provide the sender with the immediacy of transmission and response that is the central feature of GSTN-FAX. IFAX requires the use of SMTP mail names and ergonomically correct keyboards are not a standard feature on the current generation IFAX machines. Although a substantial proportion of the use of IFAX is considered to be from or to the Desktop PC there is a substantial lack of RFC 2306 or RFC 2301 viewers or printer drivers incorporated into the standard OS platforms or Email applications. 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. 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 simple additions of time/date stamping of sender/recipient transaction logs, 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 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 protocols. There is every reason to believe that a concerted effort to integrate the two technologies could yield substantial benefits to end users. 13.0 ACTION RECOMMENDATIONS Based on the concepts and conclusions discussed in this memorandum work within the IPP Work Group could commence to define IPP as a facsimile service and outline protocols for interoperability between IPP and GSTN FAX as well as RFC2302 and its successors [EIFAX work in progress]. Several documents seem appropriate A. Goals and Objective for the use of Internet Print Protocol as a facsimile service. B. IPP Client Profile when used in a Facsimile Service Mode C. Gateway Protocol Mapping between IPP and FAX/IFAX. D. IPP to FAX URL gateway syntax. A separate mailing list for IPP2IFAX work could be established and an open invitation to members of the IFAX WG to participate extended. 14.0 REFERENCES [GOALS] L. Masinter, "Terminology and Goals for Internet Fax", Internet Draft, Work in Progress, draft-ietf-fax-goals-XX.txt. [T.30] ITU-T (CCITT), "Procedures for Document Facsimile Transmission in the General Switched Telephone Network", ITU-T (CCITT), Recommendation T.30, July, 1996. [T.38] ITU-T (CCITT), ?????? [H.323] ITU ????? [E.164] ITU ???? [RFC 867/868] Simple Network Time Protocol? [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 [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 [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, 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, June, 1998. [IPP-REQ] Wright, D., "Design Goals for an Internet Printing Protocol", draft-ietf-ipp-req-02.txt, June, 1998. [IPP-RAT] Zilles, S., “Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol”, draft-ietf-ipp-rat-03.txt, June, 1998 [VCARD]+ [VCALENDAR]: http://www.imc.org/pdi/ PAGE 19 RICHARD SHOCKEY/IPP2IFAX04.txt October 20, 1998