prepared by
James Rafferty
Human Communications
Internet Mail Consortium Report: FC2-FINAL
IMCR-014, August 8, 1999
FaxConnect 2, held May 18-19, 1999 in San Jose, California and simultaneously on May 20-21 in Tokyo, Japan was an industry interoperability event for testing Internet fax, the new specifications for sending facsimile messages over Internet mail. The participants included:
Many of the companies conducted tests at both sites. In some cases, the company did single site testing in either Tokyo or San Jose. The unique test environment permitted local testing at both sites as well as transcontinental testing.
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 has now reached the standards level as RFCs 2530-2532 provides enhancements for achieving extended/full mode Internet fax.
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.
The organizations listed above participated in the event. They used:
In addition, the Internet Fax Study Association helped to organize the Tokyo side event. James Rafferty, chair of the IETF Internet Fax Working Group, developed 3 interworking matrices to meet requirements for this event and the IETF Fax WG. He also was an observer on behalf of the newly formed Internet Fax and Business Communications Association.
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.
Support for basic MIME is solid, although almost all testing involved image/tiff, rather than multipart structures. However, several vendors indicated support 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.
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. The implementors now understand the difference between the "S" profile and the commonly used "F" profile. Most testing was based on the S profile, but there were also several F profile implementations. A discrepancy in the text of RFC 2301 regarding the "fill order" was noted and it was confirmed that only a single fill order is permitted for Profile S implementations. This clarification has been passed to the IETF working group, but no other particular clarification requirements were noted. Most implementations were in the context of simple mode, but there was some exchange of TIFF S and F files just to check their content.
Support for the offramp addressing standard (RFC 2303 and 2304) was limited at Fax Connect I and still is fairly limited at this event. It appears that most of the support by receivers will be by companies that provide offramp services. Most implementors expect to be able to support the send syntax to such offramps.. The IETF working group chair feels further interworking is needed in order to have these standards progress to the draft standard level.
SMTP and POP worked well. There were some differences in interworking results that occurred when transcontinental testing was conducted.
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 as a SHOULD condition. Testing showed good support for generating failure notices, but no support yet at this event for generating them in the DSN format.
James Rafferty, the chair of the IETF Internet Fax Working Group, prepared the following matrix (and the two to follow) based on responses collected during the FaxConnect 2 event. In matrix, numeric entries under "Support" and "Interworking" are the number of companies who reported support and interworking for features, respectively. Results are shown for 13 participants and some related implementation notes are summarized at the end.
|
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. |
11 |
9 |
|
MUST |
2. The format of addresses MUST conform to the RFC 821 <addr-spec> and RFC 822 <mailbox> Internet mail standards. |
11 |
11 |
|
|
Mailbox protocols (2.1.3) |
SHOULD |
3. An offramp gateway that operates as an MTA serving multiple users SHOULD use SMTP; |
6 |
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. |
5 |
2 |
|
|
Headers (2.2.1) |
MUST |
5. IFax devices MUST be compliant with RFC 822 and RFC1123, which define the format of mail headers. |
13 |
11 |
|
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 |
9 |
|
|
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): |
8 |
7 |
|
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 (*) |
8 |
|
|
NOT REQ |
7.2 IFax recipients are NOT REQUIRED to offer to put results in a file. |
8 |
4 |
|
|
MAY |
7.3 IFax recipients MAY directly print/fax the received message rather than "display" it, as indicated in RFC 2049. |
8 |
6 |
|
|
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 |
9 |
|
Multipart (2.2.4) |
SHOULD |
9. A single multi-page document SHOULD be sent as a single multi-page TIFF file. |
11 |
10 |
|
MUST |
10. (even though) Recipients MUST process multipart/mixed containing multiple TIFF files. |
9 |
4 |
|
|
|
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. |
7 (**) |
|
|
MUST |
13. Internet mail transported via SMTP MUST contain a MAIL FROM address appropriate for delivery of return notices. |
8 |
8 |
|
|
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... |
5 |
2 |
|
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. |
11 |
7 |
|
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 |
5 |
|
MAY |
17. The address MAY be contained within message content fields, such as <authentic> and <destination> [2, 3], as appropriate. |
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). |
4 |
2 |
|
|
SHOULD |
19. The telephone number format SHOULD conform to [11, 12]. |
4 |
3 |
|
|
MUST |
20. Other formats MUST be syntactically distinct from [11, 12]. |
4 |
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)... |
11 |
10 |
|
|
MUST |
22. Receiving IFax devices MUST be able to read minimum set TIFF files. |
12 |
9 |
|
|
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. |
4 |
3 |
|
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 |
|
|
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. |
4 |
2 |
|
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. |
8 |
2 |
|
|
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. |
2 (***) |
2 |
|
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. |
|
|
Implementation Notes:
In the matrix, numeric entries under "Support" and "Interworking" are the number of companies who reported support and interworking for features, respectively. Results are shown for 11 participants and there are some related implementation notes are summarized at the end.
|
Feature Set |
Requirement Level |
Condition |
Support |
Interworking |
||||
|
Section 2: TIFF and Fax |
||||||||
|
Required Tiff Fields (2.2.1) |
MUST |
1. Support is provided for all required TIFF fields whose values are not mode dependent |
9 |
9 |
||||
|
Additional Required TIFF Fields for Fax (2.2.2) |
MUST |
2. Support is provided for all additional TIFF fields that are required for Fax, but whose values are mode dependent |
10 |
9 |
||||
|
Recommended Fields (2.2.3) |
MAY |
3. Support is provided for recommended TIFF fields (please specify field names).
|
2 |
1 |
||||
|
New Fields (new) |
MAY |
4, Support is provided for new fields (please specify field names and applicable profiles per field)
|
1 |
|
||||
|
Section 3: Minimal Black-and-White Fax Mode (Profile S) |
||||||||
|
Profile S (3.) |
MUST |
5. Support is provided for a Profile S Writer |
9 |
8 |
||||
|
MUST |
6. Support is provided for a Profile S Reader |
10 |
9 |
|||||
|
Profile S Fields (3.1.1, 3.1.2) |
MUST |
7. Support is provided for the additional required fields for Profile S |
9 |
8 |
||||
|
RTC Exclusion (3.4.1) |
SHOULD NOT |
8. Implementations which wish to maintain strict conformance with TIFF and compatibility with the historical use of TIFF for fax SHOULD NOT include the RTC sequence when writing TIFF files. |
5 |
3 |
||||
|
MAY |
9. Implementations which need to support "transparency" of T.4-generated image data MAY include RTCs when writing TIFF files if the flag settings of the T4Options field are set for non-byte aligned data |
4 |
3 |
|||||
|
MUST/ |
10. Minimal set readers MUST be able to process files which do not include RTCs and SHOULD be able to process files which do include RTCs. |
6 |
4 |
|||||
|
File Structure (3.5) |
MUST |
11. Support provided for required Profile S file structure, including LSByte-first order (little- endian) byte order and mandatory ordering of IFDs, long fields, and image data. |
10 |
9 |
||||
|
File Summary (3.6) |
MUST |
12. The Baseline and Extension fields and field values MUST be supported by all implementations. |
11 |
9 |
||||
|
Section 4. Extended Black-and-White fax mode (Profile F) |
||||||||
|
F Profile (4.) |
MAY |
13. Support is provided for Profile F Reader |
5 |
5 |
||||
|
MAY |
14. Support is provided for a Profile F Writer |
3 |
1 |
|||||
|
Required Fields (4.2) |
MUST |
15. Support is provided for the required Profile F fields and legal values are used. |
4 |
2 |
||||
|
Guidelines (4.4.6) |
SHOULD |
16. Support is provided for the guidelines for reading and writing Profile F files. |
3 |
|
||||
|
Section 5: Lossless JBIG Black-and-White Fax Mode (Profile J) |
||||||||
|
J Profile (5.) |
MAY |
17. Support is provided for Profile J Reader: |
|
|
||||
|
MAY |
18. Support is provided for a Profile J Writer: |
|
|
|||||
|
MUST |
19. Support is provided for the required Profile J fields and legal values are used. |
|
|
|||||
|
Section 6: Base Color Fax Mode (Profile C) |
||||||||
|
C Profile (6.) |
MAY |
19. Support is provided for Profile C Reader: |
|
|
||||
|
MAY |
20. Support is provided for a Profile C Writer: |
|
|
|||||
|
MUST |
21. Support is provided for the required Profile C fields and legal values are used. |
|
|
|||||
|
Section 7: Lossless Color Mode (Profile L) |
||||||||
|
L Profile (7.) |
MAY |
22. Support is provided for Profile L Reader: |
|
|
||||
|
MAY |
23. Support is provided for a Profile L Writer: |
|
|
|||||
|
MUST |
24. Support is provided for the required Profile L fields and legal values are used. |
|
|
|||||
|
Section 8: Mixed Raster Content Mode (Profile M) |
||||||||
|
M Profile (8.) |
MAY |
25. Support is provided for Profile M Reader: |
|
|
||||
|
MAY |
26. Support is provided for a Profile M Writer: |
|
|
|||||
|
MUST |
27. Support is provided for the required Profile M fields and legal values are used. |
|
|
|||||
Implementation Notes:
As per the results of items 8 and 9, there are implementations which both do not include RTCs when writing TIFF files and do include RTCs; As per item 10, support of both cases by TIFF readers is important for interoperability.
In the matrix, numeric entries under "Support" and "Interworking" are the number of companies who reported support and interworking for features, respectively. Results are shown for 4 participants and there are some related implementation notes are summarized at the end.
|
Feature Set |
Requirement Level |
Condition |
Support |
Interworking |
|
RFC 2303 - Section 1: Introduction |
||||
|
Minimum RFC 2303 Specification (1.) |
MUST |
1. All implementations supporting this PSTN over email service MUST support as a minimum the specification described in (RFC 2303). |
4 |
4 |
|
RFC 2303 - Section 2: Minimal PSTN Address |
||||
|
Non-Minimal Extensions (2.) |
MAY |
2. Implementations confirming to the minimal requirements specification are allowed to ignore any other non-minimal extension address elements which are present in the "pstn-address". |
3 |
3 |
|
MUST |
3. Conforming implementations MUST preserve all "qualif-type1" address elements they receive. |
3 |
2 |
|
|
Global Phone Syntax (2.1 - both RFCs) |
MUST NOT |
4. Any non "global-phone" dialing schema MUST NOT use the leading "+" between the "=" sign and the dialing string. The "+" sign is strictly reserved for the standard "global-phone" syntax. |
3 |
2 |
|
Written SEP Elements (2.1 - both RFCs) |
MAY |
5. Use of the written-sep elements is allowed, but not recommended. |
3 |
1 |
|
MUST |
6. Any occurrences of written-sep elements in a pstn-mbox MUST be ignored by all conformant implementations. |
3 |
|
|
|
SHOULD |
7. User Agents SHOULD remove written-sep elements before submitting messages to the Message Transport System. |
2 |
|
|
|
RFC 2303- Section 3: The email address of the I-pstn device: mta-I-pstn |
||||
|
Domain String (3. - both RFCs) |
MUST |
8. For "domain" strings used in SMTP transmissions, the string MUST conform to the requirements of that standard's <domain> specifications (RFC 821/RFC 1123). |
4 |
3 |
|
MUST |
9. For "domain" strings used in message content headers, the string MUST conform to the requirements of the relevant standards (RFC 822, RFC 1123). |
4 |
3 |
|
|
RFC 2303, Section 4: The PSTN email |
||||
|
pstn-email element (4.- both RFCs) |
MUST |
10. Implementations MUST accept the optional slashes "/" (in the pstn-email element). |
2 |
|
|
|
SHOULD NOT |
11. Implementations SHOULD NOT generate (slashes "/"). |
2 |
1 |
|
|
MAY |
12. Gateways are allowed to strip them off when converting to Internet mail addressing. |
1 |
|
|
|
MUST |
13. The ""pstn-address" element MUST strictly follow the "quoting rules" specified in the relevant standards (RFC 822, RFC 1123). |
3 (*) |
1 |
|
Multiple Subaddresses (RFC 2303 - 4.1) |
MUST (WILL) |
14. For services that require multiple subaddresses, for the same "pstn-mbox", multiple "pstn-email" elements will be used. |
|
|
|
MUST |
15. The UA could accept multiple subaddress elements for the same global-phone, but it must generate multiple "pstn-mbox" elements when passing the message to the MTA. |
|
|
|
|
RFC 2303/2304 - Section 6: Security Considerations |
||||
|
Mail Routing (6. - both RFCs) |
SHOULD |
16. Clients SHOULD ensure that mail routing (as a result of Domain Name information) is based only on authoritative answers. |
2 |
1 |
|
SHOULD |
17. Once DNS Security mechanisms [RFC 2065] become more widely deployed, clients SHOULD employ those mechanisms to verify the authenticity and integrity of mail routing records. |
1 |
|
|
|
RFC 2304 - Section 1: Introduction |
||||
|
Minimum Specification (1.) |
MUST |
18. All implementations supporting this FAX over email address format MUST support as a minimum the specification described in this document (RFC 2304). |
3 |
2 |
|
RFC 2304 - Section 2: Minimal Fax Address |
||||
|
qualif-type1 element (2.) |
REQUIRED |
19. The minimal addressing for the fax service also requires support for a "qualif-type1" element. This element is an OPTIONAL element of the fax address, but its support, when present, is REQUIRED: |
1 |
|
|
Fax address minimum specification (2.1) |
REQUIRED |
20. The minimal specification of a fax in email address is: |
2 |
1 |
|
RFC 2304 - Section 2: Minimal Fax Address |
||||
|
Multiple T.33 Subaddresses (4.1) |
MUST |
21. In case a particular service requires multiple T.33 subaddresses, and these subaddresses need to be given on the same "fax-mbox", multiple "fax-email" elements will be used. |
|
|
|
MUST |
22. In case a particular service requires multiple T.33 subaddresses, and these subaddresses need to be given on the same "fax-mbox", multiple "fax-email" elements will be used. |
|
|
|
Implementation Notes:
* - There was one problem related to use of quotes (see item 13 above); one implementation enclosed a mailbox name in quotes (e.g. "Fax=1234"@domain.com) and not all implementations could handle. Per a review within the relevant standards, this use of the quoting rules is OK, so it should be acceptable to implementations which receive it.
In discussion on a future Fax Connect, the thinking was that the next event for store and forward Internet fax should not take place until sometime in the first half of the year 2000, after manufacturers have successfully dealt with the year 2000 date (Y2K) problems. In addition, there will be time needed to begin deployment of the extended or full mode of Internet Fax. James Rafferty announced that there is a new industry association which will have a strict Internet fax focus, known as the Internet Fax and Business Communications Association. More information on that group can be found at <http://www.ifaxbus.org/>.
James and Paul Hoffman reported that the IMC and the new IFBCA have signed an agreement to transfer responsibility for the next in the series of Fax Connect events to the IFBCA, since the IMC has a predominantly email focus and the new group is directed more to Internet fax. There will be a transition period where the Fax Connect mailing list is maintained and pointers will be placed between the web sites for the two organizations. In addition, it is anticipated that the Internet Fax Study Association will continue to have some involvement in helping the IFBCA put together future Fax Connect events.
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.