path: root/doc/rfc/rfc3949.txt

Network Working Group                                         R. Buckley
Request for Comments: 3949                                    D. Venable
Obsoletes: 2301                                        Xerox Corporation
Category: Standards Track                                    L. McIntyre
                                                              Consultant
                                                              G. Parsons
                                                         Nortel Networks
                                                             J. Rafferty
                                                              Brooktrout
                                                           February 2005


                      File Format for Internet 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 (2005).

Abstract

   This document is a revised version of RFC 2301.  The revisions,
   summarized in the list attached as Annex B, are based on discussions
   and suggestions for improvements that have been made since RFC 2301
   was issued in March 1998, and on the results of independent
   implementations and interoperability testing.

   This RFC 2301 revision describes the Tag Image File Format (TIFF)
   representation of image data specified by the International
   Telecommunication Union (ITU-T) Recommendations for black-and-white
   and color facsimile.  This file format specification is commonly
   known as TIFF for Fax eXtended (TIFF-FX).  It formally defines
   minimal, extended, and lossless Joint Bi-level Image experts Group
   (JBIG) profiles (Profiles S, F, J) for black-and-white fax and base
   JPEG, lossless JBIG, and Mixed Raster Content profiles (Profiles C,
   L, M) for color and grayscale fax.  These profiles correspond to the
   content of the applicable ITU-T Recommendations.







Buckley, et al.             Standards Track                     [Page 1]
^L
RFC 3949              File Format for Internet Fax         February 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
       1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . .  5
       1.2. Approach. . . . . . . . . . . . . . . . . . . . . . . . .  5
       1.3. Overview of this Document . . . . . . . . . . . . . . . .  5
   2.  TIFF and Fax . . . . . . . . . . . . . . . . . . . . . . . . .  7
       2.1. TIFF Overview . . . . . . . . . . . . . . . . . . . . . .  7
            2.1.1. File Structure . . . . . . . . . . . . . . . . . .  8
            2.1.2. Image Structure. . . . . . . . . . . . . . . . . . 10
            2.1.3. TIFF File Structure for Fax Applications . . . . . 11
       2.2. TIFF Fields for All Fax Applications. . . . . . . . . . . 12
            2.2.1. TIFF Fields required for all fax profiles. . . . . 13
            2.2.2. Additional TIFF Fields required for all fax
                   profiles . . . . . . . . . . . . . . . . . . . . . 14
            2.2.3. TIFF Fields recommended for all fax profiles . . . 17
            2.2.4. New TIFF Fields recommended for fax profiles . . . 18
   3.  Profile S: Minimal Black-and-White Fax Profile . . . . . . . . 20
       3.1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . 20
       3.2. Required TIFF Fields. . . . . . . . . . . . . . . . . . . 21
            3.2.1. Baseline Fields. . . . . . . . . . . . . . . . . . 21
            3.2.2. Extension Fields . . . . . . . . . . . . . . . . . 23
            3.2.3. New Fields . . . . . . . . . . . . . . . . . . . . 23
       3.3. Recommended TIFF Fields . . . . . . . . . . . . . . . . . 23
       3.4. End of Line (EOL) and Return to Control (RTC) . . . . . . 23
            3.4.1. RTC Exclusion. . . . . . . . . . . . . . . . . . . 24
       3.5. File Structure. . . . . . . . . . . . . . . . . . . . . . 24
       3.6. Profile S: Minimal Black-and-White Profile Summary. . . . 26
   4.  Profile F: Extended Black-and-White Fax Profile. . . . . . . . 27
       4.1. TIFF-F Overview . . . . . . . . . . . . . . . . . . . . . 28
       4.2. Required TIFF Fields. . . . . . . . . . . . . . . . . . . 29
            4.2.1. Baseline Fields. . . . . . . . . . . . . . . . . . 29
            4.2.2. Extension Fields . . . . . . . . . . . . . . . . . 32
            4.2.3. New Fields . . . . . . . . . . . . . . . . . . . . 32
       4.3. Recommended TIFF Fields . . . . . . . . . . . . . . . . . 32
            4.3.1. Baseline Fields. . . . . . . . . . . . . . . . . . 32
            4.3.2. Extension Fields . . . . . . . . . . . . . . . . . 33
            4.3.3. New Fields . . . . . . . . . . . . . . . . . . . . 33
       4.4. Technical Implementation Issues . . . . . . . . . . . . . 34
            4.4.1. Strips . . . . . . . . . . . . . . . . . . . . . . 34
            4.4.2. Bit Order. . . . . . . . . . . . . . . . . . . . . 34
            4.4.3. Multi-Page . . . . . . . . . . . . . . . . . . . . 35
            4.4.4. Compression. . . . . . . . . . . . . . . . . . . . 35
            4.4.5. Example Use of Page-quality Fields . . . . . . . . 36
            4.4.6. Practical Guidelines for Writing and Reading
                   Multi-Page TIFF-F Files. . . . . . . . . . . . . . 36
            4.4.7. Use of TIFF-F for Streaming Applications . . . . . 38




Buckley, et al.             Standards Track                     [Page 2]
^L
RFC 3949              File Format for Internet Fax         February 2005


       4.5. Implementation Warnings . . . . . . . . . . . . . . . . . 38
            4.5.1. Uncompressed Data. . . . . . . . . . . . . . . . . 38
            4.5.2. Encoding and Resolution. . . . . . . . . . . . . . 38
            4.5.3. EOL byte-aligned . . . . . . . . . . . . . . . . . 39
            4.5.4. EOL. . . . . . . . . . . . . . . . . . . . . . . . 40
            4.5.5. RTC Exclusion. . . . . . . . . . . . . . . . . . . 40
            4.5.6. Use of EOFB for T.6 Compressed Images. . . . . . . 40
       4.6. Example Use of TIFF-F . . . . . . . . . . . . . . . . . . 40
       4.7. Profile F: Extended Black-and-white Fax Profile Summary . 41
   5.  Profile J: Lossless JBIG Black-and-White Fax Profile . . . . . 43
       5.1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . 43
       5.2. Required TIFF Fields. . . . . . . . . . . . . . . . . . . 44
            5.2.1. Baseline Fields. . . . . . . . . . . . . . . . . . 44
            5.2.2. Extension Fields . . . . . . . . . . . . . . . . . 44
            5.2.3. New Fields . . . . . . . . . . . . . . . . . . . . 44
       5.3. Recommended TIFF Fields . . . . . . . . . . . . . . . . . 45
       5.4. Profile J: Lossless JBIG Black-and-White Profile Summary. 45
   6.  Profile C: Base Color Fax Profile. . . . . . . . . . . . . . . 47
       6.1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . 47
       6.2. Required TIFF Fields. . . . . . . . . . . . . . . . . . . 47
            6.2.1. Baseline Fields. . . . . . . . . . . . . . . . . . 47
            6.2.2. Extension Fields . . . . . . . . . . . . . . . . . 49
            6.2.3. New Fields . . . . . . . . . . . . . . . . . . . . 50
       6.3. Recommended TIFF Fields . . . . . . . . . . . . . . . . . 52
       6.4. Profile C: Base Color Fax Profile Summary . . . . . . . . 52
   7.  Profile L: Lossless Color Profile. . . . . . . . . . . . . . . 54
       7.1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . 54
            7.1.1. Color Encoding . . . . . . . . . . . . . . . . . . 54
            7.1.2. JBIG Compression . . . . . . . . . . . . . . . . . 55
       7.2. Required TIFF Fields. . . . . . . . . . . . . . . . . . . 55
            7.2.1. Baseline Fields. . . . . . . . . . . . . . . . . . 56
            7.2.2. Extension Fields . . . . . . . . . . . . . . . . . 57
            7.2.3. New Fields . . . . . . . . . . . . . . . . . . . . 57
       7.3. Recommended TIFF Fields . . . . . . . . . . . . . . . . . 57
       7.4. Profile L: Lossless Color Fax Profile Summary . . . . . . 58
   8.  Profile M: Mixed Raster Content Profile. . . . . . . . . . . . 60
       8.1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . 60
            8.1.1. MRC 3-layer model. . . . . . . . . . . . . . . . . 60
            8.1.2. A TIFF Representation for the MRC 3-layer model. . 62
       8.2. Required TIFF Fields. . . . . . . . . . . . . . . . . . . 64
            8.2.1. Baseline Fields. . . . . . . . . . . . . . . . . . 64
            8.2.2. Extension Fields . . . . . . . . . . . . . . . . . 66
            8.2.3. New Fields . . . . . . . . . . . . . . . . . . . . 67
       8.3. Recommended TIFF Fields . . . . . . . . . . . . . . . . . 69
       8.4. Rules and Requirements for Images . . . . . . . . . . . . 69
       8.5. Profile M: MRC Fax Profile Summary. . . . . . . . . . . . 71
   9.  MIME content-types image/tiff and image/tiff-fx. . . . . . . . 74
   10. Security Considerations. . . . . . . . . . . . . . . . . . . . 74



Buckley, et al.             Standards Track                     [Page 3]
^L
RFC 3949              File Format for Internet Fax         February 2005


   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 74
       11.1. Normative References . . . . . . . . . . . . . . . . . . 74
       11.2. Informative References . . . . . . . . . . . . . . . . . 76
   Annex A: Summary of TIFF Fields for Internet Fax . . . . . . . . . 77
   Annex B: List of technical edits to RFC 2301 . . . . . . . . . . . 81
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 82
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 84

1.  Introduction

   This document describes the use of TIFF (Tag Image File Format) to
   represent the data content and structure generated by the current
   suite of ITU-T Recommendations for Group 3 facsimile.  These
   recommendations and the TIFF fields described here support the
   following facsimile profiles:

   S:  Minimal black-and-white profile, using binary MH compression
       [T.4]
   F:  Extended black-and-white profile, using binary MH, MR, and MMR
       compression [T.4, T.6]
   J:  Lossless JBIG black-and-white profile, with JBIG compression
       [T.85, T.82]
   C:  Lossy color and grayscale profile, using JPEG compression [T.42,
       T.81]
   L:  Lossless color and grayscale profile, using JBIG compression
       [T.43, T.82]
   M:  Mixed raster content profile [T.44], using a combination of
       existing compression methods

   Each profile corresponds to the content of ITU-T Recommendations
   shown and is a subset of the full TIFF for facsimile specification.

   Profile S describes a minimal interchange set of fields, which will
   guarantee that, at least, binary black-and-white images will be
   supported.  Implementations are required to support this minimal
   interchange set of fields.

   With the intent of specifying a file format for Internet fax, this
   document

   1. specifies the structure of TIFF files for facsimile data,
   2. defines ITU fax-compatible values for existing TIFF fields, and
   3. defines new TIFF fields and values required for compatibility with
      ITU color fax.







Buckley, et al.             Standards Track                     [Page 4]
^L
RFC 3949              File Format for Internet Fax         February 2005


   This specification of TIFF for facsimile is known as TIFF-FX (TIFF
   for Fax eXtended).  References to the format described by this
   specification should always use the term "TIFF-FX", and some profiles
   in this specification may not be interpreted correctly by other TIFF
   applications.

1.1.  Scope

   This document defines a TIFF-based file format specification for
   enabling standardized messaging-based fax over the Internet.  It
   specifies the TIFF fields and field values required for compatibility
   with the existing ITU-T Recommendations for Group 3 black-and-white,
   grayscale, and color facsimile.  TIFF has historically been used for
   handling fax image files in applications such as store-and-forward
   messaging.  Implementations that support this file format
   specification for import/export may elect to support it as a native
   format.  This document recommends a TIFF file structure compatible
   with low-memory and page-level streaming implementations.

   Unless otherwise noted, the current TIFF specification [TIFF] and
   selected TIFF Technical Notes [TTN1, TTN2] are the primary references
   for describing TIFF and defining TIFF fields.  This document is the
   primary reference for defining TIFF field values for fax
   applications.

1.2.  Approach

   The basic approach to using TIFF for facsimile data is to insert the
   compressed fax image data into a TIFF file and use TIFF fields to
   encode the parameters that describe the image data.  These fields
   will have values that comply with the ITU-T Recommendations.

   This approach takes advantage of TIFF features and structures that
   bridge the data formats and performance requirements of both legacy
   fax machines and host-based fax applications.  TIFF constructs for
   pages, images, and strips allow a TIFF file to preserve the fax data
   stream structure and the performance advantages that come with it.  A
   TIFF-based approach also builds on an established base of users and
   implementors and ensures backward compatibility with existing TIFF-
   based IETF proposals and work in progress for Internet fax.

1.3.  Overview of this Document

   Section 2 gives an overview of TIFF.  Section 2.1 describes the
   structure of TIFF files, including general guidelines for structuring
   multi-page TIFF files.  Section 2.2 lists the TIFF fields that are
   required or recommended for all fax profiles.  The TIFF fields used




Buckley, et al.             Standards Track                     [Page 5]
^L
RFC 3949              File Format for Internet Fax         February 2005


   only by specific fax profiles are described in Sections 3 - 8, which
   describe the individual fax profiles.  These sections also specify
   the ITU-compatible field values (image parameters) for each profile.

   The full set of permitted fields of TIFF for facsimile are included
   in the current TIFF specification, Section 2 of this document, and
   the sections on specific profiles of facsimile operation.  This
   document defines profiles of TIFF for facsimile, where a profile is a
   subset of the full set of permitted fields and field values of TIFF
   for facsimile.

   Section 3 defines the minimal black-and-white facsimile profile
   (Profile S), which is required in all implementations.  Section 4
   defines the extended black-and-white fax profile (Profile F), which
   provides a standard definition of TIFF-F.  Section 5 describes the
   lossless black-and-white profile using JBIG compression (Profile J).

   Section 6 defines the base color profile, required in all color
   implementations, for the lossy JPEG representation of color and
   grayscale facsimile data (Profile C).  Section 7 defines the lossless
   JBIG color and grayscale facsimile profile (Profile L), and Section 8
   defines the Mixed Raster Content facsimile profile (Profile M).  Each
   of these sections concludes with a table summarizing the required and
   recommended fields for each profile and the values they can have.

   Section 9 refers to the MIME content types used in connection with
   TIFF for facsimile.  Sections 10 and 11 give Security Considerations
   and References, followed by Authors' Addresses and the Copyright
   Notice.  Annex A gives a summary of the TIFF fields used or defined
   in this document and provides a convenient reference for
   implementors.

   To implement only the minimal interchange black-and-white set of
   fields and values (Profile S), one need read only Sections 1, 2, 3,
   9, and 10.

   The following tree diagram shows the relationship among profiles and
   between profiles and coding methods.













Buckley, et al.             Standards Track                     [Page 6]
^L
RFC 3949              File Format for Internet Fax         February 2005


                        S (MH)
                       / \
               B&W    /   \   Color
          ------------     ----------
         /      \                    \
        /        F (MH, MR, MMR)      C (JPEG)
       /                             / \
      J (JBIG)                   ----   \
                                /        \
                               L (JBIG)   \
                                           \
                                            M (MRC)

   A profile is based on a collection of ITU-T facsimile coding methods.
   For example, Profile S, the minimal profile, is based on Modified
   Huffman (MH) compression, which is defined in ITU-T Rec. T.4.
   Profile F specifies Modified Huffman (MH), Modified READ (MR), and
   Modified Modified READ (MMR) compressions, which are defined in ITU-T
   Rec. T.4 and T.6.

   All implementations of TIFF for facsimile MUST implement Profile S,
   which is the root node of the tree.  All color implementations of
   TIFF for facsimile MUST implement Profile C.  The implementation of a
   particular profile MUST also implement those profiles on the path
   that connect it to the root node, and MAY optionally implement
   profiles not on the path connecting it to the root node.  For
   example, an implementation of Profile M must also implement Profiles
   C and S and may optionally implement Profile F, J, or L.  For another
   example, an implementation of Profile C must also implement Profile S
   and may optionally implement Profile F or J.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", " NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [REQ].

2.  TIFF and Fax

2.1.  TIFF Overview

   TIFF provides a means for describing, storing, and interchanging
   raster image data.  A primary goal of TIFF is to provide a rich
   environment within which applications can exchange image data.  The
   current TIFF specification [TIFF] defines a commonly used core set of
   TIFF fields known as Baseline TIFF.  The current specification, the
   set of Pagemaker TIFF Technical Notes [TTN1], and TIFF Technical Note
   2 [TTN2] define several TIFF extensions.  The TIFF-based
   specification for fax applications uses a subset of Baseline TIFF




Buckley, et al.             Standards Track                     [Page 7]
^L
RFC 3949              File Format for Internet Fax         February 2005


   fields, with selected extensions, as described in this document.  In
   a few cases, this document defines new TIFF fields specifically for
   fax applications.

2.1.1.  File Structure

   TIFF is designed for raster images, which makes it a good match for
   facsimile documents, which are multi-page raster images.  Each raster
   image consists of a number of rows or scanlines, each of which has
   the same number of pixels, the unit of sampling.  Each pixel has at
   least one sample or component (exactly one for black-and-white
   images).

   A TIFF file begins with an 8-byte image file header.  The first two
   bytes describe the byte order used within the file.  Legal values are
   "II" (0x4949) when bytes are ordered from least to most significant
   (little-endian), and "MM" (0x4D4D), when bytes are ordered from most
   to least significant (big-endian) within a 16- or 32-bit integer.
   Either byte order can be used, except in the case of the minimal
   black-and-white profile, which SHALL use value "II".  The next two
   bytes contain the value 42, which identifies the file as a TIFF file
   and is ordered according to the value in the first two bytes of the
   header.  The last four bytes give the offset that points to the first
   image file directory (IFD).  This and all other offsets in a TIFF
   file are with respect to the beginning of the TIFF file.  An IFD can
   be at any location in the file after the header but must begin on a
   word boundary.

   An IFD is a sequence of tagged fields, sorted in ascending order by
   tag value.  An IFD consists of a 2-byte count of the number of
   fields, a sequence of field entries, and a 4-byte offset to the next
   IFD.  The fields contain information about the image and pointers to
   the image data.  Each separate raster image in the file is
   represented by an IFD.

   Each field entry in an IFD has 12 bytes and consists of a 2-byte Tag,
   2 bytes identifying the field type (e.g., short, long, rational,
   ASCII), 4 bytes giving the count (number of values or offsets), and 4
   bytes containing either the offset to a field value stored outside
   the IFD or, based on the type and count, the field value itself.
   Resolution and metadata such as dates, names, and descriptions are
   examples of "long" field values that do not fit in 4 bytes and
   therefore use offsets in the field entry.  Details are given in the
   TIFF specification [TIFF].

   A TIFF file can contain more than one IFD, where each IFD is a
   subfile whose type is given in the NewSubfileType field.  Multiple
   IFDs can be organized either as a linked list, with the last entry in



Buckley, et al.             Standards Track                     [Page 8]
^L
RFC 3949              File Format for Internet Fax         February 2005


   each IFD pointing to the next IFD (the pointer in the last IFD is 0),
   or as a tree, using the SubIFDs field in the primary IFD [TTN1].  The
   SubIFDs field contains an array of pointers to child IFDs of the
   primary IFD.

   Child IFDs describe related images, such as reduced resolution
   versions of the primary IFD image.  The same IFD can point both to a
   next IFD and to child IFDs, and child IFDs can themselves point to
   other IFDs.

   All fax profiles represent a multi-page fax image as a linked list of
   IFDs, with a NewSubfileType field containing a bit that identifies
   the IFD as one page of a multi-page document.  Each IFD has a
   PageNumber field, identifying the page number in ascending order,
   starting at 0 for the first page.  Although a Baseline TIFF reader is
   not required to read any IFDs beyond the first, an implementation
   that reads the files that comply with this specification SHALL read
   multiple IFDs.  Only the Mixed Raster Content fax profile, described
   in Section 8, requires the use of child IFDs.
































Buckley, et al.             Standards Track                     [Page 9]
^L
RFC 3949              File Format for Internet Fax         February 2005


   The following figure illustrates the structure of a multi-page TIFF
   file.

              +-----------------------+
              |         Header        |------------+
              +-----------------------+            | First IFD
              |      IFD (page 0)     |<-----------+ Offset
          +---|                       |------------+
    Value |   +-----------------------+            |
   Offset +-->|      Long Values      |--+         |
              +-----------------------|  | Strip   |
              |       Image Data      |<-+ Offset  |
              |     strip 1 page 0    |  |         |
              +-----------------------+  |         |
              |           :           |  :         |
                                                   |
              +-----------------------+            | Next IFD
              |      IFD (page 1)     |<-----------+ Offset
          +---|                       |------------+
    Value |   +-----------------------+            |
   Offset +-->|      Long Values      |--+         |
              +-----------------------|  | Strip   |
              |       Image Data      |<-+ Offset  |
              |     strip 1 page 1    |  |         |
              +-----------------------+  |         |
              |     strip 2 page 1    |<-+         |
              +-----------------------+  |         |
              |          :            |  :         |
                                                   |
              +-----------------------+            | Next IFD
              |      IFD (page 2)     |<-----------+ Offset
              |          :            |

