Internet Fax (fax) Charter

2.1.4 Internet Fax (fax)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

http://www.imc.org/ietf-fax -- Additional FAX WG Page

NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.

Last Modifield: 05/08/2002

Chair(s):

Claudio Allocchio <Claudio.Allocchio@garr.it>
Hiroshi Tamura <tamura@toda.ricoh.co.jp>

Applications Area Director(s):

Ned Freed <ned.freed@mrochek.com>
P. Faltstrom <paf@cisco.com>

Applications Area Advisor:

Ned Freed <ned.freed@mrochek.com>

Mailing Lists:

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

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
Done		Submit final draft for FFPIM to IESG for publication
Done		Submit final draft of gateway requirements
JUL 01		Submit second draft of Fax status information
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

Internet-Drafts:

- draft-ietf-fax-service-v2-05.txt

- draft-ietf-fax-tiff-fx-11.txt

- draft-ietf-fax-content-negotiation-05.txt

- draft-ietf-fax-implementers-guide-08.txt

- draft-ietf-fax-timely-delivery-05.txt

- draft-ietf-fax-tiff-regbis-05.txt

- draft-ietf-fax-gateway-protocol-08.txt

- draft-ietf-fax-gateway-options-05.txt

- draft-ietf-fax-esmtp-conneg-02.txt

- draft-ietf-fax-tiff-fx-reg-01.txt

Request For Comments:

RFC	Status	Title
RFC2302	PS	Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration
RFC2303	PS	Minimal PSTN address format in Internet Mail
RFC2301	PS	File Format for Internet Fax
RFC2304	PS	Minimal FAX address format in Internet Mail
RFC2306	I	Tag Image File Format (TIFF) - F Profile for Facsimile
RFC2305	PS	A Simple Mode of Facsimile Using Internet Mail
RFC2542	I	Terminology and Goals for Internet Fax
RFC2532	PS	Extended Facsimile Using Internet Mail
RFC2531	PS	Content feature schema for Internet fax
RFC2530	PS	Indicating Supported Media Features Using Extensions to DSN and MDN
RFC2846	PS	GSTN address element extensions in e-mail services
RFC2880	I	Internet fax T.30 Feature Mapping
RFC2879	PS	Content feature schema for Internet fax
RFC3192	DS	Minimal FAX address format in Internet Mail
RFC3191	DS	Minimal GSTN address format in Internet Mail

Current Meeting Report

TUESDAY, July 16 at 0900-1130
==============================

CHAIRS:
Claudio Allocchio <Claudio.Allocchio@garr.it>
Hiroshi Tamura <tamura@toda.ricoh.co.jp>

---------------------------------------------------------------------
Opening
---------------------------------------------------------------------
FAX WG meeting was held jointly with VPIM WG, on July 16 2002. Hiroshi Tamura, co-chair of FAX WG, welcomed the participants at his home town Yokohama and started the meeting.

---------------------------------------------------------------------
Agenda Bashing and etc.
---------------------------------------------------------------------
Hiroshi Tamura proposed to change slightly the order of the agenda discussion, moving the ESMTP-CONNEG and FFPIM topics at the end of the Fax part of the meeting, in order to allow more time to these topics without compressing the other ones. The change was apprved unanimously. We also received apology from Ned Freed, an Area Director of Application Area, who could not be with us, but Patrik Faltstrom, another Area Director, was here replacing him.

---------------------------------------------------------------------
The I-Ds which IESG approved and are in RFC editor's queue
---------------------------------------------------------------------
Hiroshi Tamura reported that the following documents are already in the RFC editor's queue:

- draft-ietf-fax-implementers-guide-08.txt
- draft-ietf-fax-content-negotiation-05.txt
- draft-ietf-fax-tiff-regbis-05.txt
- draft-ietf-fax-tiff-fx-reg-01.txt

He assured the WG that the chairs should take action with RFC editors and IANA administrators, in order to have the RFC number assigned ASAP (i.e. prior to publication) to the tiff-regbis and tiff-fx-reg I-Ds. It is needed for Draft Standard process of TIFF-FX (RFC 2301) itself as well as the reference in implementers-guide I-D and ITU-T T.37.

After the meeting, Hiroshi Tamura asked RFC editors and IANA administrators for their action. Also, content-negotiation I-D was assigned RFC number and was published. It is RFC 3297.

---------------------------------------------------------------------
The I-Ds for which IETF Last Call was finished
---------------------------------------------------------------------
Hiroshi Tamura presented the list of documents whose IETF last call was completed without significative comments:

- draft-ietf-fax-gateway-protocol-08.txt
- draft-ietf-fax-gateway-options-05.txt
- draft-ietf-fax-service-v2-05.txt

Regarding service-v2-05 I-D, it refer DSN (RFC 1894 update) and TIFF-FX (draft-ietf-fax-tiff-fx-11.txt).

