2.1.4 Internet Fax (fax)

NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01

Chair(s):

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

Applications Area Director(s):

Ned Freed <ned.freed@innosoft.com>
Patrik Faltstrom <paf@cisco.com>

Applications Area Advisor:

Ned Freed <ned.freed@innosoft.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:

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 fax<->Internet 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:

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

Jun 97

  

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

Done

  

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

Internet-Drafts:
Request For Comments:

RFC

Status

Title

RFC2301

PS

File Format for Internet Fax

RFC2302

PS

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

RFC2303

PS

Minimal PSTN address format in Internet Mail

RFC2304

PS

Minimal FAX address format in Internet Mail

RFC2305

PS

A Simple Mode of Facsimile Using Internet Mail

RFC2306

  

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

RFC2542

  

Terminology and Goals for Internet Fax

RFC2530

PS

Indicating Supported Media Features Using Extensions to DSN and MDN

RFC2532

PS

Extended Facsimile Using Internet Mail

RFC2846

PS

GSTN address element extensions in e-mail services

RFC2879

PS

Content feature schema for Internet fax

RFC2880

  

Internet fax T.30 Feature Mapping

Current Meeting Report

Minutes of Internet fax WG (fax) at IETF-50 Minneapolis

13:00 - 15:00, March 19, 2001
Chaired by Hiroshi Tamura and Claudio Allocchio
Reported by Graham Klyne, Hiroshi Tamura and Claudio Allocchio

All slides at the meeting are found at the following URL:
http://www.imc.org/ietf-fax/

----------------------------------------------------------------------
1 Agenda bashing
----------------------------------------------------------------------
Claudio Allocchio introduced the agenda and it was accepted.

----------------------------------------------------------------------
2 Charter
----------------------------------------------------------------------
The first topic pointed out at the meeting was "where is our new charter?" From a brief check with the AD (Ned Freed), we discovered that something went wrong into the process when the new charter was submitted last June 2000. Thus we decided to re-submit it now, and also to update its milestone section with the current updated data. The new updated charter was thus immediately re-submitted to ADs by the chairs very soon after this meeting. The corresponding page at IETF site will be updated soon.

----------------------------------------------------------------------
3 Status of pending Draft Standard
----------------------------------------------------------------------
----------------------------------------------------------------------
3.1 TIFF-FX
----------------------------------------------------------------------
There are the two I-Ds.
- draft-ietf-fax-tiff-fx-09.txt (Obsoleting RFC 2301)
- draft-ietf-fax-tiff-regbis-02.txt (Obsoleting RFC 2302)
They define file format for internet fax.

Technically the draft is OK, but there was one comment from Adobe during IESG Last Call. It is a possible Adobe IPR problem to TIFF-FX. It has been escalated by the AD at IAB level.

John Klensin (IAB) on TIFF-FX Adobe concerns as follows:
FAX WG has done its job. The solution to the IPR problem involves some works between IETF, Adobe and others parties (e.g. Xerox and the editors) to resolve the issues. The WG should not allow itself to be diverted by this non-techcnial issue. If that's not true, someone should stand up and say it now.

At the meeting was also present Scott Foshee (Adobe): He said that there are some concerns that need to be resolved (I speak that silence is not regarded as acceptance), and Adobe and IAB are working on them.

The editors, IAB, ADs, Adobe and WG chairs will do their best to resolve the issue soon.

----------------------------------------------------------------------
3.2 Addressing
----------------------------------------------------------------------
There are the two I-Ds.
- draft-ietf-fax-minaddr-v2-02.txt (Obsoleting RFC 2303)
- draft-ietf-fax-faxaddr-v2-02.txt (Obsoleting RFC 2304)
They define minimum and fax addressing.

Technically there are no objections, but some small comments and fixes requests from the AD were submitted to the editor during the meeting. They are only editorial and clarification issues. Therefore, there are no problems in introducing them into the drafts, which will be updated according to these comments by next week, and will directly go into the final approval process.

----------------------------------------------------------------------
4 Targeted for Draft Standard
----------------------------------------------------------------------
----------------------------------------------------------------------
4.1 Service (Simple mode)
----------------------------------------------------------------------
There is one I-D. The current status was introduced.

- draft-ietf-fax-service-v2-03.txt (Obsoleting RFC 2305) It defines simple mode internet fax.

-02 was expired. -03 is completely the same as -02. There are three dependencies. They are DSN, TIFF-FX and Addressing. TIFF-FX and Addressing are FAX-WG issues and can be solved soon within our WG. But, in fact, this I-D is stalled due to the lack of DSN "Draft Standard" status. Unfortunately, there is no progess about the DSN status. It was decided to go anyhow for the WG last-call (AD agrees) and submit the document for approval. Publication could not happen until dependencies are resolved, but this is expected to happen soon.

