Current Meeting Report

2.1.5 Internet Fax (fax)

NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date. Last Modified: 29-Jan-02
Claudio Allocchio <>
Hiroshi Tamura <>
Applications Area Director(s):
Ned Freed <>
Patrik Faltstrom <>
Applications Area Advisor:
Ned Freed <>
Mailing Lists:
To Subscribe:
In Body: subscribe
Description of Working Group:
Previous IETF efforts developed specifications for simple and extended Internet mail-based facsimile service profiles, tailored to interwork with the world of T.30 facsimile. This extension effort will take care of differential routing between classic Internet mail and timely deliveries, and consider with particular regard universal messaging issues and its relation with Internet mail.

The WG will produce a final increment of specification for supporting a "full" equivalence of T.30 service over Internet mail. Technical work for this effort includes timely delivery, [image] feature selection/negotiation, document privacy, and integrated specification of Full-mode Facsimile Profile of Internet Mail (FFPIM).

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 working group will also consider the requirements for gatewaying Internet Mail (as profiled for facsimile Simple, Extended modes and FFPIM) with T.30 Facsimile.

The working group will specifically take note of quality of service issues and might decide to produce an Implementer's Guide.

T.30 facsimile carries expectations of message privacy, so that FFPIM must specify a basic facility via the Internet. Although T.30 does not provide document integrity, users frequently believe that it does. Consequently the Faxext working group will also seek specification of a basic authentication facility over the Internet.

T.30 facsimile provides for receiver capability identification to the sender, allowing a sender to provide the "best" fax image the receiver can handle. The Faxext working group will consider mechanisms to provide similar functionality for fax images transferred by e-mail.

Additional areas of discussion will be: Annotated fax messages and universal messaging issues as they relate to FFPIM, as well as schema and TIFF extensions required to support the new JBIG-2 (T.88) compression method.

The working group will continue the excellent pattern of coordinating activities with other facsimile-related standards bodies, in particular the ITU, VPIM and other WGs, and with using work from related IETF efforts.

Goals and Milestones:
Done   Submit Internet-Draft of data specifications
Done   Submit Internet-Draft of terminology document
Done   Submit Internet-Draft of messaging-related specification
Done   Submit Internet-Draft of operational constraints document
Done   Submit terminology document to IESG for publication
Done   Submit data specifications to IESG for consideration as a standards track document
Done   Submit messaging-related specification to IESG for consideration as a standards track document
Done   Submit operational constraints document to IESG for publication as an Informational document
Jul 01   Submit final draft for FFPIM to IESG for publication
Jul 01   Submit final draft of gateway requirements
Jul 01   Submit second draft of Fax status information
Jul 01   Submit second draft of Goal for Terminal Mode
Jul 01   Submit second draft of Protocol for Terminal Mode
Nov 01   Submit final draft of TIFF-fx extensions
Nov 01   Submit final draft of schema for TIFF-fx extensions
Dec 01   Submit final draft of Fax status information
Dec 01   Submit final draft of Goal for Terminal Mode
Dec 01   Submit final draft of Goal for Terminal Mode
Request For Comments:
RFC2301PSFile Format for Internet Fax
RFC2302PSTag Image File Format (TIFF) - image/tiff MIME Sub-type Registration
RFC2305PSA Simple Mode of Facsimile Using Internet Mail
RFC2306 Tag Image File Format (TIFF) - F Profile for Facsimile
RFC2542 Terminology and Goals for Internet Fax
RFC2530PSIndicating Supported Media Features Using Extensions to DSN and MDN
RFC2532PSExtended Facsimile Using Internet Mail
RFC2846PSGSTN address element extensions in e-mail services
RFC2879PSContent feature schema for Internet fax
RFC2880 Internet fax T.30 Feature Mapping
RFC3191DSMinimal GSTN address format in Internet Mail
RFC3192DSMinimal FAX address format in Internet Mail

