FaxConnect 1, held December 1-2, 1998 in San Jose, California, was an industry interoperability event for testing Internet fax, the new specification for sending facsimile messages over Internet mail. The participants included:

Canon Cisco Systems 5th Generation Messaging Genoa Intel Interstar Technologies

iReady KDD Matsushita Metasoft Natural MicroSystems NetCentric

Open Port Technology Optus Software Ricoh WIDE Project Xerox

Existing T.30 facsimile operates as a "real-time" service over switched telephone networks. Hence, is provides direct and immediate exchange between sending and receiving stations, over a channel dedicated to the communication during the exchange. One standards effort, ITU T.38, seeks to replicate this service exactly, over the Internet, by "tunneling" T.30 over Internet transport protocols. The joint IETF and ITU effort, RFCs 2301-2305 and ITU T.37, seeks to emulate a Simple Mode of fax service as a profile of Internet mail. Later work that is about to reach standards level provides enhancements for achieving Full Mode fax emulation.

Internet mail is store-and-forward, so that communication between sending and receiving stations is indirect and has variable transmission delay. The orientation towards an email-native profile means that onramp and offramp gateways must translate between facsimile and mail standards. Such translation can result in information loss. That is, Internet mail is has inherent differences from T.30 facsimile. Hence, any effort to translate between them is certain to show up the differences, such that translating between fax and email will not have perfect fidelity. This is a generic issue for all gateways and is not specific to fax over email.

Simple Mode permits a basic fax data object and offramp addressing, with notification of delivery failure. Full mode seeks to add fax-like sender acquisition of receiver capabilities as well as full, positive delivery and handling acknowledgment.

RFCs 2301-2305 specify the details for Simple Mode by packaging fax-like content, using TIFF inside Internet mail's MIME. Addressing for offramp dial-out on the switched telephone network uses Internet mail addresses with special structure on the mailbox (left-hand side of the at-sign). Transport is achieved using the SMTP protocol, with final delivery sometimes using the POP protocol (for delivery to individual email boxes, but not for multi-recipient relaying by an offramp.) Delivery and non-delivery notices use Internet mail.

• 10 POP mailboxes, for receiving
• 7 offramp addressing implementations using <phone>@<gateway>,
  with 3 using the standardized "Fax=+<phone>@<gateway>" format
• 2 organizations did testing through remote systems in Japan.

In addition, EMA (the Electronic Messaging Association) participated as observers. James Rafferty, chair of the IETF Internet Fax Working Group, developed an interworking matrix to meet requirements for this event and the IETF Fax WG.

Although the basic email technology that is used for fax-over-email standards is well established, some of the implementations for the fax environment are new. Hence, testing needed to cover regular email functionality, as well as the enhancements for the fax profile.

The results described here apply to post-event status. That is, the report does not list problems that were uncovered and fixed during the event.

Packaging (MIME)

Support for basic MIME is solid, included for simple use of the multipart content-type. Support for complex, nested MIME structures, such as a multipart within a multipart, is frequently absent from MIME implementations. Few RFC 2305 implementations attempt such support at this stage.

Content (TIFF)

"Simple mode requires the use of the very restricted, minimum set TIFF-FX profile "S", although it allows use of other profiles when the capabilities of the recipient are known. Some implementors had not appreciated the difference between the "S" profile and the commonly used "F" profile; a few implementations only sent "F", and some only accepted "S", which caused interoperability difficulties. The group is comfortable that this problem will be readily fixed. The group strongly encouraged enhancing the TIFF-FX and the "Simple Mode" specifications to highlight profile "S".

Three vendors successfully tested Full Mode TIFF profiles "J", "C", and "M".

Addressing

Support for the offramp addressing standard is limited. Most implementors expect to have support and do not feel this is a difficult issue. Apparently few feel that it is an essential, near-term requirement.

Transport

SMTP and POP worked well.

Error Notices

Internet mail has long had non-standard delivery failure notices. It recently added a standard mechanism for success and failure reporting, called Delivery Service Notices (DSN). Beyond delivery notification is the question of final "disposition" for a message. Internet mail has also recently defined a Message Disposition Notification (MDN) standard, to indicate that a message has been read, processed or the like.

Simple Mode requires that receiving sites send some sort of failure notice, with the use of DSN encouraged. Testing showed good support for this requirement and some support for positive DSN requests.

James Rafferty, the chair of the IETF Internet Fax Working Group, prepared the following matrix based on responses collected during the FaxConnect 1 event. In matrix, numeric entries under "Support" and "Interworking" are the number of companies who reported support and interworking for features, respectively. The numbers are conservative, since some companies reported feature support and did testing, but did not fill in the "Interworking" column.

Feature Set	Requirement Level	Condition	Support	Interworking Tested
Relay (2.1.1)	MAY	1. Data transfer MAY be achieved using standard Internet mail transfer mechanisms.	10	9
	MUST	2. The format of addresses MUST conform to the RFC 821 <addr-spec> and RFC 822 <mailbox> Internet mail standards.	12	7
Mailbox protocols (2.1.3)	SHOULD	3. An offramp gateway that operates as an MTA serving multiple users SHOULD use SMTP;	8	4
	MAY	4. A gateway that operates as a UA serving a single mail recipient MAY use a mailbox access protocol such as POP or IMAP.	4	2