----------------------------------------------------------------------
5 Targeted for Informational
----------------------------------------------------------------------
----------------------------------------------------------------------
5.1 Implementers Guide
----------------------------------------------------------------------
There is one I-D. Hiroshi Tamura introduced it.
- draft-ietf-fax-implementers-guide-06.txt.
It addresses implementation guidance for RFC 2301, RFC 2305, RFC 2532, etc. It is informational.

There is one comment during WG Last Call. They are just small addition about color and re-arrangement of sections in TIFF-FX. Being a purely small issues, no new WG last call is required. After -07 will be published, the request for IESG consideration will be done.

----------------------------------------------------------------------
6 On-going Internet-Drafts
----------------------------------------------------------------------
----------------------------------------------------------------------
6.1 Gateway issue
----------------------------------------------------------------------
Katsuhiko Mimura presented the two I-Ds.
- draft-ietf-fax-gateway-protocol-03.txt
- draft-ietf-fax-gateway-options-01.txt
They address internet fax gateway protocol which has two functions: onramp and offramp.

With regard to protocol-03, there are mainly the following changes from -02 (See slides for details):
- A format of image data is defined by "Simple Mode"
- Operational mode is "store and forward"
- Addition of user authorization in Offramp
- Error information should be recoded and be notified to administrators in failure of return notice.

With regard to options-01, there are mainly the following changes from -00 (See slides for details):
- Any error information should be recoded in log.
- Recommended service in return notice
- Specific examples about log information

Larry Masinter said that there seems to be many conformance requirements that could be reasonablly left as advice to implementers, expecially concerning the use of "logs" and their format. He asked about any particular criteria used for selecting requirements vs advice. He suggested the editor to consider the use of "MAY" instead of "SHOULD" for issues not related in interoperability.

Claudio Allocchio pointed out that a good reason for specifying the log formats may have something to do with keeping logs for message tracking. Masinter commented that it is maybe strengthened to achieve interoperability. It was also noted that there are privacy related issues about logs, execially in Europe. Hiroyuki Ohno suggested to use syslog (or secure variant) for messaging logging.

The editor received all the commetns and is going to prepare new versions, according to them.

The editor also suggested that WG Last Call for these I-Ds is at next IETF (August) meeting.

----------------------------------------------------------------------
6.2 FFPIM
----------------------------------------------------------------------
----------------------------------------------------------------------
6.2.1 FFPIM itself
----------------------------------------------------------------------
Dave Crocker presented the one I-D.
- draft-ietf-fax-ffpim-01.txt

It mainly refer the content-negotiation I-D and the timely-delivery I-D.

From this version, it newly addresses ESMTP-based content negotiation and direct mode.

With regard to content-negotiation, we need to make reference to registry and procedures for updating with new features. With regard to timely-delivery, there were no special comments about it.

With regard to ESMTP-based content negotiation (CONNEG), the question was raised whether we should define additional channel for doing content negotiation in SMTP session, rather than using MDN extensions. In that case, the server must know everything needed about the address. It could be specified as an appendix to this document.

Larry Masinter reminded that previous attempt was pushed back because of assumed presence of firewalls. Dave Crocker considered that the gateway would be presumed to act for the endpoint. Ned Freed (AD) noted that this extension is different; there are real concerns that this will be unimplemented in the real world, but this is something that should stop its secification for the time being, provided that it doesn't create difficult-to-solve problems for later.

----------------------------------------------------------------------
6.2.2 Content Negotiation
----------------------------------------------------------------------
Graham Klyne presented.
- draft-ietf-fax-content-negotiation-04.txt
Content negotiation I-D defines a technique that permits an originator to send the best version known by the originator to be supported by the recipient and then to send a better version if the recipient requests it.

He presented the status of the documents. There were a few discussions in ML in February and they are already considered in next version. Except for that, there were no comments in the last weeks, thus it seems ready for final publication. The WG did no objection to it.

Larry Masinter suggests that "content-type" should always be included in "content-alternative" header. The editor replied that this is only needed when a non-TIFF file format is being used. In ML, this issue will be resolved.

----------------------------------------------------------------------
6.2.3 Timely Delivery
----------------------------------------------------------------------
Graham Klyne presented.
- draft-ietf-fax-timely-delivery-02.txt
Timely-delivery I-D defines a set of capabilities that permits an originator to request that the email transport system seek a particular timeliness in delivery and then assures that the system will report the success or failure of that request.

There were a few discussions in ML in February and they are also already considered in next version. The WG did no object to final publication.

----------------------------------------------------------------------
6.3 Fax processing status
----------------------------------------------------------------------
Toru Maeda presented.
- draft-maeda-faxwg-fax-processing-status-01.txt

It addresses the fax processing status such as the information about succesful received pages, using MDN extension field. It also addresses the detailed results such no-support of resolution. (See slides for detail.)

The chairs asked whether this should be used with EIFAX or FFPIM.
There is no clear orientation in the people present in the room.
The question will be taken to the mailing list.