Current Meeting Report

Minutes of the IETF 53 Internet Fax WG meeting Minneapolis, March 18th 2002
Chaired by Claudio Allocchio and Hiroshi Tamura

1 Agenda bashing

The meeting started with the approval of the proposed agenda, except for the swap of point 8 (UM: Unified Messaging) with point 9 (ITU-T)
(see slide: fax-0). Hiroshi Tamura welcomed the participants.

2 The I-Ds that are in RFC editor's queue

Hiroshi Tamura refered the status of the current drafts:
- draft-ietf-fax-implementers-guide-08.txt
- draft-ietf-fax-content-negotiation-05.txt
They are waiting in the RFC editor queue for publication.
Hiroshi introduced that implementerd-guide I-D should become a RFC along with draft-ietf-fax-tiff-fx-reg-01.txt because of the reference, and the IANA registration is being processed and almost finished, regarding the content-negotiation I-D.

3 The I-Ds that IESG is reviewing (Before IETF Last Call)

Ned Freed, Area Director, apologized for having the last call about
- draft-ietf-fax-gateway-options-04.txt
- draft-ietf-fax-gateway-protocol-06.txt
not yet issued by the IESG. Apparently the request got lost. However, this gave him the opportunity for another round review, and some fixes were identified. A message to the mailing list described the AD's comments.

Ned confirmed that the request for the IETF last Call for
- draft-ietf-fax-esmtp-conneg-01.txt
- draft-ietf-fax-timely-delivery-05.txt
has been sent to the Secretariat, but there are currently more than 30 requests in the queue.

Regarding the following two I-Ds:
- draft-ietf-fax-tiff-fx-reg-01.txt
- draft-ietf-fax-tiff-regbis-04.txt
the IETF Last Call request is also in the queue. We would have some related discussion later in the meeting. Lloyd McIntyre explained again the reason why image/tiff registration document is targeted for BCP and on the other hand image/tiff-fx is targeted for Standard Track (currently for Proposed Standard): image/tiff collects the common use already existing of the tag since MIME existed, and just reflects the common practice to indicate with it that an appropriate TIFF write/reader should be used for the specific body part (although some different flavors exists in TIFF encodings); on the contrary, image/tiff-fx refers to a new file format, not yet widely implemented on the network, thus a strict "standard track" progressing is foreseen for it.

4 Targeted for Draft Standard
4.1 Service

The status of the following I-D:
- draft-ietf-fax-service-v2-05.txt
is dependent on TIFF-FX, DSN specifications. Greg Vaudreuil reported that finally the DSN document was sent to IANA, and, surprisingly, only at this stage it was discovered that some of registry proposed in various documents for DNS were not in place. Ned Freed reported that this case happened for a number of IANA related documents, and the situation is being quickly corrected now, by the new IANA management. Greg confirmed that the needed fixes to the documents and IANA registries should be quick, thus solving these dependencies. Regarding TIFF-FX, we will wait until these documents find their way.


Regarding the following I-D:
- draft-ietf-fax-tiff-fx-11.txt
Larry Masinter presented some considerations and objections regarding the independency of implementation and compliancy with Licensing Rules he believes exists into the interoperability tests which were made for TIFF-FX file format (see slide: fax-2). More over he objects to the overall testing method, proposing the idea that as we are testing Internet Fax objects, we should only use as test tools objects (hardware and software) which are intended to be Internet Fax implementations. He objects that testing single features (like for example the ability of a MIME reader to recognize the appropriate TIFF-FX decoder) does not conform to the general IETF specification for interoperability testing. Lloyd McIntyre objected that the issues raised by Larry were not correct, and that both the independency of the implementation, and the correct licensing were proven by the interoperability report.

It is suggested that this is the first real case where we in the IETF try to move to Draft Standard something which has Patented technology inside, and thus the whole process needs some fixes, especially to ensure that the dialog with the Patent holders is clear at any time, and there are formal procedures to avoid the interaction problems proved by our group in this exercise.

