2.1.5 Internet Fax (fax)

NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 23-Jul-98

Chair(s):

James Rafferty <jrafferty@worldnet.att.net>

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

Current Meeting Report

Internet Fax Work Group Meeting - August 26 and 27

Chair: James Rafferty
Reported by: Graham Klyne

ITU cooperation review - James Rafferty
(see slides "ITU Cooperation")

The chair reviewed the status of cooperation with the ITU Study Group 8. The groups
cooperated to produce the simple mode specifications. The clear message from ITU is
that they are pleased with the results so far, which has included direct participation by
ISOC delegates at ITU meetings and want to continue the ISOC/ITU relationship for
the next level of Internet fax standards.

The "Communication" from ITU sets out ideas on full mode requirements, which have
triggered some further discussions.
f
Rafferty reviewed the ITU meeting schedule, which calls for meetings in early
November and next March. The ITU would like to begin the approval process for the
"full mode" of Internet Fax at the November meeting. In line with this, the chair
proposes that the group focus its efforts and aim to submit and stabilize WG core work
on "extended mode" by the November ITU meeting in order to help ensure a single
coherent standard for Ifax.

In particular, the group needs to be clear about which extended mode components can
be completed in this timescale, and which others which must be deferred for later
consideration.

The work submitted in August will be the DSN, MDN RFCs and the -eifax- draft.
Final version(s) of -eifax- based work would be targeted for ITU submission by
October 1998. Also, a response to the ITU "communication" should be drafted by the
end of
September 1998.

The room was supportive of the direction outlined, and is prepared to work
aggressively to meet the deadlines over the next two months.
.
WG charter review - James Rafferty
(See slides "Charter Review".)

The chair reviewed plans to update the charter. It is proposed that "Full mode" be
pared down to core essentials that can be agreed quickly. This would be followed by
related work that would continue over the next several months. There is also a need
to review the "simple mode" documents, with view to going to "draft standard" (also
needing documentation of interworking implementations). The core documents
targeted for completion within the WG during September are : -eifax- and
"-features-schema-".

An issue was raised that this schedule may be held up by 'conneg' documents schedule
(especially -reg- and -media-features-). It was noted that the -reg- document is
pending an IETF Last Call. oncern was also expressed that there should be time to
take account of any comments that may come from the ITU review. The chair
believes this can take place immediately following the ITU November meeting. In
this scenario, the ITU would need RFC numbers by December 1998.

The Address extensions document is also approaching stability and is also targeted
for completion in the near term.

The chair also reviewed items which are not on the immediate critical path, but could
be addressed within the work group. (See "Charter review III" slide)

Some of the confirmation issues may require review of some aspects of e-mail
architecture, so must be dependent on other groups as well as our own.

The Mailcap BOF held this week is expected to result in a new WG, which may
provide mechanisms that are useful for exchanging fax capabilities. E164 resolution
may also have some applicability to what the WG needs in this area.

A question was raised about developing real-time fax standards in the WG, but
indications are that this is out of scope for the current Ifax working group, especially
since the ITU has already developed the real time T.38 recommendation. Another
possible solution is IPP (looking somewhat like real-time fax). From the AD: we would
need substantial justification to take on work that competes directly with ITU T.38.

In another charter related item, there was consensus in the room that the-goals-
document should be put to WG last call (as informational) to document the problem
we were trying to solve.

Revisions to the "simple mode" RFCs will be considered and related milestones will
be included in the updated charter. A comment was made that a milestone should be
in the charter for completing security-related work, but it was noted that the ability to
do so in a timely manner is dependent upon progress in e-mail security. It was
suggested that security is probably related to capability exchange (e.g. key/certificate
and capability distribution may be combined).

There was support for the charter direction as outlined; the chair will prepare an
updated draft charter for circulation to the mailing list.

Store-and-forward extended/full mode - Dan Wing

