2.1.11 Internet Fax (fax)

NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 27-Oct-97


Dave Crocker <dcrocker@brandenburg.com>
James Rafferty <jrafferty@worldnet.att.net>

Applications Area Director(s):

Keith Moore <moore@cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>

Applications Area Advisor:

Harald Alvestrand <Harald.T.Alvestrand@uninett.no>

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


No Request For Comments

Current Meeting Report

Minutes of the Internet Fax (FAX) Work Group

Minutes by Glenn Parsons <Glenn.Parsons@Nortel.ca> were taken with extreme care and detail, but were then compressed and distorted by Dave Crocker.

First Session, December 11, 1997 - 9:30-11:30

There were pre-meeting subgroup meetings for TIFF, Service and Addressing. This additional effort by working group participants was extremely productive. The working group is under intense pressure to complete all the technical work by the end of this meeting. Specifically, an immediate set of documents is required for ITU use. The ITU's deadline to publish (or more accurately to submit it to the ITU secretariat for translation and distribution for ITU member voting) their Internet Fax specifications is February 1. In order for IETF document to be used in this document, they need to be published RFCs by February 1. This means the IESG will need them by January 1, and to facilitate this the WG two-week last call must start tomorrow.

Crocker concluded by noting his uncertainty if the TIFF-FX document will be able to move forward in this timeframe.

I. Agenda

2. Addressing
3. Service

Other documents to be addressed as makes sense and time allows.

The ITU documents in context:

Unlikely that the IETF will influence/overlap this document

There is overlap with the IETF on this document. The goal is for the ITU to include references to IETF documents in this protocol to solve various pieces of the puzzle. This document outlines a clear migration path of features.

II. Documents

The document contributions that needed to be discussed were listed and mapped against the agenda and a priority.

I-D Drafts (latest version) Priority Agenda Order

<draft-ietf-fax-tiff-reg-02.txt> 1 A
<draft-ietf-fax-tiff-06.txt> 1 A
<draft-ietf-fax-service-00.txt> 1 C
<draft-ietf-fax-fpim-01bis.txt> 1 C
<draft-ietf-fax-requirements-04bis.txt> 1 C
<draft-ietf-fax-addressing-03bis.txt> 1 B
<draft-ietf-fax-minaddrgen-00.txt> 1 B
<draft-ietf-fax-minaddrfax-00.txt> 1 B
<draft-ietf-fax-smtp-capabilities-00.txt> C
<draft-ietf-fax-smtp-session-01.txt> C
<draft-ietf-fax-dsn-extensions-00.txt> 1 C

The final two documents are for use in the ITU discussion and are not part of the WG's program. The group was asked who had read the various documents being discussed. Only the core group of chairs/editors had read them all. No significant jump in readership was noted until the question was reduced to just TIFF-FX & TIFF-F (on the final question, slightly more indicated reading TIFF-F).


Work on TIFF-F has been ongoing for the better part of a year. The documents on TIFF-F and image/tiff were submitted for last call in September. Several comments were received and all were adequately addressed and are represented in the latest versions of the documents. The recommendation is to forward these documents to the IESG for approval and publication:

<draft-ietf-fax-tiff-reg-02.txt> Proposed Standards RFC
<draft-ietf-fax-tiff-06.txt> Informational RFC

No objections were voiced, except a concern for application parameter being completed before these documents could go forward. Question whether standards track was required for registration. However, RFC 2026 was indicated to state otherwise.

A number of times, during the working group's two meetings, the matter of synchronizing with the ITU schedule was addressed. The desire is to make this document a standards track document in order to facilitate the ITU referencing this document in its specification. If we do not do this there might be divergence between the ITU and IETF specifications.

There was discussion about the specific need for an IETF document to be standards track, before the ITU would incorporate it as part of a specification by reference. No firm answer is available, but there is strong indication that anything less than standards track will not be incorporated.

Since the TIFF-F document had been slated for Informational, this engendered debate about the need and about its relationship with TIFF-FX.

A comment was made that reiterated the point that a different ITU and IETF standard for the same thing will be very bad for the marketplace as implementors will have to choose which to implement and customers may become disenchanted.

