2.1.5 Internet Fax (fax)

NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 25-Jan-99


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:







Minimal FAX address format in Internet Mail



A Simple Mode of Facsimile Using Internet Mail



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



File Format for Internet Fax



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



Minimal PSTN address format in Internet Mail



Terminology and Goals for Internet Fax

Current Meeting Report

Internet Fax WG Minutes - March 18, 1999

Chair: James Rafferty
Reported By: Graham Klyne

The agenda was reviewed and accepted. The chair noted an aim to be able to close the work group by the end of the year, but further discussion on this was deferred to the milestone review later in the meeting.

Status review, planned reference by ITU

The chair reviewed the status of cooperation with the ITU Study Group 8. He noted that working with ITU SG8 gives a somewhat unique flavor to the nature of the WG work. ITU agreed in principle to reference our work, subject to the availability of completed documents RFC2530, RFC2531 and RFC2532.

The documents have been submitted as contributions to ITU, and are due to be discussed by them at the Geneva SG8 meeting, end of March 1999.

A question was raised about cooperation with the new VPIM activity and it was felt that this is likely, especially since the VPIM work is addressing issues that may also apply for Internet fax going forward.

Review requirements to progress simple mode documents

The chair noted that documents with normative references to other standards track documents cannot be progressed unless the referenced documents are also progressing to the same level. This means that a document like RFC 2305 cannot progress to the draft standard level unless referenced documents RFC 2301, 2303 and 2304 are also ready to progress. There is a need to examine interworking for in order to enable progress of these documents to draft standard status. Some interworking has been confirmed, but more work remains to be done. One IMC interworking event has been held, and another is planned.

>> RFC 2305 revisions
The updated simple mode service document <draft-ietf-fax- service-v2-00.txt> was presented by co-author H. Ohno.
Interoperability has been tested in US and Japan, with 17 implementations at FaxConnect 1 in San Jose. Changes from V1 to V2 are anupdated IPR notice, updated references (notably to new IETF security standards), as well as clarifications and editorial revisions.

In the area of intellectual property which may apply to simple mode, the chair noted that IETF director Steve Coya has approached patent holder Biscom for potential submission of an IPR statement, but to date no response has been received.

As part of the progression to draft status (for the case where there are IPR claims), at least 2 companies with interoperable implementations need to assert that they have independently licensed any applicable technology required for their implementations. It was noted that a Matsuhita patent holder has informally indicated that their patent does not apply directly to RFC 2305.

There was a reminder from the chair that participants who are aware of IPR claims are required by IETF procedure to declare that knowledge, OR to withdraw from working group participation. No position on the validity of the IPR claims is implied by the mention of the Issue in this meeting.

There was some discussion on the RFC 2305 revision process and the proposed timetable of 2-3 months. It was clarified that the ITU process does not impose any requirement that the documents are at a particular level (for example draft standard), but that progress to draft standard status does enhance a perception of stability.

The target of 2-3 months is to allow reasonable period of time for completing the interoperability testing. The timing is not driven by other requirements. Hopefully, IPR issues will be resolved in the period. The chair asked if anyone thought that this was an unreasonable timescale? One attendee stated that it was not long enough. Regarding the procedural details on IPR policies, the applicable reference is RFC2026 section 10.3.2..

>> RFC2301 revisions
Co-author Lloyd McIntyre presented the status of RFC 2301 revisions. A revised version has been submitted as I-D, but was not available in time to be posted prior to the meeting. The main changes are clarifications based on received comments and interoperability tests - (see slides for details of changes).

The chair asked if the T.44 dangling reference will be addressed. The T.44 recommendation was still pending final approval as of this meeting, but McIntyre indicated that approval is quite likely on April 1, 1999 at the SG8 meeting. This follows a long awaited response to ITU from a JPEG registration authority (JURA) on marker segments required by T.44. In addition, a statement of intentions regarding IPR from Xerox was disclosed. (see slides for details). Xerox owns IPR related to profile M of RFC 2301 and is working on a more formal statement to the IETF on this matter.

>> RFC 2303, RFC 2304 (addressing)
Author Claudio Allocchio presented the status of work in progress to provide updated drafts for the RFC 2303 and 2304 minimal set addressing documents. There was some editing work done on these documents by a small group earlier this week.

The planned revisions include clarification of text, the addition of a terminology and syntax conventions section, and the addition of IANA considerations for registration of tokens used in addresses It was noted that the full addressing and minimal addressing documents currently have circular references, but that this mainly pertains to registration issues. It was suggested that pulling IANA registration procedure into a separate document might solve this issue. The author will continue to work on the IANA procedural issues to be resolved.

Interworking of Simple Mode

Allocchio went on to review needs for interworking testing on RFC 2303 and RFC 2304.
For validation of the spec, the following test environment is proposed:

submit SMTP G3fax
UA ------> submit and relay ------> offramp ------> G3 fax

>> RFC2301 interoperability report

McIntyre reviewed a report on RFC 2301 interoperability. Collectively, implementers have tested interoperability of all profiles (see slides for details). The chair asked about the independence of these implementations. McIntyre noted that there is a report produced by the testing companies containing a history of the various codesets tested, which could be submitted with the updated RFC 2301 document at the time of a request for progress to draft standard status. Further details about the testing are available at: <http://www.xerox.com/research/xac/tiff-fx/index.htm>.

The companies used a pre-release of TIFF test tools from Genoa Technologies for this testing.

In other related matters, it was noted that the WIDE consortium has published a freeware version of Internet fax software and tools. It was agreed that having Internet fax test services available on the Internet is very useful. Paul Hoffman noted that IMC hopes to provide such a service hosted on BSDI, using the WIDE freeware. It was also noted that implementors of the J profile need to make assertions about licensing of JBIG (ITU T.82) for the IETF interworking purposes.

