2.1.4 Internet Fax (fax)

NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-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):

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

RFC2846

PS

GSTN address element extensions in e-mail services

Current Meeting Report

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

----------------------------------------------------------------------
2 Status of pending Draft Standards
----------------------------------------------------------------------
It is about update of file format for internet fax (TIFF-FX: RFC 2301).

Lloyd McIntyre presented changes to TIFF-FX specification (draft-ietf-fax-tiff-fx-07.txt), which were not formally distributed before the meeting. It was confirmed the changes are purely editorial. Sooner or later, it is announced for the distribution.

The version 06 is now under Draft Standard consideration. With these changes, document will go forward in IESG without new last call.

----------------------------------------------------------------------
3 Targeted for Draft Standard
----------------------------------------------------------------------
----------------------------------------------------------------------
3.1 Service
----------------------------------------------------------------------
It is about update of RFC 2305.

Kiyoshi Toyoda introduced draft-ietf-fax-service-v2-02.txt, which mentions simple mode fax in internet mail. He presented revisions, which are mainly about non-normative issues. All are the minor editorial changes.

It was confirmed that the following three normative references need to move to Draft Standard.

----------------------------------------------------------------------
3.2 Addressing
----------------------------------------------------------------------
It is about update of RFC 2303 and 2304.

Claudio Allocchio introduced draft-ietf-fax-minaddr-v2-01.txt, which mentions minimal GSTN address format in internet mail (RFC 2303). He presented the revisions, which are minor clarification and a correction to ABNF.

He also introduced draft-ietf-fax-faxaddr-v2-01.txt, which mentions minimal fax address format in internet mail (RFC 2304). He presented clarification of sub-address format (ITU-T T.33, T.30). Digits are only allowed in it, and '#' and spaces are not allowed. No multiple sub-addresses are allowed.

He also introduced RFC 2846 (full addressing), which includes many pre-defined address elements and IANA registration procedures.

Kiyoshi Toyoda introduced interworking report about RFC 2304, in order to elevate RFC 2304 to Draft Standard. There are two attendees:TOYOCOM and MGCS. There was a test configuration in which a IFAX device sends document to an offramp gateway through internet and the gateway sends to G3 fax or onramp fax for sub-address.

All syntax defined in RFC 2304 were tried for test. The tests satisfied the items of "RFC 2304 interworking configuration Matrix" which has delivered to Fax Connect 2 (http://www.imc.org/imc-faxconnect/).

It was confirmed that "formal" report is necessary for request of Draft Standard consideration.

----------------------------------------------------------------------
4 Internet-Drafts
----------------------------------------------------------------------
----------------------------------------------------------------------
4.1 Gateway issue
----------------------------------------------------------------------
Katsuhiko Mimura presented draft-ietf-fax-gateway-protocol-00.txt.
It mentions internet fax gateway protocol which has two functions: onramp and offramp.

a) Addressing
How offramp gateway extract fax number from mail address was introduced. A question was raised about provision for separate identification of country code, to allow receiving system to isolate local dialing part.

The standard defines only fully qualified numbers with leading '+', so system should know to expect a country code. Other numbers do not have a defined meaning, and is not appropriate to try and specify behaviour in these cases.

Should a receiver be expected to know its own local dialing codes? Beyond scope of this specification, but implementations needs to takeaccount of these issues.

Suggested text is as follows:
"Gateway MUST process the mailbox string and convert it to a local dial string according to the local dialing rules".

b) File format conversion
There is difference between the format of internet fax (TIFF-FX) and the one of GSTN fax. Some conversion is necessary.

c) Drop duplications
There are the same messages to multiple mail boxes at the same domain. There is some confusion about exactly what this means.

There is the following descriptions in the draft:

An offramp gateway MUST drop the duplicate mail by confirming whether Message-ID is the same as old one. This is to avoid the duplication of the transmission to same facsimile device over GSTN.

It is suggested that the MUST be softened to MAY or SHOULD. Message IDs cannot be guaranteed to be unique (notwithstanding e-mail specification). Also, it is noted that mailing lists can change text without changing message-ID.

