Editor's Note: These minutes have not been edited. Minutes for IETF working group on FAX, April 10, 1997 Dave Crocker, James Rafferty, co-chairs. Reported by: Larry Masinter and James Rafferty Topic: Related Activities James Rafferty reported on related activities in other standards bodies and consortia: 1. Study group 8 of the ITU has established a set of objectives which include the intent to work on a session-based mode of fax over Internet and a store & forward mode. 2. The "voice over IP" group of the International Multimedia Teleconferencing Consortium is not actively working on fax over the Internet, according to consortium President Neal Starkey. The agenda included a review of several topics which related to the potential components of messaging based Internet Fax. Topic: Confirmation A feature that's important for fax is the ability to get a confirmation. It is viewed by many as a fundamental requirement. Internet mail has two kinds of activity with respect to confirmation: Delivery Status Notificaiton (DSN) and Receipt. DSN is delivery time confirmation, as fully specified in RFCs 1891-1894. You know when the message has been delivered, but not when it is read, processed, printed. The question was raised on whether this is sufficient for Internet Fax. Receipt acknowledgement is at least 1-3 months from "proposed standard". It is a notification that the recipient has 'handled' or processed the message. It has more semantics. There is less operational history. A Message Disposition Notification (MDN) says how the message was processed. Most people in the room think that DSN is adequate to emulate what a fax machine does today. DSN is interesting from the point of a service provider, and receipt may provide added value. A straw poll taken on the following question: Question: should we mandate support for DSN (when requested by sender), explore (not make a decision now) support for MDN? The consensus of the group present was to mandate support for DSN in messaging based Internet Fax. There was some interest in exploring MDN for later use. Topic: Data Content The group reviewed the alternatives for data formats: Tiff-F, Tiff-Plus, PDF * Tiff-F Draft 01 Review There was an overview of draft issued 4/2/97, by James Rafferty & Glen Parsons. (The draft missed Internet-Drafts deadline, but was sent to list). James presented slides that summarized the key changes from previous draft. TIFF-F was originally the product of an informal working group in the fax community to produce a document file format that could be implemented by them, and then has been in use for 5 years. The goal of the TIFF-F draftocument has been to document TIFF-F with some minor content adjustments in the areas of paper sizes and resolutions to provide consistency with ITU fax recommendations up to the 1993 level. James also responded to some of the comments from the ietf fax list regarding the 01 level draft: - Intent to phase out "class" and use "application" - There were some difficulties with the term "default" in the TIFF-F draft vs "baseline" in TIFF. They need to do some editorial work to fix that up. - There were some differences between typical TIFF-F values and baseline TIFF defaults, and they need to make those clear. - Byte alignment: confirmed that TIFF-F historically has been byte aligned Question: is it intended that legacy TIFF-F readers will work? It was confirmed later in the meeting that it is highly desirable to have compatibility with existing TIFF-F readers. Lloyd McIntyre presented the slides on the Tiff-FX format: Current practice in fax MH/MR (T.4) MMR (T.6), JBIG (T.82) plus color representations: T.42 JPEG (T.81), JBIG (T.43), and T.44 Mixed Raster Content. TIFF-FX addresses all of image formats specified to date by the ITU-T for facsimile. Part of the goal is to enable the migration of black & white fax to full color by taking advantage of the Internet. The primary idea is to create one Internet Fax TIFF spec, with conformance documents to capture practices. The goal is to separate out the application needs. Q: Can we have two formats? A: Yes. Steve Zilles presented slides on the concept of PDF as a fax file format. TIFF is great, but it is a raster format. While fax today is raster, tomorrow fax may be more: layering, annotations, recognition. Not raster data. He suggested that It doesn't make sense to create another compound document format out of tiff. PDF representation alternatives include: PDF image only, PDF with original image and hidden text. Advantages of PDF: - published format, multiple implementations - rasters + text and graphics - cross platform support - most relevant compression algorithms (not JBIG) - device independent color - efficient access/display of pages - hyperlinks There was some discussion on whether PDF could be as freely available as TIFF and with tools from multiple vendors. Zilles indicated that there were no obstacles to this. Dave Crocker summarized the data content alternatives: TIFF-F is 'fax today', TIFF-FX is 'fax in the near future', and PDF is 'fax using object oriented data representations". Questions: What is the relationship between Internet fax, VPIM, WIDE, legacy? What's the difference in practice between having two specs for tiff vs a single spec & multiple profiles? There was a long discussion of the alternatives. Glen Parsons noted that the VPIM work is nearing completion and would like to be able to reference TIFF-F to support exchange of fax attachments. Question: what are the Intellectual Property Rights issues? Steve Zilles of Adobe will send this in a mail message to the list: "Basically, Adobe is in the position of trying to facilitate the exchange of information. Postscript, PDF, and TIFF, there will be a printed license to implement to the specification with no charge. Ghostscript has a PDF rasterizer ("free" software), Adobe is reserving the copyright on the specification itself. TIFF has full implementations. PDF references technology that is proprietary by others. Perhaps there are some compression mechanisms and encryption mechanisms that might be part of the 'profile' for PDF. There is no problem referencing PDF publishing information." There was a discussion on the relationship between data content and capabilities negotiation. One approach is to specify a minimum format that is required and possibly use negotiations to go beyond the baseline. There was no clear outcome on the matter of negotiations at this time. The discussion concluded as Dave Crocker surveyed to room to check for consensus. There was a consensus among those present that the baseline values of TIFF-F should constitute the minimum mandatory level of data content support for messaging based Internet fax. The intent was that Internet Fax applications would support at least the baseline values for TIFF-F that are compatible with historical TIFF-F applications. There was some interest in raising the baseline to include a range of resolutions and paper sizes (for example, these are optional values in the TIFF-F 01 draft to support these additional resolutions and paper sizes). It was suggested that ideas on an enhanced baseline and on related use of negotiations be pursued on the list. There was some additional discussion about whether it was best to support the two TIFF formats (TIFF-F and TIFF-FX) in a single or multiple documents. Most people in the room had a strong opinion about image formats; after some reminders from the chair about IETF 'voting' (that final decisions get made on the list) and several different attempts to poll the room for opinion, the consensus from most (but not all) present was to create a single TIFF document which merged the content of the two TIFF drafts (TIFF-F and TIFF-FX), where TIFF-F would be the baseline as agreed previously. There was also a suggestion that it be possible to support alternatives in format choices and multiple formats as input; this discussion was deferred to the list. Addressing: (25 minutes) There was a discussion of the C. Allochio draft, resubmitted to the list shortly before the meeting. This offers an addressing mechanism for interworking between telephone numbers and email-based address, such that on the left hand side of the address, the telephone number plus subaddress, and some pieces that provide compatibility with Mixer & X.400 world. There was interest in having a simple form for 'internet fax' addresses, without too many quoted expressions and keyword value forms. The question on the need for mixer compatiability was raised. Claude argued that we should not break the Mixer compatibility. Some of the draft was based on a survey of actual practice in X.400 community. Claude asked for opinion of the group for how we should work. James points out that there are 80 million fax terminals, none of which have alpha keyboards but only have numeric keyboards. The address must handle the telephone number case, and that it was argued that at least we should handle telephone number addressing and maybe subaddressing. Analogies were made between the Internet and the phone system: the phone system has a universal address space and allows designation of service providers. The phone system considers the location of the switches and gateways as private information. Phone addresses consist of digits. A question was raised on where to put 'relay' information in an Internet fax address. The tpc.int approach puts the relay information in the DNS. The second approach puts the phone number on the left hand side & the relay on the right hand side. Keith Moore noted that putting the relay name in the address has had a lot of problems in mail relays. The phone number is a universal address space that is shared by everyone, but you're allowed to specify a service provider. Keith proposed that there be be two possibilities, one of which is a provider-less address, and one of which specifies a provider. This portion of the addressing discussion was inconclusive, so further discussion on Internet Fax addressing requirements was deferred to the list. Topic: URLs for Fax Dan Zigmond presented a proposal for Fax URLs, which is found in Internet Draft "draft-zigmond-media-url-00". These are not meant to be a way to address faxes, but offer a way that a web browser could provide a link to a fax device. The proposal is: fax://country-code/region-code/fax-number, e.g., fax://1/510/3372950 This syntax is designed to be compatible with the URL syntax for absolute and relative addressing. There was some discussion. There were a number of suggestions for looking up other standards that might provide an extended syntax for telephone numbers. James suggested that the syntax should read "fax-address", rather than fax-number, allowing for a subaddress. There are some issues with defining a telephone number in a way that actually is "uniform" no matter where you are calling from. Within the room, many people thought that syntax for a fax URL would be useful. There wasn't consensus on this syntax. However, the main interest seemed to be in monitoring and commenting on the work, rather than pursuing it within the working group at this time. Transport: (15 min) Neil Joffe presented some information on a draft that is about to be submitted (hardcopy was passed out at the meeting). It specifies some extensions to ESMTP for session-based capabilities, which could include in what is fall-back to store and forward, with facilities that include capability negotiation, delivery notification, etc. The draft proposes extending MAIL FROM with an annotation that real time fax is requested. It adds capability exchange within that for negotiation in advance of capabilities for MMR, MR, etc. Real-time capabilities negotiation is taken into account and the gateway into the PSTN has the capability of doing format conversion and fax conversion, where the power can be in the gateway, which allows the delivery of real-time fax to multiple recipients. Since this is a new topic, it will discussed further on the list. There was no time left in the meeting to discuss the remaining item on the agenda, regarding the development of an Internet Fax Messaging draft. *------------------------------------------------* James Rafferty President, Human Communications 12 Kevin Drive Danbury, CT 06811-2901 USA Voice/Fax: +1-203-746-4367 Email: JRafferty@worldnet.att.net 71043.1114@compuserve.com *---------------------------------------------------