2.1.2.  Image Structure

   An IFD stores an image as one or more strips, as shown in the
   preceding figure.  A strip consists of 1 or more scanlines (rows) of
   raster image data in compressed form.  An image may be stored in a
   single strip or may be divided into several strips, which would
   require less memory to buffer.  (Baseline TIFF recommends about 8k
   bytes per strip, but existing fax usage is typically one strip per
   image.)

   Each IFD requires three strip-related fields: StripOffsets,
   RowsPerStrip, and StripByteCounts.  The StripOffsets field is an
   array of pointers to the strip or strips that contain the actual
   image data.  The StripByteCounts field gives the number of bytes in
   each strip after compression.  TIFF requires that each strip, except



Buckley, et al.             Standards Track                    [Page 10]
^L
RFC 3949              File Format for Internet Fax         February 2005


   the last, contain the same number of scanlines, which is given in the
   RowsPerStrip field.  This document introduces the new StripRowCounts
   field that allows a variable number of scanlines per strip, which is
   required by the Mixed Raster Content fax profile (Section 8).

   Image data is stored as uninterpreted, compressed image data streams
   within a strip.  The formats of these streams follow the ITU-T
   Recommendations.  The Compression field in the IFD indicates the type
   of compression, and other TIFF fields in the IFD describe image
   attributes such as color encoding and spatial resolution.
   Compression parameters are stored in the compressed data stream
   rather than in TIFF fields.  This makes the TIFF representation and
   compressed data format specification independent of each another.
   This approach, modeled on [TTN2], allows TIFF to add new compression
   schemes gracefully as they become available.

   Some attributes can be specified both in the compressed data stream
   and within a TIFF field.  It is possible that the two values will
   differ.  When this happens for values required to interpret the data
   stream, the values in the data stream take precedence.  For
   informational values that are not required to interpret the data
   stream, such as author name, then the TIFF field value takes
   precedence.

2.1.3.  TIFF File Structure for Fax Applications

   The TIFF specification has a very flexible file structure that does
   not specify the ordering of IFDs, field values, and image data in a
   file.  Individual applications may require or recommend an ordering.

   This specification recommends that when using a TIFF file for
   facsimile, a multi-page fax document SHOULD be represented as a
   linked list of IFDs.  It also recommends that a TIFF file for
   facsimile SHOULD order pages in a TIFF file in the same way that they
   are ordered in a fax data stream.  In a TIFF file, a page consists of
   several elements: one or more IFDs (including subIFDs), long field
   values that are stored outside the IFDs, and image data (in one or
   more strips).

   The minimal black-and-white profile (Profile S) specifies a required
   ordering of pages and elements within a page (Section 3.5).  The
   extended black-and-white profile (Profile F) provides guidelines for
   ordering pages and page elements (Section 4.4.6).  Other profiles
   SHOULD follow these guidelines.  This recommendation is intended to
   simplify the implementation of TIFF writers and readers in fax
   applications and the conversion between TIFF file and fax data stream
   representations.  However, for interchange robustness, readers SHOULD




Buckley, et al.             Standards Track                    [Page 11]
^L
RFC 3949              File Format for Internet Fax         February 2005


   be prepared to read TIFF files whose structure is consistent with
   [TIFF], which supports a more flexible file structure than is
   recommended here.

   This specification introduces an optional new GlobalParametersIFD
   field, defined in Section 2.2.4.  This field has type IFD and
   indicates parameters describing the fax session.  While it is often
   possible to obtain these parameters by scanning the file, it is
   convenient to make them available together in one place for fast and
   easy access.  If the GlobalParametersIFD occurs in a TIFF file, it
   SHOULD be located in the first IFD, immediately following the 8-byte
   image file header.

2.2.  TIFF Fields for All Fax Applications

   The TIFF specification [TIFF] is organized as a baseline set and
   several extensions, including technical notes [TTN1, TTN2] that will
   be incorporated in the next release of TIFF.  The baseline and
   extensions have required and optional fields.

   Facsimile applications require (and recommend) a mixture of baseline
   and extensions fields, as well as some new fields that are not part
   of the TIFF specification and that are defined in this document.
   This sub-section lists the fields that are required or recommended
   for all profiles.  In particular, Section 2.2.1 lists the fields that
   are required by all profiles and that have values that do not depend
   on the profile.  Section 2.2.2 lists the fields that are required by
   all profiles and that have values that do depend on the profile.
   Section 2.2.3 lists the fields that are recommended for all profiles.
   Fields required or recommended by some but not all profiles are given
   in the section (Section 3 - 8) that describes that profile.  The
   sections for each fax profile have subsections for required and
   recommended fields; each subsection organizes the fields according to
   whether they are baseline, extension or new.

   The fields required for facsimile have only a few legal values,
   specified in the ITU-T Recommendations.  Of these legal values, some
   are required and some are optional, just as they are required
   (mandatory) or optional in fax implementations that conform to the
   ITU-T Recommendations.  The required and optional values are noted in
   the sections on the different fax profiles.










Buckley, et al.             Standards Track                    [Page 12]
^L
RFC 3949              File Format for Internet Fax         February 2005


   This section describes the fields required or recommended by all fax
   profiles.  The pattern for the description of TIFF fields in this
   document is as follows:

   FieldName(TagValueInDecimal) = allowable values.
   TYPE

      WhetherRequiredByTIFForTIFFforFAX
      Count = (omitted if =1) = (if not in current spec but available)
      Explanation of the field, how it's used, and the values it can
      have.  Default value, if any, as specified in [TIFF].

   When a field's default value is the desired value, that field may be
   omitted from the relevant IFD unless specifically required by the
   text of this specification.

2.2.1.  TIFF fields required for all fax profiles

   The TIFF fields listed in this section SHALL be used by all fax
   profiles but have field values that are not specified by the ITU
   standards, i.e., the fields do not depend on the profile.  The next
   subsection lists the fields that SHALL be used by all fax profiles,
   but which do have values specified by the ITU-specified or profile-
   specific values.  Fields that SHALL be used by some but not all
   profiles are given in the Sections (3 - 8) that describe the profiles
   that use them.

   ImageLength(257)
   SHORT or LONG
      RequiredByTIFFBaseline
      Total number of scanlines in image.
      No default, must be specified.

   PageNumber(297)
   SHORT
      RequiredByTIFFforFAX, TIFFExtension
      Count = 2
      The first number represents the page number (0 for the first
      page); the second number is the total number of pages in the
      document.  If the second value is 0, then the total page count is
      not available.
      No default, must be specified









Buckley, et al.             Standards Track                    [Page 13]
^L
RFC 3949              File Format for Internet Fax         February 2005


   RowsPerStrip(278)
   SHORT or LONG
      RequiredByTIFFBaseline
      The number of scanlines per TIFF strip, except for the last strip.
      For a single strip image, this is the same as the value of the
      ImageLength field.
      Default = 2**32 - 1 (meaning all scanlines in one strip).

   StripByteCounts(279)
   SHORT or LONG
      RequiredByTIFFBaseline
      Count = number of strips
      For each strip, the number of bytes in that strip after
      compression.
      No default, must be specified.

   StripOffsets(273)
   SHORT or LONG
      RequiredByTIFFBaseline
      Count = number of strips
      For each strip, the byte offset from the beginning of the file to
      the start of that strip.
      No default, must be specified.

2.2.2.  Additional TIFF fields required for all fax profiles

   The TIFF fields listed in this section SHALL be used by all fax
   profiles, but the values associated with them depend on the profile
   being described and the associated ITU Recommendations.  Therefore,
   only the fields are defined here; the values applicable to a
   particular fax profile are described in Sections 3 - 8.  Fields that
   SHALL be used by some but not all profiles are given in the section
   (3 - 8) describing the profile that uses them.

   BitsPerSample(258)
   SHORT
      RequiredByTIFFBaseline
      Number of bits per image sample.
      Default = 1 (field may be omitted if this is the value).

   Compression(259)
   SHORT
      RequiredByTIFFBaseline
      Compression method used for image data.
      Default = 1 (no compression, so may not be omitted for FAX).






Buckley, et al.             Standards Track                    [Page 14]
^L
RFC 3949              File Format for Internet Fax         February 2005


   FillOrder(266)
   SHORT
      RequiredByTIFFforFax
      The default bit order in Baseline TIFF per [TIFF] is indicated by
      FillOrder=1, where bits are not reversed before being stored.
      However, TIFF for Fax typically uses the setting of FillOrder=2,
      where the bit order within bytes is reversed before storage (i.e.,
      bits are stored with the Least Significant Bit first).
      Default = 1 (field may be omitted if this is the value)
      Facsimile data appears on the phone line in bit-reversed order
      relative to its description in the relevant ITU compression
      Recommendation.  Therefore, a wide majority of facsimile
      implementations choose this natural order for storage.

      Nevertheless, all readers conforming to this specification must be
      able to read data in both bit orders, except in the case of
      Profile S, which only requires support for FillOrder=2 (Least
      Significant Bit first).

   ImageWidth(256)
   SHORT or LONG
      RequiredByTIFFBaseline
      The number of pixels (columns) per scanline (row) of the image
      No default, must be specified.

   NewSubFileType(254)
   LONG
      RequiredByTIFFforFAX
      A general indication of the kind of data contained in this IFD Bit
      1 is 1 if the image is a single page of a multi-page document.
      Default = 0 (no subfile bits on, so may not be omitted for FAX).

   PhotometricInterpretation(262)
   SHORT
      RequiredByTIFFBaseline
      The color space of the image data.
      No default, must be specified.

   ResolutionUnit(296)
   SHORT
      RequiredByTIFFBaseline The unit of measure for resolution. 2 =
      inch, 3 = centimeter; Default = 2 (field may be omitted if this is
      the value)








Buckley, et al.             Standards Track                    [Page 15]
^L
RFC 3949              File Format for Internet Fax         February 2005


   SamplesPerPixel(277)
   SHORT
      RequiredByTIFFBaseline
      The number of color components per pixel; SamplesPerPixel is 1 for
      a black-and-white, grayscale or indexed (palette) image.  Default
      = 1 (field may be omitted if this is the value).

   XResolution(282)
   RATIONAL
      RequiredByTIFFBaseline
      The horizontal resolution of the image in pixels per resolution
      unit.  The ITU-T Recommendations for facsimile specify a small
      number of horizontal resolutions: 100, 200, 300, 400 pixels per
      inch, and 80, 160 pixels per centimeter (or 204, 408 pixels per
      inch).  The allowed XResolution values for each profile are given
      in the section defining that profile.  Per [T.4], it is
      permissible for applications to treat the following XResolution
      values as being equivalent: <204, 200> and <400,408> in
      pixels/inch.  These equivalencies were allowed by [T.4] to permit
      conversions between inch and metric based facsimile terminals.  To
      ensure interoperability, if an application accepts any member of
      the pairs then T.4 requires it to accept both (e.g., accept 204 if
      200 pixels per inch is accepted).  TIFF for Facsimile Writers
      SHOULD express XResolution in inch-based units, for consistency
      with historical practice and to maximize interoperability.  See
      the table below for information on how to convert from an ITU-T
      metric value to its inch-based equivalent resolution.
      No default, must be specified

   YResolution(283)
   RATIONAL
      RequiredByTIFFBaseline
      The vertical resolution of the image in pixels per resolution
      unit.  The ITU-T Recommendations for facsimile specify a small
      number of vertical resolutions: 100, 200, 300, 400 pixels per
      inch, and 38.5, 77, 154 pixels per centimeter (or 98, 196, 391
      pixels per inch).  The allowed YResolution values for each profile
      are given in the section defining that profile.  Per [T.4], it is
      permissible for applications to treat the following YResolution
      values as being equivalent: <98, 100>, <196, 200>, and <391, 400>
      in pixels/inch.  These equivalencies were allowed by [T.4] to
      permit conversions between inch- and metric-based facsimile
      terminals.  To insure interoperability, if an application accepts
      any member of the pairs, then T.4 requires it to accept both
      (e.g., accept 98 if 100 pixels per inch is accepted).  TIFF for
      Facsimile Writers SHOULD express YResolution in inch-based units,
      for consistency with historical practice and to maximize




Buckley, et al.             Standards Track                    [Page 16]
^L
RFC 3949              File Format for Internet Fax         February 2005


      interoperability.  See the table below for information on
      converting from the metric value to its inch based equivalent
      resolution.
      No default, must be specified.

   +-----------------------------+-----------------------------+
   |         XResolution         |         YResolution         |
   +--------------+--------------+--------------+--------------+
   |ResolutionUnit|ResolutionUnit|ResolutionUnit|ResolutionUnit|
   |  =2 (inch)   |   =3 (cm)    |  =2 (inch)   |   =3 (cm)    |
   +--------------+--------------+--------------+--------------+
   |     100      |              |     100      |              |
   +--------------+--------------+--------------+--------------+
   |     204      |      80      |      98      |     38.5     |
   |     200      |              |     100      |              |
   +--------------+--------------+--------------+--------------+
   |     204      |      80      |     196      |      77      |
   |     200      |              |     200      |              |
   +--------------+--------------+--------------+--------------+
   |     204      |      80      |     391      |     154      |
   +--------------+--------------+--------------+--------------+
   |     300      |              |     300      |              |
   +--------------+--------------+--------------+--------------+
   |     408      |     160      |     391      |     154      |
   |     400      |              |     400      |              |
   +--------------+--------------+--------------+--------------+

2.2.3.  TIFF fields recommended for all fax profiles

   The TIFF fields listed in this section MAY be used by all fax
   profiles.  However, Profile S writers (the minimal fax profile
   described in Section 3) SHOULD NOT use these fields.  Recommended
   fields that are profile-specific are described in Sections 3 - 8.

   DateTime(306)
   ASCII
      OptionalInTIFFBaseline
      Date/time of image creation in 24-hour format
      "YYYY:MM:DD HH:MM:SS".  No default.

   DocumentName(269)
   ASCII
      OptionalInTIFFExtension(DocumentStorageAndRetrieval)
      The name of the scanned document.  This is a TIFF extension field,
      not a Baseline TIFF field.  No default.






Buckley, et al.             Standards Track                    [Page 17]
^L
RFC 3949              File Format for Internet Fax         February 2005


   ImageDescription(270)
   ASCII
      OptionalInTIFFBaseline
      A string describing the contents of the image.
      No default.

   Orientation(274) = 1 - 8.
   SHORT
      OptionalinTIFFBaseline 1: 0th row represents the visual top of the
      image; the 0th column represents the visual left side of the
      image.  See the current TIFF spec [TIFF] for further values;
      Baseline TIFF only requires value=1.  Default = 1.
      Note: It is recommended that a writer that is aware of the
      orientation include this field to give a positive indication of
      the orientation, even if the value is the default.  Writers should
      not generate mirror images, because many readers will not properly
      reverse the image before display or print.

   Software(305)
   ASCII
      OptionalInTIFFBaseline
      The name and release number of the software package that
      created the image.
      No default.

2.2.4.  New TIFF fields recommended for fax profiles

   The new TIFF fields listed in this section MAY be used by all fax
   profiles.  However, Profile S writes (the minimal fax profile
   described in Section 3) SHOULD NOT use these fields.  In addition,
   support for these new TIFF fields has not been included in historical
   TIFF-F readers described in Section 4 and [TIFF-F].  These fields
   describe "global" parameters of the fax session that created the
   image data.  They are optional, not part of the current TIFF
   specification, and are defined in this document.

   The first new field, GlobalParametersIFD, is an IFD that contains
   global parameters and is located in a Primary IFD.

   GlobalParametersIFD (400) IFD or LONG

      An IFD containing global parameters.  It is recommended that a
      TIFF writer place this field in the first IFD, where a TIFF reader
      would find it quickly.

      Each field in the GlobalParametersIFD is a TIFF field that is
      legal in any IFD.  Required baseline fields should not be located
      in the GlobalParametersIFD but should be in each image IFD.  If a



Buckley, et al.             Standards Track                    [Page 18]
^L
RFC 3949              File Format for Internet Fax         February 2005


      conflict exists between fields in the GlobalParametersIFD and in
      the image IFDs, then the data in the image IFD shall prevail.

      Among the GlobalParametersIFD entries is a new ProfileType field
      that generally describes information in this IFD and in the TIFF
      file.

   ProfileType(401)
   LONG
      The type of image data stored in this IFD.
      0 = Unspecified
      1 = Group 3 fax
      No default

   The following new global fields are defined in this document as IFD
   entries for use with fax applications.

   FaxProfile(402) = 0 - 6.
   BYTE
      The profile that applies to this file; a profile is subset of the
      full set of permitted fields and field values of TIFF for
      facsimile.  The currently defined values are:
      0: does not conform to a profile defined for TIFF for facsimile
      1: minimal black & white lossless, Profile S
      2: extended black & white lossless, Profile F
      3: lossless JBIG black & white, Profile J
      4: lossy color and grayscale, Profile C
      5: lossless color and grayscale, Profile L
      6: Mixed Raster Content, Profile M

   CodingMethods(403)
   LONG
      This field indicates which coding methods are used in the file.  A
      value of 1 in a bit location indicates the corresponding coding
      method is used.  More than one bit set to 1 means more than one
      coding method is used in the file.
   Bit 0: unspecified compression
   Bit 1: 1-dimensional coding, ITU-T Rec. T.4 (MH - Modified Huffman)
   Bit 2: 2-dimensional coding, ITU-T Rec. T.4 (MR - Modified READ)
   Bit 3: 2-dimensional coding, ITU-T Rec. T.6 (MMR - Modified MR)
   Bit 4: ITU-T Rec. T.82 coding, using ITU-T Rec. T.85 (JBIG)
   Bit 5: ITU-T Rec. T.81 (Baseline JPEG)
   Bit 6: ITU-T Rec. T.82 coding, using ITU-T Rec. T.43 (JBIG color)
   Bits 7 - 31: reserved for future use







Buckley, et al.             Standards Track                    [Page 19]
^L
RFC 3949              File Format for Internet Fax         February 2005


   Note: There is a limit of 32 compression types to identify standard
   compression methods.

   VersionYear(404)
   BYTE
      Count: 4
      The year of the standard specified by the FaxProfile field, given
      as 4 characters, e.g., '1997'; used in lossy and lossless color
      profiles.

   ModeNumber (405)
   BYTE
      The mode of the standard specified by the FaxProfile field.  A
      value of 0 indicates Mode 1.0; used in Mixed Raster Content
      profile.

3.  Profile S: Minimal Black-and-White Fax Profile

   This section defines the minimal black-and-white subset of TIFF for
   facsimile.  This subset is designated Profile S.  All implementations
   of TIFF for facsimile SHALL support the minimal subset.

   Black-and-white mode is the binary fax application most users are
   familiar with today.  This mode is appropriate for black-and-white
   text and line art.  Black-and-white mode is divided into two levels
   of capability.  This section describes the minimal interchange set of
   TIFF fields that must be supported by all implementations in order to
   assure that some form of image, albeit black-and-white, can be
   interchanged.  This minimum interchange set is a strict subset of the
   fields and values defined for the extended black-and-white profile
   (TIFF-F or Profile F) in Section 4, which describes extensions to the
   minimal interchange set of fields that provide a richer set of
   black-and-white capabilities.

3.1.  Overview

   The minimal interchange portion of the black-and-white facsimile mode
   supports 1-dimensional Modified Huffman (MH) compression, with the
   original Group 3 fax resolutions, commonly called "standard" and
   "fine."

   To assure interchange, this profile uses the minimal set of fields
   with a minimal set of values.  There are no recommended fields in
   this profile.  Further, the TIFF file is required to be "little-
   endian", which means that the byte order value in the TIFF header is
   "II".  This profile defines a required ordering for the pages in a
   fax document and for the IFDs and image data of a page.  It also
   requires



Buckley, et al.             Standards Track                    [Page 20]
^L
RFC 3949              File Format for Internet Fax         February 2005


   that a single strip contain the image data for each page; see Section
   3.5.  The image data may contain RTC sequences, as specified in
   Section 3.4.

3.2.  Required TIFF Fields

   Besides the fields listed in Section 2.2.1, the minimal black-and-
   white fax profile requires the following fields.  The fields listed
   in Section 2.2.1 and the fields and fax-specific values specified in
   this subsection must be supported by all implementations.

3.2.1.  Baseline fields

   BitsPerSample(258) = 1.
   SHORT
      RequiredByTIFFBaseline
      Binary data only.
      Default = 1 (field may be omitted if this is the value)

   Compression(259) = 3.
   SHORT
      RequiredByTIFFBaseline
      3 = 1- or 2- dimensional coding.
      The value 3 is a TIFF extension value [TIFF].  The T4Options field
      must be specified, and its value specifies that the data is
      encoded with the Modified Huffman (MH) compression of [T.4].

   FillOrder(266) = 2.
   SHORT
      RequiredByTIFFBaseline
      2 = Least Significant Bit first

      NOTE: Baseline TIFF readers are only required to support FillOrder
      1, where the lowest numbered pixel is stored in the MSB of the
      byte.  However, because many devices, such as modems, transmit the
      LSB first when converting the data to serial form, it is common
      for black-and-white fax products to use the second FillOrder = 2,
      where the lowest numbered pixel is stored in the LSB.  Therefore,
      this value is specified in the minimal black-and-white profile.

   ImageWidth(256) = 1728.
   SHORT or LONG
      RequiredByTIFFBaseline
      This profile only supports a page width of 1728 pixels.  This
      width corresponds to North American Letter and Legal and to ISO A4
      size pages.  No default, must be specified.