Dan Wing outlined steps to be taken to reduce the -eifax- draft to a core document.
(See slides used for Dan's presentation)

1. Emphasis on describing standard operation of the "eifax system", which consists
of the Sender+receiver+infrastructure(MTAs). Thus compliance applies to the
overall system, not specific components.

- Consensus OK.

2. Reduce section discussing security and encryption, by using references to other
documents and eliminating overlap with RFC2305. The security section will be
retained, but simplified.

- Consensus OK.

3. Remove references to quick delivery, offramps. These will be addressed in separate
documents. Plan to write separate documents covering onramp/offramp behavior.
A separate document will be written to clarify the roles -- this may be in the
communication to the ITU, followed up by a formal document. Terms will be
described in the -goals-document. Detailed wording is left to the document
author(s).

- Consensus OK.

Confirmation of Receipt

Dan Wing reviewed proposed changes to the wording of the -eifax sections on
Delivery Confirmation and Processing confirmation. The proposed wording changes
were first reviewed for understanding and then the chair conducted a consensus check
on each of the proposals.

Slide 7 - There is new wording proposed for DSN/MDN requests tosimplify those
sections. "If EIFax sender wishes to receive processing confirmation it MAY request
an MDN". (i.e. use of MDNs to learn about processing is part of the standard, but is
not mandated). References in the current draft to different behaviors depending upon
the type of recipient are eliminated.

Consensus: Yes

Slide 8 - Addition MDN: "If a recipient receives an MDN request ... MAY indicate
success ... SHOULD indicate processing failure". There are possible problems here if
multiple clients are used against a mailbox. There are ad-hoc solutions to this scenario,
but no "standard" solution was offered (apart from, possibly, user choice). There was
a voice raised requesting "SHOULD" for processing success. But "SHOULD" is a
strong requirement, and there are potential architectural issues. The wording
deliberately talks about "recipient" rather than "user agent" or other more technically
specific terms, to allow flexibility in overall system implementation. Behavior of any
single component will generally need to vary (e.g. be configurable) depending upon
the scenario in which it is deployed. It was suggested that the wording needs
strengthening, but MAY/SHOULD/MUST is not appropriate. Also, try for consistency
of wording style in the successive sections.

- Consensus OK on the principle, with author(s) to find better form of words.

There was a plea to the e-mail community for a possible mechanism that can be
mandated to return (non-)processability information (unlike MDN). It was indicated
by Ned Freed that mandated processing-failure messages might be achievable in the
short term, for automated recipients, but probably not for human recipients.

[Further discussion and consensus gathering deferred until the next day, where these
points were re-visited]

Slide 8 - Addition DSN: "If MTA knows that user will not process message, it MAY
generate delivery failure 5.6.x". The rationale is that an MDN response cannot be
unsolicited, but a DSN may be used to generate unsolicited notice of non-processable
messages. This is consistent with the existing Ifax (simple mode) work. There was
discussion suggesting that MAY should be SHOULD and that a simplified wording
was possible. The author agreed to consider alternative wording overnight. .

On-demand SMTP

Ned Freed provided a brief review of three possible options for using SMTP in on-
demand situations. This may be applicable in Ifax for situations such as for dialup or
occasionally connected clients.

SMTP is a "push" protocol (only). POP/IMAP are "pull" protocols, but not appropriate
for some uses

Three "pull" (on-demand) options:

1. TURN command -- in RFC821

This causes the client and server roles roles to be reversed, but it is wide-open to abuse.
This option has been deprecated in the DRUMS updates to RFC821, so it is not
recommended.

2. ETRN

1C: ETRN domain.com
2S: 220 service started

Host (2) then connects to host (1) as a client. This overcomes the spoofing problem: a
new connection is created, which is safer. The main problem is that it doesn't work with
dynamic address assignment (i.e. no domain name defined). This is defined in
proposed standard, RFC 1985.

3. AUTH + ATRN

Same as TURN in most ways on-the-wire, except:

(a) requires use of SMTP AUTH
(b) adds domain parameter to ATRN