IV. Addressing

As background, the main addressing document has been added to over the past several months to add functionality and features to the fax addressing case and further to make the addressing more general in the parent PSTN case. Further, as a result of the generalization, the group has received requests from other services (e.g., voice messaging, SMS, GSM) to add in details for their service in the document. In the revised timeline these would only slow down progression, so the main document was split and slimmed down. The result was two simple short documents that defined the minimum address format for the general PSTN case and the specific fax case. The group agreed to include implementation notes in the document with specific indications (like NOTE:) but these have not been added yet. Allocchio sent the documents to the list and briefly reviewed them on an overhead for the group in this fashion:

Fax Specific

The specific case for fax is defined with the LHS as:

"FAX=" global-phone [ "/TSUB=" sub-addr ]
global-phone = "+" 1*( DIGIT , ( "-" / "." ) )
sub-addr = 1*( DIGIT , ["#" , "*"] )
T.33 subaddresses indeed do optionally need # & *.

The general case is:
service-selector "=" global-phone
This may be extended using:
"/" label "=" value

This can be viewed as a source routing mechanism for telephone numbers (noting that source routing has been since removed from email addresses). Further the service selector is essentially equivalent to using a LHS & RHS combination like <123456@offramp.service.net>. Rafferty confirmed that the key use for this addressing is for the offramp to use the LHS as a route to deliver the fax.

The chair then asked the room to confirm a proposed action to keep the original addressing document as a place holder (to perhaps later include all the addressing schemes) but to immediately progress the two new shorter documents to last call. This was agreed with no opposition. However, it was suggested to include the fax specific addressing within the service document. There was some concern about this but it was left to the editor's and chair's best judgment. The result would be reviewed during the last call.

V. Service

Three key issues were identified: confirmation, security and offramp gateways. The document editor took the group through the current draft.

The Transport section of the service document noted SMTP, POP, and IMAP as protocols. The group had a lively debate about acceptable versus mandatory transport protocols.

The Format section notes that the TIFF-F minimum set will be used in the image/tiff; application=f content-type with MIME and base64. The theme of debating TIFF-F versus TIFF-FX was continued.

To simplify the specification it was suggested that this document should merely point to MIME and indicate that conformance to MIME is required and not restate everything.

The Confirmation section (on delivery notifications or DNs) was discussed in the breakout meeting in some detail. There are two kinds of Internet Mail delivery notifications that can be used (both use the multipart/report construct):

These are for MTA-to-MTA confirmation of delivery or non-delivery. ESMTP support of a special keyword is required for requesting a positive DN. Negative DN can be sent without any ESMTP requirements.

These are UA generated receipt notifications that would occur after the delivery of the message. A positive DN must be requested using a header field, while a negative DN can be sent without any requirements on headers or SMTP.

The result for the service document was summarized as:

1. A sender MAY request a positive DSN (but its handling is out of scope)
2. A negative DN MUST be sent on failure, and it SHOULD be a DSN
3. A receiver SHOULD be able to process a DSN

It was noted that Notifications can pertain to two levels of failure:

1. MTA transfer/delivery
2. Process failure (e.g., TIFF rendering failed)

Leaving out positive DNs is leaving not a large, but a gigantic hole in the specification. PSTN fax has set the expectation for Internet fax. That is, there must failure/delivery notification. Implementor's notes are needed to try to start explaining this meaning. There is some emerging sense of need for an Implementor's guide, in addition to the specification documents currently being developed.

The group then debated the relative assurance levels being attempted by the IETF and the ITU groups. This is made complicated by variations in notification semantics, variations in notification support, and probably also by variations in the goals of the working group participants.

One concern is that once the message is delivered, and a DSN cannot be sent (for subsequent processing failure), that there was no recourse. A suggestion was to add in requesting a positive DN, using MDN as optional.

For content, there is a concern about sending anything beyond the minimum set of TIFF-F, since there are no capabilities mechanisms defined.

The frequent battle between simplicity with few choices, versus power with many, was joined, concerning content.

After the meeting, there was a demo of a TIFF-FX implementation with the purpose of getting implementation testing underway.