Buckley, et al.             Standards Track                    [Page 21]
^L
RFC 3949              File Format for Internet Fax         February 2005


   NewSubFileType(254) = (Bit 1=1).
   LONG
      RequiredByTIFFforFAX
      Bit 1 is 1 if the image is a single page of a multi-page document.
      Default = 0 (no subfile bits on, so may not be omitted for fax).

   PhotometricInterpretation(262) = 0.
   SHORT
      RequiredByTIFFBaseline
      0 = pixel value 1 means black.
      No default, must be specified.

   ResolutionUnit(296) = 2.
   SHORT
      RequiredByTIFFBaseline
      The unit of measure for resolution. 2 = inch.
      Default = 2 (field may be omitted if this is the value).

   SamplesPerPixel(277) = 1.
   SHORT
      RequiredByTIFFBaseline
      The number of components per pixel; 1 for black-and-white.
      Default = 1 (field may be omitted if this is the value).

   XResolution(282) = 200, 204.
   RATIONAL
      RequiredByTIFFBaseline
      The horizontal resolution of the image is expressed in pixels per
      resolution unit.  In pixels/inch, the allowed values are 200 and
      204, which may be treated as equivalent.  See Section 2.2.2 for
      inch metric equivalency.  No default, must be specified.

   YResolution(283) = 98, 100, 196, 200.
   RATIONAL
      RequiredByTIFFBaseline The vertical resolution of the image is
      expressed in pixels per resolution unit.  In pixels/inch, the
      allowed values are 98, 100, 196, and 200; 98 and 100 may be
      treated as equivalent, and 196 and 200 may be treated as
      equivalent.  See Section 2.2.2 for inch metric equivalency.  No
      default, must be specified.











Buckley, et al.             Standards Track                    [Page 22]
^L
RFC 3949              File Format for Internet Fax         February 2005


3.2.2.  Extension fields

   T4Options(292) = (Bit 0 = 0, Bit 1 = 0, Bit 2 = 0, 1)
      LONG
      RequiredTIFFExtension (when Compression = 3)
      Bit 0 = 0 indicates MH compression.
      Bit 1 must be 0.
      Bit 2 = 1 indicates that EOLs are byte aligned, = 0 EOLs not byte
      aligned.
      Default is all bits are 0 (applies when EOLs are not byte aligned)

   Note: The T4Options field is required when the Compression field has
   a value of 3.  Bit 0 of this field specifies the compression used (MH
   only in this profile).  MH coding requires the use of EOL (End of
   Line) codes: Bit 2 indicates whether the EOL codes are byte-aligned
   or not.  See Section 3.4 for details.

3.2.3.  New Fields

   None.

3.3.  Recommended TIFF Fields

   None.

3.4.  End of Line (EOL) and Return to Control (RTC)

   TIFF extensions for fax, used in this specification, differ from
   Baseline TIFF in the following ways:

   -  A 12-bit EOL sequence MUST precede each line of MH-compressed
      image data.  (Baseline TIFF does not use these EOL sequences.)
   -  The EOL sequence MAY be byte-aligned, in which case fill bits are
      added so that the EOL sequence ends on a byte boundary, and any
      subsequent image data begins on a byte boundary.
   -  If the EOL codes are not byte aligned, the image data MAY be
      followed by an RTC (Return to Control) sequence, consisting of 6
      consecutive EOLs.

   In conventional fax, an MH-compressed fax data stream for a page
   consists of the following sequence:
      EOL, compressed data (first line), EOL, compressed data, ... ,
      EOL, compressed data (last line), RTC (6 consecutive EOL codes)

   Baseline TIFF does not use EOL codes or Return to Control (RTC)
   sequences for MH-compressed data.  However, the TIFF extension field
   T4Options used in this specification for MH compression (Compression
   = 3) requires EOLs.



Buckley, et al.             Standards Track                    [Page 23]
^L
RFC 3949              File Format for Internet Fax         February 2005


   Furthermore, Bit 2 in the T4Options field indicates whether or not
   the EOL codes are byte aligned.  If Bit 2 = 1, indicating the EOL
   codes are byte aligned, then fill bits have been added as necessary
   before EOL codes so that an EOL code always ends on a byte boundary,
   and the first bit of data following an EOL begins on a byte boundary.
   Without fill bits, an EOL code may end in the middle of a byte.  Byte
   alignment relieves application software of the burden of bit-shifting
   every byte while parsing scanlines for line-oriented image
   manipulation (such as writing a TIFF file).  Not all TIFF readers
   historically used for fax are able to deal with non byte aligned
   data.

   While TIFF extension requires EOL codes, TIFF in fax applications has
   traditionally prohibited RTC sequences.  Implementations that seek
   common processing and interfaces for fax data streams and Internet
   fax files would prefer that the TIFF data include RTC sequences.

   To reconcile these differences, RTCs are allowed in cases where EOL
   codes are not byte aligned and no fill bits have been added to the
   data.  This corresponds to situations where the fax data is simply
   inserted in a strip without being processed or interpreted.  RTCs
   should not occur in the data when EOLs have been byte aligned.  This
   is formally specified in the next subsection.

3.4.1.  RTC Exclusion

   Implementations that seek to maintain strict conformance with TIFF
   and compatibility with the historical use of TIFF for fax SHOULD NOT
   include the RTC sequence when writing TIFF files.  However,
   implementations that need to support "transparency" of T.4-generated
   image data MAY include RTCs when writing TIFF files if the flag
   settings of the T4Options field are set for non byte aligned data,
   i.e., Bit 2 is 0.  Implementors of TIFF readers should be aware that
   there are some existing TIFF implementations for fax that include the
   RTC sequence in MH image data.  Therefore, minimal set readers MUST
   be able to process files that do not include RTCs and SHOULD be able
   to process files that do include RTCs.

3.5.  File Structure

   The TIFF header, described in Section 2.1.1, contains two bytes that
   describe the byte order used within the file.  For the minimal
   black-and-white profile, these bytes SHALL have the value "II"
   (0x4949), denoting that the bytes in the TIFF file are in LSByte-
   first order (little-endian).  The first or 0th IFD immediately
   follows the header, so offset to the first IFD is 8.  The header
   values are shown in the following table:




Buckley, et al.             Standards Track                    [Page 24]
^L
RFC 3949              File Format for Internet Fax         February 2005


      +--------+-------------------+--------+-----------+
      | Offset |   Description     |     Value          |
      +--------+-------------------+--------+-----------+
      |   0    |   Byte Order      |  0x4949 (II)       |
      +--------+-------------------+--------+-----------+
      |   2    |   Identifier      |  42 decimal        |
      +--------+-------------------+--------+-----------+
      |   4    | Offset of 0th IFD |  0x 0000 0008      |
      +--------+-------------------+--------+-----------+

   The minimal black-and-white profile SHALL order IFDs and image data
   within a file as follows: (1) There SHALL be an IFD for each page in
   a multi-page fax document; (2) the IFDs SHALL occur in the same order
   in the file as the pages occur in the document; (3) the IFD SHALL
   precede the image data to which it has offsets; (4) the image data
   SHALL occur in the same order in the file as the pages occur in the
   document; (5) the IFD, the value data, and the image data to which it
   has offsets SHALL precede the next image IFD; and (6) the image data
   for each page SHALL be contained within a single strip.

   As a result of (6), the StripOffsets field will contain the pointer
   to the image data. With two exceptions, the field entries in the IFD
   contain the field values instead of offsets to field values located
   outside the IFD.  The two exceptions are the values for the
   XResolution and YResolution fields, both of which are type RATIONAL
   and require 2 4-byte numbers.  These "long" field values SHALL be
   placed immediately after the IFD which containing the offsets to
   them, and before the image data pointed to by that IFD.

   The effect of these requirements is that the IFD for the first page
   SHALL come first in the file after the TIFF header, followed by the
   long field values for XResolution and YResolution, followed by the
   image data for the first page, then the IFD for second page, and so
   on.  This is shown in the following figure.  Each IFD is required to
   have a PageNumber field, which has value 0 for the first page, 1 for
   the second page, and so on.















Buckley, et al.             Standards Track                    [Page 25]
^L
RFC 3949              File Format for Internet Fax         February 2005


              +-----------------------+
              |         Header        |------------+
              +-----------------------+            | First IFD
              |      IFD (page 0)     | <----------+ Offset
          +---|                       |------------+
          |   |                       |--+         |
    Value |   +-----------------------+  |         |
   Offset +-->|      Long Values      |  |         |
              +-----------------------|  | Strip   |
              |  Image Data (page 0)  |<-+ Offset  |
              +-----------------------+            | Next IFD
              |      IFD (page 1)     | <----------+ Offset
          +---|                       |------------+
          |   |                       |--+         |
    Value |   +-----------------------+  |         |
   Offset +-->|      Long Values      |  |         |
              +-----------------------|  | Strip   |
              |  Image Data (page 1)  |<-+ Offset  |
              +-----------------------+            | Next IFD
              |      IFD (page 2)     | <----------+ Offset
              +-----------------------+
              |          :            |

   Using this file structure may reduce the memory requirements in
   implementations.  It also provides some support for streaming, in
   which a file can be processed as it is received and before the entire
   file is received.

3.6.  Profile S: Minimal Black-and-White Profile Summary

   The table below summarizes the TIFF fields that compose the minimal
   interchange set for black-and-white facsimile.  The Baseline and
   Extension fields and field values MUST be supported by all
   implementations.  For convenience, certain fields that have a value
   that is a sequence of flag bits are shown with integer values
   corresponding to the flags that are set.  An implementation should
   test the setting of the relevant flag bits individually, however, to
   allow extensions to the sequence of flag bits to be appropriately
   ignored.  (See, for example, T4Options below.)

   +---------------------------+--------------------------------+
   | Baseline Fields           |  Values                        |
   +---------------------------+--------------------------------+
   | BitsPerSample             | 1                              |
   +---------------------------+--------------------------------+
   | Compression               | 3: 1D Modified Huffman coding  |
   |                           |     set T4Options = 0 or 4     |
   +------------------------------------------------------------+



Buckley, et al.             Standards Track                    [Page 26]
^L
RFC 3949              File Format for Internet Fax         February 2005


   +---------------------------+--------------------------------+
   | FillOrder                 | 2: least significant bit first |
   +---------------------------+--------------------------------+
   | ImageWidth                | 1728                           |
   +---------------------------+--------------------------------+
   | ImageLength               | n: total number of scanlines   |
   |                           | in image                       |
   +---------------------------+--------------------------------+
   | NewSubFileType            | 2: Bit 1 identifies single     |
   |                           | page of a multi-page document  |
   +---------------------------+--------------------------------+
   | PageNumber                | n,m: page number n followed by |
   |                           | total page count m             |
   +---------------------------+--------------------------------+
   | PhotometricInterpretation | 0: pixel value 1 means black   |
   +---------------------------+--------------------------------+
   | ResolutionUnit            | 2: inch                        |
   +---------------------------+--------------------------------+
   | RowsPerStrip              | number of scanlines per strip  |
   |                           | = ImageLength, with one strip  |
   +---------------------------+--------------------------------+
   | SamplesPerPixel           | 1                              |
   +---------------------------+--------------------------------+
   | StripByteCounts           | number of bytes in TIFF strip  |
   +---------------------------+--------------------------------+
   | StripOffsets              | offset from beginning of       |
   |                           | file to single TIFF strip      |
   +---------------------------+--------------------------------+
   | XResolution               | 204, 200 (pixels/inch)         |
   +---------------------------+--------------------------------+
   | YResolution               | 98, 196, 100, 200 (pixels/inch)|
   +---------------------------+--------------------------------+
   | Extension Fields                                           |
   +---------------------------+--------------------------------+
   | T4Options                 | 0: MH coding, EOLs not byte    |
   |                           |               aligned          |
   |                           | 4: MH coding, EOLs byte aligned|
   +---------------------------+--------------------------------+

4.  Profile F: Extended Black-and-White fax profile

   This section defines the extended black-and-white profile or Profile
   F of TIFF for facsimile.  It provides a standard definition of what
   has historically been known as TIFF Class F and now as TIFF-F.  In
   doing so, it aligns this profile with current ITU-T Recommendations
   for black-and-white fax and with existing industry practice.
   Implementations of this profile include implementations of Profile S.




Buckley, et al.             Standards Track                    [Page 27]
^L
RFC 3949              File Format for Internet Fax         February 2005


   This section describes extensions to the minimal interchange set of
   fields (Profile S) that provide a richer set of black-and-white
   capabilities.  The fields and values described in this section are a
   superset of the fields and values defined for the minimal interchange
   set in Section 3.  In addition to the MH compression, Modified READ
   (MR) and Modified Modified READ (MMR) compression, as described in
   [T.4] and [T.6] are supported.

   Section 4.1 gives an overview of TIFF-F.  Section 4.2 describes the
   TIFF fields that SHALL be used in this profile.  Section 4.3
   describes the fields that MAY be used in this profile.  In the spirit
   of the original TIFF-F specification, Sections 4.4 and 4.5 discuss
   technical implementation issues and warnings.  Section 4.6 gives an
   example of TIFF-F use.  Section 4.7 gives a summary of the required
   and recommended fields and their values.

4.1.  TIFF-F Overview

   Though it has been in common use for many years, TIFF-F has
   previously never been documented in the form of a standard.  An
   informal TIFF-F document was originally created by a small group of
   fax experts led by Joe Campbell.  The existence of TIFF-F is noted in
   [TIFF], but it is not defined.  This document serves as the formal
   definition of the F application of [TIFF] for Internet applications.
   For ease of reference, the term TIFF-F will be used throughout this
   document as a shorthand for the extended black-and-white profile of
   TIFF for facsimile.

   Up until the TIFF 6.0 specification, TIFF supported various "Classes"
   that defined the use of TIFF for various applications.  Classes were
   used to support specific applications. In this spirit, TIFF-F has
   been known historically as "TIFF Class F".  Previous informal TIFF-F
   documents [TIFF-F0] used the "Class F" terminology.  As of TIFF 6.0
   [TIFF], the TIFF Class concept has been eliminated in favor of the
   concept of Baseline TIFF.  Therefore, this document updates the
   definition of TIFF-F as the F profile of TIFF for facsimile, by using
   Baseline TIFF as defined in [TIFF] as the starting point and then
   adding the TIFF extensions to Baseline TIFF that apply for TIFF-F.
   In almost all cases, the resulting definition of TIFF-F fields and
   values remains consistent with those used historically in earlier
   definitions of TIFF Class F.  Where some of the values for fields
   have been updated to provide more precise conformance with the ITU-T
   [T.4] and [T.30] fax recommendations, these differences are noted.








Buckley, et al.             Standards Track                    [Page 28]
^L
RFC 3949              File Format for Internet Fax         February 2005


4.2.  Required TIFF Fields

   This section lists the required fields and the values they must have
   to be ITU-compatible.  Besides the fields listed in Section 2.2.1,
   the extended black-and-white fax profile SHALL use the following
   fields.

4.2.1.  Baseline fields

   BitsPerSample(258) = 1.
   SHORT
      RequiredByTIFFBaseline
      Binary data only.
      Default = 1 (field may be omitted if this is the value)

   Compression(259) = 3, 4.
   SHORT
      RequiredByTIFFBaseline
      3 = 1- or 2- dimensional coding, must have T4Options field This is
      a TIFF Extension value [TIFF].
      4 = 2-dimensional coding, ITU-T Rec. T.6 (MMR - Modified Modified
      READ, must have T6Options field)) This is a TIFF Extension value.
      Default = 1 (and is not applicable; field must be specified)

   NOTE: Baseline TIFF permits use of value 2 for Modified Huffman
   compression, but data is presented in a form that does not use EOLs,
   and so TIFF for facsimile uses Compression=3 instead.  See Sections
   4.4.4, 4.5.1, and 4.5.2 for more information on compression and
   encoding.

   FillOrder(266) = 1 , 2.
   SHORT
      RequiredByTIFFBaseline
      Profile F readers must be able to read data in both bit orders,
      but the vast majority of facsimile products store data LSB first,
      exactly as it appears on the telephone line.
         1 = Most Significant Bit first.
         2 = Least Significant Bit first.

   ImageWidth(256)
   SHORT or LONG
      RequiredByTIFFBaseline
      This profile supports the following fixed page widths: 1728, 2592,
      3456 (corresponding to North American Letter and Legal and ISO A4
      paper sizes), 2048, 3072, 4096 (corresponding to ISO B4 paper
      size), and 2432, 3648, 4864 (corresponding to ISO A3 paper size).
      No default; must be specified.




Buckley, et al.             Standards Track                    [Page 29]
^L
RFC 3949              File Format for Internet Fax         February 2005


   NOTE: Historical TIFF-F did not include support for the following
   widths related to higher resolutions: 2592, 3072, 3648, 3456, 4096,
   and 4864.  Historical TIFF-F documents also included the following
   values related to A5 and A6 widths: 816 and 1216.  Per the most
   recent version of [T.4], A5 and A6 documents are no longer supported
   in Group 3 facsimile, so the related width values are now obsolete.
   See section 4.5.2 for more information on inch/metric equivalencies
   and other implementation details.

   NewSubFileType(254) = (Bit 1=1).
   LONG
      RequiredByTIFFforFAX
      Bit 1 is 1 if the image is a single page of a multi-page document.
      Default = 0 (no subfile bits on, so may not be omitted for fax).

   NOTE: Bit 1 is always set to 1 for TIFF-F, indicating a single page
   of a multi-page image.  The same bit settings are used when TIFF-F is
   used for a one-page fax image.  See Section 4.4.3 for details on
   multi-page files.

   PhotometricInterpretation(262) = 0, 1.
   SHORT
      RequiredByTIFFBaseline
      0 = pixel value 1 means black, 1 = pixel value 1 means white.
      This field allows notation of an inverted or negative image.
      No default, must be specified.

   ResolutionUnit(296) = 2, 3.
   SHORT
      RequiredByTIFFBaseline
      The unit of measure for resolution. 2 = inch, 3 = centimeter; =
      TIFF-F has traditionally used inch-based measurement.
      Default = 2 (field may be omitted if this is the value).

   SamplesPerPixel(277) = 1.
   SHORT
      RequiredByTIFFBaseline
      1 = monochrome, bi-level in this case (see BitsPerSample).
      Default = 1 (field may be omitted if this is the value).

   XResolution(282) = 200, 204, 300, 400, 408
   RATIONAL
      RequiredByTIFFBaseline
      The horizontal resolution of the image is expressed in pixels per
      resolution unit.  In pixels/inch, the allowed values are 200, 204,
      300, 400, and 408.  See Section 2.2.2 for inch metric equivalency.
      No default, must be specified.




Buckley, et al.             Standards Track                    [Page 30]
^L
RFC 3949              File Format for Internet Fax         February 2005


   NOTE: The values of 200 and 408 have been added to the historical
   TIFF-F values, for consistency with [T.30].  Some existing TIFF-F
   implementations may also support values of 80 pixels/cm, which is
   equivalent to 204 pixels per inch.  See section 4.5.2 for information
   on implementation details.

   YResolution(283) = 98, 100, 196, 200, 300, 391, and 400
   RATIONAL
      RequiredByTIFFBaseline
      The vertical resolution of the image is expressed in pixels per
      resolution unit.  In pixels/inch, the allowed values are 98, 100,
      196, 200, 300, 391, and 400 pixels/inch. See Section 2.2.2 for
      inch metric equivalency.
      No default, must be specified

   NOTE: The values of 100, 200, and 391 have been added to the
   historical TIFF-F values, for consistency with [T.30].  Some existing
   TIFF-F implementations may also support values of 77 and 38.5 (cm),
   which are equivalent to 196 and 98 pixels per inch, respectively. See
   section 4.5.2 for more information on implementation details.

   NOTE: Not all combinations of XResolution, YResolution, and
   ImageWidth are legal.  The following table gives the legal
   combinations and corresponding paper sizes [T.30].

   +--------------+-----------------+---------------------------+
   |   XResolution x YResolution    |         ImageWidth        |
   +--------------+-----------------+---------+--------+--------+
   |      200x100, 204x98           |         |        |        |
   |      200x200, 204x196          |  1728   |  2048  |  2432  |
   |           204x391              |         |        |        |
   +--------------+-----------------+---------+--------+--------+
   |          300 x 300             |  2592   |  3072  |  3648  |
   +--------------+-----------------+---------+--------+--------+
   |     408 x 391, 400 x 400       |  3456   |  4096  |  4864  |
   +--------------+-----------------+---------+--------+--------+
                                    |Letter,A4|   B4   |   A3   |
                                    |  Legal  |        |        |
                                    +---------+--------+--------+
                                    |         Paper Size        |
                                    +---------------------------+










Buckley, et al.             Standards Track                    [Page 31]
^L
RFC 3949              File Format for Internet Fax         February 2005


