From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2159.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc2159.txt (limited to 'doc/rfc/rfc2159.txt') diff --git a/doc/rfc/rfc2159.txt b/doc/rfc/rfc2159.txt new file mode 100644 index 0000000..148b188 --- /dev/null +++ b/doc/rfc/rfc2159.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group H. Alvestrand +Request for Comments: 2159 UNINETT +Category: Standards Track January 1998 + + + A MIME Body Part for FAX + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +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. + + NOTE: At the moment, this format does not seem appropriate for a + "general purpose image format for the Internet", if such a beast can + exist. It exists only to carry information that is already in G3 Fax + format, and may 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. + + 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. + + + + + +Alvestrand Standards Track [Page 1] + +RFC 2159 MIME Body Part for FAX January 1998 + + + (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 + + (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 + + + + + + + + + + + + + + + + + + + + + + +Alvestrand Standards Track [Page 2] + +RFC 2159 MIME Body Part for FAX January 1998 + + + 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. + +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. + + + +Alvestrand Standards Track [Page 3] + +RFC 2159 MIME Body Part for FAX January 1998 + + + 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 + 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). + + + +Alvestrand Standards Track [Page 4] + +RFC 2159 MIME Body Part for FAX January 1998 + + + (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. Usability of G3Fax body parts + + This section is not part of the proposed standard, but is intended as + guidance for people implementing G3Fax handling, so that 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 that the coding is JPEG; 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 it, but there is 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 that 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 is 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 is that some fax machines have trouble if + the scan lines do not 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. + + + + + + + + + + + + + +Alvestrand Standards Track [Page 5] + +RFC 2159 MIME Body Part for FAX January 1998 + + +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 + + + + + + + + + + + + + + + + + + + + + + + + + +Alvestrand Standards Track [Page 6] + +RFC 2159 MIME Body Part for FAX January 1998 + + +8. Full Copyright Statement + + 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. + + + + + + + + + + + + + + + + + + + + + + + + +Alvestrand Standards Track [Page 7] + -- cgit v1.2.3