2.1.5 Internet Fax (fax)

NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 06-Mar-00

Chair(s):

Claudio Allocchio <Claudio.Allocchio@garr.it>
James Rafferty <jrafferty@worldnet.att.net>
Hiroshi Tamura <tamura@toda.ricoh.co.jp>

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

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

RFC2531

PS

Content feature schema for Internet fax

RFC2532

PS

Extended Facsimile Using Internet Mail

Current Meeting Report

IETF FAX-Ext Group meeting was held at 15:30-17:50 on March 30.

------------------------------------------------------------------------
1 Opening
------------------------------------------------------------------------

New co-chairs(Claudio Allocchio and Hiroshi Tamura) introduced themselves. They thanked the out-going chair, James Rafferty and the achievements of our working group.

The meeting agenda itself was introduced and accepted.

------------------------------------------------------------------------
2 Charter
------------------------------------------------------------------------

This is the first meeting since new charter was created. New charter was discussed.

Concerning the phrase "full equivalence of T.30 service", a question about the relation with T.38 was raised. T.38 describes the procedure for Real-Time G3 fax over IP networks. It is NOT a service over Internet mail, which Fax working group has been studying for years. The group confirmed to continue the study of the specification that is equivalent to T.30 service over Internet mail.

There was an opinion that the phrase "universal messaging issues" should move and be included in the first sentence in the first paragraph. The group agreed it.

Concerning interconnecting the GSTN fax services, there are onramp and offramp gateway related issues. But they have not been deeply discussed so far in the group. The group confirmed there are things to do for these issues.

The group confirmed the Implementers' Guide is useful for quality of service.

The group confirmed FFPIM is a base for equivalence of T.30 service. It includes capability negotiation, in which a sender can transmit the "best" fax image the receiver indicates. There was an opinion about the use of RESCAP protocol for negotiation.

A question about document authentication issue was raised. There are PGP, S/MIME, digital signature, and so on. The group confirmed to study the authentication under FFPIM.

Related to FFPIM, the group confirmed TIFF-FX extensions like JBIG2 should be included. The target date of initial drafts of the extensions was modified as Jun 2000. Concerning the schema, it remains Sep 2000.

The group confirmed to continue the cooperation with ITU-T and other IETF WGs such as VPIM.

The group agreed to the charter. Modified charter will be circulated.

------------------------------------------------------------------------
3 Status of internet drafts
------------------------------------------------------------------------

1) Internet drafts waiting for RFC

- draft-ietf-fax-feature-schema-v2-01.txt
- draft-ietf-fax-feature-T30-mapping-03.txt

The chair introduced these are in the queue by IESG review and
will be approved soon.

2) Internet drafts waiting for Draft Standard.

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

The chair introduced the interworking report was circulated and there are no problems. ADs will review it. Related to this document, the status of draft-ietf-fax-tiff-regbis-00.txt (Updated RFC2302)was introduced.

[After the meeting:
The out-going chair(James Rafferty) told this draft is dependent on RFC2302. He suggests draft-ietf-fax-tiff-regbis-00.txt should be BCP in order that tiff-fx is not dependent on tiff-regbis. It is possible because tiff-regbis only contains the IANA registration information. We agreed that tiff-fx, along with the supporting interworking report, should be submitted to the IESG for Draft Standard consideration while the tiff-regbis draft should be submitted for consideration as a BCP.]

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

There are dependency problems(DSN, IMAP4 and Addressing). Concerning DSN, there is one idea in order not to be dependent on DSN. It was circulated in ML. For others, the group confirmed to wait for being Draft standards. The right format of the results of Interworking (FaxConnect2) is necessary. Hiroyuki Ohno, who was responsible for FaxConnect2 at Japan, will report it with other key people.

- draft-ietf-fax-faxaddr-v2-00.txt, draft-ietf-fax-minaddr-v2-00.txt

Interworking is not enough, especially for /T33S issue. T33S conforms to ITU-T T.33(Facsimile routing utilizing the subaddress). It is kind of an application profile. There are fax machines that support T.30 SUB signal. But there are very few implementations about T.33. A question was raised about how to validate if two independent implementations interwork for addressing. About this question, there was an opinion it is that gateways can handle the specified address correctly.

------------------------------------------------------------------------
4 On-going Internet drafts
------------------------------------------------------------------------

1) draft-ietf-fax-ffpim-00.txt

Dave Crocker introduced it.

FFPIM abbreviates Full-mode Fax Profile for Internet Mail. This specification defines "full mode" carriage of facsimile data over the Internet, building upon that previous work and adding the remaining functionality necessary for achieving reliability, timeliness and capability negotiation for Internet mail that is on a par with classic T.30 facsimile.

About timeliness, it refers to draft-ietf-fax-timely-delivery-00.txt.
About capability negotiation, it refers to draft-ietf-fax-content-negotiation-01.txt

2) draft-ietf-fax-timely-delivery-00.txt

Graham Klyne mainly introduced it.

This specification defines a set of capabilities which permits an originator to request that the email transport system give a particular timeliness in delivery and then assures if the system will report the success or failure of that request.

Specifically, it provides "while you wait" delivery of a message, with overall end-to-end transmission times of similar order to those for fax(seconds rather than minutes). It is also designed to operate within the ESMTP extension framework, allowing the sender to decide fallback to traditional e-mail if timely delivery service is unavailable.