There are the following discussion issues include the above:
- In which mode it is required? (EIFAX, FFPIM, Terminal Mode)
- Is it required in DSN?
- Multi Files: indication of success/failure for each MIME attachement
- IPP notification
- Relation with Notification ML

There are no objections about the introduction.
The WG continues the discussion.

He also suggests that next version will be published July 2001 and target of WG Last Call is Decemeber 2001.

----------------------------------------------------------------------
6.4 Terminal mode
----------------------------------------------------------------------
Toru Maeda presented the two I-Ds.
- draft-maeda-faxwg-terminal-mode-goals-01.txt
- draft-maeda-faxwg-terminal-mode-protocol-01.txt

Terminal mode is aimed for easiness to implement and full compatible to G3 fax. The main reason for conceiving the Terminal mode is the key complaint against existing EIFAX, etc: it seems that the all other methods introduce a serious complexity and size of implementation. It relates to the same principle: emulate over the Internet the end to end capabilities of G3 faxes.

It provides all features of classic fax and is designed for embedded system. It also addresses legal support.

The followings are main key elements (See slides for detail):
- End to end and one SMTP session
- Page by page confirmation
- Capability Exchange before data transmission
- TIFF-FX support
- Cover page and fax header
- Security
- Fallback to EIFAX or simple mode

There are mainly the following discussion issues include the above:
- Extension to FFPIM or EIFAX?
- Should request "processing confirmaiton"
- No need DSN confirmation
- MDN in separate session?
- NEW ESMTP command
- Extension of RFC2879 which supports T.30 signals
- Addressing
- Polling
- Gateway

The question was raised about Gateway mode. The editor believes that terminal mode can be extended to operate with gateways. Gateway may operate in real-time or store-and-forward mode.

The editor also asked the WG if "terminal mode" documents and proposal should be merged with FFPIM. He commented they're very similar in principle, but all the specifications are different currently. The WG has no current clear indication about this. There is the possibility to consider the merge, but the question will go back to the mailing list.

There are no objections about the introduction.
The WG continues the discussion.

He also suggests that next version will be published July 2001 and target of WG Last Call is Decemeber 2001.

----------------------------------------------------------------------
6.5 TIFF-FX extension
----------------------------------------------------------------------
No editors could not attend the meeting. Hiroshi Tamura presented slides provided by Lloyd McIntyre, with the latest changes.
- draft-ietf-fax-tiff-fx-Extensions-1-01.txt It mainly addresses the following extensions (See slides for detail):
- Resolutions and associated image widths
- More than 3 Layer in MRC
- Introduction of JBIG2

Questions should go directly on the list, to reach the editor.

The editors suggest that the WG Last Call for TIFF-FX extension and the associated Schema Extension are at next IETF August meeting.

----------------------------------------------------------------------
7 ITU-T issue
----------------------------------------------------------------------
Hiroshi Tamura introduced it.

The WG's response is needed for ITU-T SG16 meeting, starting at the end of May. There are three requests from ITU-T.

1. Request of new FFPIM I-D
The WG already has the new version, draft-ietf-fax-ffpim-01.txt.

2. Request of fax status information in MDN
The WG has already the related I-Ds and the discussion starts.

3. Request of adding Terminal mode to the WG charter
The WG has already the related two I-Ds and the discusion starts. The WG can agree to some items provided by it. Others may not be confirmed. It depends on the WG's future discussion.

He promised that the letter is circluated for check, prior to ITU-T SG16 meeting. After that it is submitted to SG16.

----------------------------------------------------------------------
8 Milestones review
----------------------------------------------------------------------
Some discussion on merging Terminal mode proposal into FFPIM, which would delay FFPIM. General feeling was uncertain, more inclined to take FFPIM forward as-is to lessen risk of uncontrolled delays.

There was some discussion on the charter, particularly whether TIFF-FX extensions were explicitly adopted into the charter. A proposed charter containing this work was posted to the list on 14-Jun-2000, but seems to have subsequently got lost in the system.
The current published charter for the WG is very out-of-date.

The followings are updated and agreed milestones.

Implementers-Guide April: -07 and Request for IESG Consideration
Content-Negotiation April: -05 and WG Last Call
Timely-Delivery April: -03 and WG Last Call
FFPIM itself April: -02 and WG Last Call
Fax Gateway Prior to August: -04(protocol) and -02(options)

TIFF-FX Extension Prior to August: -02

Schema of the Extension Prior to August: -00 and -01

Fax Processing Status Prior to August: next version

Terminal Mode Prior to August: next version

----------------------------------------------------------------------
9 Adjournment
----------------------------------------------------------------------
Claudio Allocchio announced the FAX WG meeting was adjourned.

Slides

Agenda
Fax Processing Status
Internet FAX Gateway
draft-ietf-fax-implementers-guide-06.txt
ITU-T issues
Fax WG milestones
Terminal Mode Protocol
Goals for Terminal Mode
TIFF-FX Extension Set 1