Headers (2.2.1)	MUST	5. IFax devices MUST be compliant with RFC 822 and RFC1123, which define the format of mail headers.	12	8
	SHOULD or MUST	6. The header of an IFax message SHOULD include Message-ID and MUST include all fields required by [2, 3], such as DATE and FROM.	11	6
MIME (2.2.2)	MUST(*)	7. IFax devices MUST be compliant with MIME [4], except as noted in Appendix A (see 7.1-7.3 below):	10	6
	NOT REQ or REQUIRED	7.1 IFax senders are NOT REQUIRED to be able to send text/plain messages (RFC 2049 requirement 4), although Ifax recipients are required to accept such messages, and to process them.	9	7
	NOT REQ	7.2 IFax recipients are NOT REQUIRED to offer to put results in a file.	6	3
	MAY	7.3 IFax recipients MAY directly print/fax the received message rather than "display" it, as indicated in RFC 2049.	8	5
Content (2.2.3)		8. The data format of the facsimile image is based on the minimum set of TIFF for Facsimile[6], also known as the S profile. Such facsimile data are included in a MIME object by use of the image/TIFF sub-type.	12	8
Multipart (2.2.4)	SHOULD	9. A single multi-page document SHOULD be sent as a single multi-page TIFF file.	11	7
	MUST	10. (even though) Recipients MUST process multipart/mixed containing multiple TIFF files.	11	5
		11. If multipart content is present and processing of any part fails, then processing for the entire message is treated as failing, per [Processing failure] below.	9	4
Delivery failure (2.3.1)	MUST or SHOULD	12. In the event of relay failure, the sending relay MUST generate a failure message, which SHOULD be in the format of a DSN.	6	3
	MUST	13. Internet mail transported via SMTP MUST contain a MAIL FROM address appropriate for delivery of return notices.	11	7
Processing failure (2.3.2)	MAY	14. IFax devices with limited capabilities might be unable to process the content of a message. If this occurs it is important to ensure that the message is not lost without any notice. Notice MAY be provided in any appropriate fashion...	7	3
Section 3: Addressing
Classic Email Destinations (3.1)	MUST	15. Messages being sent to normal Internet mail recipients will use standard Internet mail addresses, without additional constraints.	13	6
Address Formats Used by Offramps (3.3)	MUST	16. When a G3Fax device is identified by a telephone number, the entire address used for the G3fax device, including the number and offramp host reference MUST be contained within standard Internet mail transport fields, such as RCPT TO and MAIL FROM [1, 3].	8	3
	MAY	17. The address MAY be contained within message content fields, such as <authentic> and <destination> [2, 3], as appropriate.	3	2
		18. As for all Internet mail addresses, the left-hand-side (local- part)of an address is not to be interpreted except by the MTA that is named on the right-hand-side (domain).	7	3
	SHOULD	19. The telephone number format SHOULD conform to [11, 12].	6	3
	MUST	20. Other formats MUST be syntactically distinct from [11, 12].	7	2
Section 4: Image File Format
	MUST	21. Sending IFax devices MUST be able to write minimum set TIFF files,per the rules for creating minimum set TIFF files defined in TIFF for Facsimile (the S profile)...	10	5
	MUST	22. Receiving IFax devices MUST be able to read minimum set TIFF files.	13	8
	SHOULD NOT	23. A sender SHOULD NOT use TIFF fields and values beyond the minimum subset of TIFF for Facsimile unless the sender has prior knowledge of other TIFF fields or values supported by the recipient.	10	5
Section 5: Security Considerations
Resources consumed by dialout (5.2.2)	SHOULD	24. Offramp gateways SHOULD provide the ability to authorize senders in some manner to prevent unauthorized use of the offramp.	5	3
GSTN authorization information (5.2.3	SHOULD	25. Confidential information about the sender necessary to dial a G3Fax recipient might be disclosed to the G3Fax recipient (on the cover page). Senders SHOULD be provided with a method of preventing such disclosure.	6	4
Sender accountability (5.2.4)	SHOULD	26. Offramps SHOULD ensure that the recipient is provided contact information about the offramp, in the event of problems.	4	1
	SHOULD	27. The G3Fax recipient SHOULD be provided with sufficient information which permits tracing the originator of the IFax message.	4	3
Message disclosure (5.2.5)	SHOULD	28. Users of G3Fax devices have an expectation of a level of message privacy which is higher than the level provided by Internet mail without security enhancements. This expectation of privacy by G3Fax users SHOULD be preserved as much as possible.	1	1
Channel security (5.3.1)		29. Virtual Private Networks (VPN) which make use of encrypted tunnels, such as via IPSec technology [18] or transport layer security, can be used to prevent eavesdropping of a message as it traverses such networks.	1
Object security (5.3.2)		30. Message encryption, such as PGP-MIME [13] and S/MIME, can be used to provide end-to-end encryption.	1

The Internet Mail Consortium is an industry trade association for companies participating in the Internet mail market. To give feedback or to get more information on IMC reports, send mail to <mailto:reports@imc.org>. For information on the Internet Mail Consortium, please visit our web site at <http://www.imc.org/>, or call us at +1 (831) 426-9827.