Subject: Interworking Requirements for RFC2305

From: James Rafferty <[email-masked]>
Date: Wed, 02 Dec 1998 13:37:22 -0500

Folks, 

This week at Fax Connect I there are interworking tests going on related to
RFC
2305 (the simple mode of Internet fax).   

In a related effort, I have extracted a list of the various MUST/SHOULD/MAY
and
other conditions from RFC 2305 to aid interworking and related
test/implementation activities.     

A copy of this information is attached.   

Next week at the Thurs IETF Fax meeting, we will review the results of
interworking activities to date for RFC 2305 and RFC 2301 (TIFF Profiles).   
This will aid us as we review the requirements for progressing the current
Internet fax RFCs to draft standard status.   

James 

________________________________

Internet Fax Simple Mode Interworking
Matrix of Requirements (derived from RFC 2305) 

1.  Communication Cases (per RFC 2305, 1.2)

A) Internet mail             =>  Network printer

B) Internet mail             =>  Offramp gateway (forward to
                                 G3Fax)

C) Network scanner           =>  Network printer

D) Network scanner           =>  Offramp gateway (forward to
                                 G3Fax)

E) Network scanner           =>  Internet mail

For the remainder of the document, conditions found in the RFC 2305 document
are presented.   For ease of reference, the conditions are numbered and
presented by section, in the same order as they appear within RFC 2305.  
(There is one special case.   Appendix A of RFC 2305 specifies the permitted
exceptions to normal MIME behavior.  These exceptions are itemized as part of
condition 7 on MIME compliance below). 

Most of the conditions are requirements at the MUST, SHOULD or MAY level, with
the meaning of these words defined per RFC 2119. 

Section 2 -  Communication Protocols

Transport (2.1)

Relay (2.1.1)

1.  Data transfer MAY be achieved using standard Internet mail transfer
mechanisms[1, 3].  

2. The format of addresses MUST conform to the RFC
821 <addr-spec> and RFC 822 <mailbox> Internet mail standards.   

Mailbox protocols (2.1.3)

3.  An offramp gateway that operates as an MTA serving multiple users SHOULD
use SMTP; 

4.  A gateway that operates as a UA serving a single
   mail recipient MAY use a mailbox access protocol such as POP or IMAP.  

Message Formats (2.2)

Headers  (2.2.1)

5.  IFax devices MUST be compliant with RFC 822 and RFC1123, which define the
format of mail headers. 

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.

MIME (2.2.2)

7.  IFax devices MUST be compliant with MIME [4], except as noted in Appendix
A.

 Appendix A exceptions:  

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.

   7.2    IFax recipients are NOT REQUIRED to offer to put results in  a file.
(Also see 2.3.2.)

   7.3    IFax recipients MAY directly print/fax  the received message rather 
than "display" it, as indicated in RFC 2049.

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. 

Multipart (2.2.4)

9.  A single multi-page document SHOULD be sent as a single multi-page TIFF
file.  

10.  (even though) Recipients MUST process multipart/mixed
   containing multiple TIFF files. 

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.

Error Handling (2.3)  

Delivery failure (2.3.1)

12.  In the event of relay failure, the sending relay MUST generate a failure
message, which SHOULD be in the format of a DSN. 

13.  Internet mail transported via SMTP MUST contain a MAIL FROM address
appropriate for delivery of return notices.  

Processing failure (2.3.2)

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, and the exact handling is a local matter.

Section 3  ADDRESSING

Classic Email Destinations (3.1)

15.  Messages being sent to normal Internet mail recipients will use standard
Internet mail addresses, without additional constraints.

Address Formats Used by Offramps (3.3)

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]. 

17.  The address MAY be contained within message content fields, such as
<authentic> and <destination> [2, 3], as appropriate.

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).

19.  The telephone number format SHOULD conform to [11, 12].  

20.  Other formats MUST be syntactically distinct from [11, 12].

Section 4  IMAGE FILE FORMAT

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) [6], which is also compatible with the specification for the minimum
subset of TIFF-F in [5].  

22.  Receiving IFax devices MUST be able to read minimum set TIFF files.

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.

Section 5  SECURITY CONSIDERATIONS

Resources consumed by dialout (5.2.2)

24.  Offramp gateways SHOULD provide the ability to authorize senders in some
manner to prevent unauthorized use of the offramp. (There are no standard
techniques for authorization using Internet protocols.)

GSTN authorization information (5.2.3)

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.

Sender accountability (5.2.4)

26.  Offramps SHOULD ensure that the recipient is provided contact information
about the offramp, in the event of problems.

27.   The G3Fax recipient SHOULD be provided with sufficient information which
permits tracing the originator of the IFax message.

Message disclosure (5.2.5)

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.

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.  

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.

*------------------------------------------------*
James Rafferty			
President, Human Communications 	
12 Kevin Drive			
Danbury, CT  06811-2901		
USA					
Voice/Fax:  +1-203-746-4367
Email:  [email-masked]
	 [email-masked]

HC Web Site:  http://www.humancomm.com  
*---------------------------------------------------