Second Session
December 11, 1997 - 9:30-11:30

I. Introduction

Those attending the meeting supported a commitment to meet a schedule for completing all technical work by today in order to make the core IETF fax documents available for reference by the ITU.

Given that, the dates presented yesterday are not firm but are instead a conservative estimate. There are two milestones that it is felt IETF RFCs are required in order to facilitate reference by the ITU recommendations. The first is to have RFCs available at the start of the ITU ballot, the second is to have RFCs available at the start of the ITU rapporteurs meeting.

Herman Silbiger (ITU Internet Fax question rapporteur) clarified that at a minimum, the text of the documents is required for the rapporteurs' meeting starting January 12. Additionally, final text is required before the TSB begins translation of the documents for balloting on February 1.

Absent any formal agreement, the IETF working group is guessing what will be acceptable and by when.

The process to becoming published as an RFC was explained:

1. IESG Last Call

Upon receipt, the IESG will issue a two week last call for comments on the document. This process may reveal issues that have to be addressed before further progression.

2. IESG Consideration

After last call comments have been addressed, the IESG will consider the request for progression. Consideration often takes 1-3 months as there are many topics on the IESG's plate. As a result, it helps to grease the wheels' to speed this up -- Crocker has already done this. As well, this process may result in additional issues that have to be addressed before further progression.

3. RFC Editor

This is an independent process of the IESG and has been known to be prone to delays due to backlog. However, the RFC Editor hopes to keep this process to under a month.

II. Agenda

1. Introduction
2. Service
3. TIFF Application Parameter
5. Straw polls

III. Service

Rafferty introduced that the agenda for this section would be as follows:

1. Review of Informal Meeting proposal - Larry Masinter
2. Discussion and Consensus - James Rafferty
3. Security Considerations - Dan Wing

1. Summary

Clarifications will be added to indicate that this is the simple mode and that extensions to this document will follow. Further, Internet Mail protocols will be used in place of SMTP and the conformance language of RFC 2119 will be referenced.

2. Scope: Services

It will be clarified that this document details communication between various services: network printer, network scanner, Internet mail host and offramp gateway. An IFAX device is a combination of these features that can send or receive. However, the onramp case is not mentioned here as it is too broad.

3. Scope: Cases

The specific cases will be noted as follows:

Internet mail host -> Network printer
Internet mail host -> Offramp gateway
Network scanner -> Network printer
Network scanner -> Internet mail host
Network scanner -> Offramp gateway

4. Scope

A G3 fax device is defined as a classic terminal that uses T.30. As well, email addresses may be used to send to G3 fax devices via an IFAX offramp.

5. Transport

This section was split, with some text moved to the gateway section. Only the SMTP related text remains.

6. Gateway direction

It was agreed that onramps are out of scope. However, cover page addressing, confirmation and failure are in scope.

7. Gateway (text from Transport)

It is noted that gateways do not represent classic Internet mailboxes and that delivery is defined as being to the gateway and not to the G3 fax device.

8. Mailbox Protocols

The uses of POP/IMAP protocols are described here.

9. Failure to process

The agreement is that a message cannot be lost (e.g., discarded) without any notice. A failure action is required but not specified (but needs to be careful enough to avoid mail loops).

10. MIME Formats

The document will reference RFC 2049 for MIME conformance. Only exceptions will be noted in an Annex.

11. Headers

There is uncertainty whether the requirement on all RFC822 headers should be retained for fax. The document will reference RFC822bis but require the at least Date & Message ID be present.

12. Multipart

Again, there is uncertainty over the acceptability of the proposal. Should multiple TIFF files within a multipart/mixed be supported (e.g., a multipage, multifile fax)? The proposal is that multipage documents SHOULD be sent as one file, but accepting the multipart/mixed with many files MUST be supported. It is recommended that the multipart structure not be used. A further note is that if any part of a multipart message fails to render then the entire message fails.

13. Confirmation

For delivery failures, a negative DN MUST be sent and it SHOULD be in DSN format. Failure to process errors is also required.

14. Addressing

The addressing document will be referenced.

15. Security Considerations

Deferred to next discussion section.

16. Image File Format

