home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_ietf_j_p
/
draft-ietf-mixer-fax-01.txt
< prev
next >
Wrap
Text File
|
1997-09-18
|
11KB
|
379 lines
draft A MIME body part for Group 3 FAX Nov 95
A MIME body part for FAX
Mon Aug 19 14:32:21 MET DST 1996
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-01.txt
Alvestrand Expires May 96 [Page 1]
draft A MIME body part for Group 3 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.
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.
(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:
Alvestrand Expires May 96 [Page 2]
draft A MIME body part for Group 3 FAX Nov 95
(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 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
Alvestrand Expires May 96 [Page 3]
draft A MIME body part for Group 3 FAX Nov 95
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.
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:
Alvestrand Expires May 96 [Page 4]
draft A MIME body part for Group 3 FAX Nov 95
(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).
(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.
Alvestrand Expires May 96 [Page 5]
draft A MIME body part for Group 3 FAX Nov 95
4. Usability of G3Fax body parts
This section is not part of the standard (if this becomes a
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.
6. 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]
draft A MIME body part for Group 3 FAX Nov 95
[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
Alvestrand Expires May 96 [Page 7]