RFC 2159

A MIME Body Part for FAX

📅 published January 1998, from ietf

A MIME Body Part for FAX 📠✨

Bestie, this one's a whole vintage vibe 🎀

  • RFC: 2159
  • Author: H. Alvestrand (UNINETT) 🧚
  • Category: Standards Track 👑
  • Date: January 1998 🌸
  • Obsoletes / Updates: none listed in the title block 🫶

Status of This Memo 📜

This document specifies an Internet standards track protocol for the Internet community, and it's asking everyone for discussion and suggestions for improvements 💅. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🦋.

Copyright (C) The Internet Society (1998). All Rights Reserved.

1. Introduction ✨

Okay so this doc has the definitions that were originally in RFC 1494 🌸. It explains how to carry CCITT G3Fax in MIME, and how to translate it into its X.400 representation 💖.

NOTE: Real talk, this format doesn't seem appropriate for a "general purpose image format for the Internet," if such a beast can exist 💀. It only exists to carry information that's already in G3 Fax format, and it can be usefully converted to other formats when used in specific contexts.

2. The image/g3fax content-type 🎀

This content-type is defined to carry G3 Facsimile byte streams 📠. A G3Fax image is basically 3 pieces of info, and it's giving organized 🍓:

  1. A set of flags indicating the particular coding scheme. CCITT Recommendation T.30 defines how the flags get 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, and this is used here to indicate page breaks ✂️.
  3. For each page, a sequence of bits that forms the encoding of the image. CCITT recommendation T.4 defines the bit image format, and 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 🦋

These parameters are defined, and they're all iconic 👑:

  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
  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's possible (but misleading) to view 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 bit numbers differ because X.400 counts bits in an octet from the MSB down to the LSB, while T.30 uses the opposite numbering scheme 🔄. Lowkey confusing, but it makes sense once you see it 💅.

If any bit other than these is set in the Device Control String, the DCS parameter should be supplied 📝.

2.2. Content Encoding 🌸

X.400 defines the g3-facsimile data stream as a SEQUENCE of BIT STRINGs 🧶. Each BIT STRING is one page of facsimile image data, encoded as defined by Recommendation T.4. The following content encoding is reversible between MIME and X.400, and it makes sure page breaks are honored in the MIME representation 💖.

An EOL is defined as this bit sequence (eleven zeroes and a one) ✨:

000000000001

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 just searching for the byte sequence (HEX) below, which cannot occur inside the image 🔍:

00 10 01 00 10 01 00 10 01

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 get 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 must be used.
  3. Interworking is not guaranteed if any bit apart from those specially named is used in the NonBasicParameters ⚠️.

From X.400 to G3Fax, the body gets created like this 🌈:

  1. Any trailing EOL markers on each bitstring get removed. The bit order changes to match the most common Internet encoding (highest bit of first byte = first bit of the G3Fax). The bitstring gets padded to a byte boundary.
  2. 6 consecutive EOL markers get appended to each bitstring.
  3. The padded bitstrings get concatenated together.

An EOL marker is the bit sequence 000000000001 (11 zeroes and a one) ✨.

From G3Fax to X.400, the body gets created like this 🦋:

  1. The body gets 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 conform 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. Usability of G3Fax body parts 🙈

This section is not part of the proposed standard, but it's intended as guidance for people implementing G3Fax handling, so they know a little about what to expect 💅.

The DCS bitstring is a LONG thing 😭. The T.30 Recommendation (1993) gives 67 bits with specific functions, SG8 Report R33 extends this to 75 bits, and Report R41 (approved in 1995) extends it to 79 bits. (For curiosity, bit 68 says the coding is JPEG, and bit 27 is "error correcting mode".) No sane implementor will send such things without being able to negotiate them down if the recipient doesn't support them, but there's no guarantee that messages with such bits set in the DCS won't arrive through X.400 💀.

The ISO P2 profile from 1995 [PROFILE] says the profile makes support for reception of two-dimensional and fine-resolution mandatory if g3-facsimile is supported at all 📜. Research by Andrew Gordon of Net-Tel indicates that it's easy for an access unit to support fine resolution, unlimited length and B4 length, while support for B4 width is nearly impossible, and A3 width is hard 🥲.

Another interesting point: some fax machines have trouble if the scan lines don't contain exactly the declared number of pixels on each scan line, so "omitting right-hand white space" is likely to give trouble 🙃.

5. Security Considerations 🔐

There are no known security issues specific to the FAX body part 🫶.

6. References 📚

[MIME] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

[GUIDE] X.400 Implementor's Guide, version 8.

[PROFILE] ISO/IEC ISP 12062-2: 1995:

[T.30] ITU-T Recommendation T.30 (1993): Procedures for document facsimile transmission in the general switched telephone network.

7. Author's Address 🧚

Harald Tveit Alvestrand UNINETT P.O.box 6883 Elgeseter N-7002 Trondheim NORWAY

EMail: Harald.T.Alvestrand@uninett.no 💌

Copyright (C) The Internet Society (1998). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🦋

📦 where this page comes from