4.2.2.  Extension fields

   T4Options(292) = (Bit 0 = 0 or 1, Bit 1 = 0, Bit 2 = 0 or 1)
   LONG
      RequiredTIFFExtension (when Compression = 3)
      T4Options was also known as Group3Options in a prior version of
      [TIFF].
      Bit 0 = 1 indicates MR compression, = 0 indicates MH compression.
      Bit 1 must be 0.
      Bit 2 = 1 indicates that EOLs are byte aligned, = 0 EOLs not byte
      aligned.
      Default is all bits are 0 (applies when MH compression is used and
      EOLs are not byte aligned) (See Section 3.2.2.)  The T4Options
      field is required when the Compression field has a value of 3.
      This field specifies the compression used (MH or MR) and whether
      the EOL codes are byte aligned or not.  If they are byte aligned,
      then fill bits have been added as necessary so that the End of
      Line (EOL) codes always end on byte boundaries.  See Sections 3.4,
      4.5.3, and 4.5.4 for details.

   T6Options(293) = (Bit 0 = 0, Bit 1 = 0).
   LONG
      RequiredTIFFExtension (when Compression = 4)
      Used to indicate parameterization of 2D Modified Modified READ
      (MMR) compression.  T6Options was also known as Group4Options in a
      prior version of [TIFF].  Bit 0 must be 0.
      Bit 1 = 0 indicates uncompressed data mode is not allowed; = 1
      indicates that uncompressed data is allowed (see [TIFF]).  Default
      is all bits 0.  For FAX, the field must be present and have the
      value 0.  The use of uncompressed data where compression would
      expand the data size is not allowed for FAX.

   NOTE: MMR compressed data is two-dimensional and does not use EOLs.
   Each MMR encoded image MUST include an "end-of-facsimile-block"
   (EOFB) code at the end of each coded strip; see Section 4.5.6.

4.2.3.  New fields

   None.

4.3.  Recommended TIFF fields

4.3.1.  Baseline fields

   See Section 2.2.3.






Buckley, et al.             Standards Track                    [Page 32]
^L
RFC 3949              File Format for Internet Fax         February 2005


4.3.2.  Extension fields

   See Section 2.2.3.

4.3.3.  New fields

   See Section 2.2.4 and optional fields below.

   Three new, optional fields, used in the original TIFF-F description
   to describe page quality, are defined in this specification.  The
   information contained in these fields is usually obtained from
   receiving facsimile hardware (if applicable).  They SHOULD NOT be
   used in writing TIFF-F files for facsimile image data that is error
   corrected or otherwise guaranteed not to have coding errors.  Some
   applications need to understand exactly the error content of the
   data.  For example, a CAD program might wish to verify that a  file
   has a low error level before importing it into a high-accuracy
   document.  Because Group 3 facsimile devices do not necessarily
   perform error correction on the image data, the quality of a received
   page must be inferred from the pixel count of decoded scanlines.  A
   "good" scan line is defined as a line that, when decoded, contains
   the correct number of pixels.  Conversely, a "bad" scanline is
   defined as a line that, when decoded, contains an incorrect number of
   pixels.

   BadFaxLines(326)
   SHORT or LONG
      The number of "bad" scanlines encountered by the facsimile device
      during reception.  A "bad" scanline is defined as a scanline that,
      when decoded, comprises an incorrect number of pixels.  Note that
      PercentBad = (BadFaxLines/ImageLength) * 100.
      No default.

   CleanFaxData(327) = 0, 1, 2.
   SHORT
      Indicates whether "bad" lines encountered during reception are
      stored in the data, or whether "bad" lines have been replaced by
      the receiver.
      0 = No "bad" lines
      1 = "bad" lines exist but were regenerated by the receiver,
      2 = "bad" lines exist but have not been regenerated.
      No default.

   NOTE: Many facsimile devices do not actually output bad lines.
   Instead, the previous good line is repeated in place of a bad line.
   Although this substitution, known as line regeneration, results in a
   visual improvement to the image, the data is nevertheless corrupted.
   The CleanFaxData field describes the error content of the data.  That



Buckley, et al.             Standards Track                    [Page 33]
^L
RFC 3949              File Format for Internet Fax         February 2005


   is, when the BadFaxLines and ImageLength fields indicate that the
   facsimile device encountered lines with an incorrect number of pixels
   during reception, the CleanFaxData field indicates whether these bad
   lines are actually still in the data or whether the receiving
   facsimile device replaced them with regenerated lines.

   ConsecutiveBadFaxLines(328)
   LONG or SHORT
      Maximum number of consecutive "bad" scanlines received.  The
      BadFaxLines field indicates only the quantity of bad lines.
      No Default.

   NOTE: The BadFaxLines and ImageLength data indicate only the quantity
   of bad lines.  The ConsecutiveBadFaxLines field is an indicator of
   the distribution of bad lines and may therefore be a better general
   indicator of perceived image quality.  See Section 4.4.5 for examples
   of the use of these fields.

4.4.  Technical Implementation Issues

4.4.1.  Strips

   In general, TIFF files divide an image into "strips", also known as
   "bands".  Each strip contains a few scanlines of the image.  By using
   strips, a TIFF reader need not load the entire image into memory,
   enabling it to fetch and decompress small random portions of the
   image as necessary.

   The number of scanlines in a strip is described by the RowsPerStrip
   value and the number of bytes in the strip after compression by the
   StripByteCount value.  The location in the TIFF file of each strip is
   given by the StripOffsets values.

   Strip size is application dependent.  The recommended approach for
   multi-page TIFF-F images is to represent each page as a single strip.
   Existing TIFF-F usage is typically one strip per page in multi-page
   TIFF-F files.  See Sections 2.1.2 and 2.1.3.

4.4.2.  Bit Order

   The current TIFF specification [TIFF] does not require a Baseline
   TIFF reader to support FillOrder=2, i.e., lowest numbered 1-bit pixel
   in the least significant bit of a byte.  It further recommends that
   FillOrder=2 be used only in special purpose applications.







Buckley, et al.             Standards Track                    [Page 34]
^L
RFC 3949              File Format for Internet Fax         February 2005


   Facsimile data appears on the phone line in bit-reversed order
   relative to its description in ITU-T Recommendation T.4.  Therefore,
   most facsimile applications choose this natural order for data in a
   file.  Nevertheless, TIFF-F readers must be able to read data in both
   bit orders and support FillOrder values of 1 and 2.

4.4.3.  Multi-Page

   Many existing applications already read TIFF-F-like files but do not
   support the multi-page field.  Since a multi-page format greatly
   simplifies file management in fax application software, TIFF-F
   specifies multi-page documents (NewSubfileType = 2) as the standard
   case.

   It is recommended that applications export multiple-page TIFF-F files
   without manipulating fields and values.  Historically, some TIFF-F
   writers have attempted to produce individual single-page TIFF-F files
   with modified NewSubFileType and PageNumber (page one-of-one) values
   for export purposes.  However, there is no easy way to link such
   multiple single-page files together into a logical multiple-page
   document, so this practice is not recommended.

4.4.4.  Compression

   In Group 3 facsimile, there are three compression methods which had
   been standardized as of 1994 and are in common use.  The ITU-T T.4
   Recommendation [T.4] defines a one-dimensional compression method
   known as Modified Huffman (MH) and a two-dimensional method known as
   Modified READ (MR) (READ is short for Relative Element Address
   Designate).  In 1984, a somewhat more efficient compression method
   known as Modified Modified READ (MMR) was defined in the ITU-T T.6
   Recommendation [T.6].  MMR was originally defined for use with Group
   4 facsimile, so that this compression method has been commonly called
   Group 4 compression.  In 1991, the MMR method was approved for use in
   Group 3 facsimile and has since been widely utilized.

   TIFF-F supports these three compression methods.  The most commonly
   used is the one-dimensional Modified Huffman (MH) compression method.
   This is specified by setting the Compression field value to 3 and
   then setting bit 0 of the T4Options field to 0.  Alternatively, the
   two dimensional Modified READ (MR) method, which is much less
   frequently used in historical TIFF-F implementations, may be selected
   by setting bit 0 of the T4Options field to 1.  The value of Bit 2 in
   this field is determined by the use of fill bits.

   Depending upon the application, the more efficient two-dimensional
   Modified Modified READ (MMR)compression method from T.6 may be
   selected by setting the Compression field value to 4 and then setting



Buckley, et al.             Standards Track                    [Page 35]
^L
RFC 3949              File Format for Internet Fax         February 2005


   the first two bits (and all unused bits) of the T6Options field to 0.
   More information to aid the implementor in making a compression
   selection is contained in Section 4.5.2.

   Baseline TIFF also permits use of Compression=2 to specify Modified
   Huffman compression, but the data does not use EOLs.  As a result,
   TIFF-F uses Compression=3 instead of Compression=2 to specify
   Modified Huffman compression.

4.4.5.  Example Use of Page-quality Fields

   Here are examples for writing the CleanFaxData, BadFaxLines, and
   ConsecutiveBadFaxLines fields:

   1. Facsimile hardware does not provide page-quality information: MUST
      NOT write page-quality fields.

   2. Facsimile hardware provides page-quality information, but reports
      no bad lines.  Write only BadFaxLines = 0.

   3. Facsimile hardware provides page-quality information and reports
      bad lines.  Write both BadFaxLines and ConsecutiveBadFaxLines.
      Also write CleanFaxData = 1 or 2 if the hardware's regeneration
      capability is known.

   4. Source image data stream is error corrected or otherwise
      guaranteed to be error free such as for a computer-generated file:
      SHOULD NOT write page-quality fields.

   TIFF Writers SHOULD only generate these fields when the image has
   been generated from a fax image data stream where error correction,
   e.g., Group 3 Error Correction Mode, was not used.