Ned Freed reminded that the IESG is following closely this problem and in particular the TIFF-FX issue. Thus the IESG, having received Larry's objections, will put a careful consideration to verify if the raised points are consistent or not. It is thus strongly suggested to the editors and the WG to make any possible additional effort to clarify these points. Also, he suggested that it is not necessary to recycle the I-D, i.e., draft-ietf-fax-tiff-fx-11.txt.

Following the TIFF-FX discussion, a test plan for MIME image/tiff-fx registration was introduced (draft-ietf-fax-tiff-fx-reg-01.txt), although it is now not for Draft Standard discussion.

Lloyd McIntyre noticed that this is the first time that an interoperability test plan is done for a MIME type registration, and that the test actions (see slides: fax-7, fax-8) are definitely obvious and simple, but in order to fulfill all possible flavors of the Draft Standard process, this test should be done. Larry again suggested that for testing even a single feature like this, one should not use "generic tools" like MIME User Agents etc, but only specific "Internet Fax" implementations which have this MIME capability. A discussion followed, without a clear conclusion, but with the suggestion that the WG considered valid to test single features, but suggested that these features will be then tested also by the implementations conformant to Internet Fax specifications (e.g. as in testing of RFC 2532 "Extended Facsimile Using Internet Mail" or ffpim).

The specific MIME type image/tiff-fx test procedure outlined in the test plan was the accepted (with the above observation). The I-D, draft-ietf-fax-tiff-fx-reg-01.txt, will go for Proposed Standard ASAP, and is aimed for Draft Standard after the necessary revision period. Again it is suggested that, due to the objections raised to the previous interoperability report, while performing the image/tiff-fx tests, additional test with at least 2 independent clearly licensed implementation are added, in order to speed up the final approval of all the other documents, including the TIFF-FX file format.

5 On-Going Internet-Drafts

"As a late X-mas gift", Dave Crocker posted the latest version of
- draft-ietf-fax-ffpim-01.txt
on his web site, asking for the last comments to the WG and mailing-list.
As soon, these will be received and included, the WG last call will follow.

5.2 TIFF-FX extension issue

Regarding the following two I-Ds:
- draft-ietf-fax-tiff-fx-extension-1-01.txt
- darft-mcintyre-feature-schema-extension1-00.txt
there were no news. We confirmed the status is "dormant" waiting for the TIFF-FX issues to be solved.

6 Addressing

Regarding the following I-D:
- draft-allocchio-gstn-02.txt
Claudio Allocchio announced that after polling again the IETF general list for comments last January, he received suggestions for representative of some telephone companies to include an additional Implementer's note in the document, regarding the actual use of "pause" and "tonewait" in real practice (see slide: fax-1). Larry Masinter asked why the specification does not mandate a specific implementation practice foe these elements. Claudio explained there are currently a large number of existing implementations which de-facto use pause and tonewait, and even if most of them commonly implement these features in the same way, mandating them would outlaw some others. However, after a brief discussion, the WG suggested that, instead of an implementers note, it would be much useful to include the suggestions given by the phone companies "as non mandatory specifications", using "SHOULD" and "MAY". Claudio would edit consequently the document and issue a -03 version by the next days.

7 Use of ENUM RFC2916 by Internet Fax

Richard Shockey (see slide: fax-10) introduced the question "What use of ENUM could be done by Internet Fax?". Among possibilities lies the announcement of I-fax devices associated to an E.164 number, including eventually their capabilities (simple/full mode fax for example). The issue of inserting capabilities is also discussed into SIP and CONNEG, and ENUM NAPTR record is just another possible choice. Dave Crocker observed that currently the Internet Fax service seems to "know in advance" that to reach that "service" a known gateway is needed, while using NAPTRs one could "discover" this information from DNS, but the whole model will be different: in fact currently we only connect via known gateways islands of Internet fax service. In general the problem must be investigated carefully. Richard asked the WG to think and discuss also on the list of possible uses, and report them to the ENUM lists, too.