This can be achieved by the three ESMTP extensions(DSN, DELIVERBY, CONFORMANCE-REQUIRED). DELIVERBY imposes a responsibility on MTAs to complete delivery within a specified time. CONFORMANCE-REQUIRED imposes responsibility on MTAs to complete delivery in conformance with stated requirements, or not to deliver the message.

There was the following comments about timelines. Page-by-page confirmation like T.30 cannot be done. Those kinds of confirmation are not necessary over Internet-mail.

There was an comment that all MTAs should be changed to configure it.

Graham Klyne also commented the reverse(DSN return) path is not considered now and it should be done for complete timeliness.

3) draft-ietf-fax-content-negotiation-01.txt

Graham Klyne mainly introduced it.

This specification uses a post-hoc technique that permits an originator to send the best version known by the originator to be supported by the recipient and then sending a better version the recipient requests it.

There are the following goals.
I. Normal behavior with ordinary e-mail
II. No "administrative non-messages"
III. Work with current simple- and extended-mode fax systems
IV. Recovery from stale cached capability information
V. Possible low-memory device implementation

Sender specifies MDN option "Alternative-available" and alternative features in "Content-alternative". Receiver indicates "alternative-preferred" disposition-modifier-extension and its capabilities in MDN. Sender selects alternative format based on receiver's capabilities. Negotiation case example and optimized one were introduced.

A question was raised about negotiation mechanism. Graham Klyne emphasized it is sender who judges the capabilities indicated by receiver and selects the format. He also notified the Receiver's state issue.

4) draft-ietf-fax-implementers-guide-01.txt

Vivian Cancio introduced it.

This guide addresses implementations of the followings.
- RFCs 2305, 2532, 2301
- RFC 2298 in connection with RFC 2532
- Others related as needed

Users want to know if returned MDN indicates Main body text or TIFF attachments. There are no suitable disposition-types. This draft describes guides on how to express, using the existing definitions. It also describes TIFF interoperability issue, including the issue of low-end limited memory embedded recipients.

There are controversies that how many TIFF problems should be included and if examples should reflect desired best practice to accomplish model or not.

There were suggestions on Subject field and first part text of MDN as follows.

- Subject
"Return Receipt:", followed by original subject field text "Disposition Notification:" followed by original subject field text

- First part text
"This is a Return Receipt for the mail that you sent to __ etc.
The message and attached file may have been printed or saved.
This is no guarantee that the message has been read or understood."

There was an indication as open issues that MDN new disposition-types (e.g. "telephone line busy" etc.) and MDN message part identification (main body vs. attachment etc.) should be addressed as standard track (other internet drafts). There were the following comments. In other mail applications, there are similar issues. MDN extension is considered in other WGs.

The group confirmed to refine this draft.

------------------------------------------------------------------------
5 TIFF-FX extensions
------------------------------------------------------------------------

Lloyd McIntyre introduced Tiff-fx extensions.

There are the following two extensions.

1) New field values and/or relaxed constraints

- higher resolutions
300x600, 600x600, 400x800, 600x1200 and 1200x1200 are introduced.

- MRC (more than 3 MRC layers)
Arranged in mask and foreground pairs.
It is beneficial to synthetic images.

- MRC (multi-strip background and foreground layers)
It is to reduce overhead of IFDs when there is no change in coding parameters between strips (i.e. cases where multiple IFDs are not needed and a single IFD will do) by removing constraint requiring separate IFD for each TIFF strip

2) New fields and/or profiles

- More than one profile within document
- allow use of more than one profiles within a document
- add new MultiFaxProfile field to the GlobalParameters IFD
- use of the MultiFaxProfile field is signaled by a FaxProfile field value of X'FF'

- JBIG2 (T.88) (Black and White, Color)

JBIG2 boosts compression of text-like documents by 3x or more by retaining similar shapes across multiple images. There are 3 ways in which JBIG2 may be used in TIFF-FX. One is in B&W case and two are in Color case. Two new profiles, 3 new fields and a new value for an existing field may be required to accommodate the three usage

- Annotation
It brings life to raster images by accommodating a limited level of editability. The result is increased desktop citizenship and a significant step towards realization of integrated messaging. There are 3 forms(information annotation, quality annotation and tag annotation) of annotation to be considered. New fields and new values for existing fields may be required to accommodate the three forms.

He will submit the internet-drafts.

------------------------------------------------------------------------
6 Fax Gateway issue
------------------------------------------------------------------------

Takurou Kitagawa explained new proposal with the use of HTTP and CGI, concerning Fax Offramp issues.

In his ideas, users put only a telephone number into a device which is connected to Internet. The device accesses to a directory server and resolves the addressing information for the number by getting it from the directory server. He emphasized the gateway local policy.

This issue may possibly be solved in ENUM WG. The group confirmed the discussion should take place in both Fax WG and Enum WG. No internet draft exists. Therefore, he will submit the internet-draft about it.

------------------------------------------------------------------------
7 ITU-T issue
------------------------------------------------------------------------

There was no time to introduce ITU related matter, as scheduled. Therefore, the chair promised to circulate this issue in ML soon.

[After the meeting:
The chair(Hiroshi Tamura) circulated the report of February SG8 meeting and the information of re-organizing ITU-T in ML. Q4/SG8 confirmed to continue cooperation between IETF Fax WG and them. They will be merged into new SGs and continue to study. Plan for T.37 extension such as support for Full-mode enhancements, new image compression method, and T.37 gateway functionality was introduced. The group agreed to send a letter and Implementer's Guide draft to Q4/SG8.]

------------------------------------------------------------------------
8 Closing
------------------------------------------------------------------------

The meeting finished.

Slides

None received.