Network Working Group L. McIntyre
Request for Comments: 2880 Xerox Corporation
Category: Informational G. Klyne
Content Technologies
August 2000
Internet Fax T.30 Feature Mapping
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This document describes how to map Group 3 fax capability
identification bits, described in ITU T.30 [6], into the Internet fax
feature schema described in "Content feature schema for Internet fax"
[4].
This is a companion to the fax feature schema document [4], which
itself defines a profile of the media feature registration mechanisms
[1,2,3], for use in performing capability identification between
extended Internet fax systems [5].
Table of Contents
1. Introduction .............................................31.1 Organization of this document ........................31.2 Terminology and document conventions .................31.3 Discussion of this document ..........................42. Combining feature tags ...................................42.1 Relationship to Group 3 fax ..........................52.2 Feature set descriptions .............................52.3 Examples .............................................52.3.1 Data resource example ............................62.3.2 Recipient capabilities example ...................63. Survey of media-related T.30 capability bits .............63.1 DIS/DTC bit 15 (resolution) ..........................63.2 DIS/DTC bit 16 (MR coding) ...........................73.3 DIS/DTC bits 17,18 (width) ...........................73.4 DIS/DTC bits 19,20 (length) ..........................7
McIntyre & Klyne Informational [Page 1]
RFC 2880 Internet Fax T.30 Feature Mapping August 2000
3.5 DIS/DTC bit 31 (MMR coding) ..........................73.6 DIS/DTC bit 36 (JBIG multi-level coding) .............83.7 DIS/DTC bit 37 (plane interleave) ....................83.8 DIS/DTC bits 41,42,43 (resolution) ...................83.9 DIS/DTC bits 44,45 (preferred units) .................93.10 DIS/DTC bit 68 (JPEG) ...............................93.11 DIS/DTC bit 69 (colour) .............................93.12 DIS/DTC bit 71 (bits/sample) .......................103.13 DIS/DTC bit 73 (no subsampling) ....................103.14 DIS/DTC bit 74 (custom illuminant) .................103.15 DIS/DTC bit 75 (custom gamut) ......................103.16 DIS/DTC bits 76,77 (paper size) ....................113.17 DIS/DTC bit 78 (JBIG bi-level coding) ..............113.18 DIS/DTC bit 79 (JBIG stripe size) ..................113.19 DIS/DTC bit 92,93,94 (MRC maximum functional mode) .11
3.20 DIS/DTC bit 95 (MRC stripe size) ...................123.21 DIS/DTC bit 97 (resolution) ........................123.22 DIS/DTC bit 98 (resolution) ........................124. Summary of T.30 capability dependencies .................124.1 Image coding ........................................134.1.1 Bi-level coding .................................134.1.2 Multi-level coding ..............................144.1.3 MRC format ......................................144.2 Resolution and units ................................154.3 Colour capabilities .................................174.4 Document size .......................................185. Mapping T.30 capabilities to fax feature schema .........185.1 Image coding ........................................205.1.1 Bi-level coding .................................205.1.2 Multi-level coding ..............................215.1.3 MRC format ......................................235.2 Resolution and units ................................235.3 Colour capabilities .................................245.4 Document size .......................................266. Examples ................................................266.1 Common black-and-white fax machine ..................276.1.1 Corresponding Internet fax capabilities .........296.2 Full-featured color fax machine .....................307. Security Considerations .................................348. Acknowledgements ........................................349. References ..............................................3410. Authors' Addresses .....................................36
Full Copyright Statement ...................................37
McIntyre & Klyne Informational [Page 2]
RFC 2880 Internet Fax T.30 Feature Mapping August 2000
This document describes how to map Group 3 fax capability
identification bits, described in ITU T.30 [6], into the Internet fax
feature schema described in "Content feature schema for Internet fax"
[4].
This is a companion to the fax feature schema document [4], which
itself defines a profile of the media feature registration mechanisms
[1,2,3], for use in performing capability identification between
extended Internet fax systems [5].
Section 2 introduces the mechanisms that combine feature tag
constraints to describe complex recipient capabilities.
Section 3 surveys Group 3 fax (T.30) capability bits that relate to
media handling capabilities.
Section 4 describes the dependencies between Group 3 fax (T.30)
capability bits. These are presented in a decision table format [16]
with descriptive text in place of the action bodies.
Section 5 describes a formal mechanism for converting Group 3 fax
(T.30) capability masks to fax feature schema statements. The
conversion process is driven by the decision tables introduced
previously, using fax feature schema statements and combining rules
in the action bodies.
Section 6 presents an example of a Group 3 fax (T.30) capability
mask, and uses the formal mechanism described previously to convert
that into a corresponding fax feature schema statement.
eifax system
is used to describe any software, device or combination
of these that conforms to the specification "Extended
Facsimile Using Internet Mail" [5].
Feature is used as defined in [15]. (See also section 2 of this
memo.)
Feature tag
is used as defined in [15]. (See also section 2.)
McIntyre & Klyne Informational [Page 3]
RFC 2880 Internet Fax T.30 Feature Mapping August 2000
Feature collection
is used as defined in [2]. (See also section 2.)
Feature set
is used as defined in [2]. (See also section 2.)
Discussion of this document should take place on the Internet fax
mailing list hosted by the Internet Mail Consortium (IMC). Please
send comments regarding this document to:
ietf-fax@imc.org
To subscribe to this list, send a message with the body 'subscribe'
to "ietf-fax-request@imc.org".
To see what has gone on before you subscribed, please see the mailing
list archive at:
http://www.imc.org/ietf-fax/
A fax document can be described by media features. Any single media
feature value can be thought of as just one component of a feature
collection that describes some instance of a document (e.g. a
printed fax, a displayed image, etc.). Such a feature collection
consists of a number of media feature tags (each per [1]) and
associated feature values.
A feature set contains a number of feature collections. Thus, a
feature set can describe a number of different fax document
instances. These can correspond to different treatments of a single
document (e.g. different resolutions used for printing a given fax),
a number of different documents subjected to a common treatment (e.g.
the range of different images that can be rendered on a given
display), or some combination of these (see examples below).
Thus, a description of a feature set can describe the rendering
requirements of a fax document or the capabilities of a receiving
eifax system.
McIntyre & Klyne Informational [Page 4]
RFC 2880 Internet Fax T.30 Feature Mapping August 2000
A "feature tag" can be compared with a single bit in a T.30 DCS
frame, describing a specific attribute of a specific fax document.
A "feature collection" corresponds to a complete T.30 DCS frame,
describing a range of attributes of a specific fax document.
A "feature set" corresponds to a DIS or DTC frame, describing the
range of document attributes that can be accepted by a given fax
machine.
Within T.30 DIS/DTC frames, dependencies between the various
capabilities are implicit in the definitions of the capabilities.
E.g. multi-level coding (DIS/DTC bit 68) requires support for
200*200dpi resolution (DIS/DTC bit 15). In the feature set
description framework used by eifax systems [1,2,3,4] such
dependencies between different features are expressed explicitly.
Later sections of this memo describe how the implicit dependencies of
T.30 are expressed using the media feature set notation.
The general approach to describing feature sets, described more fully
in [2], is to use functions ("predicates") that, when applied to a
feature collection value, yield a Boolean value that is TRUE if the
feature collection describes an acceptable fax document instance,
otherwise FALSE.
P(F)
P(F) = TRUE <- : -> P(F) = FALSE
:
+----------:----------+ This box represents some
| : | universe of fax documents (F)
| Included : Excluded | from which some acceptable subset
| : | is selected by the predicate P.
+----------:----------+
:
In the examples below the following notation is used:
(x ? y) tests feature tag 'x' for some relationship
with value 'y'.
(| p1 p2 ... pn ) represents the logical-OR of predicates 'p1',
'p2' up to 'pn'.
McIntyre & Klyne Informational [Page 5]
RFC 2880 Internet Fax T.30 Feature Mapping August 2000
(& p1 p2 ... pn ) represents the logical-AND of predicates
'p1', 'p2' up to 'pn'.
The following expression uses the syntax of [2] to describe a data
resource that can be displayed either:
(a) as a 750x500 pixel image using 15 colours, or
(b) at 150dpi on an A4 page.
(| (& (pix-x=750) (pix-y=500) (color=15) )
(& (dpi>=150) (papersize=A4) ) )
The following expression describes a receiving system that has:
(a) a screen capable of displaying 640*480 pixels and 16 million
colours (24 bits per pixel), 800*600 pixels and 64 thousand
colours (16 bits per pixel) or 1024*768 pixels and 256 colours
(8 bits per pixel), or
(b) a printer capable of rendering 300dpi on A4 paper.
(| (& (| (& (pix-x<=640) (pix-y<=480) (color<=16777216) )
(& (pix-x<=800) (pix-y<=600) (color<=65535) )
(& (pix-x<=1024) (pix-y<=768) (color<=256) ) )
(media=screen) )
(& (dpi=300)
(media=stationery) (papersize=A4) ) )
The following sections refer to T.30 DIS/DTC bits identified and
described in Table 2/T.30 and accompanying notes [6]. Bit numbers
that are not referenced below are considered to be not related to
media features, hence not relevant to the Internet fax feature
schema.
NOTE: some of the DIS/DTC bits identified below are
documented in revisions of the T.30 specification that
may be not yet publicly available from the ITU.
All Group 3 fax systems are required to support a basic resolution of
200*100dpi (dots per inch) or 8*3.85dpmm (dots per millimetre).
Setting this bit indicates additional support for 200*200dpi or
8*7.7dpmm.
McIntyre & Klyne Informational [Page 6]
RFC 2880 Internet Fax T.30 Feature Mapping August 2000
For multi-level images, 200*200dpi is the basic resolution, and this
bit must be set. The other basic resolution options apply to bi-
level images only.
See also: bits 44,45.
All Group 3 fax systems are required to support Modified Huffman (MH)
1-dimensional coding for bi-level images. (A bi-level image is one
with just two pixel states such as black and white, as opposed to a
grey-scale or colour image.)
Setting this bit indicates additional support for Modified Read (MR)
2-dimensional coding for bi-level images.
Both MH and MR coding are described in ITU T.4 [7].
See also: bits 31,78,79.
All Group 3 fax systems are required to support 215mm paper width.
These bits can be set to indicate additional support for 255mm and
303mm paper widths.
See also: bits 76,77.
All Group 3 fax systems are required to support 297mm paper length.
These bits can be set to indicate additional support for 364mm and
unlimited paper lengths.
See also: bits 76,77.
Setting this bit indicates support for Modified Modified Read (MMR)
2-dimensional coding for bi-level images, in addition to the required
support for MH coding.
MMR coding is described in ITU T.6 [8].
See also: bits 16,78,79.
McIntyre & Klyne Informational [Page 7]
RFC 2880 Internet Fax T.30 Feature Mapping August 2000
If multi-level images are to be handled, support for JPEG coding is
required (i.e. bit 68 must be set). Setting bit 36 indicates
additional support for JBIG lossless coding of multi-level images.
JBIG coding for multi-level images is described in ITU T.43 [10] and
T.4 Annex G [7].
See also: bits 68,69.
Setting this bit indicates support for plane interleave for JBIG-
coded multi-level images in addition to stripe interleave, which is
standard for JBIG multi-level images.
JBIG coding for multi-level images is described in ITU T.43 [10] and
T.4 Annex G [7].
See also: bit 36.
Setting these bits indicates support for resolutions in addition to
200*100dpi and 200*200dpi, or 8*3.85dpmm and 8*7.7dpmm. (Or in
addition to the basic 200*200dpi resolution when using a multi-level
image mode.)
Bit 41 indicates support for 8*15.4dpmm bi-level images
(independently of the settings of bits 44 and 45).
Bit 42 indicates support for 300*300dpi bi-level images
(independently of the settings of bits 44 and 45). Also applies to
multi-level images or MRC mask if bit 97 is set.
Bit 43 indicates support for 400*400dpi and/or 16*15.4dpmm bi-level
images, depending upon the settings of bits 44 and 45. Also applies
to multi-level images or MRC mask if bit 97 is set.
See also: bits 15,44,45,97.
McIntyre & Klyne Informational [Page 8]
RFC 2880 Internet Fax T.30 Feature Mapping August 2000
These bits are used to indicate the preferred resolution units for
received images. Because the exact resolution and x/y pixel density
measures in dpi or dpmm are slightly different, some image size and
aspect ratio distortion may occur if the sender and receiver use
different units.
Even when sender and recipient have different preferred units, image
transfer must be accomplished. For most fax uses, the dpi and dpmm
measurements are sufficiently close to each other that the difference
is not noticed.
The preferred units setting affects the detailed interpretation of
the following resolutions:
dpi dpmm (dpi equivalent)
--- ----
Base 200*100 8*3.85 204*98
Bit 15 200*200 8*7.7 204*196
Bit 43 400*400 16*15.4 408*391
But terminals are required to accept the inch- and metric-based
measures given above as equivalent, distorting the image if necessary
to accommodate the differences.
See also: bits 15, 43
This bit indicates support for JPEG coding of multi-level images.
JPEG coding for multi-level images is described in ITU T.81 [12] and
T.4 Annex E [7].
See also: bits 15,69,73
This bit indicates support for colour images, in addition to just
grey-scale.
Both grey-scale and colour require multi-level coding. The
difference is that grey is single component while colour is multi-
component.
See also: bits 36,68,73.
McIntyre & Klyne Informational [Page 9]
RFC 2880 Internet Fax T.30 Feature Mapping August 2000
Standard support for multi-level images uses 8 bits per sample.
Setting this bit indicates additional support for 12 bits per sample.
For a grey-scale multi-level image, there is just one sample per
pixel, giving 256 or 4096 possible pixel values. For a full colour
multi-level image there are three samples per pixel, giving 256^3
(16777216) or 4096^3 (6871946736) possible values.
When related to a mapped colour image, bit 71 also affects the
maximum number of entries in the mapping table: when it is reset, up
to 4096 different pixel values can be used; when set, up to 65536
different values can be used.
See also: bit 68.
Standard support for JPEG-coded multi-level images uses 4:1:1
chrominance subsampling. That is, for each 4 luminance samples in
the image data there is a single chrominance sample.
Setting this bit indicates that JPEG-coded colour images without
subsampling can also be supported. This is not applicable to JBIG
coding (bit 36).
See also: bits 68,69.
Standard support for multi-level images requires use of D50
illuminant. Setting this bit indicates that a custom illuminant also
can be supported for multi-level images (both grey-scale and colour).
Details of the custom illuminant are contained in the image data.
Use of a custom illuminant with multi-level images is described in
ITU T.4 Annex E [7].
See also: bits 36,68.
Standard support for a default colour gamut is required for multi-
level images. Setting this bit indicates that a custom gamut also
can be supported for multi-level images (both grey-scale and colour).
Details of the custom gamut are contained in the image data.
McIntyre & Klyne Informational [Page 10]
RFC 2880 Internet Fax T.30 Feature Mapping August 2000
The default gamut (L*=[0,100], a*=[-85, 85], b* = [-75, 125]), and
use of a custom gamut with multi-level images is described in ITU
T.42 [9] and T.4 Annex E [7].
See also: bits 36,68.
All Group 3 faxes are required to support A4 paper size. These bits
can be set to indicate additional support for North American letter
and legal paper sizes.
See also: bits 17,18,19,20.
Setting bit 78 indicates support for JBIG coding of bi-level images
(using T.85 encoding rules), in addition to the required support for
MH coding.
JBIG coding of bi-level images is described in ITU T.85 [14].
See also: bits 16,31,79.
Setting bit 79 (along with bit 78) indicates support for the 'LO'
option with JBIG coded bi-level images. Basic bi-level JBIG coding
uses 128 lines per stripe; the 'LO' option allows other stripe sizes
to be used.
The stripe size is used for all stripes except the last, which may
have fewer lines than the indicated value.
JBIG coding of bi-level images is described in ITU T.85 [14].
See also: bits 16,31,78.
If these bits are all zero, then Mixed Raster Content (MRC) coding is
not supported. Otherwise, they represent a number in the range 1-7
that indicates an MRC maximum functional mode.
MRC coding of images is described in ITU T.44 [11] and T.4 Annex H
[17].
See also: bits 68,95.
McIntyre & Klyne Informational [Page 11]
RFC 2880 Internet Fax T.30 Feature Mapping August 2000
Standard support for MRC uses a maximum stripe size of 256 lines.
When this bit is set, the maximum stripe size is a full page.
This bit is meaningful only if bits 92-94 indicate an MRC coding
capability. MRC coding of images is described in ITU T.44 [11] and
T.4 Annex H [17].
See also: bits 92,93,94.
Setting this bit indicates that the additional resolutions indicated
by bits 42 and 43 may be used for multi-level images and any MRC mask
layer.
When this bit is set, bit 42 implies 300dpi and bit 43 implies 400dpi
for multi-level or MRC mask layer images (irrespective of the
preferred units indicated by bits 44 and 45).
See also: bits 42,43,68.
Setting this bit indicates that the additional resolution 100*100dpi
may be used for multi-level images.
NOTE: 100dpi is not used for bi-level images, including
the MRC mask layer.
See also: bit 36,68,92-94.
This section contains a number of decision tables that indicate the
allowable combinations of T.30 DIS/DTC mask bits.
Within the decision table bodies, the following symbols are use to
indicate values of T.30 DIS/DTC bits:
0 = bit set to '0'
1 = bit set to '1'
x = don't care bit value: may be '0' or '1'
*0 = bit must be '0' ('1' is invalid in given combination)
*1 = bit must be '1' ('0' is invalid in given combination)
# = bits in row combined to form a numeric value
McIntyre & Klyne Informational [Page 12]
RFC 2880 Internet Fax T.30 Feature Mapping August 2000
This section follows the structure of the previous section, except
that the decision tables are restated with feature set expression
mappings in the action stub. The feature set expressions use media
feature tags presented in "Content feature schema for Internet fax"
[4].
To construct a feature set expression corresponding to a collection
of DIS frame bits:
o Compare the DIS bits with each decision table in the following
sections (5.1 to 5.4). Some decision tables consist of a number
of sub-tables separated by horizontal lines.
o The DIS bits will match exactly one row from each table or sub-
table: collect the corresponding feature set expression from the
action stub (the right hand column of the table).
McIntyre & Klyne Informational [Page 18]
RFC 2880 Internet Fax T.30 Feature Mapping August 2000
o In the case of the table in section 5.2, which consists of
several sub-tables, combine the feature set expressions from each
sub-table with a logical-OR: (| s1 s2 ... sn ), where 's1', 's2'
etc. are the feature set expressions selected from each sub-
table. In this way, a single feature set expression is obtained
for the table.
o In the case of the tables in sections 5.3 and 5.4, combine the
sub-table expressions with a logical-AND: (& s1 s2 ... sn ).
o Combine the feature set expressions for each table as follows:
(& (| T511 T512 ) T513 T52 T53 T54 )
where:
- T511 is the feature set expression obtained from the table in
section 5.1.1
- T512 is obtained from the table in section 5.1.2
- T513 is obtained from the table in section 5.1.3
- T52 is obtained from the table in section 5.2
- T53 is obtained from the table in section 5.3
- T54 is obtained from the table in section 5.4
The resulting expression is the feature set expression corresponding
to the DIS bits given. Remember that there may be other capabilities
not expressed by the DIS bits that should be incorporated into the
final feature expression (e.g. TIFF image file structure).
To do the reverse transformation, match the feature set to each row
of each decision table using the matching algorithm in RFC 2533 [2],
and OR together the DIS bit masks for each row whose feature set
expression is completely contained by (i.e. is a subset of) that
given (where the bit value in a table is 'x', use '0').
A feature set A is completely contained by B if the feature set match
of A and B (obtained by applying the feature set matching algorithm
in [2]) is equal to A.
McIntyre & Klyne Informational [Page 19]
RFC 2880 Internet Fax T.30 Feature Mapping August 2000
NOTE: Although motivated by the requirements of eifax [5], this
document is concerned with describing capabilities of Group 3 fax
systems [6]. As such, the algorithms do not of themselves create
equivalent Internet fax capability statements but, rather, they
construct capability expressions that might be incorporated into
those for eifax systems.
This point is illustrated at the end of the first example below where
subsection 6.1.1 has been added, which combines T.30 capabilities
with an appropriate TIFF file format capability to yield an
expression that might be used to describe an Internet fax system.
McIntyre & Klyne Informational [Page 26]
RFC 2880 Internet Fax T.30 Feature Mapping August 2000
In the case of an Internet fax device, additional capabilities not
described by the T.30 DIS frame should be included; e.g. the
supported TIFF file structure:
(& (color=binary)
(image-file-structure=[TIFF-Limited,TIFF-Minimal])
(image-coding=[MH,MR,MMR])
(MRC-mode=0)
(| (& (dpi=204) (dpi-xyratio=204/98) )
(& (dpi=204) (dpi-xyratio=205/196) )
(& (dpi=200) (dpi-xyratio=200/100) )
(& (dpi=200) (dpi-xyratio=1) )
(& (dpi=300) (dpi-xyratio=1) ) )
(size-x<=2150/254)
(Paper-size=[A4,Letter]) )
McIntyre & Klyne Informational [Page 29]
RFC 2880 Internet Fax T.30 Feature Mapping August 2000
Security considerations are discussed in the fax feature schema
description [4]. This memo is not believed to introduce any
additional security concerns.
The authors gratefully acknowledge the following persons who made
comments on earlier versions of this memo: Mr. Hiroshi Tamura and
and Dr. Robert Buckley.
[1] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag
Registration Procedure", RFC 2506, March 1999.
[2] Graham, K., "A syntax for describing media feature sets" RFC
2533, March 1999.
[3] Masinter, L., Holtman, K., Mutz, A. and D. Wing, "Media Features
for Display, Print, and Fax", RFC 2534, March 1999.
[4] Klyne, G. and L. McIntyre, "Content Feature Schema for Internet
Fax (V2)", RFC 2879, July 2000.
McIntyre & Klyne Informational [Page 34]
RFC 2880 Internet Fax T.30 Feature Mapping August 2000
[5] Masinter, L. and D. Wing, "Extended Facsimile Using Internet
Mail", RFC 2532, March 1999.
[6] "Procedures for document facsimile transmission in the general
switched telephone network" ITU-T Recommendation T.30 (1996),
including Amendment 1 (1997), Amendment 2 (1997), Amendment 3
(1998) and Amendment 4 (1999) International Telecommunications
Union
[7] "Standardization of Group 3 facsimile terminals for document
transmission" ITU-T Recommendation T.4 (1996), including
Amendment 1 (1997), Amendment 2 (1997) and Amendment 3 (1999)
International Telecommunications Union (Covers basic fax coding
formats: MH, MR; Annex E deals with some color image related
matters, including codes for optional custom illuminants. Annex
G deals with some aspects of JBIG encoding of multi-level
images.)
[8] "Facsimile coding schemes and coding control functions for Group
4 facsimile apparatus" ITU Recommendation T.6 International
Telecommunications Union (Commonly referred to as the MMR
standard; covers extended 2-D fax coding format)
[9] "Continuous-tone colour representation method for facsimile"
ITU-T Recommendation T.42 (1996) International
Telecommunications Union (Covers custom illuminant, gamut)
[10] "Colour and gray-scale image representation using lossless
coding scheme for facsimile" ITU-T Recommendation T.43 (1997)
International Telecommunications Union (Covers JBIG for
colour/grey images)
[11] "Mixed Raster Content (MRC)" ITU-T Recommendation T.44 (1999)
International Telecommunications Union
[12] "Information technology - Digital compression and coding of
continuous-tone still image - Requirements and guidelines" ITU-T
Recommendation T.81 (1992) | ISO/IEC 10918-1:1993 International
Telecommunications Union (Commonly referred to as JPEG standard)
[13] "Information technology - Coded representation of picture and
audio information - Progressive bi-level image compression"
ITU-T Recommendation T.82 (1993) | ISO/IEC 11544:1993
International Telecommunications Union (Commonly referred to as
JBIG1 standard)
McIntyre & Klyne Informational [Page 35]
RFC 2880 Internet Fax T.30 Feature Mapping August 2000
[14] "Application profile for Recommendation T.82 - Progressive bi-
level image compression (JBIG1 coding scheme for facsimile
apparatus)" ITU-T Recommendation T.85 (1995), including
Amendment 1 (1996), Amendment 2 (1997) and Corrigendum 1 (1997)
International Telecommunications Union (Covers bi-level JBIG)
[15] Klyne, G., "Protocol-independent Content Negotiation Framework",
RFC 2703, September 1999.
[16] "Programs from Decision Tables" E. Humbey Macdonald/American
Elsevier computer monographs (19), 1973 ISBN 0-444-19569-6/0-
356-04126-3 (This is an old title, and may not be still in
print. It contains a number of references to decision table
articles published in Communications of the ACM: August 1967,
September 1970, January 1966, November 1966, October 1968,
January 1965, February 1964, June 1970, November 1965, June
1965, February 1971.)
[17] "Mixed Raster Content (MRC) mode for G3 facsimile" ITU-T
Recommendation T.4, Annex H (1999) International
Telecommunications Union (Covers stripe size)
Copyright (C) The Internet Society (2000). 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
McIntyre & Klyne Informational [Page 37]