2.1.5 Internet Fax (fax)

NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98


James Rafferty <jrafferty@worldnet.att.net>

Applications Area Director(s):

Keith Moore <moore@cs.utk.edu>
Patrik Faltstrom <paf@swip.net>

Applications Area Advisor:

Keith Moore <moore@cs.utk.edu>

Mailing Lists:

General Discussion:ietf-fax@imc.org
To Subscribe: ietf-fax-request@imc.org
In Body: In Body: subscribe
Archive: http://www.imc.org/ietf-fax/

Description of Working Group:

Facsimile (fax) serves as a reliable, inexpensive global communications service. As the Internet becomes pervasive, integrating fax and Internet services is appealing in terms of cost savings and opportunities for functional enhancements. This working group will pursue a review and specification for enabling standardized messaging-based fax over the Internet. It will also develop informal requirements for faxInternet gateways as a first step toward devising standards for session-based fax over the Internet. The messaging-based (via e-mail) service will be specified first, since it should produce useful results for the least additional technical effort.

Facsimile/Internet integration can be considered in terms of two user service models, in order of increasing technical difficulty:

o Messaging (as with electronic mail) having high latency o Session-based, for observed delivery, with or without capabilities negotiation

Within these models, a real-time (telephone network replacement) based service is considered to be a subset of the session-based model.

For interconnecting fax services over the dial-up telephone network and carriage of facsimile message data over the Internet, two types of interface systems are required:

o Internet/Dial-up Fax gateway, moving data from the Internet to classic or Internet-aware dial-up fax products and services

o Dial-up/Internet Fax gateway, moving data from classic or Internet-aware dial-up fax products and services to the Internet

The dominant fax communications mode in use today is a session-based connection operating in real-timeover the dial up telephone network; hence an Internet-based direct replacement service would potentially save significant long- distance telephone charges. However, it is believed that from a technical standpoint this service is the most difficult task to produce over the Internet, whereas an messaging-based service is likely to be the simplest. In addition, it is anticipated that the two services will ultimately utilize at least some common technical components. Therefore, this working group will initially review and specificy messaging-based fax over the Internet, using as much existing practice as possible.

The working group will take the following steps to specify a core fax-related messaging service over the Internet:

Terminology: Develop a shared set of terminology and definitions, to ensure a common framework for participants having differing backgrounds in Internet protocols and facsimile telecommunication.

Data Representations: Review existing facsimile- related Internet data specifications and accept, modify, replace or augment them, with particular attention to their encapsulation, such as via MIME.

Addressing and transport: Specify the mechanisms for addressing and receipt notification for facsimile data carried via Internet mail.

For session-oriented operation, the following specification will be created, as a basis for further work:

Operational constraints: Detail the operational constraints for achieving session-oriented use of messaging, tailored for timely delivery with the sender waiting for delivery confirmation. Existing protocols and data specifications will be used as much as possible.

The working group will take note of quality of service issues.

The working group will coordinate its activities with other facsimile- related standards bodies.

Goals and Milestones:

Jan 97


Submit Internet-Draft of data specifications

Jan 97


Submit Internet-Draft of terminology document

Feb 97


Submit Internet-Draft of messaging-related specification

Feb 97


Submit Internet-Draft of operational constraints document

Apr 97


Submit terminology document to IESG for publication

Apr 97


Submit data specifications to IESG for consideration as a standards track document

Jun 97


Submit messaging-related specification to IESG for consideration as a standards track document

Jun 97


Submit operational constraints document to IESG for publication as an Informational document


Request For Comments:







File Format for Internet Fax



Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration



Minimal PSTN address format in Internet Mail



Minimal FAX address format in Internet Mail



A Simple Mode of Facsimile Using Internet Mail



Tag Image File Format (TIFF) - F Profile for Facsimile

Current Meeting Report

Minutes - Internet Fax WG Meeting
Date: December 10, 1998
Chair: James Rafferty
Reported by: Graham Klyne

The agenda as presented below was accepted.

- Agenda bash
- Planned ITU reference to RFCs
- Internet drafts review
- Other drafts
- Review of charter update
- Interworking update
- Fax over IPP status

Planned ITU reference to RFCs:

The joint work on Internet Fax has helped to create a more practical working relationship between ITU/IETF. In particular, the ITU has again agreed to reference IETF RFCs to define the "Full Mode" of T.37. (see slides)