4.4.6.  Practical Guidelines for Writing and Reading Multi-Page TIFF-F
        Files

   Traditionally, TIFF-F has required readers and writers to be able to
   handle multi-page TIFF-F files.  The experience of various TIFF-F
   implementors has shown that implementing TIFF-F can be greatly
   simplified if certain practical guidelines are followed when writing
   multi-page TIFF-F files.

   The structure for a multi-page TIFF-F file will include one IFD per
   document page.  In this case, this IFD will define the attributes for
   a single page.  A second simplifying guideline is that the writer of
   TIFF-F files SHOULD present IFDs in the same order as the actual
   sequence of pages.  (The pages are numbered within TIFF-F beginning
   with page 0 as the first page and then ascending (i.e., 0, 1,



Buckley, et al.             Standards Track                    [Page 36]
^L
RFC 3949              File Format for Internet Fax         February 2005


   2, ...).  However, any field values over 4 bytes will be stored
   separately from the IFD.  TIFF-F readers SHOULD expect IFDs to be
   presented in page order but be able to handle exceptions.

   Per [TIFF], the exact placement of image data is not specified.
   However, the offsets for each image strip are defined from within
   each IFD.  Where possible, another guideline for TIFF-F writers is
   that the image data for each page of a multi-page document SHOULD be
   contained within a single strip (i.e., one image strip per fax page).
   A single image strip per page further simplifies TIFF-F file writing
   for applications such as store and forward messaging, where the file
   is usually prepared in advance of the transmission, but other
   assumptions may apply for the size of the image strip for
   applications that require "streaming" techniques (see section 4.4.7).
   If a different image strip size guideline has been used (e.g.,
   constant size for image strips that may be less than the page size),
   this will immediately be evident from the values/offsets of the
   fields related to strips.

   Another simplifying guideline is that each IFD SHOULD be placed in
   the TIFF-F file structure at a point preceding the image that the IFD
   describes.

   In addition, placing the image data in a physical order within the
   TIFF file structure which is consistent with the logical page order
   simplifies TIFF-F file writing and reading.  In practice, TIFF-F
   readers will need to use the strip offsets to find the exact physical
   location of the image data, whether or not it is presented in logical
   page order.

   If the image data is stored in multiple strips, then the strips
   SHOULD occur in the file in the same order that the data they contain
   occurs in the facsimile transmission, starting from the top of the
   page.

   TIFF-F writers MAY follow another simplifying guideline, in which the
   IFD, the value data and the image data to which the IFD has offsets
   precede the next image IFD.  However, this guideline has been relaxed
   compared to the others given here.

   In the case of the minimal profile, which is also the minimal subset
   of Profile F, the SHOULDs and MAYs of these guidelines become SHALLs
   (see Section 3.5).

   A TIFF-F file structured using the guidelines of this section will
   essentially consist of a linked list of IFDs, presented in ascending
   page order, each pointing to a single page of image data




Buckley, et al.             Standards Track                    [Page 37]
^L
RFC 3949              File Format for Internet Fax         February 2005


   (one strip per page), where the pages of image data are also placed
   in a logical page order sequence within the TIFF-F file structure.
   (The pages of image data may themselves be stored in a contiguous
   manner, at the option of the implementor).

4.4.7.  Use of TIFF-F for Streaming Applications

   TIFF-F has historically been used for handling fax image files in
   applications such as store and forward messaging, where the entire
   size of the file is known in advance.  Although TIFF-F may also be
   used as a file format for cases such as streaming applications,
   assumptions differing from those provided in this section (e.g., the
   entire size and number of pages within the image are not known in
   advance) may be required.  As a result, a definition for the
   streaming application of TIFF-F is beyond the scope of this document.

4.5.  Implementation Warnings

4.5.1.  Uncompressed data

   TIFF-F requires the ability to read and write at least one-
   dimensional T.4 Huffman ("compressed") data.  Uncompressed data is
   not allowed.  The "Uncompressed" bit in T4Options or T6Options must
   be set to 0.

4.5.2.  Encoding and Resolution

   Since two-dimensional encoding is not required for Group 3
   compatibility, some historic TIFF-F readers have not been able to
   read such files.  The minimum subset of TIFF-F REQUIRES support for
   one-dimensional (Modified Huffman) files, so this choice maximizes
   portability.  However, implementors seeking greater efficiency SHOULD
   use T.6 MMR compression when writing TIFF-F files.  Some TIFF-F
   readers will also support two-dimensional Modified READ files.
   Implementors who wish to have the maximum flexibility in reading
   TIFF-F files should support all three of these compression methods
   (MH, MR, and MMR).

   Almost all facsimile products support both standard (98 dpi) vertical
   resolution  and "fine" (196 dpi) resolution.  Therefore, fine-
   resolution files are quite portable in the real world.

   In 1993, the ITU-T added support for higher resolutions in the T.30
   recommendation, including 200 x 200, 300 x 300, and 400 x 400 in dots
   per inch-based units.  At the same time, support was added for metric
   dimensions equivalent to the following inch-based resolutions: 391v x
   204h and 391v x 408h.  Therefore, the full set of inch-based
   equivalents of the new resolutions are supported in the TIFF-F



Buckley, et al.             Standards Track                    [Page 38]
^L
RFC 3949              File Format for Internet Fax         February 2005


   writer, as they may appear in some image-data streams received from
   Group 3 facsimile devices.  However, many facsimile terminals and
   older versions of TIFF-F readers are likely not to support these
   higher resolutions.

   Per [T.4], it is permissible for applications to treat the following
   XResolution values as equivalent: <204,200> and <400,408>.
   Similarly, the following YResolution values may also be treated as
   equivalent:  <98, 100>, <196, 200>, and <391, 400>.  These
   equivalencies were allowed by [T.4] to permit conversions between
   inch- and metric-based facsimile terminals.

   The optional support of metric-based resolutions in the TIFF-F reader
   (i.e., 77 x 38.5 cm) is included for completeness, as they are used
   in some legacy TIFF-F applications, but this use is not recommended
   for the creation of TIFF-F files by a writer.

4.5.3.  EOL byte-aligned

   The historical convention for TIFF-F has been that all EOLs in
   Modified Huffman or Modified READ data must be byte-aligned.
   However, Baseline TIFF has permitted use of non byte-aligned EOLs by
   default, so that a large percentage of TIFF-F reader implementations
   support both conventions.  Therefore, the minimum subset of TIFF-F,
   or Profile S, as defined in Section 3, includes support for both
   byte-aligned and non-byte-aligned EOLs; see Section 3.2.2.

   An EOL is said to be byte-aligned when Fill bits have been added as
   necessary before EOL codes so that EOL always ends on a byte
   boundary, thus ensuring an EOL sequence of a one byte preceded by a
   zero nibble: xxxx0000 00000001.

   Modified Huffman compression encodes bits, not bytes.  This means
   that the end-of-line token may end in the middle of a byte.  In byte
   alignment, extra zero bits (Fill) are added so that the first bit of
   data following an EOL begins on a byte boundary.  In effect, byte
   alignment relieves application software of the burden of bit-shifting
   every byte while parsing scan-lines for line-oriented image
   manipulation (such as writing a TIFF file).

   For Modified READ compression, each line is terminated by an EOL and
   a one-bit tag bit.  Per [T.4], the value of the tag bit is 0 if the
   next line contains two-dimensional data and 1 if the next line is a
   reference line.  To maintain byte alignment, fill bits are added
   before the EOL/tag bit sequence so that the first bit of data
   following an MR tag bit begins on a byte boundary.





Buckley, et al.             Standards Track                    [Page 39]
^L
RFC 3949              File Format for Internet Fax         February 2005


4.5.4.  EOL

   As illustrated in FIGURE 1/T.4 in [T.4], MH-encoded facsimile
   documents begin with an EOL, which in TIFF-F may be byte-aligned.
   The last line of the image is not terminated by an EOL.  Similarly,
   respect, images encoded with Modified READ two-dimensional
   compression begin with an EOL, followed by a tag bit.

4.5.5.  RTC Exclusion

   Aside from EOLs, TIFF-F files have historically only contained image
   data.  This means that applications seeking to maintain strict
   conformance with the rules in [TIFF] and compatibility with
   historical TIFF-F SHOULD NOT include the Return To Control sequence
   (RTC) (consisting of 6 consecutive EOLs) when writing TIFF-F files.
   However, applications intended to support "transparency" of [T.4]
   image data MAY include RTCs if the flag settings of the T4Options
   field are set for non byte aligned MH or MR image data.  Implementors
   of TIFF readers should also be aware that there are some existing
   TIFF-F implementations that include the RTC sequence in MH/MR image
   data.  Therefore, TIFF-F readers MUST be able to process files that
   do not include RTCs and SHOULD be able to process files that do
   include RTCs.

4.5.6.  Use of EOFB for T.6 Compressed Images

   TIFF-F pages encoded with the T.6 Modified Modified READ compression
   method MUST include an "end-of-facsimile-block" (EOFB) code at the
   end of each coded strip.  Per [TIFF], the EOFB code is followed by
   pad bits as needed to align on a byte boundary.  TIFF readers SHOULD
   ignore any bits other than pad bits beyond the EOFB.

4.6.  Example Use of TIFF-F

   The Profile F of TIFF (i.e., TIFF-F content) is a secondary component
   of the VPIM Message, as defined in [VPIM 2].  Voice messaging systems
   can often handle fax store-and-forward capabilities in addition to
   traditional voice message store-and-forward functions. As a result,
   TIFF-F fax messages can optionally be sent between compliant VPIM
   systems and may be rejected if the recipient system cannot deal with
   fax.

   Refer to the VPIM Specification for proper usage of this content.








Buckley, et al.             Standards Track                    [Page 40]
^L
RFC 3949              File Format for Internet Fax         February 2005


4.7.  Profile F: Extended Black-and-white Fax Profile Summary

   Recommended fields are shown with an asterisk (*).

   Required fields or values are shown with a double asterisk (**).  If
   the double asterisk is on the field name, then all the listed values
   are required of implementations; if the double asterisks are in the
   Values column, then only the values suffixed with a double asterisk
   are required of implementations.

   +---------------------------+--------------------------------+
   | Baseline Fields           |  Values                        |
   +---------------------------+--------------------------------+
   | BitsPerSample             | 1**                            |
   +---------------------------+--------------------------------+
   | Compression               | 3**: 1D Modified Huffman and   |
   |                           |      2D Modified READ coding   |
   |                           | 4: 2D Modified Modified READ   |
   |                           |    coding                      |
   +---------------------------+--------------------------------+
   | DateTime*                 | {ASCII}: date/time in 24-hour  |
   |                           | format "YYYY:MM:DD HH:MM:SS"   |
   +---------------------------+--------------------------------+
   | FillOrder**               | 1: most significant bit first  |
   |                           | 2: least significant bit first |
   +------------------------------------------------------------+
   | ImageDescription*         | {ASCII}: A string describing   |
   |                           | the contents of the image.     |
   +---------------------------+--------------------------------+
   | ImageWidth                | 1728**, 2048, 2432, 2592,      |
   |                           | 3072, 3456, 3648, 4096, 4864   |
   +---------------------------+--------------------------------+
   | ImageLength**             | n: total number of scanlines   |
   |                           | in image                       |
   +---------------------------+--------------------------------+
   | NewSubFileType            | 2**: Bit 1 identifies single   |
   |                           | page of a multi-page document  |
   +---------------------------+--------------------------------+
   | Orientation               | 1**-8, Default 1               |
   +---------------------------+--------------------------------+
   | PhotometricInterpretation | 0: pixel value 1 means black   |
   |  **                       | 1: pixel value 1 means white   |
   +---------------------------+--------------------------------+
   | ResolutionUnit**          | 2: inch                        |
   |                           | 3: centimeter                  |
   +------------------------------------------------------------+





Buckley, et al.             Standards Track                    [Page 41]
^L
RFC 3949              File Format for Internet Fax         February 2005


   +---------------------------+--------------------------------+
   | RowsPerStrip**            | n: number of scanlines per     |
   |                           | TIFF strip                     |
   +---------------------------+--------------------------------+
   | SamplesPerPixel           | 1**                            |
   +---------------------------+--------------------------------+
   | Software*                 | {ASCII}: name & release        |
   |                           | number of creator software     |
   +---------------------------+--------------------------------+
   | StripByteCounts**         | <n>: number or bytes in TIFF   |
   |                           | strip                          |
   +---------------------------+--------------------------------+
   | StripOffsets**            | <n>: offset from beginning of  |
   |                           | file to each TIFF strip        |
   +---------------------------+--------------------------------+
   | XResolution               | 200, 204**, 300, 400, 408      |
   |                           | (written in pixels/inch)       |
   +---------------------------+--------------------------------+
   | YResolution               | 98**, 196**, 100,              |
   |                           | 200, 300, 391, 400             |
   |                           | (written in pixels/inch)       |
   +---------------------------+--------------------------------+
   | Extension Fields                                           |
   +---------------------------+--------------------------------+
   | T4Options                 | 0**: required if Compression   |
   |                           | is Modified Huffman, EOLs are  |
   |                           | not byte aligned               |
   |                           | 1: required if Compression is  |
   |                           | 2D Modified READ, EOLs are     |
   |                           | not byte aligned               |
   |                           | 4**: required if Compression   |
   |                           | is Modified Huffman, EOLs are  |
   |                           | byte aligned                   |
   +---------------------------+--------------------------------+
   | T4Options (continued)     | 5: required if Compression     |
   |                           | is 2D Modified READ, EOLs are  |
   |                           | byte aligned                   |
   +---------------------------+--------------------------------+
   | T6Options                 | 0: required if Compression is  |
   |                           | 2D Modified Modified READ      |
   +---------------------------+--------------------------------+
   | DocumentName*             | {ASCII}: name of scanned       |
   |                           | document                       |
   +---------------------------+--------------------------------+
   | PageNumber**              | n,m: page number followed by   |
   |                           | total page count               |
   +---------------------------+--------------------------------+




Buckley, et al.             Standards Track                    [Page 42]
^L
RFC 3949              File Format for Internet Fax         February 2005


   +---------------------------+--------------------------------+
   | New Fields                                                 |
   +---------------------------+--------------------------------+
   | BadFaxLines*              | number of "bad" scanlines      |
   |                           | encountered during reception   |
   +---------------------------+--------------------------------+
   | CleanFaxData*             | 0: no "bad" lines              |
   |                           | 1: "bad" lines exist, but were |
   |                           | regenerated by receiver        |
   |                           | 2: "bad" lines exist, but have |
   |                           | not been regenerated           |
   +---------------------------+--------------------------------+
   | ConsecutiveBadFaxLines*   | Max number of consecutive      |
   |                           | "bad" lines received           |
   +---------------------------+--------------------------------+
   | GlobalParametersIFD*      | IFD: global parameters IFD     |
   +---------------------------+--------------------------------+
   | ProfileType*              | n: type of data stored in file |
   +---------------------------+--------------------------------+
   | FaxProfile*               | n: ITU-compatible fax profile  |
   +---------------------------+--------------------------------+
   | CodingMethods*            | n: compression algorithms used |
   |                           | in file                        |
   +---------------------------+--------------------------------+

5.  Profile J: Lossless JBIG Black-and-White Fax profile

   This section defines the lossless JBIG black-and-white profile of
   TIFF for facsimile, designated Profile J.  Implementations of this
   profile are required to implement Profile S as well.

   The previous section described the extended interchange set of TIFF
   fields for black-and-white fax, which provided support for the MH,
   MR, and MMR compression of black-and-white images.  This section adds
   a profile with JBIG compression capability.

5.1.  Overview

   This section describes a black-and-white profile that uses JBIG
   compression.  The ITU-T has approved the single-progression
   sequential mode of JBIG [T.82] for Group 3 facsimile.  JBIG coding
   offers improved compression for halftoned originals.  JBIG
   compression is used in accordance with the application rules given in
   ITU-T Rec. T.85 [T.85].

   This profile is essentially the extended black-and-white profile with
   JBIG compression used instead of MH, MR, or MMR.




Buckley, et al.             Standards Track                    [Page 43]
^L
RFC 3949              File Format for Internet Fax         February 2005


5.2.  Required TIFF Fields

   This section lists the required fields and the values they must have
   to be ITU-compatible.  Besides the fields listed in Section 2.2.1,
   the extended black-and-white fax profile requires the following
   fields.

5.2.1.  Baseline fields

   The TIFF fields that SHALL be used in this profile are the same as
   those described in Section 4.2.1 for the extended black-and-white
   profile, with two exceptions: the following text replaces the text in
   Section 4.2.1 for the Compression and FillOrder fields.

   Compression(259) = 9.
   SHORT
      RequiredByTIFFBaseline
      9 = JBIG coding.  This is a TIFF extension value.
      Default = 1 (and is not applicable; field must be specified).
      Profile J uses ITU-T T.85 profile of T.82; see T82Options field.

   FillOrder(266) = 1, 2.
   SHORT
      RequiredByTIFFBaseline
      1 = Pixels are arranged within a byte such that pixels with lower
      values are stored in the higher-order bits of the byte, i.e., most
      significant bit first (MSB).
      2 = Pixels are arranged within a byte such that pixels with lower
      column values are stored in the lower-order bits of the bytes,
      i.e., least significant bit first (LSB).
      Profile J readers must be able to read data in both bit orders.

5.2.2.  Extension fields

   Same fields as those in Section 2.2.1.

5.2.3.  New fields

   T82Options(435) = 0
   LONG
      Required when Compression = 9
      Individual bits are set to indicate the applicable profile of JBIG
      coding; all bits set to 0 indicates ITU-T T.85 profile of T.82;
      Other values are for further study.
      Default is all bits 0, and field may be omitted if this is the
      value.  (Field may be omitted in Profile J files.)





Buckley, et al.             Standards Track                    [Page 44]
^L
RFC 3949              File Format for Internet Fax         February 2005


   Note: A T.82 decoder can decode a T.85-encoded image when it handles
   the NEWLE marker code as described Corrigendum 1 in [T.85].

5.3.  Recommended TIFF Fields

   See Sections 2.2.3 and 2.2.4.

5.4.  Profile J: Lossless JBIG Black-and-white Fax Profile Summary

   Recommended fields are shown with an asterisk (*).

   Required fields or values are shown with a double asterisk (**).  If
   the double asterisk is on the field name, then all the listed values
   are required of implementations; if the double asterisks are in the
   Values column, then only the values suffixed with a double asterisk
   are required of implementations.

+---------------------------+--------------------------------+
| Baseline Fields           |  Values                        |
+---------------------------+--------------------------------+
| BitsPerSample             | 1**                            |
+---------------------------+--------------------------------+
| Compression               | 9**: JBIG coding               |
+---------------------------+--------------------------------+
| DateTime*                 | {ASCII}: date/time in 24-hour  |
|                           | format "YYYY:MM:DD HH:MM:SS"   |
+---------------------------+--------------------------------+
| FillOrder**               | 1: most significant bit first  |
|                           | 2: least significant bit first |
+---------------------------+--------------------------------+
| ImageDescription*         | {ASCII}: A string describing   |
|                           | the contents of the image      |
+---------------------------+--------------------------------+
| ImageWidth                | 1728**, 2048, 2432, 2592,      |
|                           | 3072, 3456, 3648, 4096, 4864   |
+---------------------------+--------------------------------+
| ImageLength**             | n: total number of scanlines   |
|                           | in image                       |
+---------------------------+--------------------------------+
| NewSubFileType**          | 2: Bit 1 identifies single     |
|                           | page of a multi-page document  |
+---------------------------+--------------------------------+
| Orientation               | 1**-8, Default 1               |
+---------------------------+--------------------------------+
| PhotometricInterpretation | 0: pixel value 1 means black   |
|  **                       | 1: pixel value 1 means white   |
+---------------------------+--------------------------------+




Buckley, et al.             Standards Track                    [Page 45]
^L
RFC 3949              File Format for Internet Fax         February 2005


+---------------------------+--------------------------------+
| ResolutionUnit**          | 2: inch                        |
|                           | 3: centimeter                  |
+---------------------------+--------------------------------+
| RowsPerStrip**            | n: number of scanlines per     |
|                           | TIFF strip                     |
+---------------------------+--------------------------------+
| SamplesPerPixel**         | 1                              |
+---------------------------+--------------------------------+
| Software*                 | {ASCII}: name & release        |
|                           | number of creator software     |
+---------------------------+--------------------------------+
| StripByteCounts**         | <n>: number of bytes in TIFF   |
|                           | strip                          |
+---------------------------+--------------------------------+
| StripOffsets**            | <n>: offset from beginning of  |
|                           | file to each TIFF strip        |
+---------------------------+--------------------------------+
| XResolution               | 200, 204**, 300, 400, 408      |
|                           | (written in pixels/inch)       |
+---------------------------+--------------------------------+
| YResolution               | 98**, 196**, 100,              |
|                           | 200, 300, 391, 400             |
|                           | (written in pixels/inch)       |
+---------------------------+--------------------------------+
| Extension Fields                                           |
+---------------------------+--------------------------------+
| DocumentName*             | {ASCII}: name of document      |
|                           |  scanned                       |
+---------------------------+--------------------------------+
| PageNumber**              | n,m: page number followed by   |
|                           | total page count               |
+---------------------------+--------------------------------+
| New Fields                                                 |
+---------------------------+--------------------------------+
| GlobalParametersIFD*      | IFD: global parameters IFD     |
+---------------------------+--------------------------------+
| T82Options**              | 0: T.85 profile of T.82        |
+---------------------------+--------------------------------+
| ProfileType*              | n: type of data stored in file |
+---------------------------+--------------------------------+
| FaxProfile*               | n: ITU-compatible fax profile  |
+---------------------------+--------------------------------+
| CodingMethods*            | n: compression algorithms used |
|                           | in file                        |
+---------------------------+--------------------------------+





Buckley, et al.             Standards Track                    [Page 46]
^L
RFC 3949              File Format for Internet Fax         February 2005


6.  Profile C: Base Color Fax profile

6.1.  Overview

   This section defines the lossy color profile of TIFF for facsimile,
   designated Profile C.  Implementations of this profile are required
   to also implement Profile S as well.

   This is the base profile for color and grayscale facsimile, which
   means that all applications that support color fax must support this
   profile.  The basic approach is the lossy JPEG compression [T.4,
   Annex E; T.81] of L*a*b* color data [T.42].  Grayscale applications
   use the L* lightness component; color applications use the L*, a* and
   b* components.

   This profile uses a new PhotometricInterpretation field value to
   describe the L*a*b* encoding specified in [T.42].  This encoding
   differs in two ways from the other L*a*b* encodings used in TIFF
   [TIFF, TTN1]: it specifies a different default range for the a* and
   b* components, based on a comprehensive evaluation of existing
   hardcopy output, and it optionally allows selectable range for the
   L*, a* and b* components.

6.2.  Required TIFF Fields

   This section lists the required fields, in addition to those given in
   Section 2.2.1, and the values they must support to be compatible with
   ITU-T Rec. T.42 and Annex E in ITU-T Rec. T.4.

6.2.1.  Baseline Fields

   ImageWidth(256).
   SHORT or LONG
      This profile supports the following fixed page widths: 864, 1024,
      1216, 1728, 2048, 2432, 2592, 3072, 3456, 3648, 4096, 4864.

   NewSubFileType(254) = (Bit 1=1).
   LONG
      RequiredByTIFFforFAX
      Bit 1 is 1 if the image is a single page of a multi-page document.
      Default = 0 (no subfile bits on, so may not be omitted for fax).

   BitsPerSample(258) = 8.
   SHORT
      Count = SamplesPerPixel
      The base color fax profile requires 8 bits per sample.





Buckley, et al.             Standards Track                    [Page 47]
^L
RFC 3949              File Format for Internet Fax         February 2005


   Compression(259) = 7.
   SHORT
      Base color fax profile uses Baseline JPEG compression.  Value 7
      represents JPEG compression as specified in [TTN2].

   FillOrder(266) = 1 , 2.
   SHORT
      RequiredByTIFFBaseline
      Profile C readers must be able to read data in both bit orders,
      but the vast majority of facsimile products store data LSB first,
      exactly as it appears on the telephone line.
         1 = Most Significant Bit first.
         2 = Least Significant Bit first.

   PhotometricInterpretation(262) = 10.
   SHORT
      Base color fax profile requires pixel values to be stored with the
      CIE L*a*b* encoding defined in ITU-T Rec. T.42.  This encoding is
      indicated by the PhotometricInterpretation value 10, referred to
      as ITULAB.  With this encoding, the minimum sample value is
      mapped to 0, and the maximum sample value is mapped to (2^n - 1),
      i.e., the maximum value, where n is the BitsPerSample value.  The
      conversion from unsigned ITULAB-encoded samples values to signed
      CIE L*a*b* values is determined by the Decode field; see Section
      6.2.3.

   NOTE: PhotometricInterpretation values 8 and 9 specify encodings for
   use with 8-bit-per-sample CIE L*a*b* [TIFF] and ICC L*a*b* [TTN1]
   data, but they are fixed encodings, which use different minimum and
   maximum samples than the T.42 default encoding.  As currently
   defined, they are not able to represent fax-encoded L*a*b* data.

   ResolutionUnit(296) = 2.
   SHORT
      The unit of measure for resolution. 2 = inch.
      ITU-T standards only specify inch-based resolutions for color fax.
      Default = 2 (field may be omitted if this is the value).

   SamplesPerPixel(277) = 1, 3.
   SHORT
      1: L* component only, required in base color profile
      3: L*, a*, b* components
      Encoded according to PhotometricInterpretation field








Buckley, et al.             Standards Track                    [Page 48]
^L
RFC 3949              File Format for Internet Fax         February 2005


   XResolution(282) = 100, 200, 300, 400.
   RATIONAL
   YResolution(283) = 100, 200, 300, 400.
   RATIONAL
      The resolution of the image is expressed in pixels per resolution
      unit.  In pixels per inch, allowed XResolution values are 100,
      200, 300, and 400.  The base color fax profile requires the pixels
      to be square, hence YResolution must equal XResolution.  Base
      resolution is 200 pixels per inch and SHALL be supported by all
      implementations of this profile.

   NOTE: The functional equivalence of inch-based and metric-based
   resolutions is maintained, per Annex E.6.5 in [T.4].  See table in
   Section 2.2.2.

   NOTE: Not all combinations of XResolution, YResolution and ImageWidth
   are legal.  The following table gives the legal combinations for
   inch-based resolutions and the corresponding paper sizes [T.30].

   +--------------------------------+---------------------------+
   |   XResolution x YResolution    |         ImageWidth        |
   +--------------------------------+---------------------------+
   |           100 x 100            |   864   |  1024  |  1216  |
   +--------------------------------+---------------------------+
   |           200 x 200            |  1728   |  2048  |  2432  |
   +--------------------------------+---------------------------+
   |           300 x 300            |  2592   |  3072  |  3648  |
   +--------------------------------+---------------------------+
   |           400 x 400            |  3456   |  4096  |  4864  |
   +--------------------------------+---------------------------+
                                    |Letter,A4|   B4   |   A3   |
                                    |  Legal  |        |        |
                                    +---------------------------+
                                    |         Paper Size        |
                                    +---------------------------+

6.2.2.  Extension Fields

   The JPEG compression standard allows for the a*b* chroma components
   of an image to be subsampled relative to the L* lightness component.
   The extension fields ChromaSubSampling and ChromaPositioning define
   the subsampling.  They are the same as YCbCrSubSampling and
   YCbCrPositioning in [TIFF] but have been renamed to reflect their
   applicability to other color spaces.







Buckley, et al.             Standards Track                    [Page 49]
^L
RFC 3949              File Format for Internet Fax         February 2005


   ChromaSubSampling(530).
   SHORT
      Count = 2
      Specifies the subsampling factors for the chroma components of a
      L*a*b* image.  The two subfields of this field,
      ChromaSubsampleHoriz and ChromaSubsampleVert, specify the
      horizontal and vertical subsampling factors respectively.

      SHORT 0: ChromaSubsampleHoriz = 1, 2.
      1: equal numbers of lightness and chroma samples horizontally,
      2: twice as many lightness samples as chroma samples horizontally,

      SHORT 1: ChromaSubsampleVert = 1, 2.
      1: equal numbers of lightness and chroma samples vertically,
      2: twice as many lightness samples as chroma samples vertically,

      The default value for ChromaSubSampling is (2,2), which is the
      default for chroma subsampling in color fax [T.4, Annex E].  No
      chroma subsampling, i.e., ChromaSubSampling = (1,1), is an option
      for color fax.

   ChromaPositioning(531) = 1.
   SHORT
      Specifies the spatial positioning of chroma components relative to
      the lightness component.
      1: centered, value of 1 means chrominance samples are spatially
      offset and centered with respect to luminance samples.  See the
      current TIFF specification under YcbCr positioning for further
      information.
      Default = 1, which is what ITU-T T.4, Annex E specifies.

6.2.3.  New Fields

   Decode(433).
   SRATIONAL
      Count = 2 * SamplesPerPixel
      Describes how to map image sample values into the range of values
      appropriate for the current color space.  In general, the values
      are taken in pairs and specify the minimum and maximum output
      value for each color component.  For the base color fax profile,
      Decode has a count of 6 values and maps the unsigned ITULAB-
      encoded sample values (Lsample, asample, bsample) to signed L*a*b*
      values, as follows:
         L* = Decode[0] + Lsample x (Decode[1]-Decode[0])/(2^n -1)
         a* = Decode[2] + asample x (Decode[3]-Decode[2])/(2^n -1)
         b* = Decode[4] + bsample x (Decode[5]-Decode[4])/(2^n -1)
      where Decode[0], Decode[2] and Decode[4] are the minimum values
      for L*, a*, and b*; Decode[1], Decode[3] and Decode[5] are the



Buckley, et al.             Standards Track                    [Page 50]
^L
RFC 3949              File Format for Internet Fax         February 2005


      maximum values for L*, a*, and b*; and n is the BitsPerSample.
      When n=8,=20  L*=Decode[0] when Lsample=0 and L*=Decode[1] when
      Lsample=255.

   ITU-T Rec. T.42 specifies the ITULAB encoding in terms of a range and
   offset for each component, which are related to the minimum and
   maximum values as follows:

      minimum = - (range x offset) / 2^n - 1
      maximum = minimum + range

   The Decode field default values depend on the color space.  For the
   ITULAB color space encoding, the default values correspond to the
   base range and offset, as specified in ITU-T Rec. T.42 [T.42].  The
   following table gives the base range and offset values for
   BitsPerSample=8, and the corresponding default minimum and maximum
   default values for the Decode field, calculated using the equations
   above when PhotometricInterpetation=10.

   Refer to ITU-T Rec. T.42 [T.42] to calculate the range and offset,
   and hence the minimum and maximum values, for other BitsPerSample
   values.

                      +-----------------------------------------------+
                      | ITU-T Rec. T.42  |           Decode           |
+---------+-----------|   base values    |       default values       |
| BitsPer + Component +------------------+----------------------------+
| -Sample |           |  Range | Offset  |      Min     |     Max     |
+---------+-----------+--------+---------+--------------+-------------+
|    8    |    L*     |   100  |    0    |       0      |     100     |
|         +-----------+--------+---------+--------------+-------------+
|         |    a*     |   170  |   128   |  -21760/255  |  21590/255  |
|         +-----------+--------+---------+--------------+-------------+
|         |    b*     |   200  |    96   |  -19200/255  |  31800/255  |
+---------+-----------+--------+---------+--------------+-------------+

   For example, when PhotometricInterpretation=10 and BitsPerSample=8,
   the default value for Decode is (0, 100, -21760/255, 21590/255,
   -19200/255, 31800/255).  For guidelines on the use of the Decode
   field, see section 5.2.2 of [GUIDE].











Buckley, et al.             Standards Track                    [Page 51]
^L
RFC 3949              File Format for Internet Fax         February 2005


6.3.  Recommended TIFF Fields

   See Sections 2.2.3. and 2.2.4.

6.4.  Profile C: Base Color Fax Profile Summary

   Recommended fields are shown with an asterisk (*).

   Required fields or values are shown with a double asterisk (**).  If
   the double asterisk is on the field name, then all the listed values
   are required of implementations; if the double asterisk is in the
   Values column, then only the values suffixed with a double asterisk
   are required of implementations.

   +---------------------------+--------------------------------+
   | Baseline Fields           | Values                         |
   +---------------------------+--------------------------------+
   | BitsPerSample             | 8**: 8 bits per color sample   |
   +---------------------------+--------------------------------+
   | Compression**             | 7: JPEG                        |
   +---------------------------+--------------------------------+
   | DateTime*                 | {ASCII}: date/time in 24-hour  |
   |                           | format "YYYY:MM:DD HH:MM:SS"   |
   +---------------------------+--------------------------------+
   | FillOrder**               | 1: most significant bit first  |
   |                           | 2: least significant bit first |
   +---------------------------+--------------------------------+
   | ImageDescription*         | {ASCII}: A string describing   |
   |                           | the contents of the image      |
   +---------------------------+--------------------------------+
   | ImageWidth                | 864, 1024, 1216, 1728**, 2048  |
   |                           | 2432, 2592, 3072, 3456, 3648   |
   |                           | 4096, 4864                     |
   +---------------------------+--------------------------------+
   | ImageLength**             | n: total number of scanlines   |
   |                           | in image                       |
   +---------------------------+--------------------------------+
   | NewSubFileType**          | 2: Bit 1 identifies single page|
   |                           | of a multi-page document       |
   +---------------------------+--------------------------------+
   | Orientation               | 1**-8, Default 1               |
   +---------------------------+--------------------------------+









Buckley, et al.             Standards Track                    [Page 52]
^L
RFC 3949              File Format for Internet Fax         February 2005


   +------------------------------------------------------------+
   | PhotometricInterpretation | 10**: ITULAB                   |
   +---------------------------+--------------------------------+
   | ResolutionUnit**          | 2: inch                        |
   +---------------------------+--------------------------------+
   | RowsPerStrip**            | n: number of scanlines per     |
   |                           | TIFF strip                     |
   +---------------------------+--------------------------------+
   | SamplesPerPixel           | 1**: L* (lightness)            |
   |                           | 3: LAB                         |
   +---------------------------+--------------------------------+
   | Software*                 | {ASCII}: name & release number |
   |                           | of creator software            |
   +---------------------------+--------------------------------+
   | StripByteCounts**         | <n>: number or bytes in        |
   |                           | TIFF strip                     |
   +---------------------------+--------------------------------+
   | StripOffsets**            | <n>: offset from beginning     |
   |                           | of file to each TIFF strip     |
   +---------------------------+--------------------------------+
   | XResolution               | 100, 200**, 300, 400 (written  |
   |                           | in pixels/inch)                |
   +---------------------------+--------------------------------+
   | YResolution               | 100, 200**, 300, 400           |
   |                           | (must equal XResolution)       |
   +---------------------------+--------------------------------+
   | Extension Fields                                           |
   +---------------------------+--------------------------------+
   | DocumentName*             | {ASCII}: name of scanned       |
   |                           | document                       |
   +---------------------------+--------------------------------+
   | PageNumber**              | n,m: page number followed by   |
   |                           | total page count               |
   +---------------------------+--------------------------------+
   | ChromaSubSampling         | (1,1), (2, 2)**                |
   |                           | (1, 1): equal numbers of       |
   |                           | lightness and chroma samples   |
   |                           | horizontally and vertically    |
   |                           | (2, 2): twice as many lightness|
   |                           | samples as chroma samples      |
   |                           | horizontally and vertically    |
   +---------------------------+--------------------------------+
   | ChromaPositioning         | 1**: centered                  |
   +------------------------------------------------------------+







Buckley, et al.             Standards Track                    [Page 53]
^L
RFC 3949              File Format for Internet Fax         February 2005


   +---------------------------+--------------------------------+
   | New Fields                                                 |
   +---------------------------+--------------------------------+
   | Decode**                  | minL, maxL, mina, maxa, minb,  |
   |                           | maxb: minimum and maximum      |
   |                           | values for L*a*b*              |
   +---------------------------+--------------------------------+
   | GlobalParametersIFD*      | IFD: IFD containing            |
   |                           | global parameters              |
   +---------------------------+--------------------------------+
   | ProfileType*              | n: type of data stored in      |
   |                           | TIFF file                      |
   +---------------------------+--------------------------------+
   | FaxProfile*               | n: ITU-compatible fax profile  |
   +---------------------------+--------------------------------+
   | CodingMethods*            | n: compression algorithms      |
   |                           | used in file                   |
   +---------------------------+--------------------------------+
   | VersionYear*              | byte sequence: year of ITU std |
   +---------------------------+--------------------------------+

7.  Profile L: Lossless Color Profile

   This section defines the lossless color profile of TIFF for
   facsimile, designated Profile L.  Implementations of this profile are
   required to also implement Profiles S and C as well.

7.1.  Overview

   This profile, specified in [T.43] and [T.4] Annex G, uses JBIG to
   code three types of color and grayscale images losslessly: one bit
   per color CMY, CMYK, and RGB images; a palettized (i.e., mapped)
   color image; and continuous tone color and grayscale images.  The
   last two are multi-level and use the L*a*b* encoding specified in
   [T.42].

7.1.1.  Color Encoding

   While under development, ITU-T Rec. T.43 was called T.Palette, as one
   of its major additions was palettized color images.  Baseline TIFF
   only allows RGB color maps, but ITU-T Rec. T.43 requires L*a*b* color
   maps, using the encoding specified in ITU-T Rec. T.42.  Palette color
   images are expressed with indices (bits per sample) of 12 bits or
   less, or optionally 13 to 16 bits, per [T.43] and Annex G in [T.4].
   Profile L files use the color table in the T.43 data stream rather
   than the TIFF ColorMap field.





Buckley, et al.             Standards Track                    [Page 54]
^L
RFC 3949              File Format for Internet Fax         February 2005


   Enabling T.43 color maps in TIFF requires the extension field
   Indexed, as defined in [TTN1], and the PhotometricInterpretation
   field value 10, as defined in Section 6.2.1.  The following table
   shows the corresponding PhotometricInterpretation, SamplesPerPixel,
   BitsPerSample, and Indexed field values for the different T.43 image
   types.

   +----------------------------------------------------------+
   | Image Type |PhotometricIn| Samples  | Bits Per | Indexed |
   |            |-terpretation| Per Pixel|  Sample  |         |
   |------------+-------------+----------+----------+---------|
   |     RGB    |    2=RGB    |     3    |    1     |    0    |
   +----------------------------------------------------------+
   |     CMY    |    5=CMYK   |     3    |    1     |    0    |
   +------------+-------------+----------+----------+---------+
   |     CMYK   |    5=CMYK   |     4    |    1     |    0    |
   +------------+-------------+----------+----------+---------+
   |   Palette  |  10=ITULAB  |     1    |    n     |    1    |
   +------------+-------------+----------+----------+---------+
   |  Grayscale |  10=ITULAB  |     1    |2-8, 9-12 |    0    |
   +------------+-------------+----------+----------+---------+
   |    Color   |  10=ITULAB  |     3    |2-8, 9-12 |    0    |
   +------------+-------------+----------+----------+---------+

7.1.2.  JBIG Compression

   T.43 uses the single-progression sequential mode of JBIG, defined in
   ITU-T Rec. T.82.  (Other compression methods are for further study.)
   To code multi-level images using JBIG, which is a bi-level
   compression method, an image is resolved into a set of bit-planes,
   and each bit-plane is then JBIG compressed.  For continuous-tone
   color and grayscale images, Gray code conversion is used.  The Gray
   code conversion is part of the data-stream encoding and is therefore
   invisible to TIFF.

7.2.  Required TIFF Fields

   This section lists the required fields, in addition to those in
   Section 2.2.1, and the values they must have to be compatible with
   ITU-T Rec. T.43.











Buckley, et al.             Standards Track                    [Page 55]
^L
RFC 3949              File Format for Internet Fax         February 2005


7.2.1.  Baseline Fields

   ImageWidth(256).
   SHORT or LONG
      Same page widths as the base color profile; see Section 6.2.1.
      NewSubFileType(254) = (Bit 1=1).
   LONG
      RequiredByTIFFforFAX
      Bit 1 is 1 if the image is a single page of a multi-page document.
      Default = 0 (no subfile bits on, so may not be omitted for fax).

   BitsPerSample(258) = 1, 2 - 8, 9 - 12.
   SHORT
      Count = SamplesPerPixel
      RGB, CMY, CMYK: 1 bit per sample
      Continuous tone (L*a*b*): 2 - 8 bits per sample, 9 - 12 bits
      optional.  Palette color: 12 or fewer bits per sample.
      Note: More than 8 bits per sample is not baseline TIFF.

   Compression(259) = 10.
   SHORT
      10: ITU-T Rec. T.43 representation, using ITU-T Rec. T.82 (JBIG)
      coding

   FillOrder(266) = 1 , 2.
   SHORT
      RequiredByTIFFBaseline
      Profile L readers must be able to read data in both bit orders,
      but the vast majority of facsimile products store data LSB
      first, exactly as it appears on the telephone line.
         1 = Most Significant Bit first.
         2 = Least Significant Bit first.

   PhotometricInterpretation(262) = 2, 5, 10.
   SHORT
      2: RGB
      5: CMYK, including CMY
      10: ITULAB
      Image data may also be stored as palette-color images, where pixel
      values are represented by a single component that is an index into
      a color map using the ITULAB encoding.  This color map is
      specified by the color palette table embedded in the image data
      stream.  To use palette-color images, set the
      PhotometricInterpretation to 10, SamplesPerPixel to 1, Indexed to
      1, and use the color map in the data stream.  See Section 7.1.1
      for discussion of the color encoding.





Buckley, et al.             Standards Track                    [Page 56]
^L
RFC 3949              File Format for Internet Fax         February 2005


   ResolutionUnit(296) = 2.
   SHORT
      The unit of measure for resolution. 2 = inch.
      ITU-T standards only specify inch-based resolutions for color fax.
      Default = 2 (field may be omitted if this is the value).

   SamplesPerPixel(277) = 1, 3, 4.
   SHORT
      1: Palette-color image, or L*-only if Indexed = 0 and
         PhotometricInterpretation is 10 (ITULAB).
      3: RGB, or L*a*b*, or CMY if PhotometricInterpretation is 5
      (CMYK).
      4: CMYK.

   XResolution(282) = 100, 200, 300, 400.
   RATIONAL
   YResolution(283) = 100, 200, 300, 400.
   RATIONAL
      The resolution of the image is expressed in pixels per resolution
      unit.  In pixels per inch, allowed XResolution values are 100,
      200, 300, and 400.  The lossless color fax profile requires the
      pixels to be square, hence YResolution must equal XResolution.
      Base resolution is 200 pixels per inch.

7.2.2.  Extension Fields

   Indexed(346) = 0, 1.
   SHORT
      0: not a palette-color image.
      1: palette-color image.
      This field is used to indicate that each sample value is an index
      into an array of color values specified in the image data stream.
      Because the color map is embedded in the image data stream, the
      ColorMap field is not used in Profile L.  Lossless color fax
      profile supports palette-color images with the ITULAB encoding.
      The SamplesPerPixel value must be 1.

7.2.3.  New Fields

   Decode(433)
   SRATIONAL
      Decode is used in connection with the ITULAB encoding of image
      data; see Section 6.2.3.

7.3.  Recommended TIFF Fields

   See Sections 2.2.3. and 2.2.4.




Buckley, et al.             Standards Track                    [Page 57]
^L
RFC 3949              File Format for Internet Fax         February 2005


7.4.  Profile L: Lossless Color Fax Profile Summary

   Recommended fields are shown with an asterisk (*).

   Required fields or values are shown with a double asterisk (**).  If
   the double asterisk is on the field name, then all the listed values
   are required of implementations; if the double asterisks are in the
   Values column, then only the values suffixed with a double asterisk
   are required of implementations.

   +--------------------+--------------------------------------+
   |   Baseline Fields  |             Values                   |
   +--------------------+--------------------------------------+
   | BitsPerSample      | 1: Binary RGB, CMY(K)                |
   |                    | 8**: 8 bits per color sample         |
   |                    | 9 - 12: optional                     |
   +--------------------+--------------------------------------+
   | Compression        | 10**: JBIG, per T.43                 |
   +--------------------+--------------------------------------+
   | DateTime*          | {ASCII}:  date/time in the 24-hour   |
   |                    | format "YYYY:MM:DD HH:MM:SS"         |
   +--------------------+--------------------------------------+
   | FillOrder**        | 1: Most significant bit first        |
   |                    | 2: Least significant bit first       |
   +--------------------+--------------------------------------+
   | ImageDescription*  | {ASCII}: A string describing the     |
   |                    | contents of the image                |
   +--------------------+--------------------------------------+
   | ImageWidth         | 864, 1024, 1216, 1728**, 2048, 2432, |
   |                    | 2592, 3072, 3456, 3648, 4096, 4864   |
   +--------------------+--------------------------------------+
   | ImageLength**      | n: total number of scanlines in image|
   +--------------------+--------------------------------------+
   | NewSubFileType     | 2**: Bit 1 identifies single page of |
   |                    | a multi-page document                |
   +--------------------+--------------------------------------+















Buckley, et al.             Standards Track                    [Page 58]
^L
RFC 3949              File Format for Internet Fax         February 2005


   +--------------------+--------------------------------------+
   | Orientation        | 1**-8, Default 1                     |
   +--------------------+--------------------------------------+
   | PhotometricInter-  | 2: RGB                               |
   | pretation          | 5: CMYK                              |
   |                    | 10**: ITULAB                         |
   +--------------------+--------------------------------------+
   | ResolutionUnit**   | 2: inch                              |
   +--------------------+--------------------------------------+
   | RowsPerStrip**     | n: number of scanlines per TIFF strip|
   +--------------------+--------------------------------------+
   | SamplesPerPixel    | 1**: L* (lightness)                  |
   |                    | 3: LAB, RGB, CMY                     |
   |                    | 4: CMYK                              |
   +--------------------+--------------------------------------+
   | Software*          | {ASCII}: name & release number of    |
   |                    | creator software                     |
   +--------------------+--------------------------------------+
   | StripByteCounts**  | <n>: number or bytes in TIFF strip   |
   +--------------------+--------------------------------------+
   | StripOffsets**     | <n>: offset from beginning of file to|
   |                    | each TIFF strip                      |
   +--------------------+--------------------------------------+
   | XResolution        | 100, 200**, 300, 400 (pixels/inch)   |
   +--------------------+--------------------------------------+
   | YResolution        | equal to XResolution (pixels must be |
   |                    | square)                              |
   +--------------------+--------------------------------------+
   | Extension Fields                                          |
   +--------------------+--------------------------------------+
   | DocumentName*      | {ASCII}: name of scanned document    |
   +--------------------+--------------------------------------+
   | PageNumber**       | n,m: page number followed by total   |
   |                    | page count                           |
   +--------------------+--------------------------------------+
   | Indexed            | 0: not a palette-color image         |
   |                    | 1: palette-color image               |
   +--------------------+--------------------------------------+
   | New Fields                                                |
   +--------------------+--------------------------------------|
   | Decode             | minL, maxL, mina, maxa, minb, maxb:  |
   |                    | minimum and maximum values for L*a*b*|
   +--------------------+--------------------------------------+
   | GlobalParameters   | IFD: global parameters IFD           |
   | IFD*               |                                      |
   +-----------------------------------------------------------+





Buckley, et al.             Standards Track                    [Page 59]
^L
RFC 3949              File Format for Internet Fax         February 2005


   +--------------------+--------------------------------------+
   | ProfileType*       | n: type of data stored in TIFF file  |
   +--------------------+--------------------------------------+
   | FaxProfile*        | n: ITU-compatible fax profile        |
   +--------------------+--------------------------------------+
   | CodingMethods*     | n: compression algorithms used in    |
   |                    | file                                 |
   +--------------------+--------------------------------------+
   | VersionYear*       | byte sequence: year of ITU fax std   |
   +--------------------+--------------------------------------+

8.  Profile M: Mixed Raster Content Profile

   This section defines the Mixed Raster Content profile of TIFF for
   facsimile, designated Profile M.  Implementations of this profile are
   required to implement Profiles S and C and may optionally implement
   Profiles F, J and L.

8.1.  Overview

   Unlike previous fax profiles, which use a single coding method and
   resolution for an entire fax page, Mixed Raster Content [T.44]
   enables different coding methods and resolutions within a single
   page.  For example, consider a page that contains black-and-white
   text, which is best coded with MMR or JBIG; a color bar chart, best
   coded with JBIG; and a scanned color image, best coded with JPEG.
   Similarly, although spatial resolution of 400 pixels per inch may be
   best for the black-and-white text, 200 pixels per inch is usually
   sufficient for a color image.

   Rather than applying one coding method and resolution to all
   elements, MRC allows multiple coders and resolutions within a page.
   By itself, MRC does not define any new coding methods or resolutions.
   Instead it defines a 3-layer image model for structuring and
   combining the scanned image data.  The MRC 3-layer model has been
   applied here with the TIFF format to yield a data structure that
   differs from [T.44], though it applies the same coding methods, uses
   the same compressed image data streams, and is consistent with the
   TIFF principle of a single IFD per image.

8.1.1.  MRC 3-layer model

   The 3 layers of the MRC model are Foreground and Background, which
   are both multi-level, and Mask, which is bi-level.  Each layer may
   appear only once on a page and is coded independently of the other
   two layers.  The final image is obtained by using the Mask layer to
   determine whether output pixels come from the Foreground layer or the
   Background layer.  When the Mask layer pixel value is 1, the



Buckley, et al.             Standards Track                    [Page 60]
^L
RFC 3949              File Format for Internet Fax         February 2005


   corresponding pixel from the Foreground layer is selected; when it is
   0, the corresponding pixel from the Background layer is selected.
   Details are given in the Introduction of [T.44].

   In our earlier example, the shape of the black-and-white text and the
   mask for the color chart could be in the Mask layer, the color of the
   chart and text in the Foreground layer, and the color image in the
   Background layer.  If a Mask layer pixel has a value of 1, the final
   image pixel will be, depending on the pixel location, from either the
   color chart or text color in the Foreground layer.  If a Mask layer
   pixel has a value of 0, the final image pixel will be from the color
   image in the Background layer.

   Each layer is an image and, when present, is represented by at least
   one IFD in a TIFF file.  This is consistent with TIFF, which provides
   fields to define the attributes, such as resolution, image size, bits
   per sample, etc., of a single image or layer.  The distribution of
   content among layers is determined by the writer, as is the choice of
   coding method, color encoding, and spatial resolution for a layer.

   Not all pages, and not all parts of a page, require 3 layers.  If a
   page has of only one layer, then that layer is the primary image
   whether it is a Background, Mask, or Foreground layer.  If there is
   more than one layer, then the Mask must be one of the layers, in
   which case it is the primary image.  In all cases, the primary image
   must be page size.

   MRC [T.44] allows a page to be transmitted as a series of stripes,
   each consisting of 1, 2 or 3 layers.  The number of scanlines in each
   stripe can vary over the page.  Although [T.44] does not allow
   overlap between images of a single layer, the MRC profile permits
   overlapping IFDs when one of the IFDs is used only to define a
   default image color.  According to [T.4] Annex H, stripes having more
   than 1 layer SHOULD NOT be more than 256 lines in length unless the
   capability to receive longer stripes has been negotiated.

   Furthermore, color fax also requires the spatial resolutions of
   Background and Foreground images to be legal fax values that are also
   integer factors of the Mask image resolution.  For example, if the
   Mask-Layer resolution is 400 pixels per inch, then allowable
   resolutions for the Foreground and Background layers are 100, 200, or
   400 pixels per inch; if the Mask is at 300 pixels per inch, then
   allowable values are 100 and 300.  The Foreground and Background
   layer resolutions can be set independently of each other.







Buckley, et al.             Standards Track                    [Page 61]
^L
RFC 3949              File Format for Internet Fax         February 2005


8.1.2.  A TIFF Representation for the MRC 3-layer model

   In the TIFF representation of the 3-layer MRC model, each page is
   represented by a single IFD, called the Primary IFD.  The nextIFD
   offset associated with a Primary IFD will point to the Primary IFD of
   the next page.  If the page consists of a single layer, then the
   Primary IFD represents that layer.  If more than one layer is
   present, the Primary IFD represents the Mask layer and the other
   layers are represented by a set of child IFDs that are referenced
   through the SubIFD extension field [TTN1] of the Primary IFD.  To
   distinguish MRC-specific SubIFDs from other SubIFDs, the
   NewSubFileType field MUST have Bit 4 ON, indicating an MRC-related
   IFD.  A new ImageLayer field is also introduced that consists of two
   values that identify the layer (Foreground, Background, or Mask) and
   the order within the layer (first, second, ... image of the layer);
   see Section 8.2.3.

   In Profile M, the Primary IFD represents a complete layer and
   corresponds to the primary image described in Section 8.1.1.  There
   must be no other MRC-related IFDs or SubIFDs that contain image data
   corresponding to the layer represented by the Primary IFD.

   MRC [T.44] allows a page to be transmitted as a series of stripes.  A
   strip within an IFD in a Profile M file represents a stripe in a
   [T.44] data stream.  The [T.44] stripes of the Primary image are
   represented by a single, multiple-strip IFD; the [T.44] stripes of
   other layers are represented as multiple, single-strip IFDs.

   The layer represented by the Primary IFD may consist of strips of
   image data, but all the strips must be part of the single Primary
   IFD.  For example, if the page consisted of only the Background
   layer, then all strips associated with the Background layer must be
   treated as a single image.  Because MRC allows stripes with variable
   numbers of scanlines, a reader MUST support StripRowCounts field, as
   a writer may use it in place of the RowsPerStrip field to support a
   variable number of scanlines in each strip of the Primary IFD.  In
   accordance with [TTN2], each strip shall be independently encoded,
   but coding parameters may not change between strips.

   Layers other than the layer represented by the Primary IFD store each
   strip as a separate IFD, allowing the coding parameters to change
   from strip to strip as described by the MRC standard [T.44].  In all
   cases, if the Mask layer exists, it shall be represented by a single
   IFD and a single set of coding parameters.

   The use of SubIFDs to store child IFDs is described in [TTN1].  When
   the Mask is the primary image, the Background and Foreground layer
   images are represented with child IFDs referenced by the SubIFDs



Buckley, et al.             Standards Track                    [Page 62]
^L
RFC 3949              File Format for Internet Fax         February 2005


   field in the Primary IFD.  There are multiple ways to organize the
   images of the Background and Foreground layer images:  (1) the SubIFD
   field of the Primary IFD is an array of pointers to all child image
   IFDs, one entry per child image; (2) the SubIFD field is a single
   pointer to a linked list of all child image IFDs; (3) the SubIFD
   field is an array of two pointers, where the first pointer is to a
   linked list of all Background layer image IFDs, and the second
   pointer is to a linked list of all Foreground layer image IFDs.  A
   Profile M writer SHOULD structure the Background and Foreground layer
   images by using (3), as shown in the example below.  Furthermore, the
   child IFDs representing the images of the Background and Foreground
   layers SHOULD be ordered in the file in the same order as they occur
   on the page.  However, a Profile M reader must scan all available
   child IFDs to locate and identify IFDs associated with MRC layers.

                             (nextIFD)
PRIMARY IFD PAGE 0  -----------------------> PRIMARY IFD PAGE 1--> ...
          ImageLayer = [2,1]
          NewSubFileType = 18
          SubIFD[0] ---------------------- SubIFD[1]
               |                                |
               V                                V
            Child IFD                        Child IFD
               ImageLayer = [1,1]               ImageLayer [3,1]
               NewSubFileType = 16              NewSubFileType 16
               |                                |
               |(nextIFD)                       |(nextIFD)
               V                                V
            Child IFD                        Child IFD
               ImageLayer = [1,2]               ImageLayer [3,2]
               NewSubFileType = 16              NewSubFileType 16
               |                                |
               |(nextIFD)                       |(nextIFD)
               V                                V
            Child IFD                        Child IFD
               ImageLayer = [1,3]               ImageLayer [3,3]
               NewSubFileType = 16              NewSubFileType 16
               |                                |
               |(nextIFD)                       |(nextIFD)
               V                                V
               0                                0

   The XPosition and YPosition TIFF fields specify the offset to the
   upper left corner of the IFD in resolution units, which are inches in
   Profile M; see Section 8.2.2.  The Primary IFD must not use XPosition
   or YPosition fields.





Buckley, et al.             Standards Track                    [Page 63]
^L
RFC 3949              File Format for Internet Fax         February 2005


   MRC [T.44] allows the specification of a default image color that is
   to be applied in the event no image data is transmitted for a given
   stripe and layer.  The new field ImageBaseColor is used to store
   default image color specifications in Profile M, see 8.2.3.  By
   setting the StripByteCounts array to zero values, an IFD defining a
   default color but containing no encoded image data can be specified.
   ImageBaseColor can also be used in IFDs that contain encoded image
   data.  In that case, the fields of the IFD must accurately reflect
   the encoding of the image data.  If the StripByteCount entry for a
   given strip is 0, then the ImageBaseColor is used for that strip.  If
   the encoded image data is ITU L*a*b, the ImageBaseColor is
   interpreted with the encoding parameters of the image data.  If the
   image data is not ITU L*a*b*, the ImageBaseColor is interpreted as
   8-bit ITU L*a*b*; see Section 8.2.3.

8.2.  Required TIFF Fields

   This section describes the TIFF fields required, in addition to those
   in Section 2.2.1, to represent MRC fax images.  Since MRC stores fax
   data as a collection of images corresponding to layers or parts of
   layers, the coding methods, color encodings, and spatial resolutions
   used by previous profiles apply to Profile M.  Therefore, the
   descriptions here will typically reference the appropriate earlier
   sections.  Fields and values specific to Profile M are pointed out.

8.2.1.  Baseline Fields

   ImageWidth(256).
   SHORT or LONG
      Same page widths as Profile C, the base color profile; see Section
      6.2.1.  In Profile M, the width of a Foreground or Background
      image in the coded data stream may be less than the page width,
      unless the Background or Foreground is the primary image, in which
      case the width of the coded data stream is the page width.  The
      ImageWidth field will always store the actual width of the coded
      data.

   NewSubFileType(254) = 16, 18.
   LONG
      For Profile M, the NewSubFileType field has two bits that are
      required.  Bit 1 indicates a single page of a multi-page document
      and must be set for the Primary IFD; Bit 4 indicates the MRC
      imaging model as described in ITU-T Recommendation T.44 [T.44] and
      must be set for Primary IFDs and all MRC-specific child IFDs.







Buckley, et al.             Standards Track                    [Page 64]
^L
RFC 3949              File Format for Internet Fax         February 2005


   BitsPerSample(258) = 1, 2-8, 9-12
   SHORT
   SamplesPerPixel(277) = 1, 3, 4.
   SHORT
   Compression(259) = 1, 3, 4, 7, 9, 10.
   SHORT
      For Mask layer, see Sections 4.2.1 and 5.2.1.  For Foreground and
      Background layers, see Sections 6.2.1 and 7.2.1 Compression=1 is
      not used by previous profiles.  An IFD used only to specify the
      default image color for a layer and strip will not have any
      encoded image data associated with it, i.e., the StripByteCounts
      field will contain a 0.  Since no image data exists in the IFD,
      the Compression field shall be set to 1, indicating no
      compression.  A Compression field value of 1 is not allowed for
      any other IFDs.

   FillOrder(266) = 1 , 2.
   SHORT
   RequiredByTIFFBaseline
      Profile M readers must be able to read data in both bit orders,
      but the vast majority of facsimile products store data LSB first,
      exactly as it appears on the telephone line
         1 = Most Significant Bit first.
         2 = Least Significant Bit first.

   PhotometricInterpretation(262) = 0, 2, 10.
   SHORT
      For Mask layer, 0.  For Foreground and Background layers, see
      Sections 6.2.1 and 7.2.1.

   ResolutionUnit(296) = 2.
   SHORT
      The unit of measure for resolution. 2 = inch.
      ITU-T standards only specify inch-based resolutions for color fax
      Default = 2 (field may be omitted if this is the value).

   StripByteCounts(279)
   SHORT or LONG
      In Profile M, it is permissible for the StripByteCounts value for
      a given strip to have a zero entry.  This means there is no
      encoded image data corresponding to that strip.  Instead, the
      current default image color should be used for the strip.  The
      standard default image colors are black for the Foreground layer
      and White for the Background layer.  The ImageBaseColor field can
      be used to specify other default colors; see Section 8.2.3.






Buckley, et al.             Standards Track                    [Page 65]
^L
RFC 3949              File Format for Internet Fax         February 2005


   XResolution(282) = 100, 200, 300, 400.
   RATIONAL
   YResolution(283) = 100, 200, 300, 400.
   RATIONAL
      The resolution of the image is expressed in pixels per resolution
      unit.  In pixels per inch, allowed XResolution values for all
      layers are 100, 200, 300, and 400.  Color fax requires the pixels
      to be square, hence YResolution must equal XResolution for all
      layers.  The resolution of Background and Foreground layers must
      each be an integer factor of the Primary image, which is the Mask
      layer, when it is present; see Section 8.4.

8.2.2.  Extension Fields

   ChromaSubSampling(530).
   SHORT
   ChromaPositioning(531).
   SHORT
      For Foreground and Background layers, see Section 6.2.2.

   Indexed(346) = 0, 1.
   SHORT
      For Foreground and Background layers: 1 indicates a palette-color
      image; see Section 7.2.2.

   T4Options(292) = 0, 1, 4, 5.
   SHORT
   T6Options(293) = 0.
   SHORT
      For Mask layer, see Section 4.2.2.

   SubIFDs(330).
   IFD
      Count = number of child IFDs.  Each value is an offset from the
      beginning of the TIFF file to a child IFD [TTN1].

   XPosition(286).
   RATIONAL
   YPosition(287).
   RATIONAL
      Specifies the horizontal and vertical offsets of the top left of
      the IFD from the top left of the Primary IFD in resolution units.
      For example, if the Primary IFD is at 400 pixels per inch, and a
      foreground layer IFD is at 200 pixels per inch and located at
      pixel coordinate (345, 678) with respect to the Primary IFD, the
      XPosition value is 345/400 and the YPosition value is 678/400 in
      inches.




Buckley, et al.             Standards Track                    [Page 66]
^L
RFC 3949              File Format for Internet Fax         February 2005


      The Primary IFD does not use the XPosition or YPosition fields.
      The XPosition and YPosition values must be specified for MRC child
      IFDs; there is no default value.

8.2.3.  New Fields

   Decode(433).
   SRATIONAL
      For Foreground and Background layers, see Section 6.2.3.

   T82Options(435)
   LONG
      For Mask layer, see Section 5.2.3.

   ImageBaseColor(434).
   SHORT
      Count = SamplesPerPixel

   In areas of an image layer where no image data is available (i.e.,
   where no strips are defined, or where the StripByteCounts entry for
   a given strip is 0), the color specified by ImageBaseColor will be
   used.

   If the ImageBaseColor field is used in an IFD that contains image
   data encoded in ITU L*a*b*, then the ImageBaseColor will be
   interpreted with the color-encoding parameters of the image data
   (i.e., color gamut, illuminant, bit/sample, and decode).  If the
   ImageBaseColor field is used in an IFD that contains image data that
   is not encoded in ITU L*a*b, then the ImageBaseColor SHALL be
   interpreted as 8 bits/sample, 3 samples/pixel ITU L*a*b*.  If the
   ImageBaseColor field is used in an IFD that contains no encoded
   image data, then the ImageBaseColor SHALL be interpreted as 8
   bits/sample, 3 samples/pixel ITU L*a*b*.  If the fax data stream
   requires a different encoding, then transferring the default color
   value between a TIFF file and fax data stream requires a color
   conversion.

   A [T.44] stripe may contain a Foreground or Background image less
   than full stripe size, with the rest of the stripe assuming a
   default image color.  In this case, the default image color is imaged
   first, followed by the image data.  In Profile M, this is represented
   as a child IFD containing no encoded image data but specifying the
   default image color in the ImageBaseColor field.  A second child IFD
   contains the image data.  To ensure the default image color is imaged
   first, the order value in the ImageLayer field of the IFD defining
   the ImageBaseColor field MUST have a lower value than the order
   value in the ImageLayer field of the IFD defining the image data.




Buckley, et al.             Standards Track                    [Page 67]
^L
RFC 3949              File Format for Internet Fax         February 2005


   To define a child IFD specifying a ImageBaseColor but containing no
   encoded image data, create an IFD with the following settings.

      ImageLayer[0]:             specified layer
      ImageLayer[1]:             less than any other IFDs corresponding
                                 to the same layer and strip.
      RowsPerStrip:              strip height
      ImageLength:               strip height
      ImageWidth:                full image width
      BitsPerSample:             8
      PhotometricInterpretation: 10 (ITULAB)
      SamplesPerPixel:           3
      Compression:               1 (none)
      X/YResolution:             that of the Primary IFD
      XPosition:                 0
      YPosition:                 the offset from the top of the page to
                                 the beginning of the strip in the
                                 resolution units of inches
      StripByteCounts:           single 0 value
      StripOffsets:              single 0 entry
      NewSubFileType:            bit 4 O     (MRC)
      ImageBaseColor:            desired color in 8 bit ITULAB

   For the Foreground layer image, the default value for the
   ImageBaseColor field is black.  For other cases, including the
   Background layer image, the default value is white.

   StripRowCounts(559).
   LONG
      Count = number of strips.
      The number of scanlines stored in a strip.  Profile M allows each
      fax strip to store a different number of scanlines.  For strips
      with more than one layer, the maximum strip size is either 256
      scanlines or full page size.  The 256 maximum SHOULD be used
      unless the capability to receive longer strips has been
      negotiated.  This field replaces RowsPerStrip for IFDs with
      variable-size strips.  Only one of the two fields, StripRowCounts
      and RowsPerStrip, may be used in an IFD.

   ImageLayer (34732).
   LONG
      Count = 2.
      Image layers are defined such that layer 1 is the Background
      layer, layer 3 is the Foreground layer, and layer 2 is the Mask
      layer, which selects pixels from the Background and Foreground
      layers.  The ImageLayer tag contains two values, which describe
      the layer to which the image belongs and the order in which it is
      imaged.



Buckley, et al.             Standards Track                    [Page 68]
^L
RFC 3949              File Format for Internet Fax         February 2005


      ImageLayer[0] = 1, 2, 3.
      1: Image is a Background image, i.e., the image that will appear
         whenever the Mask contains a value of 0.  Background images
         typically contain low-resolution, continuous-tone imagery.
      2: Image is the Mask layer.  In MRC, if the Mask layer is present,
         it must be the Primary IFD and be full page in extent.
      3: Image is a Foreground image, i.e., the image that will appear
         whenever the Mask contains a value of 1.  The Foreground image
         generally defines the color of text or lines but may also
         contain high-resolution imagery.

      ImageLayer[1]:
      1: first image to be imaged in this layer
      2: second image to be imaged in this layer
      3: ...

      In Profile M, more than one image can exist in a single layer.
      ImageLayer[1] specifies the order in which images within a single
      layer are to be imaged.  This insures that overlapping images
      within a single layer are imaged correctly.

      If an IFD contains no encoded image data and is used only to
      specify the ImageBaseColor field, the value of ImageLayer[1] must
      be less than that of any other IFD corresponding to the same layer
      and strip to ensure the image data is interpreted as on top of the
      default color.

      In Profile M, it is possible to have only a single layer.  For
      example, if a page contains only a single continuous-tone
      photograph, then only the Background layer would occur.  In this
      case, the Background layer will be stored as the Primary IFD.
      ImageLayer[0] will be 1, indicating Background; ImageLayer[1] will
      be 1, as there can be no other IFDs associated with that layer.
      No Mask layer will exist.

8.3.  Recommended TIFF Fields

   See Sections 2.2.3. and 2.2.4.

8.4.  Rules and Requirements for Images

   Profile M defines a fundamental set of rules for images in the 3
   layer representation.








Buckley, et al.             Standards Track                    [Page 69]
^L
RFC 3949              File Format for Internet Fax         February 2005


   1. If more than one layer exists, then the binary Mask layer SHALL be
      present and be the primary image.  The Mask layer SHALL support
      the binary data representations defined in Section 3 and MAY
      support those defined in Sections 4 and 5, with the exception that
      PhotometricInterpretation MUST be 0.  If only one layer exists,
      then the image corresponding to that layer is the primary image.

   2. The Primary IFD defines and extends to the entire page boundary;
      all attached model images cannot extend beyond the Primary image.
      Resolution differences may cause some pixels to "hang over" the
      page boundary, but no new pixels should exist completely beyond
      the page extent.

   3. The Background and Foreground images SHALL support the color
      representations defined in Section 6 and MAY support those defined
      in Section 7.  These images MAY optionally cover only a portion of
      the strip or page.

   4. Each Primary IFD and each MRC-specific SubIFD must have an
      ImageLayer field to specify which layer the IFD belongs to, and
      the imaging order of that IFD within the layer.

   5. Each Primary IFD must have a NewSubFileType field value set to 18,
      indicating a single page of a multi-page document (bit 1) and MRC
      (bit 4).

   6. Each MRC-specific child IFD must have a NewSubFileType field value
      set to 16, indicating MRC (bit 4).

   7. In MRC fax, each layer is transmitted as a sequence of strips.  If
      the page consists of a single layer, then all strips shall be
      stored in the single Primary IFD.  In this case, coding parameters
      cannot change between strips.  If the page consists of more than
      one layer, then all strips of the Mask layer shall be stored in
      the single Primary IFD.  All strips of the Foreground/Background
      layers SHALL be stored in separate IFDs, referenced by the Primary
      IFD's SubIFD field, containing an ImageLayer field with
      ImageLayer[0] identifying either Background (layer 1) or
      Foreground (layer 3), and Imagelayer[1] identifying order in which
      images within a single layer are to be imaged.  The TIFF XPosition
      and YPosition fields are used to indicate the placement of these
      images with respect to the primary image.

   8. When the Mask image is present, the resolution of Background and
      Foreground images must each be an integer factor of the Mask
      image.  For example, if the Mask image is 400 pixels/inch, then
      the Background or Foreground image may be at 400 pixels/inch
      (400/1), 200 pixels/inch (400/2), or 100 pixels/inch (400/4).



Buckley, et al.             Standards Track                    [Page 70]
^L
RFC 3949              File Format for Internet Fax         February 2005


8.5.  Profile M: MRC Fax Profile Summary

   Recommended fields are shown with an asterisk (*).

   Required fields or values are shown with a double asterisk (**).  If
   the double asterisk is on the field name, then all the listed values
   are required of implementations; if the double asterisk is in the
   Values column, then only the values suffixed with a double asterisk
   are required of implementations.

   +------------------+-----------------------------------------+
   | Baseline Fields  |               Values                    |
   +------------------+-----------------------------------------+
   | BitsPerSample    | 1**: binary mask, RGB, CMY(K)           |
   |                  | 2 - 8**: bits per color sample          |
   |                  | 9 - 12: optional 12 bits/sample         |
   +------------------+-----------------------------------------+
   | Compression      | 1: None (ImageBaseColor IFD only)       |
   |                  | 3**: Modified Huffman and Modified READ |
   |                  | 4: Modified Modified READ               |
   |                  | 7**: JPEG                               |
   |                  | 9: JBIG, per T.85                       |
   |                  | 10: JBIG, per T.43                      |
   +------------------+-----------------------------------------+
   | DateTime*        | {ASCII): date/time in the 24-hour format|
   |                  | "YYYY:MM:DD HH:MM:SS"                   |
   +------------------+-----------------------------------------+
   | FillOrder**      | 1: Most significant bit first           |
   |                  | 2: Least significant bit first          |
   +------------------+-----------------------------------------+
   | ImageDescription*| {ASCII}: A string describing the        |
   |                  | contents of the image.                  |
   +------------------+-----------------------------------------+
   | ImageWidth       | 864, 1024, 1216, 1728**, 2048, 2432,    |
   |                  | 2592, 3072, 3456, 3648, 4096, 4864      |
   |                  | Note: legal widths for the Primary IFD. |
   +------------------+-----------------------------------------+
   | ImageLength**    | n: total number of scanlines in image   |
   +------------------+-----------------------------------------+
   | NewSubFileType** | 16, 18:                                 |
   |                  | Bit 1 indicates single page of a multi- |
   |                  | page document on Primary IFD            |
   |                  | Bit 4 indicates MRC model               |
   +------------------+-----------------------------------------+







Buckley, et al.             Standards Track                    [Page 71]
^L
RFC 3949              File Format for Internet Fax         February 2005


   +------------------+-----------------------------------------+
   | Orientation      | 1**-8, Default 1                        |
   +------------------+-----------------------------------------+
   | PhotometricInter | 0**:  WhiteIsZero  (Mask Layer)         |
   | pretation        | 2:  RGB                                 |
   |                  | 10**: ITULAB                            |
   +------------------+-----------------------------------------+
   | ResolutionUnit** | 2: inch                                 |
   +------------------+-----------------------------------------+
   | RowsPerStrip     | n: number or scanlines per strip        |
   +------------------+-----------------------------------------+
   | SamplesPerPixel  | 1**: L* (lightness)                     |
   |                  | 3: RGB, LAB, CMY                        |
   |                  | 4: CMYK                                 |
   +------------------+-----------------------------------------+
   | Software*        | {ASCII}: name & release number of       |
   |                  | creator software                        |
   +------------------+-----------------------------------------+
   | StripByteCounts**| <n>: number or bytes in each strip      |
   +------------------+-----------------------------------------+
   | StripOffsets**   | <n>: offset from beginning of file to   |
   |                  | each TIFF strip                         |
   +------------------+-----------------------------------------+
   | XResolution      | 100, 200**, 300, 400 (written in        |
   |                  | pixels/inch)                            |
   +------------------+-----------------------------------------+
   | YResolution      | equal to XResolution (pixels must be    |
   |                  | square)                                 |
   +------------------+-----------------------------------------+
   | Extension Fields                                           |
   +------------------+-----------------------------------------+
   | T4Options        | 0**: required if Compression is Modified|
   |                  | Huffman, EOLs not byte aligned          |
   |                  | 1: required if Compression 2D Modified  |
   |                  | READ, EOLs are not byte aligned         |
   |                  | 4**: required if Compression Modified   |
   |                  | Huffman, EOLs byte aligned              |
   |                  | 5: required if Compression 2D Modified  |
   |                  | READ, EOLs are byte aligned             |
   +------------------+-----------------------------------------+
   | T6Options        | 0: required if Compression is 2D        |
   |                  | Modified Modified READ                  |
   +------------------+-----------------------------------------+
   | DocumentName*    | {ASCII}: name of scanned document       |
   +------------------+-----------------------------------------+
   | PageNumber**     | n,m: page number followed by total page |
   |                  | count                                   |
   +------------------+-----------------------------------------+



Buckley, et al.             Standards Track                    [Page 72]
^L
RFC 3949              File Format for Internet Fax         February 2005


   +------------------+-----------------------------------------+
   | ChromaSubSampling| (1,1), (2, 2)**                         |
   |                  | (1, 1): equal numbers of lightness and  |
   |                  | chroma samples horizontally & vertically|
   |                  | (2, 2): twice as many lightness samples |
   |                  | as chroma horizontally and vertically   |
   +------------------+-----------------------------------------+
   | ChromaPositioning| 1: centered                             |
   +------------------+-----------------------------------------+
   | Indexed          | 0: not a palette-color image            |
   |                  | 1: palette-color image                  |
   +------------------+-----------------------------------------+
   | SubIFDs          | <IFD>: byte offset to FG/BG IFDs        |
   +------------------+-----------------------------------------+
   | XPosition        | horizontal offset in primary IFD        |
   |                  | resolution units                        |
   +------------------+-----------------------------------------+
   | YPosition        | vertical offset in primary IFD          |
   |                  | resolution units                        |
   +------------------+-----------------------------------------+
   | New Fields                                                 |
   +------------------+-----------------------------------------+
   | Decode           | minL, maxL, mina, maxa, minb, maxb:     |
   |                  | minimum and maximum values for L*a*b*   |
   +------------------+-----------------------------------------+
   | ImageBaseColor   | a,b,c: background color in ITULAB       |
   +------------------+-----------------------------------------+
   | StripRowCounts   | <n>: number of scanlines in each strip  |
   +------------------+-----------------------------------------+
   | ImageLayer       | n, m: layer number, imaging sequence    |
   |                  | (e.g., strip number)                    |
   +------------------+-----------------------------------------+
   | T82Options       | 0: T.85 profile of T.82 coding          |
   +------------------+-----------------------------------------+
   | GlobalParameters | IFD: global parameters IFD              |
   | IFD*             |                                         |
   +------------------+-----------------------------------------+
   | ProfileType*     | n: type of data stored in TIFF file     |
   +------------------+-----------------------------------------+
   | FaxProfile*      | n: ITU-compatible fax profile           |
   +------------------+-----------------------------------------+
   | CodingMethods*   | n: compression algorithms used in file  |
   +------------------+-----------------------------------------+
   | ModeNumber*      | n: version of T.44 standard             |
   +------------------+-----------------------------------------+
   | VersionYear*     | byte sequence: year of ITU fax standard |
   +------------------+-----------------------------------------+




Buckley, et al.             Standards Track                    [Page 73]
^L
RFC 3949              File Format for Internet Fax         February 2005


9.  MIME content-types image/tiff and image/tiff-fx

   The MIME content-types image/tiff and image/tiff-fx are used for
   TIFF-FX encoded image data, as defined in this document.  [TIFF-REG]
   and [TIFF-FX-REG] describe the registration of these MIME content-
   types.

10.  Security Considerations

   This document describes a file format for Internet fax, which is a
   series of profiles of TIFF for facsimile.  As such, it does not
   create any security issues not already identified in [TIFF-REG], in
   its use of fields as defined in [TIFF].  There are also new TIFF
   fields defined within this specification, but they are of a purely
   descriptive nature, so no new security risks are incurred.

   Further, the encoding specified in this document does not in any way
   preclude the use of any Internet security protocol to encrypt,
   authenticate, or non-repudiate TIFF-encoded facsimile messages.

11.  References

11.1.  Normative References

   [REQ]         Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

   [T.4]         ITU-T Recommendation T.4, Standardization of group 3
                 facsimile apparatus for document transmission, October
                 1997.

   [T.6]         ITU-T Recommendation T.6, Facsimile coding schemes and
                 coding control functions for group 4 facsimile
                 apparatus, November 1988

   [T.30]        ITU-T Recommendation T.30 - Procedures for Document
                 Facsimile Transmission in the General Switched
                 Telephone Network, June 1996

   [T.42]        ITU-T Recommendation T.42, Continuous-tone colour
                 representation method for facsimile, February 1996

   [T.43]        ITU-T Recommendation T.43, Colour and gray-scale image
                 representations using lossless coding scheme for
                 facsimile, February 1997

   [T.44]        ITU-T Recommendation T.44, Mixed Raster Content (MRC),
                 April 1999.



Buckley, et al.             Standards Track                    [Page 74]
^L
RFC 3949              File Format for Internet Fax         February 2005


   [T.81]        ITU-T Recommendation T.81, Information technology -
                 Digital compression and coding of continuous-tone still
                 images - Requirements and guidelines, September 1992

   [T.85]        ITU-T Recommendation T.85, Application profile for
                 Recommendation T.82 - Progressive bi-level image
                 compression (JBIG coding scheme) for facsimile
                 apparatus, August 1995

   [T.82]        ITU-T Recommendation T.82, Information technology -
                 Coded representation of picture and audio information -
                 Progressive bi-level image compression, March 1995

   [TIFF]        Tag Image File Format, Revision 6.0, Adobe Developers
                 Association, June 3, 1992,
                 http://partners.adobe.com/public/developers/en/tiff/
                 TIFF6.pdf

                 The TIFF 6.0 specification dated June 3, 1992
                 specification (c) 1986-1988, 1992 Adobe Systems
                 Incorporated. All Rights Reserved.

   [TIFF-F0]     TIFF Class F specification, Apr 28, 1990,
                 ftp://ftp.faximum.com/pub/documents/tiff_f.txt

   [TIFF-REG]    Parsons, G. and J. Rafferty, "Tag Image File Format
                 (TIFF) - image/tiff MIME Sub-type Registration", RFC
                 3302, September 2002.

   [TTN1]        Adobe PageMaker 6.0 TIFF Technical Notes, Sept. 14,
                 1995,
                 http://partners.adobe.com/public/developers/en/tiff/
                 TIFFPM6.pdf

   [TTN2]        Draft TIFF Technical Note 2, Replacement TIFF/JPEG
                 specification, March 17, 1995,
                 ftp://ftp.uu.net/graphics/jpeg/

   [TIFF-FX-REG] McIntyre, L., Parsons, G., and J. Rafferty, "Tag Image
                 File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME
                 Sub-type Registration", RFC 3250, September 2002.










Buckley, et al.             Standards Track                    [Page 75]
^L
RFC 3949              File Format for Internet Fax         February 2005


11.2.  Informative References

   [GUIDE]       Cancio, V., Moldovan, M., Tamura, H., and D. Wing,
                 "Implementers Guide for Facsimile Using Internet Mail",
                 RFC 3249, September 2002.

   [TIFF-F]      Parsons, G. and J. Rafferty, "Tag Image File Format
                 (TIFF) - F Profile for Facsimile", RFC 2306, March
                 1998.

   [VPIM 2]      Vaudreuil G. and G. Parsons, "Voice Profile for
                 Internet Mail - version 2 (VPIMv2)", RFC 3801, June
                 2004.






































Buckley, et al.             Standards Track                    [Page 76]
^L
RFC 3949              File Format for Internet Fax         February 2005


Annex A:  Summary of TIFF Fields for Internet Fax

   This annex includes tables which list by profile the TIFF fields used
   in the proposed fax file format.  The fields are organized into 3
   categories:

      1)  TIFF Baseline Fields
      2)  TIFF Extension Fields
      3)  New Fields.

   The tables include the allowed values for each fax profile.  Entries
   other than explicit numbers are described by:

      n        - single number
      n, m     - 2 numbers
      a, b, c  - 3 numbers
      r        - rational number
      <n>      - array of numbers
      <b>      - byte sequence
      {ASCII}  - string
      IFD      - IFD byte offset
      <IFD>    - array of IFD byte offsets

   A blank entry in the table indicates that the field is not used by
   that particular fax profile.

   Table A.1  TIFF Baseline Fields

           +---------------------------------------------------------+
           |                       Fax Profile                       |
           +---------------------------------------------------------|
           | Minimal | Extended |  JBIG  |  Lossy  |Lossless| Mixed  |