It is proposed to change the name from TIFF to Image File Format. Further, specific word wrangled text is proposed that notes the minimum set must be sent if there is no prior knowledge (and that capabilities is out of scope).

17. Exceptions to MIME

Several exceptions are proposed:

· No requirement to send text/plain
· No requirement to place results in a file, but may invoke failure to process
· May print/fax rather than display

18. References

These need to be updated.

After the review, the material was discussed:

1. Summary

Is this a conformance document? A concern was raised about how the ITU would map their optional/mandatory to the IETFs various conformance levels. An editorial pass will be made over this section to align with the technical material.

Consensus: Agreed (none oppose)


1. Scope: Cases

A suggestion was offered to define cases in terms of sender and receiver. This was rejected as it was one of many options that was already evaluated.

Consensus: Agreed (none oppose)

2. Scope

There were no questions on the email addressing and forwarding points.

Consensus: Agreed (none oppose)

3. Transport

There were concerns about the precise wording of this section, the degree of requirement and the ability to use non-email transport.

Consensus: Split (about 1/8 of room for and 1/8 against)

4. Gateway direction

This is editorial instruction for the editing team. The group will see final text in the last call next week.

Consensus: Agreed (none oppose)

5. Gateway (text from Transport)

Consensus: Agreed (none oppose)

6. Mailbox Protocols

The uses of POP/IMAP protocols are described here as optional. Parsons notes that the wording suggests that a system may be compliant if it only supports POP. There was a suggestion that this should be local implementation issue (i.e., out of scope) -- the current text implies non-interoperability.

Consensus on point 1: Split, so defer to list (about 1/8 of room for and 1/8 against))

Failure to process is also mentioned on this slide and was separated, for polling.

Consensus on point 2: Agreed (none oppose)

7. Failure to process

Concerns over degree of specificity in instructions and permission for alternatives, possibly resulting in lost notifications. Should notice be to the sender or receiving operator? Should DSNs or MDNs be required? The recommendation was to use the form described in the slides.

Consensus: Agreed (about 1/8 of room for and none against)

8. MIME Formats

The current service document says nothing so adding the MIME conformance is required at a minimum, but some tutorial text has also been added. The actual exceptions are noted on another slide (and in the document Annex).

Consensus: Agreed (none oppose)

9. Headers

RFC822 will be referenced as RFC822bis will not be ready in time. There are some open issues here that need to be addressed on the list (i.e., mandate which headers, which headers map to the cover page). However, it was proposed at least Date and Message-ID SHOULD be present.

Consensus on points that are not open: Agreed (none oppose)

10. Multipart

Typically, a multipage fax is contained in one file (actually TIFF-F & TIFF-FX require this). If there are multiple TIFF files within a message, the confirmation must be based on all of the files. Recipients MUST process a multipart/mixed content with multiple TIFF files.

Consensus: Agreed (about 1/8 of room for and none against)