ISOC/IETF have been requested to provide completed documents and final RFC numbers to the ITU-T as soon as possible. The next ITU meeting is in late March/early April 1999 (approval meeting is April

1. Per rapporteur Herman Silbiger, the documents need to be circulated and reviewed in ITU well before the next ITU meeting. Ideally, the final drafts/RFCs need to be ready by Jan 24 and then submitted as contributions for ITU member review.

Internet drafts review:

The "-Goals-" draft has been sent to IESG review for publication as an informational RFC. The "-eifax-" draft is very stable at rev -11. The reporting extensions draft is limited to sending capabilities via MDN/DSN, using conneg syntax with usage indicated by "-fax-feature-schema-". The WG also anticipates future mechanisms from mailcap. The plan is to submit these documents to IESG for standards track consideration as soon as feature schema is done. Submission will be coordinated with the 'conneg' WG submission. The relevant 'conneg' drafts are -reg-, -syntax- and -media-features-.

Fax feature schema:

Graham Klyne reviewed the status of this draft. Most of it is now stable. The last set of work has been on handling of color. The conclusion of this review on color has been as follows: There is a series of features which can be used to progressively refine the color capabilities; In the fax feature draft, there are additional refinements that go beyond that which is specified in the CONNEG media features document.

This is the first application of the Conneg framework; Authors Klyne and McIntyre believe they now have a reasonable balance between broad color capabilities and full color matching.

There is a new draft which incorporates these features that will be issued as soon as the ID directory opens up. In the meantime, it will be posted to the WG web site. The WG Last Call will be extended to allow for sufficient review time of the latest draft.

Concerning an IESG last call once the documents are submitted, this is nominally 2 weeks, but a holiday period is approaching and one of the ADs is mostly unavailable for the rest of the year. The chair will try to ensure some review in this time period once the documents have been submitted to the IESG.

Full addressing:

The status of this document was presented by Claudio Allocchio: [[[see slides]]] The PINT WG requsted additional dialtone/wait-for-dialtone characters in dialing string, which are addressed in the current draft. There are security concerns regarding possible disclosure of access codes, etc, in address. There was some discussion on what level of requirement the optional address elements specified in the full addressing draft need to be supported. There was some support for the current SHOULD and some for must; the chair noted that Normative references are really imposed by the protocol documents which would use this document . The conclusion was that there is a requirement to make it clear that the additional recipient qualifiers are optional, and a minimum set should be used. [see wording in draft]. Therefore, it was agreed by the room to add that only the strictly needed elements SHOULD be used. There is also a need to reference RFC821 or the equivalent DRUMS (if ready in time) for maximum length of local part that a recipient must support.

There has been a request to use ";" as alternative to "/" for parameters; but, ";" needs to be quoted in mailbox. A greater range of allowed control sequences in address has been requested; this can be achieved by additional 'qualif-type1' elements.

Glen Parsons noted that comments were submitted to the list by the voice community requesting that they be able to use "voice=" form. In addition, there is interest in using "AMIS=", which has two telephone numbers, where the 1st is the number of the voicemail system and the second is number of mailbox.

There was support from the floor for for several future extensions of this type, hence the most important need is for an IANA considerations section to be included in the draft so that other communities to add extensions.

There was some discussion on the appropriate process to be used in maintaining registrations for this name space. It was felt there is a need for IANA procedures for registering both new keywords and qualifiers.

It was noted that the development of standards track documents was one of the ways to register new keywords and qualifiers, but not the only way. The consensus was that an IANA considerations section is needed within this document and it should be reviewed on the list. Since this document is not on the critical path [for ITU cooperation], it was proposed that early January would be a good timeframe.

In further discussion, it was noted that the pending SIP document from the MMUSIC WG has a URL scheme that uses phone addresssing elements. The question was raised on whether we should try for alignment between this and the e-mail addressing work? It was noted that by the author that some attempt at alignment has already been made. The chair summarized the discussion by stating that the full addressing document has been available for some time, and has been subjected to significant levels of review. Final detail comments should be set to the list for a targeted completion in January, once the draft which includes the IANA considerations section has been posted.

Other drafts:

- The related work from the 'conneg' WG was summarized by chair Ted Hardie: The -reg- draft has undergone WG and IETF last call, and is in IESG review. The -media-features- draft is in IETF last call: some comments suggesting small revisions have been received. Regarding the -syntax- draft, Hardie suggested that interested persons should come to the conneg WG meeting scheduled for later in the day.

The decision on moving to last call will be made after today's conneg meeting. It was noted that the fax feature schema document contains many examples that help to clarify the content of the syntax document.

- T.30 feature mapping

Per the chair, there is a WG consensus that this document is needed. It is , intended to be progressed as an informational document. Author Klyne noted that there is a section that is still missing, dealing with the detail of transformation from T.30 DIS to conneg feature expressions, pending completion of the fax schema draft. The conclusion was that the goal is to complete and stabilize on January time frame.

Review of charter update [see slides from chair]

What's left?
- Potential progression of the simple mode documents to draft standard. The necessary 6 months has elapsed. The documents need to be revisited, so that comments and interworking testing experience can be folded in. This may result in recycle at proposed or move to draft, depending on whether any technical changes are needed.
- onramp/offramp: Offramp work has been deferred. Onramp has been left out of scope to date, but interworking experience suggests that this decision should be reviewed. DSN/MDN extensions for offramps to be considered. There could be problems with IPR, and the experience of other groups suggests this is a difficult area to standardize.
- DSN/MDN extensions for processability (can receiver view/print the document as received?): The Fax WG has pushed the standard features of DSN/MDN to the limit; It was noted that the members of the DRUMS WG are interested in considering MDN/DSN extensions (and mailcap) as priorities for work by the email community once DRUMS is complete.
- New IETF work: security, ODMR, Mailcap.

There was some discussion about current and pending IETF work which may be valuable to incorporate for Internet fax use it is available. Paul Hoffman provided a short review of the status of security for email. The OpenPGP message format has been approved. S/MIME WG is ready for IETF last call next week on their main documents.

A difference between the two approaches is that S/MIME has a much better-specified public key infrastructure interface than OpenPGP. This may be viewed as an advantage or a disadvantage. The three main drafts are base format, message format,and certification. A 4th draft (ESS) is looking at signed return receipts. All of these documents are on the same timeline. There is also security labels (labelling for vetting who can see a document).

Other potential charter items

There was discussion on whether an an implementer's guide is an appropriate document. It was noted that Mike Moldovan has volunteered to worki on such as draft, based on interworking experiences. It was not clear what addition charter milestones will be acceptable to the ADs. It was noted that for document/process issues, a mailing list may stay open even if the WG closes. It was further noted that gateway issues may involve a lot of work and IETF experience is limited. There was thought that incorporation of new features such as additional security and enhanced MDN/DSN may go beyond full mode (super-mode?) The question of the need for security gateways between G3 and email was briefly discussed, but this is not really needed until there is deployment, which currently is non-existant for G3 fax.

- File Formats - there was brief discussion on file formats other than TIFF (e.g. postscript, PDF). Should this be revisited? Current progress in ITU to extend resolutions, include new compression (e.g. JBIG2, etc.). Need to consider extending TIFF format to encompass new developments. It was noted that by the chair stable references would need to be in place in a 6-9 month timeframe; JBIG2 is far enough out to be out of scope.

There was the further comment that "Super-fax" would need to reconcile fundamental differences in transmission models of fax and e-mail.

- Status of MailCap and ODMR(On Demand Mail Relay) The Mailcap -- activity is going on behind the scenes, expect some news about January. The ODMR draft from Gellens (draft-gellens-on-demand-05.txt) is awaiting a pending new standards track authentication method based on digest authentication for SASL. Completion of the draft is targeted in the next couple of monthstimeframe. The method currently operates at level of a full domain rather than individual mailboxes, but the author believes it could be extended if required.

Charter review timescales [See James' slide]

Some straw polls were conducted on refined/new milestones. There was Consensus for adding a milestone of an implementers guide as work item, for January submission as I-D. Onramp/offramp: A considerations document was proposed for February. The room felt that this is a complicated topic, and this is not an "emergency" task, hence wary of pushing for a quick result. It was suggested that this becomes less of an immediate focus. The chair agreed to push this date back, noting implementer feedback would help here.

Progressing Simple Mode Documents to Draft Standard

There was some discussion on potential revisions to the simple mode documents. Points made includedupdating RFC2305 language to be more specific and clear about some of the gateway issues 2) It was felt there is a need to document interoperability, and use of licensed technology. This sequed into a brief IPR discussion on known patents. The understanding of the chair with respect to these matters was

1) For Biscom we don't yet know if their patent overlaps simple mode in any way (the chair is in contact with them) and
2) Matsushita patent was stated to be be non-overlapping in mail to the list by one of the patent holders; a related statement has been posted to the IETF. It was further noted that the draft standard requirement involves finding two interoperable implementations which employ licensable technology on an open non-discriminatory basis; i.e. two examples of the IPR being used in a demonstrably non-infringing fashion is sufficient to meet the "reasonable" condition of RFC 2026.