+----------|   B&W   |    B&W   |  B&W   |  Color  | Color  | Raster |
|   TIFF   |         |          |        |         |        | Content|
|  Field   |    S    |     F    |   J    |    C    |   L    |   M    |
+----------+---------+----------+--------+---------+--------+--------+
| BitsPer  | 1       | 1        | 1      | 8       | 1, 2-8 | 1, 2-8 |
| Sample   |         |          |        |         | 9-12   | 9-12   |
+----------+---------+----------+--------+---------+--------+--------+
| Compres- | 3       | 3, 4     | 9      | 7       | 10     | 3, 4, 7|
| sion     |         |          |        |         |        | 9,10   |
+----------+---------+----------+--------+---------+--------+--------+
| DateTime |         | {ASCII}  | {ASCII}| {ASCII} | {ASCII}| {ASCII}|
+----------+---------+----------+--------+---------+--------+--------+
| FillOrder| 2       | 1, 2     | 1, 2   | 1, 2    | 1, 2   | 1,2    |
+----------+---------+----------+--------+---------+--------+--------+





Buckley, et al.             Standards Track                    [Page 77]
^L
RFC 3949              File Format for Internet Fax         February 2005


+----------+---------+----------+--------+---------+--------+--------+
| ImageDes-|         | {ASCII}  | {ASCII}| {ASCII} | {ASCII}| {ASCII}|
| cription |         |          |        |         |        |        |
+----------+---------+----------+--------+---------+--------+--------+
| Image-   | n       | n        | n      | n       | n      | n      |
| Length   |         |          |        |         |        |        |
+----------+---------+----------+--------+---------+--------+--------+
| Image-   | 1728    | 1728, 2048, 2432  |   864, 1024, 1216, 1728,  |
| Width    |         | 2592, 3072, 3456  |  2048, 2432, 2592, 3072,  |
|          |         | 3648, 4096, 4864  |  3456, 3648, 4096, 4864   |
|          |         | Note, for the Mixed Raster Content M profile  |
|          |         | these widths apply to the Primary IFD.        |
+----------+---------+----------+--------+---------+--------+--------+
| NewSub-  | 2       | 2        | 2      | 2       | 2      | 16, 18 |
| FileType |         |          |        |         |        |        |
+----------+---------+----------+--------+---------+--------+--------+
| Orien-   | 1       | 1-8      | 1-8    | 1-8     | 1-8    | 1-8    |
| tation   |         |          |        |         |        |        |
+----------+---------+----------+--------+---------+--------+--------+
| Photo-   | 0       | 0, 1     | 0, 1   | 10      | 2, 5,  | 0,     |
| metric-  |         |          |        |         | 10     | 2,     |
| Interp-  |         |          |        |         |        | 10     |
| retation |         |          |        |         |        |        |
+----------+---------+----------+--------+---------+--------+--------+
| Resolu-  | 2       | 2, 3     | 2, 3   | 2, 3    | 2, 3   | 2, 3   |
| tionUnit |         |          |        |         |        |        |
+----------+---------+----------+--------+---------+--------+--------+
| RowsPer- | n       | n        | n      | n       | n      | n      |
| Strip    |         |          |        |         |        |        |
+----------+---------+----------+--------+---------+--------+--------+
| Samples- | 1       | 1        | 1      | 1, 3    | 1, 3, 4| 1, 3, 4|
| PerPixel |         |          |        |         |        |        |
+----------+---------+----------+--------+---------+--------+--------+
| Software |         | {ASCII}  | {ASCII}| {ASCII} | {ASCII}| {ASCII}|
+----------+---------+----------+--------+---------+--------+--------+
| Strip-   | n       | <n>      | <n>    | <n>     | <n>    | <n>    |
| Byte-    |         |          |        |         |        |        |
| Counts   |         |          |        |         |        |        |
+----------+---------+----------+--------+---------+--------+--------+
| Strip-   | n       | <n>      | <n>    | <n>     | <n>    | <n>    |
| Offsets  |         |          |        |         |        |        |
+----------+---------+----------+--------+---------+--------+--------+
| XResolu- | 204     | 200, 204, 300     |    100, 200, 300, 400     |
| tion     | 200     | 400, 408          |                           |
+----------+---------+----------+--------+---------+--------+--------+
| YResolu- | 98, 196 | 98, 196, 100, 200 |    100, 200, 300, 400     |
| tion     | 100,200 | 300, 391, 400     |                           |
+----------+---------+----------+--------+---------+--------+--------+