Other Current Internet drafts

Author Allocchio reviewed the status of the full addessing draft <draft-ietf-fax-fulladdr-05.txt>. He noted that the document has been updated to include an IANA considerations section and related registrations. Service-selectors and qualif-type1 elements must be registered. Allocchio proposes that registrations must reference a standards track RFC; experimental tags must use X- names.

The question was raised on why a standards track RFC was being proposed, rather than any RFC? Allocchio stated that he had received this advice from IANA.

The chair and others suggested that if we feel strongly that a less struct requirement is OK, IANA will probably accept our judgement.

It was suggested that the WG needs to be clear about what level of quality control to apply and then select the appropriate mechanism. The chair suggested that the final details on the IANA requirements be taken to the discussion list, and that the WG try to resolve it quickly. He felt that the next revision of this document with the changes applied should be suitable for last call.

It was noted that the service-selector element registration has needed review by other communities, but this process has been ongoing for an extended period of time. It was suggested that the author select a mechanism from IANA considerations RFC, discuss this with the group on the mailing list and then the WG will need AD concurrence with the choice.

** The chair made a call for consensus on taking the next version of the full addressing draft to last call and there was general support.

Glenn Parsons reviewed a draft on VPIM addressing <draft-ema-vpim-address-00.txt>. He noted that in VPIM V2, no specific structure was suggested for addressing, other than permitting phone numbers to appear as mailbox name in a mail address. Some voice mail systems can accept only numbers in the mailbox name (LHS of e-mail address).

The proposed draft uses (a) arbitrary mailbox name as per VPIM V2 (b) fax addressing work for structured address formats.
An attendee stated that it has been alleged that any mechanism that uses structure in e-mail LHS to determine message routing is patented. The chair noted that the addressing documents are related to syntax and that behavior is not specified. Parsons also reviewed a draft on multi-part addresses for fax and voice <draft-ema-vpim-um-01.txt>.

The documents introduce the concept of "primary" content type, which may be of value for Internet fax as well going forward. Other elements include selection of an appropriate viewer and the provision of meaningful "discard" rules. For example, for the purpose of MDN generation, an e-mail client may claim message is "read" even if voice part has not been read, depending upon the "primary" content type It is proposed to add semantics to multipart/voice-message (already defined for VPIM) and devise a new multipart/fax-message, to indicate primary content type (from the choice of voice or fax).

Cover-page draft

Author Mike Ruhl reviewed the Fax cover page draft <draft-ietf-fax-coverpage-01.txt>

The purpose of this draft is to provide a way to indicate the presence of a cover page. The method used in the draft is to include a cover page as part of a "multi-part fax" MIME media type. There was a discussion on the requirements for cover pages and there were several different views in the room. It was felt that current practice in GSTN based fax will carry over into Internet fax and that there will often be cover pages. It was suggested that three situations may apply: cover page not present, likely present, definitely present. There was also a desire to distinguish between a separate cover page and an embedded one. A question was raised on cover page content, but Ruhl stated that this was outside the scope of this draft and had been deliberately omitted. There was also a question on whether cover pages might be generated based on the content of mail headers. The key issue is to define the problem to be solved. Further discussion is deferred to the list.

MDN fullmode

T. Maeda reviewed a draft on MDN fullmode (draft-ietf-fax-mdn-fullmode-03.txt): He reviewed his ideas about goals of I-fax: (see slides) and made a distinction between "eifax" and full mode fax devices. "FullMode" is intended to be interoperable with new fax devices and the draft's concept is to implement fax as terminal functions over the Internet

Four additional requirements beyond "eifax" are stated:
- capability exchange (MDN request/mandatory response)
- fax capability format (T.30 DIS bits, etc.)
- fax status report (includes total pages and error page number)
- use existing infrastructure

An issue was raised suggesting that the capabilities exchange would not work, because scanning must wait for capabilities to be identified. The author replied that scanning is accomplished before transmission, and conversion performed later when capabilities are known.

He also stated that two manufacturers are undertaking a "fullmode" feasibility trial.

New conneg drafts

Graham Klyne briefly described 3 drafts in process within the Conneg working group and noted that more detailed discussion will take place in the Conneg working group. The key drafts that may be of interest for fax are:

Review charter milestones

(see slides from Chair)

The chair suggested that the practical approach for the working group was to review potential changes to milestones now that the simple mode and extended fax RFCs have been published, rather than attempt to do a re-chartering. Time was limited, so that this was a short discussion.

Onramp/offramp draft, targeted for informational

The chair asked if the room felt that this is important? There is a rough consensus (but not
unanimity) for doing this. .

** Later, there was a proposal that the WG focus on the completing Internet specific work ASAP and having the onramp/offramp work be a separately chartered effort. There was general consensus in the room in favor of this approach.

- Advance Simple Mode drafts to Draft Standard by June? The group agreed to shoot for this. .

- An Implementer's guide is felt to be important.

Other items for consideration in milestones are:
- On-demand SMTP, for DSN to dial-up devices.
- Submit cover page draft (standard track)

There was a brief discussion on security as it pertained to Draft Standard status. Some felt the WG may need to address security better to move to Draft Standard. It was suggested that there is a need to distinguish issues unique to fax-over-email, as opposed to email in General, and that the WG should look for unique aspects of fax over the Internet. Security must be discussed to create a profile for global service, but this may not be critical path for current work.

The question of where security fits in the milestones is left for discussion on the list.

Combine drafts/security?

There was no time left to discuss these items any further, so the meeting was closed.


None received.