This can be implemented without having a full SMTP server on the port (i.e. the
software recognizes ATRN, then becomes a client.) The scope is for an entire domain,
not an individual mailbox. The author indicated this *could* be addressed in the
current proposal, but has not been to date.

It was pointed out that ATRN (with SMTP pipelining) is a better choice than POP from
a performance standpoint for single-mailbox downloads.

The Mailing list for ATRN is <ietf-disconn-smtp[-request]@imc.org> The current draft
is: <draft-gellens-on-demand-04.txt>, which was scheduled for review in the mail
extensions BOF the next day. The implications and requirements for using ATRN
for Ifax need more discussion.

** The meeting continued on Thursday, resuming where it left on the matters of
confirmation within the -eifax draft and proposed wording changes, before continuing
with the planned Thursday agenda. Slide 7 (re-visited) Addition MDN: "If a recipient
receives an MDN request... SHOULD respond to the MDN". Comments from after
yesterday's meeting that different MDN response criteria might apply to automated
recipients vs human recipients. Suggested words: "If the recipient is an unattended
terminal, the MDN response MAY be automated".

- Consensus OK on principle, with author(s) to find better form of words.

Slide 8 (re-visited) Addition DSN: "If MTA is able to determine that the message
cannot be processed, it SHOULD generate delivery failure with status 5.6.x". Rationale:
an MDN response cannot be unsolicited. Using DSN in this way allows the possibility
of unsolicited non-processable messages. It is likely that a new status code will be
defined, rather than using 5.6.x.

- Consensus OK, wording may be simplified by author

Slide 9 - Miscellaneous changes were reviewed:

- define processing
- add note that DSN is deterministic
- re-write intro and section 2 with emphasis on *system*
- Remove 7.1 (multiple POP clients)
- RFC 974 to implementation note
- Consensus OK

