draft A MIME body part for FAX Nov 95 A MIME body part for FAX Tue Nov 21 15:32:07 MET 1995 Harald Tveit Alvestrand UNINETT Harald.T.Alvestrand@uninett.no Status of this Memo This draft document is being circulated for comment. Please send comments to the author, or to the MIXER list <ietf- mixer@innosoft.com>. The following text is required by the Internet-draft rules: This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. The file name of this version is draft-ietf-mixer-fax-00.txt Alvestrand Expires May 96 [Page 1]
draft A MIME body part for FAX Nov 95 1. Introduction This document contains the definitions, originally contained in RFC 1494, on how to carry CCITT G3Fax in MIME, and how to translate it to its X.400 representation. This document is an Experimental standard; if it turns out to be useful and widely deployed, it can be moved onto the standards track. 2. The image/g3fax content-type This content-type is defined to carry G3 Facsimile byte streams. In general, a G3Fax image contains 3 pieces of information: (1) A set of flags indicating the particular coding scheme. CCITT Recommendation T.30 defines how the flags are transmitted over telephones. In this medium, the flags are carried as parameters in the MIME content-type header field. (2) A structure that divides the bits into pages. CCITT recommendation T.4 describes a "return to command mode" string; this is used here to indicate page breaks. (3) For each page, a sequence of bits that form the encoding of the image. CCITT recommendation T.4 defines the bit image format. This is used without change. The highest bit of the first byte is the first bit of the T.4 bitstream. 2.1. G3Fax Parameters The following parameters are defined: (1) page-length - possible values: A4, B4 and Unlimited (2) page-width - possible values: A3, A4, B4 (3) encoding - possible values: 1-dimensional, 2-dimensional, Uncompressed Alvestrand Expires May 96 [Page 2]
draft A MIME body part for FAX Nov 95 (4) resolution - possible values: Fine, Coarse (5) DCS - a bit string, represented in Base64. (6) pages - an integer, giving the number of pages in the document If nothing is specified, the default parameter settings are: page-length=A4 page-width=A4 encoding=1-dimensional resolution=Coarse It is possible (but misleading) to view the representation of these values as single-bit flags. They correspond to the following bits of the T.30 control string and X.400 G3FacsimileParameters: Parameter T.30 bit X.400 bit page-length=A4 no bit set page-length=B4 19 21 page-length=Unlimited 20 20 page-width=A4 no bit set page-width=A3 18 22 page-width=B4 17 23 encoding=1-dimensional no bit set encoding=2-dimensional 16 8 encoding=Uncompressed 26 30 resolution=Coarse no bit set resolution=Fine 15 9 The reason for the different bit numbers is that X.400 counts bits in an octet from the MSB down to the LSB, while T.30 uses the opposite numbering scheme. If any bit but these are set in the Device Control String, the DCS parameter should be supplied. Alvestrand Expires May 96 [Page 3]
draft A MIME body part for FAX Nov 95 2.2. Content Encoding X.400 defines the g3-facsimile data stream as a SEQUENCE of BIT STRINGs. Each BIT STRING is a page of facsimile image data, encoded as defined by Recommendation T.4. The following content encoding is reversible between MIME and X.400 and ensures that page breaks are honored in the MIME representation. An EOL is defined as a bit sequence of 000000000001 (eleven zeroes and a one). Each page of the message is delimited by a sequence of six (6) EOLs that MUST start on a byte boundary. The image bit stream is padded with zeroes as needed to achieve this alignment. Searching for the boundary is a matter of searching for the byte sequence (HEX) 00 10 01 00 10 01 00 10 01, which cannot occur inside the image. See Section 7.5 for the algorithm on conversion between this encoding and the X.400 encoding. The Base64 content-transfer-encoding is appropriate for carrying this content-type. 3. g3-facsimile - image/g3fax X.400 Body part: g3-facsimile MIME Content-Type: image/g3fax Conversion Type: nearly Byte copy Comments: The Parameters of the X.400 G3Fax body part are mapped to the corresponding Parameters on the MIME Image/G3Fax body part and vice versa. Note that: (1) If fineResolution is not specified, pixels will be twice as tall as they are wide (2) If any bit not corresponding to a specially named option is set in the G3Fax NonBasicParameters, the "DCS" parameter Alvestrand Expires May 96 [Page 4]
draft A MIME body part for FAX Nov 95 must be used. (3) Interworking is not guaranteed if any bit apart from those specially named are used in the NonBasicParameters From X.400 to G3Fax, the body is created in the following way: (1) Any trailing EOL markers on each bitstring is removed. The bit order is changed to conform to the most common Internet encoding (highest bit of first byte = first bit of the G3Fax). The bitstring is padded to a byte boundary. (2) 6 consecutive EOL markers are appended to each bitstring. (3) The padded bitstrings are concatenated together An EOL marker is the bit sequence 000000000001 (11 zeroes and a one). From G3Fax to X.400, the body is created in the following way: (1) The body is split into bitstrings at each occurrence of 6 consecutive EOL markers. Trailing EOLs must NOT be removed, since the X.400 Implementor Guide recommends that each page should end with 6 consecutive EOLs. (This is a change from RFC 1494). (2) Each bitstring is made into an ASN.1 BITSTRING, reversing the order of bits within each byte to conforom to the X.400 Implementors Guide recommendation for bit order in the G3Fax body part. (3) The bitstrings are made into an ASN.1 SEQUENCE, which forms the body of the G3Fax body part. 4. Security considerations Security issues are not consiered in this memo. Alvestrand Expires May 96 [Page 5]
draft A MIME body part for FAX Nov 95 5. REFERENCES [MIME] RFC 1521: N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", 09/23/1993 Alvestrand Expires May 96 [Page 6]