Greg Vaudreuil reported the status of DSN (see slides). After IANA questions were answered in April, and an extended implementation report was submitted in early June, the document is currently on IESG table, without any apparent outstanding issues. The ADs will check its status, too.

The draft-ietf-fax-tiff-fx-11.txt I-D is waiting for the supplementary implementation report to be published (see later on).

We confirmed, even if the targeted I-D refers other I-Ds, it may finish IETF Last Call and move to RFC-editors' queue. In that case, it will be published as RFC after all the reference I-Ds become RFC. In fact, service-v2-05 I-D will finish IETF Last Call sooner or later, while it refers DSN and TIFF-FX.

---------------------------------------------------------------------
The I-D which IESG is reviewing (Before IETF Last Call)
---------------------------------------------------------------------
Hiroshi Tamura presented one I-D on the IESG queue (Area Directors review stage):

- draft-ietf-fax-timely-delivery-05.txt

There were no comments and modifications since the last meetings. The WG Last Call was already finished. Thus, we just wait for the ADs review and for the reference to draft-vaudreuil-1983ext-01.txt to be solved.

The 1983ext I-D status was also updated by Greg Vaudreuil. The situation is very similar to DNS. There are no outstanding issues. After the meeting, Greg Vaudreuil and Hiroshi Tamura agreed that FAX WG will do the WG Last Call after it is reposted, as it is already expired.

---------------------------------------------------------------------
TIFF-FX implementation report
---------------------------------------------------------------------
Hiroshi Tamura introduced it. There is already the original report in IETF site. This was for the additional (new) report to be submitted.

He explained (see slides) that the CIAJ (Communications and Information network Association of Japan), whose members practically contain all the fax manufactures in Japan, agreed to perform an extended further TIFF-FX implementation test, to supplement the original report. CIAJ already succeeded IFax and TIFF-FX testing in 1999 and 2001 for Profile S, F and J. The participats are Oki Data, Canon, Kyocera Mita, Sharp, Toshiba-Tec, NEC, Fuji-Xerox, Brother, Matsushita, Minolta, Murata and Ricoh.

The testing for Profile C, L and M is planned. Some testings for Profile C was done successfully last month, and the remains will be done by the end of August.

CIAJ requires the new report should be supplementary to the orignal report. It will include specified product name, supported tag information, license validation for some profiles It will be submitted by the end of September.

Patrik Faltstrom, Area Director, explicitly reminded that the license statement should specify that the company has exercised the proof of "independent licensing" in implementing their products. The chairs should be careful for it.

---------------------------------------------------------------------
Addressing
---------------------------------------------------------------------
-draft-allocchio-gstn-03.txt

Claudio Allocchio made a short report about the addressing documents. After the last meeting and the suggestions from the WG, version 03 was published in March. The only difference from version 02 was that the "implementer's note", regarding 'pause' and 'tonewait' was turned into a recommended (SHOULD, MAY) implementation specification. As there were not further comments, and a numver of IDs are starting to use the docuement as a reference, the ADs decided to issue the IETF last call: the request was submitted on July 15th.

---------------------------------------------------------------------
FAX in ENUM
---------------------------------------------------------------------
Kiyoshi Toyoda reported on the I-D in preparation to register IFax service in ENUM with IANA. The IFax functional specification is different from the normal email service, PSTN-fax service and T.38 fax service.

The returned DNS NAPTR record will specify an email address that is to be used for reaching the target system fax mailbox. The email address is used in accordance with "Simple Mode" RFC 2305, "Extended Mode" RFC 2532 or FFPIM.
Service name: "ifax"
Protocol: smtp
URI scheme: "mailto"
Intended Usage: COMMON

Patrik Faltstrom, as editor of the current ENUM NAPTR record specification, reported the discussion of the preceding day at the ENUM WG, where the final syntax was again discussed. Now the final decision will be taken on the mailing list. Thus, the Ifax ENUM I-D, which Kiyoshi Toyoda prepare, will have to follow the discussion, and conform with it.

However, this is not a problem for the IFax case, as we do not require specific hierarchical syntax for the resource record data fields. Patrik and the WG asked Kiyoshi Toyoda now to submit the text of the I-D, and discuss it within the FAX WG, with CC to the ENUM mailing list, although Patrik commented it should be mainly discussed and solved in FAX WG. He promised he will submit it within a short time.

---------------------------------------------------------------------
ITU issues
---------------------------------------------------------------------
Hiroshi Tamura introduced. The next ITU-T SG16 meeting is held in October 2002. He will report our activities there. Also, As a WG the documents which are referenced by ITU-T documents and need some processing are:
"image/tiff" MIME Sub-type Registration
"image/tiff-fx" MIME Sub-type Registration
Implementers Guide

FAX WG are now asking the RFC editors at least for the assignement of the RFC number. He will also report on the status of the TIFF-FX issue, which should progress after the supplementary implementation report is submitted in September. The inputed information will be decided on the mailing list.

