Richard Shockey Shockey Consulting LLC 8045 Big Bend Blvd Suite 100 St. Louis, MO 63119 Voice 314.918.9020 Fax 314.918.9015 Email/EFAX rshockey@ix.netcom.com Draft Date Friday, September 18, 1998 Memorandum on the Use of IPP as a Facsimile Service Requirements and Protocol Mapping 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 to see how IPP could be used as a facsimile service and investigate what the functional and protocol mappings between IPP and current work in Internet Fax [RFC 2305 ] might be. Should interest in this area build, it might be appropriate to establish a separate mailing list for discussion as not to distract the FAX or IPP WG’s from their current work. 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. It is my belief that further work in this area should be divided into two distinct areas. One document exploring the operational and marketing aspects of IPP as a facsimile service, opportunities for IPP and Internet Fax integration and another separate document that would map appropriate protocols between IPP and RFC 2305 and current IETF-FAX work on extending RFC 2305 [fullmode-eifax]. I would be delighted to receive comments, additions, corrections, flames etc on the thoughts contained herein. GENERAL THOUGHTS 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. At the IPP WG meeting there was some discussion of putting together a Informational Draft in this area. 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 such a proposed draft. 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 on store-and-forward fax using SMTP while IPP is realtime and would provide no integration with universal messaging and would require realtime transmission (instead of store-and-forward). There is a need now and there will always be a need for two distinct types of facsimile service. One that integrates with the existing E-Mail infrastructure in a Store and Forward model as well as a specific point to point service. 1.OVERVIEW 1.1 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 ITU E.164. The content types specified by T.30 are highly restricted due to the lack of available bandwidth available on the analog GSTN. 1.2 The Internet Fax service (EFAX)[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. EFAX 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 [DSN-MDN], as well as some outlines for client/device capabilities negotiation. Future work within the FAX WG will look at the behavior of EFAX Onramps and Offramps to the GSTN. 1.3 The ITU (International Telecommunications Union) has taken two approaches to defining an Internet Fax service. In the first instance it has essentially adopted the body of IETF EFAX 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. The ITU has also defined a “realtime” Internet fax standard as well, now documented as T.38. T.38 defines a methodology by which the T.30 protocol is tunneled 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, im 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” at very little incremental cost. 1.4 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 The document "Terminology and Goals for Internet Fax" [GOALS] produced by the EFAX 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 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. A typical end user question might be, “Did the message get to its destination?” 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 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 works 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 a Internet Fax service are driven by the perceptions of, if not necessarily the reality of, GSTN FAX. Any attempt at a “Goals and Objectives for Internet Printing Protocol as a Internet Fax Service” should bear in mind these considerations. 2.2 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, altering the attributes of a print job. {end quote} 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. EFAX Message Addressing = IPP Finding/Locating a printer EFAX Message Creation = IPP Creating a Instance for a Printer EFAX Message Transmission = IPP Submitting a Print-Job EFAX Message Confirmation (Receipt) = IPP Viewing Print-Job Status 3.0 FUNCTIONAL MATRIX OF FAX – EFAX – T.38 – IPP PROTOCOLS The following table attempts to map the specific operational protocols of the four models of facsimile transmission. I’ve included all the ones that I can recall. If I have made any errors please let me know. GSTN- FAX EFAX ITU –T.38 IPP Addressing E.164 RFC 822 IP Server Name IPP - URL Protocol T.30 SMTP H.323 – RTP HTTP 1.1 “PUSH” Negotiation Capabilities T.30 (DIS>DCS) TBD – Directory Services ? T.30 Printer Formats Specified Allowable Content T.30 Specified RFC 2301 TIFF-FX T.30 Specified Any W/Capability 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 RFC 822 T.30 CSID Print-Job Request Attributes ? Compression MR or MMR InBand Negotiated M-MR-MMR Supported Printer Supported Protocols Printer Supported Protocols Security Circuit Network S-MIME ?? ???? TLS Auth Transmission Direct Point to Point 2 Step from MUA to MTA to MUA Direct Point to Point Direct Point to Point Status Reporting - Tracking InBand T.30 Monitoring MDN – DSN (in development) T.30 Monitoring Poll for Job State ?? Gateway Addressing N/A RFC 2303 RFC 2304 Somewhere in H.323 N/A Job Redirection Notification & Confirmation InBand T.30 Monitoring (EOM)End of Message MDN - DSN InBand T.30 Monitoring ??? Begin Job - End Job? Time Date Stamp? Error Coding T.30 SMTP T.30 [IPP-MOD] Specified X.0 DESCRIPTIVE MAPPING OF IPP to EFAX SERVICE REQUIREMENTS 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 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 EFAX facilitates display as well. Interoperability IPP and the requirements for an Internet Fax both specify the independendence of the protocols on the underlying operating system of either the client or server. As 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 EFAX and IPP is a clear and explicit method of service interoperability that would allow for the content payloads to be transported from the EFAX service to the IPP service or from the IPP service to EFAX.(see IPP TO GSTN GATEWAY CONCEPTS). Versatility The assumptions of versatility in a service are that they can operate over a variety of configurations and situations using a variety of clients, devices or servers. All the form of facsimile service have been shown to operate on platforms of various capabilities. Reliability The current EFAX 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 EFAX 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 PDL necessary to transport the payload to the server and that it be must be down loaded prior to transmission and potentially expose the senders device to corrupted or corruptible PDL. In addition the sender device may not have sufficient local storage available to handle multiple PDL’s and consequently must reload the PDL every time transmission is attempted. Data Formats (Content Payload) IPP and EFAX take to fundamentally different approaches to the actual content payload of a message. EFAX limits its Content-Type to a highly defined set of TIFF images specified in RFC 3201 and specifically limits Content-Type to a subset of TIFF defined in 3206 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 specific type of content for a facsimile service 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 EFAX 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 acceptable to legacy fax machines. IPP has none of these restrictions. IPP is limited only by the capabilities of the PDL of IPP server of the recipient. This is facilitated by content negotiation during the IPP session setup. If the sender does not have the appropriate PDL available for the recipients’ server it can be down loaded. Were directory services implemented in a IPP environment senders could search for printers that matched specific output requirements. Addressing Both IPP and EFAX use commonly understood addressing schemes well known among internet users. EFAX uses SMPT addressing and RFC 822 envelopes Routing (IPP redirection?) [NEEDS WORK] Capabilities – Upgrade Possible The traditional GSTN-FAX service and EFAX suffer from the severe restraints put on it by the limited content types available for transmission [RFC2301 and RFC 2306] which limit the quality of of potential output. IPP has no such restriction since it is only limited by the capabilities of the recipient’s output device which, in theory could be upgraded over time to other output devices that have higher resolution or greater color density options or the ability to bind or output the document in various forms. Tracking Confirmation Traditional FAX uses IN-Band monitoring to signal the sender when a document transmission has completed or report on any errors encountered. EFAX 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 are the ability to cancel or modify the transaction at any point. 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 EFAX 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 a IPP URL on your business card, then people will use it. Authentication There are clearly instances where there is a need to authorize a document transaction. [MORE WORK] x.0 DESCRIPTIVE MAPPING OF SELECTED IPP and EFAX PROTOCOL MECHANISMS [Authors note .. this is the area that needs substantial work.. and Don Bergman’s text ftp://ftp.pwg.org/pub/pwg/ipp/new_IPP-IFax/980820-ipp-ifax.txt Looks like a place to start.] Rather than attempt a comprehensive mapping of IPP attributes to EFAX or GSTN-FAX protocols. The following is a selected list that would be necessary to facilitate IPP to EFAX service interoperability. Architecture IPP introduces the object concepts of a “Printer” and a “Job”. Similar to LAN FAX server models. {begin quote} For a Printer object: Print-Job (section 3.2.1) REQUIRED Print-URI (section 3.2.2) OPTIONAL Validate-Job (section 3.2.3) REQUIRED Create-Job (section 3.2.4) OPTIONAL Get-Printer-Attributes (section 3.2.5) REQUIRED Get-Jobs (section 3.2.6) REQUIRED For a Job object: Send-Document (section 3.3.1) OPTIONAL Send-URI (section 3.3.2) OPTIONAL Cancel-Job (section 3.3.3) REQUIRED Get-Job-Attributes (section 3.3.4) REQUIRED Addressing [NEEDS WORK] Transport [NEEDS WORK] Data Formats (Content Payload) The most significant difference between EFAX and IPP is the point at which the payload is rendered into a format suitable for transmission In EFAX the Content Type is preselected from the avaiable options in RFC 3301 before transmission. In IPP the payload is not rendered for transmission until after there has been negotiation between client and server. Document Format: From [IPP-MOD] {begin quote} 4.1.9 'mimeMediaType' – “The 'mimeMediaType' attribute syntax is the Internet Media Type (sometimes called MIME type) as defined by RFC 2046 [RFC2046] and registered according to the procedures of RFC 2048 [RFC2048] for identifying a document format.” {end quote} Print Resolution: [NEEDS WORK] Compression: [NEEDS WORK] Page Counts: [NEEDS WORK] Tracking Confirmation: [NEEDS WORK] Capabilities Discovery [NEEDS WORK] 3.1.6 Operation Status Codes and Messages for Job Objects X.0 COMMON CLIENT INTERFACE MODELS All forms of facsimile service do not specify a particular type User Agent. Imput: Scanner Client Terminal (Printer Drivers) Output: Display Print Store X.0 IPP ADVANTAGES AS A FACSIMILIE SERVICE - IMHO 4.1 CONTENT - IPP offers the end user a rich set of options for the creation and delivery of documents. Essentially any Page Description Language [PDL] supported by the recipients’ server could process the transaction and output the document. Though no minimum PDL format is specified in IPP it not be unreasonable for implementers to consider or the development of a standard RFC 2301 conversion engine as a standard feature set should demand warrant. In this case the client would notify the IPP server that this is as EFAX transaction and specify the particular type of output. Normal “Output to Paper” or “Output to File” with the appropriate EFAX TIFF Profile specified by the client. 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. 4.2 FEATURE NEGOTIATION – IPP excels in feature negotiation over all other forms of facsimile service with the benefit of the ability to download during the transaction a non supported PDL. 4.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. The implications for Output Options and distribution lists should be explored 4.4 NOTIFICATION AND RECIEPT - Based on a simple reading of [IPP- MOD] and [IPP-PRO] all the facilities exist for being able to both monitor the IPP-Job in real time as well as report on the status of the IPP-Job upon completion. It seems clear that a implementer 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. I’m assuming there is Time Date stamping in all IPP-Job transactions as well. 4.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.” Of course what “there” is another semantics debate. 4.6 CLIENT-ADMINSTATOR CONTROL 4.6 EXTINSIBILITY - ATTRIBUTES 5.0 IPP SHORTCOMINGS AS A FACSIMILIE SERVICE - IMHO 5.1 IPP GATEWAY CONCEPTS IPP does not specify any form or function that might allow it to be used as a gateway to either the EFAX or GSTN FAX service. There is a discussion of the concept of “redirection” in the IPP documentation [IPP-MOD], however this technique was deemed out of scope for IPP 1.0. 5.1.1 The concepts for gateways in EFAX 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 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 EFAX 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 EFAX 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 5.1.2 There could be several scenarios for the role of IPP in Gateways. [fax-term]-PSTNfax->[onramp]-IPP->[recipient] [sender]-IPP->[offramp]-PSTNFax->[fax-term] [fax-term]-PSTNfax->[onramp]-IPP->[offramp]-PSTNFax->[fax- term] [POP3Client]-SMTP-IPP_onramp->recipient [sender]-IPP_offramp->SMTP-[POP3Client] Etc. Etc. [NEEDS WORK] x.x 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. The designated service bureau would then periodically poll for “Jobs”, download the print stream and output options and then execute appropriately. 5.2 LEGAL ISSUES The use of IPP as an Internet Fax Protocol should 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 EFAX, T.38 as well as IPP for document transmission. The United States Federal Communication Commission regulations and US Federal Law (47 USC 227) state: "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." 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 other networks as facsimile traffic is taken off the GSTN. Future IPP work should consider extensions to the protocol for the transmission of Sender Identification to the recipient. Perhaps a VCARD included in the Job Ticket? [NEEDS WORK] 5.2.1 COVER PAGES Closely associated with the legal issues are the format and requirements for cover pages in a facsimile service. This might be Operation Attribute “job-media-sheets” 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: 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.” Elements of the IPP Attributes [IPP-MOD 3.2.1.1 and 4.3.19] for inclusion in the “media-job-sheets” should be considered. 5.3 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. 5.4 Distribution Lists Mapping to a “Broadcast Fax” like service? ? 5.5 Fall Back Options If IPP service unavailable, what do you do then? Does client “fall back” to SMTP, GSTN? 6.0 EFAX SHORTCOMINGS AS A FACSIMILIE SERVICE The most obvious shortcoming of the EFAX 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. EFAX requires the use of SMTP mail names and ergonomically correct keyboards are not a standard feature on the current generation EFAX machines. Since a substantial proportion of the use of EFAX 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 applications. 7.0 E.164 RESOLUTION BOF Of additional interest to those considering IPP as an Internet Facsimile Service is new work being undertaken in the IETF to resolve E.164 numbers to a variety of Internet services. This work is underway to solve the initial problem of how do you use a regular telephone number [E.164] to establish and connect with an IP Telephony service. In other words, how does a caller with nothing more than traditional telephone keyset (or FAX keypad) find the location of some form of IP service and identify the capabilities of that service. The ability to resolve a E.164 number to a variety of services could be used with any number of facsimile protocols. For instance: E.164 to EFAX SMTP address > Based on a phone number send the fax to person@domain.com E.164 to T.38 gateway E.164 to IPP server .0 CONCLUSIONS IPP has all of the functional elements to be a superior facsimile service over the Internet. IPP has most of the functional specifications as well attributes necessary to successfully map to RFC 2305 protocols. There is every reason to believe that a concerted effort to integrate the two technologies could yield substantial benefits to end users. .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 ???? [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] ???? ipp2EFAX-map-01.txt Page 10 09/09/98