Hiroshi Tamura reported about the ITU-T meeting held in Geneva in February 2002, especially about the T.37 distribution issue (see slides: fax-3, fax-9). Apparently the ITU-T was missing the official licensing letter from Adobe, regarding T.37 (it was missing in their archives). Hiroshi provided them a copy in the meeting and T.37 distribution was re-started.

Also, the plan for submission of TIFF-FX related documents and Implementer's guide was suggested for coincidence between RFCs and T.37.

9 UM ("Unified Messaging" was re-named as "Pink Lemonade".)

Eric Burger introduced some issues which he described into his draft:
- draft-burger-um-reqts-00.txt
(see slide: fax-4). There are some topics which needs further work, but it is not clear in which framework to insert them. They all regards "messaging" in general, even if the generic term "Unified Messaging" should be avoided as it may convey wrong feeling. For this reason the provisional term of "Pink Lemonade" will be used (but Ned recommends possibly a 'more standard' name for the activity :-) ). More over there are items which are not inserted in FAX and VPIM wg charters, and which should require a re-chartering just to insert them, plus the residual work to be finished into FAX and VPIM. The main idea is to think of a structure (WG re-chartered, existing ones?) where to perform the tasks, and keeping together the expert people. The constituency is quite well identified, and the inclusion of somebody also currently not belonging to it is foreseen.

Greg Vaudreuil then presented his draft:
- draft-vaudreuil-um-issues-00.txt
and some further work items (see slide: fax-5) in the same framework.

There are some elements to be considerd in the new work:

Performance requirement, Functional limitations, Message Submission and Notification.

Glenn Parsons, VPIM WG chair, presented 4 possible scenarios to perform the tasks (see slide: fax-6). Among the scenario, the WG suggested #3, i.e. the creation of a new WG with a very clear and delimited charter (to avoid the possible generic definitions of Unified Messaging which would make the new WG an umbrella for nearly anything), which takes care of the new work items suggested, and eventually of those which do not fit properly into FAX, VPIM and eventually IMAPext and others. The existing FAX and VPIM WGs are winding up, and thus should finish their tasks "as they are".

Given than a number of tasks both in FAX and VPIM WGs are expected to be finished after this IETF meeting, Claudio Allocchio proposed that from the next meeting, IETF FAX and VPIM WG meet jointly in the same time slot, also saving time for the same constituency people attending both. The WG expressed consensus on this, which needs also confirmation from the VPIM WG meeting.

Ned Freed agreed that option #3 is the most viable solution, and in case the charter is clear, the new WG startup process should be straightforward.

There would be (announced on the list) some eventual intermediate unofficial BOFs during the meeting (the first one rolled out just before the FAX WG) to define details, and the discussion would continue at VPIM WG meeting to finalize a working plan. An editor for the new charted is wanted.

10 Confirmation of milestone

Finally the milestones were revised, according to the discussion
(see slide: fax-0):

- Draft Standard in October 02
- image/tiff-fx
- Proposed Standard in late April 02
- Draft Standard in October 02
- Gateway protocol
- Fixing and last call April 02
- Last call in April 02
- Proposed Standard in July 02
- TIFF-FX extension
- (dormant)

11 Closing

Claudio Allocchio and Hiroshi Tamura closed the meeting and said "See you all in Yokohama!".


Need for TIFF-FX implementations for Draft Standard
Letter to ITU-T meeting
Pink Lemonade
Required Extensions for Pink Lemonade
Pink Lemonade (Unified Messaging)
Image/tiff-fx Test Plan Draft
Image/tiff-fx MIME Content Subtype and .tfx File Extension Testing
ITU-Telecommunications Standardization Sector Temporary Document XX (WP 1/16)
ENUM Telephone Number Mapping