---------------------------------------------------------------------
SMTP Service Extension for Content Negotiation (ESMTP CONNEG)
---------------------------------------------------------------------
Claudio Allocchio summarized the status of the discussion which started on the mailig lists after the IETF last call was issued for the Service Extension for Content Negotiation. The new version is at http://www.brandenburg.com/specifications/draft-ietf-fax-esmtp-conneg-03.txt. It is not yet available at ID repository.

On the mailing lists (including the IETF general one), we saw discussion which mainly can be grouped under these three major topics:

- is the proposal doing layering violations of the model MTA-MUA?
- how the proposal handles the multi-relays case?
- which is the most efficient/more elegant specification approach, i.e. use RCPT TO or another sepcific command and then RCPT TO?

On the mailing list the dabate did not show yet a clear direction, and the WG discussion should help in clarifying ideas. After Claudio's introduction, Dave Crocker, one of the authors of the I-D, started the debate, thanking Claudio for his very neutral introduction of the topics, and explained the reasons why he is convinced that the current approach taken into the document should be the one to go for.

On the layering violations (i.e. the MTA knowing the MUA capabilities and keeping information about it to report back to the sender MUA), Dave suggested that we should be pragmatic, and consider that for most of the cases where Internet Fax is involved, the final MTA and MUA are on the same host, and very often are the same piece of software. This might not be the case in all possible circumstances, but it will quite well fit the model. Furthermore, most of the Ifax traffic would be point to point, without relaying. There were comments reminding that in most of the corporate cases, this might be false, as firewalls and single entrance SMTP relay are in common use, and this might introduce complications into the paradigm.

After a discussion about the general model, which showed that there is not a common behaviours expected from the current SMTP messaging system, the WG pointed out that this is not a situation specific to Ifax, but it applies in general to all messaging purposes, incliding VPIM, MIME etc. Solving the basic philosophical problem thus requires the involvement of the whole SMTP area expertise people, and not only the FAX WG people.

There was a comment that the debate on this should continue either on the general IETF list, or considered to be moved to the area covered by the proposed WG on "unified messaging" having a BOF later during the week (LEMONAGEe).

The discussion then focused on the implementation methods, i.e. should we use an option into the RCPT TO command, and thus use a single command, or should issue first another command, and then when capabilities of the recipient(s) are discovered, only then issue the set of RCPT TO commands?

The aim should be the efficiency of the interaction in the transport system between MTAs, and also some MUAs. Dave defended the current specification, where a single command (RCPT TO) is used to ask and discover capabilities of the recipient MUA, while Greg Vaudreuil prefered the idea of another command to be issued before the RCPT TO sequence is started, in order to sort first recipients depending on capabilities. Claudio, removing momentarily his chair hat, also supported the single command, in favour of a more practical, even if probably less elegant, approach. Patrik Faltstrom reminded that Ned Freed commented a lot on this topic, and at the end asked the WG to come to a conclusion on this two alternates. Harald Alvestrand, as a member of the IESG, also reminded that this is the fundamental topic where the IESG should be convinced of the best solution, and also removing his IESG hat for a moment, he instead suggested that two separate commands would do an easier job for implementors. Claudio reminded that there is no apparent prevalent opinion on how the current SMTP system behaves, and reminded that some implementers think the SMTP world is mostly "one recipient per MTA" when there is not a firewall or similar security measures in effect, and "many users per relay MTA" where these measueres are in effect.

A query to the ones present in the room showed 1 hand in favour of a simple command (current specification), 2 hands in favour of using 2 separate commands and the vast majority of the WG, which did not make its mind on it yet (the FAX WG is not so good in humming, we use hands). Keeping in mind that also many other people not present in the room have opinions on this topic, the further discussion and decision was moved to the mailing lists involved, including the general IETF list.

---------------------------------------------------------------------
FFPIM
---------------------------------------------------------------------
Dave Crocker reported the the newest version of the document contained some minor edits (upon suggestions from Dan Wing), and asked to those presents some questions:

- Use of ESMTP options as MAY or SHOULD?
- FFPIM conformance require RFC2305 and RFC2532 conformance?

We decided to vote by a show of hands. The result was "SHOULD" and "require". After the meeting, Hiroshi Tamura again asked them in the mailing list. But, there were no comments. Thus, those are the results.

Moreover, the document refers ESMTP CONNEG specification. It was agreed that the CONNEG text should be more detailed in ESMTP CONNEG I-D, and that we should of course adapt it to the output of the dicussion about it.

---------------------------------------------------------------------
Closing
---------------------------------------------------------------------
FAX WG handed over to VPIM agenda points, and Glenn Parsons, chair of VPIM WG, chaired the rest of the meeting. Note that the FAX and VPIM WGs confirmed they will continue joint meetings until all their work is finished. Thus, we will meet again together in Atlanta, in November 2002.