Reporting extensions
(See James' slide)

The chair noted that there is a reporting-extensions draft. It appears that extensions
to the current DSN/MDN model may be needed, but these must be done by the e-mail
community and will take place over a longer timeframe than the immediate -eifax work.

Capabilities/Identification
(See James' slide)

The chair noted a strong requirement to report failure to process. This may need some
extension to the e-mail notification framework -- it doesn't fully fit either DSN or MDN.

Dan Wing presented a single slide (slide 12) on proposed changes to the -eifax draft
related to capabilities.

The mechanism is unlikely to be finalized in current timeframes, therefore manual
configuration of sender is explicitly allowed.

The immediate focus will be on media features, not other T.30 capabilities.

There was a suggestion that the SDP protocol (Session Description Protocol.)
[RFC ????] should be considered for ideas.

(James' slide "Cap Exchange - Features" -- list of current drafts)

(James' slide "Cap Exchange - Features (2)")

Lloyd McIntyre discussed T.30 capabilities and how it related to the -eifax work.
Relevant items include TIFF profiles, paper size, resolution options, coding and colour
model options.

Toru Maeda announced a new draft was sent to the fax list that proposes an alternative
approach to capability exchange using a new MIME type and empty message to trigger
transmission.

There was a comment on a "metadata" content-disposition draft. Content features
might be sent in a body part thus labeled. This suggests a new MIME type for carrying
media feature metadata. Some work is being initiated. Contacts for this are Ted
Hardie/Chris Newman. vCard specification was suggested as a way of carrying this
information, rather than a new MIME type. There is also possible tie-in with LDAP
and certificate access.

A straw poll was conducted on developing a draft for fax media feature schema
development, to capture ideas in T.30 as they relate to Ifax.

General consensus - OK

A straw poll was also conducted on the definition of a related MIME type for
capabilities.

There was no consensus, so this question is to be deferred to the mailing list.

Capabilities -- feature representation

Conneg chair Ted Hardie reported that the registration draft has gone through WG last
call, and is requested to go to IETF last call. The algebra draft exists to define a
framework for combining individual media features into capability statements.

- Consensus OK to use 'conneg' framework for fax feature schema

Capabilities -- Mechanisms

(James' slide "Cap Exchange - Mechanisms")

There was a comment from the room about dependence on directory-based mechanisms
for distributing capability information, since there is evidence of resistance to deploying
this kind of approach. It is suggested that the use of e-mail (e.g. DSN,MDN,etc.) may be
a more popular option for actual deployment -- at least in the near term.

Another comment is that a combination of directory and other methods may be deployed.
E.g. directory is local source of information, with e-mail used to communicate across
organization boundaries. This suggests that both MIME and LDAP schema should be
defined.

It was noted that the 'Mailcap' BOF (which is likely to become a work group) may
produce a useful mechanism. The Mailing list is <Mailcap@cs.utk.edu>; to subscribe,
send to <Mailcap-request@cs.utk.edu> with SUBSCRIBE in the body.).

The chair summarized by noting that the aggressive target for the -fax-features-schema-
WG last call is by September 15. This is 2nd core document for EIFAX. The choice
of preferred mechanism probably must come later.

Schedule - core documents

(James' slide "Proposed Schedule - Core Documents")

The chair reviewed the core documents with last call dates and schedule for submission
to ITU. The timetable had been accepted by the room during the charter agenda item.

Review of Other drafts:

-fulladdr-03- (Claudio)

Claudio Allocchio reviewed the -fulladdr-03- draft. The details in this document are
not fax-specific, but part of a generalization of the framework adopted for simple
mode. The Mixer folks want to use this approach. He believes that it is nearly
ready for last call.

There was some discussion on how the draft related to the use of fields for cover page
generation. The framework of -fulladdr- is claimed to easily support the common case
of fax cover generation, with extensibility using references to less common cases. This
is a tricky problem, without a clear single solution at this time. Also, It was noted that
the cover page is really an offramp issue, to be picked up in a later document.

Dan Wing reviewed ietf-fax-smtp-session-04.txt. This document has been declared
out of scope for the Fax WG by the AD. There was a suggestion to promote it as an
experimental private contribution. Also may be useful as an option for message tracking.

Toru Maeda reviewed draft-ietf-fullmode-application--00.txt with related slides.

He notes various applications in Group 3 fax, including
- Polling, Subaddress and password,
- Relay broadcast, and
- BFT transmission.
There was only brief discussion. It is not clear if direct support for these applications
is needed in the extended mode of Ifax. For example, MIME is an equivalent for
BFT in e-mail, so BFT conversion to MIME may simply be an onramp/offramp issue.

Simple mode interworking

(James' slide "Simple Mode Interworking")

The chair noted that activities are beginning to address simple mode interworking
based on the standards track RFCs 2301-2305.

Those interested should sign up for the following mailing lists.

<imc-faxconnect[-request]@imc.org>
<<http://www.imc.org/imc-faxconnect>http://www.imc.org/imc-faxconnect>

The date and location have been determined. Detailed planning is to start early in
September. This is an Engineering event, NOT a marketing event. It will be attendee
driven testing and may include some T.38 testing.

It was noted that moving to draft standard involves documenting interoperability on
each feature. There was a call for testing framework submissions (to the mailing list)
to help build framework for interoperability documentation.

Lloyd McIntyre and Rob Buckley reviewed current activities in TIFF interworking
based on RFC 2301. TIFF profile testing has matured quickly. The concept is to
start with known images, pass through a TIFF writer and reader and then do a
compare with the original. Test cases are designed to cover all features and options.
Prototype utilities have been developed for a TIFF file validator, comparators, viewers.
It is anticipated that these would eventually are be available in a product form.

To date, profiles S,F,C,M have all been tested and interchanged. (M at preliminary stages.)
The goal of the companies involved is that all of the profile testing would be complete
by December 1998.

The chair then closed the meeting and thanked the participants for productive efforts.

Slides

Agenda
InternetFAX FullMode Applications
Full Address
Changes

Attendees List

go to list