The chair asked if January 1999 was a reasonable timeframe for proceeding to draft status for simple mode? It was counter-proposed that February be the target in order to have things in shape for the March IETF.

There was a proposal from the floor to to combine simple and extended documents. The chair and the rapporteur stated that this would be unacceptable to ITU. It was clarified that it would be more practical to merge documents when *both* are ready to advance to draft standard, so that this would be much later.

The conclusion of the room was that the target should be February 1999 for publication of draft mode documents, followed by a review at the March meeting and formal submission to the IESG in April.

Proposed: I-D profile of ODMR profile for Internet fax published April 1999. There was some discussion on whether this would be informational or standards track, but it was concluded that this can't be resolved until there is an ODMR document available for reference. Proposed: I-D profile on refinements to reporting extensions for Internet fax. This is likely to be linked to work by the mail community on extensions to DSN/MDN, but the fax community needs to participate to ensure that our needs are met.

Conclusion: The chair will update the milestones based on the charter review and post them to the list. It may be sufficient to simply add milestones and not do a full charter update.

Interworking update

The chair introduced this agenda item, noting that some interoperability testing has been performed:
- In Japan, in October 1998, there was testing of interoperability of simple mode among fax vendors (8 vendors). All testing was done over the Internet. Contents of testing was much like the San Jose tests. The Wide project has prepared a free software toolkit for Internet fax systems.
- San Jose: December 1998 [see James' slide] There was testing by 17 companies in a face to face two day session. Just about everything in the simple mode and TIFF profiles but lossless JBIG was tested successfully. It was noted that iImplementors need to read TIFF-S section in RFC2301 very carefully. Some implementors assumed TIFF-F constraints on bit order and byte order applied, which was inconsistent with the S profile constraints used in simple mode. The related suggestion was to add profile labels to relevant chapter headings when updating the RFC 2301 text. There was also an issue regarding the proper handling if other multipart structures with other media types come into play. RFC 2305 currently says multipart failure handling is all-or-nothing; may need to be reviewed.

Support for message/RFC822 for forwarding was uneven. This suggests that some clarification of required MIME support should be provided in the update to RFC 2305. It was also noted that onramps may need to use the "badfaxlines" TIFF attribute (allowed in profile F, not in S). But general TIFF behaviour is to ignore unrecognized tags (this only applies to MH/MR encodings).

The proposal to create an "Implementation Discoveries" document has been well received and will be added to the charter milestones as agreed during the charter review. In other review of results, Dave Crocker noted that there was much use of non-standard addressing for offramps. So far, there was not much telephone use, but that present was very successful. Lots of small bugs were found in implementations(but that is what these events are for).

Lloyd McIntyre review the results for TIFF profile interoperability (also tested in San Jose): This entailed testing profiles within TIFF other than S and F. Three participants tested profiles J, C, and M. The L profile was not tested (color JBIG). Testing continues in US and Japan. He anticipates that all of the profiles will be fully tested by January 1999, with issue of full report of implications to RFC 2301. It was noted that the IMC interworking event will be in about 6 months. Sample files will be posted on the IMC web site. In addition, EMA is working on a public interoperability demonstration. The good news here is that real implementations are being developed.

Fax over IPP status [see Rich Shockey's slides] See: <draft-shockey-ipp2ifax-00.txt>

The starting point is to ensure that use of fax over IPP meets the requirements of -goals-. There are some added benefits (session mode). The protocol documents already exist (Informational in January 1999). There is work required which includes
1) describe how to satisfy legal and "custom and practice" requirements,
2) "Watermarking" of pages,
3) cover page generation,
4) Sender identification, and
5) Gateway issues and attribute mapping for file types and relay modes.

There are also some questions of usage to resolve. IPP has an advantage of being "recipient driven"; no media limits imposed by the system.

Fax WG members are invited (urged) to participate in these discussions,which will take place outside of the Internet Fax WG.

The Mail list is: ifx@pwg.org.
Subscribe by sending message to <majordomo@pwg.org> with message body containing "subscribe ifx <your-e-mail-address>". Some volunteers were noted.

In another item, it was noted that there is an MDN/DSN interoperability event planned in February 1999.


IETF Presentation on IPP2IFAX