INTERNET DRAFT Richard Shockey February 15, 1999 Shockey Consulting LLC Expires August 15, 1999 draft-shockey-ipp2ifax-goals-00.txt Goals and Requirements for the use of the Internet Print Protocol [IPP] as a Facsimile Service STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. A discussion list is available on topics related to this draft. To subscribe to the mailing list, send a message to majordomo@pwg.org with the line "ifx subscribe yourname@address.com" in the body of the message. The subject line should be left blank. Archives are available from http://www.pwg.org/hypermail/ifx ABSTRACT This document discusses the use of the Internet Print Protocol [IPP] as a Facsimile Service on the Internet. A variety of goals and requirements are outlined to facilitate the use of IPP in compliance with the legal as well as general custom and practice surrounding General Switched Telephone Network Facsimile Services [FAX]. SHOCKEY EXPIRES AUGUST 1999 [PAGE 1] INTERNET DRAFT IPP2IFAX GOALS February 15, 1999 1.0 INTRODUCTION Facsimile [FAX] has a long and successful tradition as a telephony application for sending and printing a document from one device to another. The Internet Print Protocol has developed within the IETF as an application level protocol that can be used for distributed printing over the Internet using HTTP as the transport protocol. [IPP-RAT] As document distribution technologies IPP and FAX share a number of common elements including: A. Document Creation B. Addressing for the Delivery of Documents C. Capabilities Negotiation between Sender and Recipient D. Receipt and Confirmation of Transactions E. Security At a sufficient level of abstraction, the concept of FAX could be considered a "remote printing" technology. Therefore, a comparison of IPP to other facsimile services is useful. 1.1 DEFINITION OF TERMS The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Facsimile Service Mode shall be defined as the Internet Print Protocol transmission of non-alterable documents across Internet domains or the use of IPP to gateway to other Internet Fax or GSTN Facsimile Services. Throughout this document "PDL" shall refer to the IPP Page Description Language Content-Types defined in [IPP-MOD] IPP introduces objects described as "Job" and "Printer" to describe functions normally associated with printing. The concept of an IPP "Job" encapsulates transaction requests and responses that create and deliver a document to a "Printer". The actual nature of the IPP "Printer" could be a device capable of creating impressions on paper, but it is not a requirement. SHOCKEY EXPIRES AUGUST 1999 [PAGE 2] INTERNET DRAFT IPP2IFAX GOALS February 15, 1999 2.0 OVERVIEW OF EXISTING FACSIMILIE SERVICES 2.1 TRADITIONAL FAX Traditional facsimile as defined by the ITU [T.30] is a connection oriented technology between two terminal devices over the GSTN (Global Switched Telephone Network). It is specifically a "point to point" service where the end point is identified by an ITU [E.164] telephone number. The content types specified by T.30 are highly restricted due to the lack of bandwidth on the analog GSTN, typically limited to 14.4Kpbs, but standards do exist to support up to 28.8Kpbs. 2.2 IETF FAX SERVICE The Internet Fax service [IFAX][RFC2301-RFC2306 inclusive] has developed within the IETF 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 mode. IFAX adds additional functionality by integrating with other SMTP services, such as the Voice Profile for Internet Mail [VPIM2], in a concept often referred to as "Universal Messaging". 2.3 ITU FAX The ITU-T (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 designated the body of IETF IFAX work, [RFC2301-RFC2306 inclusive] and defined it as [T.37]. 2.3.2 ITU REALTIME FAX The ITU has also defined a "real time" Internet fax standard, 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. No addressing scheme is defined for T.38. The standard describes only a transport protocol. SHOCKEY EXPIRES AUGUST 1999 [PAGE 3] INTERNET DRAFT IPP2IFAX GOALS February 15, 1999 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 a facsimile 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 processed {End Quote} SHOCKEY EXPIRES AUGUST 1999 [PAGE 4] INTERNET DRAFT IPP2IFAX GOALS February 15, 1999 3.2 OTHER GOALS OF A FACSIMILE SERVICE In addition to the above specifications there are additional requirements for Sender/Recipient Identification Exchange, time/date stamping, and sender identification requirements such as page marking currently required by law in the United States and several other countries (see LEGAL ISSUES). 3.2.1 CONFIRMATION REQUIREMENTS FOR A FACSIMILIE SERVICE Detailed progress reports and transaction logs have become standard end user requirements for a facsimile service in order to document the receipt and confirmation of facsimile delivery. Any facsimile service report or log: 1. MUST note status (SUCCESS, FAILURE, CAUSE OF FAILURE) 2. MUST note date and time of all attempts (log files recorded at each end by client and server locally) 3. MAY note duration of transaction 4. MAY note number of pages transferred 5. SHOULD mutually exchange and document the identity of both sender and recipient. 4.0 REQUIREMENTS FOR THE USE OF IPP AS A FACSIMILIE SERVICE IPP clients and server operating in a facsimile service mode MUST comply with all IPP protocol requirements specified in [IPP-MOD] [IPP-PRO] [IPP-REQ] and [IPP-SCHEME]. In addition IPP implementation recommendations are contained in separate document [IPP-IMPLEMENTER]. 4.1 REQUIREMENTS FOR DATA FORMAT SUPPORT 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 RFC 2301 and specifically limits Content-Type to a subset of TIFF [Profile S] in the event that the capabilities of the recipient are not known in advance. The rationale 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. SHOCKEY EXPIRES AUGUST 1999 [PAGE 5] INTERNET DRAFT IPP2IFAX GOALS February 15, 1999 IPP does not specify any specific form of PDL for use by IPP Printer Objects. This is negotiated between IPP clients and servers during an IPP Job transaction. In order to facilitate interoperability between IPP and other facsimile services, all IPP clients and servers SHOULD support file formats for Internet Fax specified by RFC2301 to be defined in IPP as IANA registered "mimeMediaTypes". IPP transactions that gateway to other services MUST support the creation or acceptance of the minimum file format recommendation of RFC2301 known as Profile S. 4.2 REQUIREMENTS FOR ADDRESSING Both IPP and IFAX use commonly understood addressing schemes well known among Internet users. IFAX uses e-mail addressing. IPP uses Universal Resource Locators as specified by the [IPP-SCHEME]. IPP has the ability to allow multiple URL's to access a single IPP Output resource such as: ipp://domain.com/daffy_duck ipp://domain.com/canada_goose ipp://domain.com/color_printer These separate addresses might output to a single printer in much the same way a single FAX number is available to several individuals. In order for IPP to interoperate with other facsimile services and gateway between them it will be necessary to develop new IPP Job Template attributes that will permit IPP clients the ability to pass [E.164] FAX numbers, e-mail addresses, e-mail notification requirements, e-mail security or encryption requirements to IPP servers. 4.3 REQUIREMENTS FOR 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). SHOCKEY EXPIRES AUGUST 1999 [PAGE 6] INTERNET DRAFT IPP2IFAX GOALS February 15, 1999 IPP has a reliable methodology for the exchange of Capabilities between IPP client and server. For example an IPP client could request the capabilities of the server through the IPP query "get-printer-attributes" which would return "operations-supported" values to the client that would include the supported PDL's and specific PDL attributes. IPP Protocols for reliable negotiation and download of unavailable PDL drivers in IPP are currently out of scope for IPP , but it is assumed that subsequent versions of IPP will address this problem. Work is underway within the IETF to document such capabilities in a format that may be useful to IPP [CONNEG- FEATURE-SYNTAX] [FAX-SCHEMA] Implementations of IPP capability exchange in a facsimile service mode may vary. Many IPP clients may not be able to support the creation of RFC2301 or GSTN fax file formats but IPP servers may have the capability of converting a variety of PDL's to such formats before forwarding to another facsimile service. If the IPP client operating in a facsimile service mode is unable to send a RFC2301 or appropriate GSTN fax file format but wishes to gateway to another facsimile service then the IPP server MUST be able to convert the PDL to the appropriate file required by the facsimile service. 4.4 REQUIREMENTS FOR IDENTITY EXCHANGE The identity of senders and recipients in traditional FAX are achieved through the legal requirements for fax (see LEGAL ISSUES) and the exchange of T.30 CSID frames between terminal devices. IFAX uses e-mail header information to identify the sender to the recipient. The recipient has no requirement to exchange identification data. Though not a specific legal requirement, it is RECOMENDED that IPP Job Attribute extensions for the transmission and exchange of Advanced Sender Identification be developed, such as a [VCARD], when operating in a facsimile service mode. 4.5 REQUIERMENTS FOR RECIEPT, TRACKING AND CONFIRMATION SHOCKEY EXPIRES AUGUST 1999 [PAGE 7] INTERNET DRAFT IPP2IFAX GOALS February 15, 1999 Traditional FAX uses In-Band monitoring to signal the sender when a document transmission has completed or report on any errors encountered. Advanced IFAX service proposals [EIFAX] have recommended the use of [DSN] and [MDN] for receipt and confirmation. IPP offers a comprehensive suite of options for monitoring the success or failure of a document submission or Job. IPP clients can listen for a response to the HTTP POST from an IPP Printer object or may poll the IPP Printer Object for Job Status information at any time during processing. The IPP work group is proceeding on a more advanced suite of Notification Attributes [IPP-NOT] to permit notification on either the success or failure of any IPP job submitted. 4.6 REQUIREMENTS FOR IPP TRANSACTION TIME/DATE INFORMATION Closely associated with the need for transaction receipt and notification is the legal requirement [see LEGAL ISSUES] that at least the first page of a facsimile contain the time and date of transmission and that information be included in any facsimile service log or record. 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 appropriately. All IFAX transactions note time/date information in the e- mail header information. IPP clients and servers in a facsimile service mode MUST implement clocks in their systems or consider the use of the Time Protocol or Daytime Protocol [RFC 867/868] to implement time/date transaction logging. Examples of IPP transaction information that may be useful to record include: time of transmission as claimed by sender time of reception by IPP server IPP Printer Attribute "time-at-creation" time print job was commenced by IPP printer IPP Printer Attribute "time-at-processing" time print job completed by IPP printer IPP Printer Attribute "time-at-completion" SHOCKEY EXPIRES AUGUST 1999 [PAGE 8] INTERNET DRAFT IPP2IFAX GOALS February 15, 1999 4.7 GOALS FOR SECURITY On the surface, it would seem that no one would want to make his or her printer available on the Internet. It should be noted, however, that we have globally accessible printers available now. They are just called fax machines. IPP offers several types of security to enable transaction authorization [RFC2069 - Digest Authorization] or transaction encryption [RFC2246 - Transport Layer Security] 5.0 GATEWAY CONCEPTS FOR IPP IPP can be used to gateway to other facsimile services. IPP will need to develop a variety of new status codes to indicate how IPP servers interoperate with these services. Gateways between messaging services consist of On-Ramps, which accept transactions and Off-Ramps, which deliver the transaction to its ultimate destination. 5.1 IPP TO GSTN FAX IPP servers may accept transactions ultimately bound for a GSTN FAX machine if appropriate IPP attributes are developed to pass E.164 destination information along with the PDL. IPP servers should be able to monitor the T.30 Off-Ramp transaction in real time and be able to offer the senders IPP client accurate transaction reports when polled. 5.2 IPP TO IFAX Should IPP servers be used to gateway to the IFAX service IPP servers MUST comply with all requirements of RFC2305 and its successors [EIFAX]. 5.3 REDIRECTION GATEWAY SERVER A redirection gateway is defined as an IPP server capable of accepting documents and submitting them to other facsimile services such as GSTN FAX or IFAX where the final delivery address is known to the server by administrative or recipient configuration. SHOCKEY EXPIRES AUGUST 1999 [PAGE 9] INTERNET DRAFT IPP2IFAX GOALS February 15, 1999 This class of gateway might be used by individuals to permit the forwarding of transactions to e-mail addresses while on the road. A user has configured an IPP gateway server with a IPP address that is distributed on his business card or stationary such as. ipp://domain.com/donald_duck Normally all facsimile documents would be directed to the Output device configured for this address. If Mr. Duck is traveling on the road, then the server could be configured to automatically forward all of Mr. Ducks IPP transactions to his E-Mail address at donald_duck@bigducks.com as IFAX transactions or, perhaps delivered to a trusted colleague or as a GSTN fax. Server authorization to send by only by selected individuals or TLS transaction security might be optional server configuration options. 5.4 RELAY GATEWAY SERVER A relay gateway is defined as a IPP server capable of accepting documents and submitting them to other facsimile services where the address is submitted to server by sender during an IPP Job submission through the use of IPP attribute extensions. This class of IPP server might be operated by telecommunications carriers who are using IPP to onramp to GSTN fax services, thus eliminating the need for an analog fax point of presence for the sender. A customer of such a fax service might be given a special IPP URI such as: ipp://domain.com/fax_onramp Once the document was created and the appropriate destination fax number recorded for IPP attribute submission, the IPP client and server could authenticate the transaction through the use of Digest Authorization or some other means. Once the GSTN transaction was completed IPP Job records could be created and requested by the sender's IPP client. The IPP relay gateway could require submission of an SHOCKEY EXPIRES AUGUST 1999 [PAGE 10] INTERNET DRAFT IPP2IFAX GOALS February 15, 1999 appropriate fax file format or be configured to accept a variety of PDL's and conversion done at the server. 6.0 LEGAL ISSUES The use of IPP as an Internet Facsimile Service SHOULD attempt to accommodate the legal requirements for GSTN facsimile. 6.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 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. 6.2 LEGAL REQUIREMENTS IN OTHER NATIONS Many nations have legal requirements for FAX similar to those in the United States. 6.3 "WATERMARKING" OF PAGES The marking of pages in FAX is commonly referred to as "watermarking" of the transmission. These marks are SHOCKEY EXPIRES AUGUST 1999 [PAGE 11] INTERNET DRAFT IPP2IFAX GOALS February 15, 1999 typically placed at the top of each page by the sender's FAX terminal device or software application. The information inserted into page may 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. IPP Clients SHOULD, when operating in a facsimile service mode, insert such data into the PDL before connection to a IPP server irrespective or whether the transaction will gateway to the GSTN or IFAX service. 6.4 COVER PAGES Closely associated with the legal issues are the formats and requirements for cover pages. IPP has facilities for the generation of cover pages defined as Job-Separation pages generated by the recipient IPP Output device. The format of the IPP Job-Separation pages are implementation specific and may not satisfy the legal or general custom and practice involved in facsimile services. 6.4.1 TYPICIAL COVER PAGE DATA To satisfy legal requirements for Facsimile transmission cover pages: MUST contain identification of Sender: SHOULD contain identification of Recipient: MUST contain time/Date of Transmission: MAY contain number of pages in Transmission: MAY contain an area for short comments: IPP Client workstation software, when operating in a facsimile service mode, SHOULD offer Cover Page generation options to be inserted into the PDL and MAY offer other features, as deemed appropriate. 7.0 SCENERIOS OF IPP BEHAIVOR IN A FACSIMILE SERVICE MODE The following are several scenarios illustrating how IPP could be used in a facsimile service mode. Some parts of these scenarios may include functions or capabilities that are outside the current scope and capabilities of either IPP or IFAX. SHOCKEY EXPIRES AUGUST 1999 [PAGE 12] INTERNET DRAFT IPP2IFAX GOALS February 15, 1999 Legend: C. = IPP Client S. = IPP Server O. = Operator 7.1 IPP WORKSTATION TO IPP OUTPUT DEVICE In this example an individual at a workstation or personal computer has created a document using some form of document editor and wishes to transmit that document in a facsimile service mode to an IPP Output device. O. Creates Document on Workstation O. Select IPP Output Driver from list of available printers O. Selects Facsimile Service Mode from IPP client application options menu O. Enters Cover Page Data into IPP client application O. Enters IPP URI address of server C. Begins IPP transaction S. Negotiation of PDL requirements C. Renders output of Cover Page Data and "watermarks" pages into Document PDL stream. S. Accepts data and Outputs transaction C. Logs successful transaction S. Logs successful transaction NOTE: No attempt is made to negotiate support for RFC2301 or file formats or GSTN FAX. It is not necessary since there is no attempt to gateway to GSTN FAX or IFAX services. 7.2 IPP NETWORK SCANNING DEVICE TO IPP OUTPUT DEVICE A sender is using a network scanner device to imput an existing document for submission by IPP to an Output Device. O. Manually create or organize documents for transmission O. Manually fill out predeveloped cover page form and add to the documents to be transmitted O. Insert documents into network scanner device O. Select IPP facsimile service mode O. Enter IPP URI address of Output server C. Scan documents inserting "watermark" on pages into PDL stream S. Accepts data and Outputs transaction C. Logs successful transaction S. Logs successful transaction SHOCKEY EXPIRES AUGUST 1999 [PAGE 13] INTERNET DRAFT IPP2IFAX GOALS February 15, 1999 NOTE: No attempt is made to negotiate support for RFC2301 file formats or GSTN FAX. It is not necessary since there is no attempt to gateway to GSTN FAX or IFAX services. 7.3 IPP NETWORK SCANNING DEVICE TO GATEWAY FOR ULTIMATE DELIVERY BY GSTN FAX A sender is using a network scanning device to imput a document using IPP to onramp to a fax service bureau which will ultimately deliver the document to a existing GSTN FAX machine designated by the operator. O. Manually create or organize documents for transmission O. Manually fill out predeveloped cover page form and add to the documents to be transmitted O. Insert documents into network scanner device O. Select IPP facsimile service mode O. Enter IPP URI of onramp service bureau O. Enter E.164 address of ultimate destination O. Begin IPP transaction S. Request authorization of IPP client via RFC2069 [Digest Auth] C. Submit user ID and passcode C. IPP request to gateway to GSTN FAX at specified E.164 number C. Negotiate acceptance of PDL S. PCL5 or TIFF Profile S presented as options C. Renders documents into PCL5 and submits S. Converts PCL5 data stream to appropriate format for GSTN FAX transmission. S. Completes GSTN transmission S. Logs successful transaction C. Polls IPP gateway for transaction record C. Logs successful transaction 7.4 IPP WORKSTATION TO GATEWAY FOR ULTIMATE DELIVERY BY E- MAIL A recipient desires that all inbound IPP transactions to his personal IPP address be converted to a IFAX message. O. Sender creates Document on Workstation O. Select IPP Output Driver from list of available printers O. Selects Facsimile Service Mode from IPP client application options menu O. Enters Cover Page Data into IPP client application O. Enters IPP URI address of server C. Begins IPP transaction S. Negotiation of PDL requirements SHOCKEY EXPIRES AUGUST 1999 [PAGE 14] INTERNET DRAFT IPP2IFAX GOALS February 15, 1999 C. Renders output of Cover Page Data and "watermarks" pages into Document PDL stream. S. Accepts PDL data C. Logs successful transaction S. Converts PDL stream to appropriate RFC2301 file format specified by recipient and submits IFAX message to E-Mail address specified by recipient. S. Logs successful transaction NOTE: It is assumed that the IPP redirection server has access to some form of internal table or directory service that has the recipients preferences for reception. 8.0 ACKNOLEDGEMENTS 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: Dan Wing, Graham Klyne, Carl- Uno Manros, Larry Masinter 9.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-xx.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 SHOCKEY EXPIRES AUGUST 1999 [PAGE 15] INTERNET DRAFT IPP2IFAX GOALS February 15, 1999 [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 [RFC1894] [DSN] K. Moore, G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996. [RFC2119] S. Bradner, "Key words for use in RFC's to Indicate Requirement Levels", RFC2119, March 1997 [RFC2246] T. Dirks, C. Allen, "The TLS Protocol Version 1.0", RFC2246, January 1999 [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) - 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] G. Vaudreuil, and G. Parsons, "Voice Profile for Internet Mail - version 2", RFC 2421, September 1998. SHOCKEY EXPIRES AUGUST 1999 [PAGE 16] INTERNET DRAFT IPP2IFAX GOALS February 15, 1999 [IPP-MOD] S. Isaacson, R. deBry, T. Hastings, R. Herriot, P. Powell, "Internet Printing Protocol/1.0: Model and Semantics" draft-ietf-ipp-mod-xx.txt, Work In Progress, June, 1998. [IPP-PRO] R. Herriot, S. Butler, P. Moore, R. Tuner, "Internet Printing Protocol/1.0: Encoding and Transport", Work In Progress draft-ietf-ipp-protocol-xx.txt. [IPP-REQ] D. Wright, "Design Goals for an Internet Printing Protocol", Work In Progress draft-ietf-ipp-req-xx.txt. [IPP-RAT] S. Zilles, "Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol", Work In Progress, draft-ietf-ipp-rat-xx.txt. [IPP-NOT] R. deBry, "Requirements for IPP Notifications", Work in Progress, draft-ietf-ipp-not-xx.txt. [IPP-SCHEME] R. Herriot, C. Manros, "Internet Printing Protocol/NV : IPP URL Scheme", Work in Progress, draft-ietf- ipp-scheme-xx.txt [IPP-IMPLEMENTER] T. Hastings, C. Manros, "Internet Printing Protocol/1.0: Implementers's Guide", Work in Progress, draft-ietf-ipp-implementers-guide-xx.txt [VCARD] M. Smith, F. Dawson, T. Howes, "A MIME Content-Type for Directory Information", RFC2425, September 1998. F. Dawson, T. Howes, - "vCard MIME Directory Profile", RFC2426, September 1998. Additional information at : http://www.imc.org/pdi/ 10.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 SHOCKEY EXPIRES AUGUST 1999 [PAGE 17] INTERNET DRAFT IPP2IFAX GOALS February 15, 1999 11.0 COPYRIGHT NOTICE 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 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. INTERNET DRAFT IPP2IFAX GOALS February 15, 1999