A question was raised on what is scope of duplicate detection (period of time).

d) Automatic retransmission
An offramp gateway may automatically retry to send fax data in the case of delivery failure.

Questions were raised on whether or not specification to link any retransmissions to the original ones is provided and whether or not retransmissions must be constrained to local legal operating requirements.

There was a comment that retransmission specification is not described in ITU-T T.30. It was commented to add a note that retransmission issues may be particularly sensitive, and must be handled with care, because the sending user will not generally be present to deal with any transmission failures.

e) Error behaviour
Retransmission depends on the contents of errors. It is necessary to distinguish between T.30/fax "soft" errors (for which retransmission may be appropriate -- e.g. line busy) and "hard" errors (for which retransmission is not appropriate -- e.g. paper out). He suggests this issue should be addressed in another draft.

f) Return notice
When mail to fax is multicast or broadcast and a delivery error happens, there is an issue about when and how return notice should be done. He suggests this issue should also be addressed in another draft.

g) Onramp gateway
Onramp gateway functions fax to mail. It is noted that current version is based strictly on simple mode. But, WG may need to decide whether we wish to be restricted to this scope, or whether to address extended /full mode issues from the start.

h) Addressing with FAX terminal
There is the following description in the draft:

An onramp gateway MUST have the function that onramp gateway analyze destination address from address data sent by facsimile device over GSTN.

Direct and indirect addressing are discussed. Direct uses given number directly as mailbox name, and uses prefix to select destination domain. Indirect may use number mapping table to select destination mailbox and domain.

i) Authorization by DTMF
It is necessary that authorization should be done at onramp gateway. GSTN users send UserID and Password to onramp gateway in some ways such as sending DTMF after dialing.

j) Next version -01
He promises to announce the next version soon.

----------------------------------------------------------------------
4.2 Implementers Guide
----------------------------------------------------------------------
Vivian Cancio presented draft-ietf-fax-implementers-guide-02.txt. It is a guide for simple and extended modes.

She explained changes to current drafts. There are mainly corrections to the examples (MDN and MTA/ESMTP) and the addition of the case of receiving multiple TIFF attachments, in which it is recommended extended mode recipient returns an error when it is unable to decode any of the attached files.

A question was raised on a reasonable mechanism for a sender to determine whether or not an MDN/DSN has been sent *after* the TIFF image has been processed. This information may be useful to automatic status logging systems.

----------------------------------------------------------------------
4.3 FFPIM
----------------------------------------------------------------------
Graham Klyne presented it. it consists of the following three drafts.
a) draft-ietf-fax-ffpim-00.txt
b) draft-ietf-fax-timely-delivery-00.txt
c) draft-ietf-fax-content-negotiation-02.txt

Timely delivery draft will be moved forward, because now DELIVERBY has become RFC 2852.

Concerning content negotiation, he explained the overview again. There are a number of technical issues in the negotiation draft that really should have some group discussion on the list, such as use of 'Original-recipient", content-id, cache-control, "content-alternative" header, MDN extensions. They are highlighted in the draft. Further suggestions and comments are invited.

For now, it is noted that there may be security concerns (message tracing) if negotiation is allowed with recipients not named by the sender.

The distinction between 'definitive' and 'informative' introduces some unintended complexities, and the "sender decides" model for quality decisions seems to be adequate. But it is noted that it should not be done for now.

----------------------------------------------------------------------
4.4 TIFF-FX extension issue
----------------------------------------------------------------------
Lloyd McIntyre presented it. It is not formally distributed. But it is
draft-mcintyre-fax-tiff-fx-extension-00.txt in http://www.imc.org/
draft-mcintyre-fax-tiff-fx-extension.

>From the contents of the Adelaide meeting in March, MRC:multi-strip background and foreground layers and Annotation are deleted, because they are immature. They are candidate for future draft. Therefore, the extension includes new field values and/or relaxed constraints (higher resolutions and MRC with more than 3 MRC layers) and new fields and/or profiles(more than one profile within document and JBIG2).