The requirement might be to process any multipart/*. There was a suggestion for multiple files to sequentially number the pages from 1 to n for all the files combined. These were open issues.

11. Confirmation

A negative DN MUST be set, but it should be a DSN.

Consensus: Agreed (about 1/3 of room for and none against)

12. Addressing

The fax-address will be noted.

Consensus: Agreed (about 1/4 of room for and none against)

13. Security Considerations


14. Image File Format

It is proposed to change the name from TIFF to Image File Format.

Consensus on name: Agreed (none opposed)

As there was potential dissension here, Rafferty held a different poll on the new text.

Consensus: Rough consensus (about 1/3 of room for and several against)

Concerns from some participants: The minimum set MUST NOT be used without capabilities negotiation. RFC 2119 words should be swapped in.

15. Exceptions to MIME

RFC 2049 might require that implementations MUST send text/plain. This will be followed up on the list.

Consensus on intent: Agreed (about 1/3 of room for and none against)

16. References

Consensus: Agreed (about 1/3 of room for and none against)


Current proposal for the security considerations section. This section has not received the same review this week as the other sections of service document have. The proposed security issues:

1. Eavesdropping
2. Both on the wire (IPsec, TLS) and on disk (PGP-MIME, SMIME)
3. Unsolicited fax

Both junk faxes and blasts resulting in denial of service

1. Spoof sender
2. Authenticated Recipient
3. Only the intended recipient should be reading the fax
4. Viewing faxes in public
5. Sender identification
6. Whether it is the email from addresses or the telephone number

The proposal would be sent to the list by Wing next Tuesday.


Status of the latest TIFF-FX draft: Revised this week based on comments received and distributed hard copies of the 04 draft <draft-ietf-fax-tiffplus-04.txt> to the group -- it will be sent to the list next week.

TIFF-FX now integrates TIFF-F (as of the 03 draft) and is consistent with the image/tiff content registration. Further, all facsimile features represented in the document are ITU standards and all relevant ITU standards are represented. The document is consistent with current and emerging industry practice and provides a consistent framework for TIFF.

Currently, the document is organized with section 2 introducing features and tags common to all profiles of TIFF. Sections 3-8 then delineate the details for the profiles of:

1. S - Minimum Set TIFF
2. F - TIFF-F
3. J - JBIG
4. C - Color
5. P - Palette color
6. M - Mixed Raster Content

A diagram that reflected the ITU structure of these profiles:

MH (S)
/ \
B&W / \ Color
------------ ----------
/ \ \
/ \
--- \
/ \

There was a concern that the F profile (i.e., TIFF-F) was not noted in this model. McIntyre explained that this was because it did not exactly fit since it combines both MH and MMR.

It is claimed that TIFF-FX contains the definition of TIFF-F that has been reviewed extensively. Further, TIFF-FX has been reviewed and specific comments have been received (a summarizing table of the comments was handed out). Interoperability can be guaranteed by conforming to each of the profile levels (S, F, J, C, P, and M).

The TIFF-FX authors recommend that it be progressed to last call as a standards track document. The concern is over the degree of public comment on the TIFF-FX document so far.

V. Straw Polls

(Reduced meeting attendance by this time.)

First, does the group agree that the Requirements document (i.e., Terminology and Goals) should be progressed immediately to last call and then forwarded to the IESG as an Informational RFC?

Consensus: Agreed (none oppose)

To permit TIFF-F to be included by reference by the ITU, is the group comfortable to progress TIFF-F to the IESG with standards track status?

Consensus: Split (about 1/8 of room for and 1/8 against)

Finally, is the group comfortable to progress TIFF-FX with standards track status?

Consensus: Rough consensus (about 1/8 of room for and several against)

VI. Application Parameter

A proposal from several informal meetings and discussions this week to resolve the role and use of the optional application parameter in the image/tiff content-type. There were three possible roles perceived for this parameter:

1. Capability indication
2. Hint to application dispatcher
3. Hint on the reproduction requirement

It was agreed that the first role was an overloading of this parameter and the intent would only be as a hint.

The informal group listed eight options:

1. no parameter
2. fax
3. fax, color fax
4. F (B&W), J (JBIG), C (color), M (mixed)
5. S,F,J,C,P,M
6. comma separated list of #4
7. comma separated list of #5
8. two dimensional list of #3
9. two dimensional list of #4

A straw poll of the informal group resulted in a split amongst all options except 5 and 6. However, most votes were for option 2 or 3 (with other people later expressing a preference for 3).

If there are any changes required, minor editorials will be made to the appropriate documents. The group was polled based on the suggestion that a preference be stated on option 3. Does the group accept defining the values of the application parameter as fax or color fax?

Consensus: Rough consensus (about 1/8 of room for and several against)

VII. Upcoming Meetings

There are several important Internet Fax meetings coming up. TIAs TR29 which decides US input into the ITU (actually various members will be meeting off-line after this meeting) will have an official meeting before the June ITU meeting. Non TIA members may attend once before having to become a member.

The ITU rapporteur's meeting will be held starting January 12 in New Jersey. Only ITU members may attend but conveniently the Internet Society is a member. As a result, Crocker and Rafferty will coordinate official designation of anyone who wants to attend as an ISOC delegate. The details of this meeting will be posted to the list next week.

The meeting was adjourned with applause.


None Received

Attendees List

go to list

Previous PageNext Page