NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.
Dave Crocker <firstname.lastname@example.org>
James Rafferty <email@example.com>
Applications Area Director(s):
Keith Moore <firstname.lastname@example.org>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
Applications Area Advisor:
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
General Discussion: email@example.com
To Subscribe: firstname.lastname@example.org
In Body: In Body: subscribe
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:
· Messaging (as with electronic mail) having high latency
· 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:
· Internet/Dial-up Fax gateway, moving data from the Internet to classic or Internet-aware dial-up fax products and services
· 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:
Submit Internet-Draft of data specifications
Submit Internet-Draft of terminology document
Submit Internet-Draft of messaging-related specification
Submit Internet-Draft of operational constraints document
Submit terminology document to IESG for publication
Submit data specifications to IESG for consideration as a standards track document
Submit messaging-related specification to IESG for consideration as a standards track document
Submit operational constraints document to IESG for publication as an Informational document
· Tag Image File Format (TIFF) - Application F
· File Format for Internet Fax
· Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration
· Fax address format in e-mail services
· Tag Image File Format (TIFF) - image/tiff-f MIME Sub-type Registration
No Request For Comments
Minutes of the Internet Fax Working Group
Chairs: James Rafferty, Dave Crocker
Reported by: Graham Klyne
Agenda, Goals, Etc.
I. TIFF Finalization
II. Service Integration Issues
IV. Session Mode SMTP Proposal
I. TIFF Finalization
TIFF-F: Tiny, core set, separate extension set
TIFF-FX: Further extensions
Internet draft: Tag Image File Format (TIFF) - Application F <draft-ietf-fax-tiff-03.txt>
Changes in the latest revision are:
· Defines application F of TIFF (a.k.a., TIFF-F)
· Baseline TIFF 6.0 as starting point
· Defines and specifies min subset of TIFF-F consistent with historical TIFF-F
· Range of values for fields consistent with T.4/T.30 recommendations
· TIFF overview moved to image/tiff (registration doc)
· Clarified practice for readers and writers
· Various editorial changes
· Intended as stable reference for TIFF-F.
Internet Draft: Tag Image File Format (TIFF) - image/tiff
MIME sub-type registration <draft-ietf-fax-tiff-reg-01.txt>
Defines MIME content type "image/tiff"
Potential referrers are:
· Internet fax
James Rafferty, regarding the relationship to WIDE: We now have new and maturer drafts for both TIFF-F (and -FX). WIDE was using a different subset of TIFF. It was agreed in Memphis that TIFF-F should include a definition of a minimum set of TIFF features for Internet fax, but WIDE defined a different minimum set. A meeting between TIFF-F and WIDE authors was held to try and resolve these differences.
1. Differences in fields/values for WIDE vs "minimum" TIFF-F
2. Differences between WIDE TIFF file structure and TIFF-F "guidelines"
Proposals for alignment:
1. Revise "minimum" TIFF-F values to satisfy WIDE requirements.
2. Revise WIDE to reference "minimum" TIFF-F using multi-page TIFF files (Subfiletype 2).
3. Maintain the principle that all Internet fax readers must read the "minimum" TIFF set.
Proposed changes to "minimum" TIFF-F:
1. Field T4Options: permit 0 in addition to 4 (byte aligned and non-byte aligned).
2. Field ImageWidth: keep 1728, delete 2048
Agreement: The meeting consensus was to accept these proposals.
It was proposed to add one additional point to the current TIFF-F recommended "guidelines" for reading/writing tiff files, for better consistency with WIDE: This is to require the IFD to precede the related image.
Agreement: The meeting consensus was to accept the proposal.
The WIDE authors propose a stricter ordering of header, IFD0, image0, IFD1, image1, ... would be required for the case of writing a TIFF-F file which uses the minimum set of TIFF-F. For the more general case, the TIFF-F recommended "guidelines" will still apply. (The reason for this stricter ordering is to allow low-memory devices to receive fax images. Some other implementations have all IFDs at front)
(a) Will this break existing computer-based TIFF writers?
(b) It is sometimes useful to put all IFDs at the front so files can be selectively byte-served.
(Floor): experience suggests first page is wanted first. Zilles: but what do we want second?
Q: why do we want to do this change?
A: (Ritsuo Shirahama): In case of the paired format used by WIDE, the amount of memory needed to process image is an absolute minimum, there being no need to buffer IFDs.
Q: Has a survey of TIFF writers been conducted to determine whether or not they conform to this proposal?
A: Existing TIFF-F writers have not been checked. Readers have been checked.
A:(Neil Joffe?): Some legacy TIFF writers put the IFDs at the end.
Agreement: The consensus in the meeting was to adopt the WIDE proposed amendment (i.e., the stricter IFD/image ordering will apply when writing minimum TIFF-F files).
Question about RTCs: Does WIDE include this? -- deferred to the list
Internet draft: File Format for Internet Fax
Steve Zilles presented an overview of the latest draft on slides.
The goal is to achieve a set of nested file formats: TIFF-FX has been revised with this end in mind. The nesting consists of WIDE, TIFF-F and TIFF-FX, covering the following features:
· WIDE: MH (T.4) b/w
· TIFF-F: MMR (T.6) b/w
· TIFF-FX: JBIG (T.82) b/w halftones
- T.42 JPEG (T.81) color photo
- T.43 JBIG (T.82) 'office' color
- T.44 MRC Mixes photo/office color
Sect 2: this contains an introduction to TIFF and related Fax concepts, and may be moved to a separate MIME registration document.
Sect 2.2, fields for all applications: This has the agreement of the WIDE authors for defining a baseline feature set.
GlobalParametersIFD field is new
Sect 3: approx. correspondence to WIDE, except:
These are not required in minimum set (not usually applicable for Internet-carried fax)
The draft has been re-structured to better represent the nested structure of minimum TIFF -> TIFF-F -> TIFF-FX (multiple modes).
The draft's current structure addresses:
(a) WIDE (minimum TIFF-F)
(c) ITU fax extensions
It provides a common structure for the document parts relating to these levels of functionality.
Zilles suggested the document is ready to edit as a proposed standard. However, few people in the room had actually read the document. The TIFF authors are directed to complete the integration between TIFF-F and TIFF-FX in the TIFFPLUS document, while also incorporating the latest agreements from this meeting.
Q (Neil Joffe): Wants streamable file type for low-memory senders on the Internet. What is the position of the TIFF-FX authors?
A: The ordering proposals begin to address this. MRC allows striping of data. But there is a fundamental conflict between low-memory writer and low-memory reader requirements in the context of the TIFF file structure.
Further discussion of this point was moved to the list as TIFF file format changes will be needed to resolve low-memory reader/writer requirements conflict.
II. Service Integration Issues
Presented by Dave Crocker, using the WIDE proposal document as a base for discussion.
The thrust of this part of the discussion was to present ideas which characterize a user's perception of what constitutes a fax service, with a view to evaluating the extent to which this perception can/should be satisfied by a version 1.0 proposed Internet fax standard.
(a) Service goals
· Fax emulation -- within reason (fax service emulation, not fax protocol emulation)
· Store and forward (asynchronous, not user-observed delivery)
· Integrate fax and email user bases
· Use of Internet mail technical base in "natural" fashion. A profile of classic Internet email for use as fax transport.
· Can reply to message
· Can use with mailing lists
Leads to requirement that address is not in message body.
This is a somewhat recent ITU feature, which is showing up surprisingly quickly in the installed base. This suggests that any Internet fax address syntax must be able to represent sub-addressing. Sub-addressing is use of address information in addition to the base telephone number to target a specific recipient. There is a need to discuss, on the mailing list, the issue of multiple sub-addresses "to the same destination."
· Syntax that explicitly identifies an address as a fax number?
· Form of telephone phone number to be used?
Q: (Dan Wing?): Should we follow VPIM spec wrt addressing?
A: (DC): Yes (in narrow and wide senses)
Email Address Candidates:
· Number as mailbox? (user-based knowledge for network routing) GK: this form can also be used for network-based routing knowledge.
· Number in service name? (network-based routing knowledge) WIDE proposal:
· Q: use some kind of explicit fax type label?
· George Pajari has commented on the mailing list that there is not always a country code in a telephone number.
· "Pause" ("-") duration - should be specified?
· How does gateway process the number wrt its own location, etc.
· Larry Masinter - pattern proposal posted to mailing list.
(Floor): what is the end-users' problem that we are trying to solve? -- this should guide our discussion.
Claudio Allochio will post to the list a description that shows the consequences of different choices of address format. Continuing discussion is moved onto the list.
E-mail now has DSN, semantically equivalent to fax message confirmation (MCF).
Also under way is notification of a message being processed by its recipient (e.g., read).
E-mail has no re-transmission concept (in absence of confirmation) - same as fax.
Issue of when confirmation should be sent by gateway: when gateway receives message? when gateway receives confirmation? What about multiple gateway chains?
Experience with s/f fax indicates that having fax confirmation decoupled (delayed) from original call must be an end-to-end confirmation, or troubles result. (But where is the "end".)
Agreement: The group in the meeting supported the idea that confirmation should be sent when it arrives at final mailbox or fax machine."
Should use of DSN be required?
· Sending from email: selection of DSN notification request is by user.
· Sending from a fax, use of DSN notification request might be:
(a) user chooses?, or
(b) DSN use is mandatory?, or
(c) implementation dependent choice?
There was a feeling in the room that this was an implementation issue.
DC: language is needed in the specification to explain this issue, without saying whether or not DSN is mandatory, but defining the fashion in which it must be used if it is used at all.
Issues of who pays the cost of providing a confirmation callback and the issue that callback may not be possible (due to lack of return path information) should be discussed on the mailing list.
(d) Security [[[and identification]]]
· Identification - label without authentication
· Authentication - "of undisputed origin".
· Integrity - usually for free with authentication.
· Privacy - proof against snooping.
· Authorization to use service (Denial of service protection?)
Larry: FROM of email to correspond roughly to required content of fax identification header line (per US law).
DC: proposed that identification behavior be provided equivalent to fax identification behavior, but no strong cryptography requirement for authentication, etc.
(Floor): Need to identify sending fax machine for purposes of sending notification back.
DC: On-ramp may need to adjust the FROM:, TO:, SENDER:, and other fields to get notification to work properly. (Some speculation about likely legal requirements for identification, ref. US requirement for all faxes to identify sender).
Identification: there are difficult issues need to be addressed.
A call was made for information about range of legal requirements of identification in different regions to be posted to the list.
DC, Privacy over the Internet: The Internet is perceived as not secure and easily tapped. Therefore the Internet should be assumed to be less secure that telephone system, and therefore IF we are to emulate perceived current fax security THEN we must implement encryption of message data over the Internet, or some other privacy mechanism (e.g. control the path). JR: the user will make the choice.
DC: suggested that the authentication and privacy issues would need to be considered in any fax standard, but would probably not be fully specified by this working group. Further discussion will take place on the mailing list.
DC: There is currently no widely-used Internet standard for authorization.
Steve Zilles: Authorization to use the service consists of two separate issues:
(a) mechanisms to control access to the facilities provided, given the identity of a party who is trying to use them, and
(b) mechanisms to verify the identity of a party who is trying to use them.
Issue (a) must be dealt with within the service protocol, but issue (b) could be handled by reference to some external authentication mechanism.
DC: may pay attention to security without necessarily solving it. Need to explore very wide range of issues related to security, and interactions between them.
No specific consensus was reached by the meeting.
Further discussion is moved to the list.
No time available
IV. Session Service
No time available
V. Closing Presentation: Relation to ITU Work.
James Rafferty briefly summarized the relation of the IETF work to that ongoing in ITU. He noted that some ITU members have expressed interest in using TIFF-F for store and forward fax via e-mail. Some of the current IDs, notably on TIFF, are likely to be submitted to the October ITU SG8 meeting. Cross reference between ITU and IETF documents is now permitted, so this would provide a way for ITU to incorporate IETF work (and vice versa) and reduce the chance of producing conflicting standards. Continued communication and cooperation between the two standards bodies is desirable.
FAX - Service Integration Issues
TIFF-FX Status, Draft 01
go to list