He presented these new field values like 600x600dpi, relaxed constrains like more than 3 MRC layers, JBIG2 etc. He also explained overview of relation of changes to current TIFF-FX profiles.

It was confirmed that the enhancements require new tags to be approved by Adobe, for which a formal WG request may be required.

----------------------------------------------------------------------
5 Issue from VPIM WG
----------------------------------------------------------------------
Glenn Parsons, who is a co-chair of VPIM WG, introduced the internet fax related issues discussed in VPIM WG.

----------------------------------------------------------------------
5.1 Partial Non-Delivery Notifications (draft-ietf-vpim-pndn-00.txt)
----------------------------------------------------------------------
It describes the interaction between systems sending multipart Internet main to systems that cannot render parts of the sent message. In particular, it describes an extension to the Delivery Status Notification mechanism.

----------------------------------------------------------------------
5.2 Critical Content of Internet Mail (draft-ietf-vpim-cc-00.txt)
----------------------------------------------------------------------
It mentions method for sending user Agent (or sender) to indicate body parts that the sender deems critical. "Content-Criticality" entity on each body parts is proposed and there are "critical", "important" and "ignore". For example, receiver rejects message if critical part is undeliverable and notify sender. The issue of backward compatibility is also introduced.

----------------------------------------------------------------------
5.3 Content Hint for Internet Mail (draft-ietf-vpim-hint-00.txt)
----------------------------------------------------------------------
It mentions method of identifying message as belonging to a (small number of) enumerated message classes, such that it does not require scanning the entire message, etc. Top-level "Content-Hint" header is proposed and there are initial types like "voice-message", "fax-message" and "video-message". There are security considerations. Some concerns are raised and careful discussion is needed.

----------------------------------------------------------------------
6 ITU issue
----------------------------------------------------------------------
----------------------------------------------------------------------
6.1 Letter from Q4/SG8
----------------------------------------------------------------------
Hiroshi Tamura attended ITU-T Q4/SG8 meeting in June and introduced it.

There were the following three items to be discussed at Q4 meeting.

T.37 will refer implementers guide after draft-ietf-fax-implementers-guide-0x.txt is completed.

There were the same requests as the ones WG received last year.
a) Enhancement of capability mechanism
b) Fax processed status information
c) MDN enhancements
A question was raised on capability mechanism. In fact there was little discussion in June Q4 meeting.

Draft response to ITU-T was introduced. For a), WG's content-negotiation draft is one solution. For b), there is no direct discussion now and fax-specific information may be difficult in MDN/DSN. For c), some clarification is in implementers guide, but may not be enough. Through the introduction, there were comments that PNDN (Partial Non-Delivery Notifications), which VPIM WG discusses, may solve b) and c) partly. (Refer the following section 7.)

It was emphasized that any interested people can propose in IETF and IETF is welcome to direct contribution at IETF WGs by ITU people.

There was also introduction of WG plan for new SGx meeting in November. It includes notification of WG status, response to request issues and input to newly assigned RFCs. They will be decided in ML until November.

----------------------------------------------------------------------
6.2 Terminal mode
----------------------------------------------------------------------
Toru Maeda presented terminal mode discussion that is taking place in ITU-T Q4/SG8. The target of terminal mode is easiness to implement and color fax.

He commented simple mode and EIFAX as follows. Simple mode is not good for FAX terminal because of no capability exchange and no confirmation. EIFAX is not good for FAX terminal because of complexity for embedded system.

----------------------------------------------------------------------
7 Confirmation of Milestone and charter
----------------------------------------------------------------------
Claudio Allocchio introduced. WG confirmed milestones and there were no objections. There was also call to all members to get draft reviews quickly.

Some members commented that PNDN issue should also be discussed in FAX WG. Whether to take it and add in WG charter will be discussed in ML. AD agrees to it.

----------------------------------------------------------------------
8 Closing
----------------------------------------------------------------------
Meeting was closed.

Slides

IETF FAX WG Meeting General Info