Buckley, et al.             Standards Track                    [Page 78]
^L
RFC 3949              File Format for Internet Fax         February 2005


   Table A.2  TIFF Extension Fields

           +---------------------------------------------------------+
           |                       Fax Profile                       |
           +---------------------------------------------------------|
           | Minimal | Extended |  JBIG  |  Lossy  |Lossless| Mixed  |
+----------|   B&W   |    B&W   |  B&W   |  Color  | Color  | Raster |
|   TIFF   |         |          |        |         |        | Content|
|  Field   |    S    |     F    |   J    |    C    |   L    |   M    |
+----------+---------+----------+--------+---------+--------+--------+
| Chroma-  |         |          |        | 1       |        | 1      |
| Position-|         |          |        |         |        |        |
| ing      |         |          |        |         |        |        |
+----------+---------+----------+--------+---------+--------+--------+
| Chroma-  |         |          |        | <1, 1>  |        | <1, 1> |
| SubSampl-|         |          |        | <2, 2>  |        | <2, 2> |
| ing      |         |          |        |         |        |        |
+----------+---------+----------+--------+---------+--------+--------+
| Document-|         | {ASCII}  | {ASCII}| {ASCII} | {ASCII}| {ASCII}|
| Name     |         |          |        |         |        |        |
+----------+---------+----------+--------+---------+--------+--------+
| Indexed  |         |          |        |         | 0,1    | 0,1    |
+----------+---------+----------+--------+---------+--------+--------+
| Page-    | n, m    | n, m     | n, m   | n, m    | n, m   | n, m   |
| Number   |         |          |        |         |        |        |
+----------+---------+----------+--------+---------+--------+--------+
| SubIFDs  |         |          |        |         |        | <IFD>  |
+----------+---------+----------+--------+---------+--------+--------+
| T4Options| 0, 4    | 0, 1,    |        |         |        | 0, 1,  |
|          |         | 4, 5     |        |         |        | 4, 5   |
+----------+---------+----------+--------+---------+--------+--------+
| T6Options|         | 0        |        |         |        | 0      |
+----------+---------+----------+--------+---------+--------+--------+
| XPosition|         |          |        |         |        | r      |
+----------+---------+----------+--------+---------+--------+--------+
| YPosition|         |          |        |         |        | r      |
+----------+---------+----------+--------+---------+--------+--------+














