idnits 2.17.1 draft-ietf-mixer-fax-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 4. Security considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 140: '... EOLs that MUST start on a byte bou...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date () is 739384 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'MIME' on line 215 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 draft A MIME body part for FAX Nov 95 3 A MIME body part for FAX 5 Tue Nov 21 15:32:07 MET 1995 7 Harald Tveit Alvestrand 8 UNINETT 9 Harald.T.Alvestrand@uninett.no 11 Status of this Memo 13 This draft document is being circulated for comment. 15 Please send comments to the author, or to the MIXER list . 18 The following text is required by the Internet-draft rules: 20 This document is an Internet Draft. Internet Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its 22 Areas, and its Working Groups. Note that other groups may also 23 distribute working documents as Internet Drafts. 25 Internet Drafts are draft documents valid for a maximum of six 26 months. Internet Drafts may be updated, replaced, or obsoleted by 27 other documents at any time. It is not appropriate to use 28 Internet Drafts as reference material or to cite them other than 29 as a "working draft" or "work in progress." 31 Please check the I-D abstract listing contained in each Internet 32 Draft directory to learn the current status of this or any other 33 Internet Draft. 35 The file name of this version is draft-ietf-mixer-fax-00.txt 37 draft A MIME body part for FAX Nov 95 39 1. Introduction 41 This document contains the definitions, originally contained in 42 RFC 1494, on how to carry CCITT G3Fax in MIME, and how to 43 translate it to its X.400 representation. 45 This document is an Experimental standard; if it turns out to be 46 useful and widely deployed, it can be moved onto the standards 47 track. 49 2. The image/g3fax content-type 51 This content-type is defined to carry G3 Facsimile byte streams. 53 In general, a G3Fax image contains 3 pieces of information: 55 (1) A set of flags indicating the particular coding scheme. 56 CCITT Recommendation T.30 defines how the flags are 57 transmitted over telephones. In this medium, the flags are 58 carried as parameters in the MIME content-type header 59 field. 61 (2) A structure that divides the bits into pages. CCITT 62 recommendation T.4 describes a "return to command mode" 63 string; this is used here to indicate page breaks. 65 (3) For each page, a sequence of bits that form the encoding of 66 the image. CCITT recommendation T.4 defines the bit image 67 format. This is used without change. The highest bit of 68 the first byte is the first bit of the T.4 bitstream. 70 2.1. G3Fax Parameters 72 The following parameters are defined: 74 (1) page-length - possible values: A4, B4 and Unlimited 76 (2) page-width - possible values: A3, A4, B4 78 (3) encoding - possible values: 1-dimensional, 2-dimensional, 79 Uncompressed 81 draft A MIME body part for FAX Nov 95 83 (4) resolution - possible values: Fine, Coarse 85 (5) DCS - a bit string, represented in Base64. 87 (6) pages - an integer, giving the number of pages in the 88 document 90 If nothing is specified, the default parameter settings are: 92 page-length=A4 93 page-width=A4 94 encoding=1-dimensional 95 resolution=Coarse 97 It is possible (but misleading) to view the representation of 98 these values as single-bit flags. They correspond to the following 99 bits of the T.30 control string and X.400 G3FacsimileParameters: 101 Parameter T.30 bit X.400 bit 103 page-length=A4 no bit set 104 page-length=B4 19 21 105 page-length=Unlimited 20 20 107 page-width=A4 no bit set 108 page-width=A3 18 22 109 page-width=B4 17 23 111 encoding=1-dimensional no bit set 112 encoding=2-dimensional 16 8 113 encoding=Uncompressed 26 30 115 resolution=Coarse no bit set 116 resolution=Fine 15 9 118 The reason for the different bit numbers is that X.400 counts bits 119 in an octet from the MSB down to the LSB, while T.30 uses the 120 opposite numbering scheme. 122 If any bit but these are set in the Device Control String, the DCS 123 parameter should be supplied. 125 draft A MIME body part for FAX Nov 95 127 2.2. Content Encoding 129 X.400 defines the g3-facsimile data stream as a SEQUENCE of BIT 130 STRINGs. Each BIT STRING is a page of facsimile image data, 131 encoded as defined by Recommendation T.4. The following content 132 encoding is reversible between MIME and X.400 and ensures that 133 page breaks are honored in the MIME representation. 135 An EOL is defined as a bit sequence of 137 000000000001 (eleven zeroes and a one). 139 Each page of the message is delimited by a sequence of six (6) 140 EOLs that MUST start on a byte boundary. The image bit stream is 141 padded with zeroes as needed to achieve this alignment. 143 Searching for the boundary is a matter of searching for the byte 144 sequence (HEX) 00 10 01 00 10 01 00 10 01, which cannot occur 145 inside the image. 147 See Section 7.5 for the algorithm on conversion between this 148 encoding and the X.400 encoding. 150 The Base64 content-transfer-encoding is appropriate for carrying 151 this content-type. 153 3. g3-facsimile - image/g3fax 155 X.400 Body part: g3-facsimile 156 MIME Content-Type: image/g3fax 157 Conversion Type: nearly Byte copy 158 Comments: 160 The Parameters of the X.400 G3Fax body part are mapped to the 161 corresponding Parameters on the MIME Image/G3Fax body part and 162 vice versa. Note that: 164 (1) If fineResolution is not specified, pixels will be twice as 165 tall as they are wide 167 (2) If any bit not corresponding to a specially named option is 168 set in the G3Fax NonBasicParameters, the "DCS" parameter 170 draft A MIME body part for FAX Nov 95 172 must be used. 174 (3) Interworking is not guaranteed if any bit apart from those 175 specially named are used in the NonBasicParameters 177 From X.400 to G3Fax, the body is created in the following way: 179 (1) Any trailing EOL markers on each bitstring is removed. The 180 bit order is changed to conform to the most common Internet 181 encoding (highest bit of first byte = first bit of the 182 G3Fax). The bitstring is padded to a byte boundary. 184 (2) 6 consecutive EOL markers are appended to each bitstring. 186 (3) The padded bitstrings are concatenated together 188 An EOL marker is the bit sequence 000000000001 (11 zeroes and a 189 one). 191 From G3Fax to X.400, the body is created in the following way: 193 (1) The body is split into bitstrings at each occurrence of 6 194 consecutive EOL markers. Trailing EOLs must NOT be removed, 195 since the X.400 Implementor Guide recommends that each page 196 should end with 6 consecutive EOLs. (This is a change from 197 RFC 1494). 199 (2) Each bitstring is made into an ASN.1 BITSTRING, reversing 200 the order of bits within each byte to conforom to the X.400 201 Implementors Guide recommendation for bit order in the 202 G3Fax body part. 204 (3) The bitstrings are made into an ASN.1 SEQUENCE, which forms 205 the body of the G3Fax body part. 207 4. Security considerations 209 Security issues are not consiered in this memo. 211 draft A MIME body part for FAX Nov 95 213 5. REFERENCES 215 [MIME] 216 RFC 1521: N. Borenstein, N. Freed, "MIME (Multipurpose 217 Internet Mail Extensions) Part One: Mechanisms for 218 Specifying and Describing the Format of Internet Message 219 Bodies", 09/23/1993