Buckley, et al.             Standards Track                    [Page 79]
^L
RFC 3949              File Format for Internet Fax         February 2005


   Table A.3   New Fields

           +---------------------------------------------------------+
           |                       Fax Profile                       |
           +---------------------------------------------------------|
           | Minimal | Extended |  JBIG  |  Lossy  |Lossless| Mixed  |
+----------|   B&W   |    B&W   |  B&W   |  Color  | Color  | Raster |
|   TIFF   |         |          |        |         |        | Content|
|  Field   |    S    |     F    |   J    |    C    |   L    |   M    |
+----------+---------+----------+--------+---------+--------+--------+
| BadFax-  |         | n        |        |         |        |        |
| Lines    |         |          |        |         |        |        |
+----------+---------+----------+--------+---------+--------+--------+
| CleanFax-|         | 0, 1, 2  |        |         |        |        |
| Data     |         |          |        |         |        |        |
+----------+---------+----------+--------+---------+--------+--------+
| Coding-  |         |          | n      | n       | n      | n      |
| Method   |         |          |        |         |        |        |
+----------+---------+----------+--------+---------+--------+--------+
| Consecu- |         | n        |        |         |        |        |
| tiveBad- |         |          |        |         |        |        |
| FaxLines |         |          |        |         |        |        |
+----------+---------+----------+--------+---------+--------+--------+
| Decode   |         |          |        | <r>     | <r>    | <r>    |
+----------+---------+----------+--------+---------+--------+--------+
| Fax-     |         |          | n      | n       | n      | n      |
| Profile  |         |          |        |         |        |        |
+----------+---------+----------+--------+---------+--------+--------+
| Global-  |         | IFD      | IFD    | IFD     | IFD    | IFD    |
| Parame-  |         |          |        |         |        |        |
| tersIFD  |         |          |        |         |        |        |
+----------+---------+----------+--------+---------+--------+--------+
| Image-   |         |          |        |         |        | n, m   |
| Layer    |         |          |        |         |        |        |
+----------+---------+----------+--------+---------+--------+--------+
| T82-     |         |          | n      |         |        | n      |
| Options  |         |          |        |         |        |        |
+----------+---------+----------+--------+---------+--------+--------+
| Image-   |         |          |        |         |        | <n>    |
| BaseColor|         |          |        |         |        |        |
+----------+---------+----------+--------+---------+--------+--------+
| Mode-    |         |          |        |         |        | n      |
| Number   |         |          |        |         |        |        |
+----------+---------+----------+--------+---------+--------+--------|
| Profile- |         |          | n      | n       | n      | n      |
| Type     |         |          |        |         |        |        |
+--------------------------------------------------------------------+




Buckley, et al.             Standards Track                    [Page 80]
^L
RFC 3949              File Format for Internet Fax         February 2005


+----------+---------+----------+--------+---------+--------+--------+
| Strip-   |         |          |        |         |        | <n>    |
| RowCounts|         |          |        |         |        |        |
+----------+---------+----------+--------+---------+--------+--------+
| Version- |         |          |        | <b>     |<b>     |        |
| Year     |         |          |        |         |        |        |
+----------+---------+----------+--------+---------+--------+--------+

Annex B: List of technical edits to RFC2301

   This Annex lists technical differences between this document and
   RFC 2301, the Proposed Standard File Format for Internet Fax.

+----+---------+-------------------------------------------------+
| No.| Section |             Technical Edit                      |
+----+---------+-------------------------------------------------+
| 1. | 5.2.1   | Added FillOrder=1 to Profile J                  |
+----+---------+-------------------------------------------------+
| 2. | 6.2.1   | Constrained ResolutionUnit to 2 (i.e., inch) for|
|    | 7.2.1   | all color profiles, per ITU-T Recommendations   |
|    | 8.2.1   |                                                 |
+----+---------+-------------------------------------------------+
| 3. | 7.2.1   | Deleted ColorMap field; it re-encoded the color |
|    | 7.4     | palette already in the T.43 data stream         |
+----+---------+-------------------------------------------------+
| 4. | 7.2.2   | Changed TAG value of Indexed field from 364 to  |
|    |         | 346 to agree with Section 8.2.2 and Ref. [TTN1] |
+----+---------+-------------------------------------------------+
| 5. | 8.2.1   | Added text clarifying the use of ImageWidth     |
|    |         | when Background or Foreground layer is Primary  |
|    |         | IFD                                             |
+----+---------+-------------------------------------------------+
| 6. | 8.2.3   | Changed field name from DefaultImageColor to    |
|    |         | ImageBaseColor;                                 |
+----+---------+-------------------------------------------------+
| 7. | 8.2.1   | Added Compression=1 for ImageBaseColor IFDs     |
+----+---------+-------------------------------------------------+
| 8. | 5.2.1   | Redefined compression = 9 to be T.82 (JBIG);    |
|    | 5.2.3   | added T82Options field, with a default value (0)|
|    |         | corresponding to the T.85 application profile   |
+----+---------+-------------------------------------------------+
| 9. | 4.3.3   | Added GlobalParametersIFD, ProfileType,         |
|    | 4.7     | FaxProfile and CodingMethod to the New Fields   |
|    |         | portion of Profile F, per Sec. 2.2.4            |
+----+---------+-------------------------------------------------+






Buckley, et al.             Standards Track                    [Page 81]
^L
RFC 3949              File Format for Internet Fax         February 2005


+----+---------+-------------------------------------------------+
| 10.|  6.2.1  | Deleted BitsPerSample=12 as an option when      |
|    |6.2.3,6.4| Compression=7 due to lack of interop testing.   |
|    |Table A.1|                                                 |
+----+---------+-------------------------------------------------+
| 11.|8.2.1,8.4| Deleted PhotometricInterpretation=5 in Profile M|
|    |Table A.1| due to insufficient interop testing.            |
+----+---------+-------------------------------------------------+
| 12.|7.2.1,7.4| Deleted BitsPerSample=13-16 for Palette-color   |
|    |8.2.1,8.5| due to lack of interop testing.                 |
|    |Table A.1|                                                 |
+----+---------+-------------------------------------------------+
| 13.| Annex B | Deleted Annex B due to discontinued use of      |
|    |         | application parameter; Annex C renamed Annex B  |
+----+---------+-------------------------------------------------+

Authors' Addresses

   Robert Buckley
   Xerox Corporation
   Mailstop 0128-30E
   800 Phillips Road
   Webster, NY 14580, USA

   Phone: +1-585-422-1282
   Fax:   +1-585-422-2636
   EMail: rbuckley@crt.xerox.com


   Dennis Venable
   Xerox Corporation
   Mailstop 0128-27E
   800 Phillips Road
   Webster, NY 14580, USA

   Phone: +1-585-422-3138
   Fax:   +1-585-422-6117
   EMail: dvenable@crt.xerox.com













Buckley, et al.             Standards Track                    [Page 82]
^L
RFC 3949              File Format for Internet Fax         February 2005


   Lloyd McIntyre
   10328 S. Stelling Road
   Cupertino, CA 95014 USA

   Phone: +1-408-725-1624
   EMail: lloyd10328@pacbell.net or
          Lloyd_McIntyre@Dell.com


   Glenn W. Parsons
   Nortel Networks
   P.O. Box 3511, Station C
   Ottawa, ON K1Y 4H7, Canada

   Phone: +1-613-763-7582
   Fax:   +1-613-967-5060
   EMail: gparsons@nortel.com


   James Rafferty
   Brooktrout Technology
   410 First Avenue
   Needham, MA 02494 USA

   Phone: +1-781-433-9462
   Fax:   +1-781-433-9268
   EMail: jraff@brooktrout.com
























Buckley, et al.             Standards Track                    [Page 83]
^L
RFC 3949              File Format for Internet Fax         February 2005


Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the IETF's procedures with respect to rights in IETF Documents can
   be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Buckley, et al.             Standards Track                    [Page 84]
^L