INTERNET-DRAFT                                               R. Buckley
Fax Working Group                                     Xerox Corporation
May 26, 2004                                                 D. Venable
draft-ietf-fax-tiff-fx-14.txt                         Xerox Corporation
                                                             L. McIntyre
                                                              G. Parsons
                                                         Nortel Networks
                                                             J. Rafferty
                                                              Brooktrout
                                                                May 2004


                      File Format for Internet Fax


Status of this Memo:

     This document is an Internet-Draft and is in full conformance with
     all provisions of Section 10 of RFC2026.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and its working groups.  Note that
     other groups may also distribute working documents as
     Internet-Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other documents
     at any time.  It is inappropriate to use Internet- Drafts as
     reference material or to cite them other than as "work in progress."

     The list of current Internet-Drafts can be accessed at
     <http://www.ietf.org/ietf/1id-abstracts.txt>

     The list of Internet-Draft Shadow Directories can be accessed at
     <http://www.ietf.org/shadow.html>.

     A version of this document is intended for submission to the
     RFC editor as a Draft Standard for the Internet Community.
     Discussion and suggestions for improvement are requested.


Copyright Notice

     Copyright (C) The Internet Society 2003.  All Rights Reserved.










Buckley et al.             Expires November 2004                [Page 0]


Internet Draft        File Format for Internet Fax              May 2004





Abstract

    This document is a revised version of RFC 2301.
    The revisions, summarized in the list attached as Annex B to this
    document, are based on the 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 TIFF (Tag Image File Format)
    representation of image data specified by the ITU-T Recommendations
    for black-and-white and color facsimile. This file format
    specification is commonly known as TIFF-FX. It formally defines
    minimal, extended and lossless 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.             Expires November 2004                [Page 1]


Internet Draft        File Format for Internet Fax              May 2004


Table of Contents

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



Buckley et al.             Expires November 2004                [Page 2]


Internet Draft        File Format for Internet Fax              May 2004


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




Buckley et al.             Expires November 2004                [Page 3]


Internet Draft        File Format for Internet Fax              May 2004


11. References........................................................69
12. Authors' Addresses................................................71
Annex A: Summary of TIFF Fields for Internet Fax .....................72
Annex B. List of technical edits to RFC2301...........................77
Full Copyright Statement..............................................78

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,
        3.  defines new TIFF fields and values required for compatibility
            with ITU color fax.

    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.



Buckley et al.             Expires November 2004                [Page 4]


Internet Draft        File Format for Internet Fax              May 2004

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 that is
    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 in 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
    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



Buckley et al.             Expires November 2004                [Page 5]


Internet Draft        File Format for Internet Fax              May 2004


    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, 11, 12 and 13 give Security
    Considerations, the ISOC Copyright Notice, References and Authors'
    Addresses. 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.

                                 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.



Buckley et al.             Expires November 2004                [Page 6]


Internet Draft        File Format for Internet Fax              May 2004


    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].

1.4 IPR Notification

    The IETF has been notified of intellectual property rights claimed in
    regard to some or all of the specification contained in this
    document.  For more information consult the online list of claimed
    rights in <http://www.ietf.org/ipr.html>.


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
    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).




Buckley et al.             Expires November 2004                [Page 7]


Internet Draft        File Format for Internet Fax              May 2004

    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 that 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 that either contain 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
    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. While a Baseline TIFF reader is not


Buckley et al.             Expires November 2004                [Page 8]


Internet Draft        File Format for Internet Fax              May 2004


    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.

    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.)




Buckley et al.             Expires November 2004                [Page 9]


Internet Draft        File Format for Internet Fax              May 2004

    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 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 gracefully add new
    compression schemes 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, then 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, which 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




Buckley et al.              Expires November 2004              [Page 10]


Internet Draft        File Format for Internet Fax              May 2004


    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
    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 which do depend on the profile. Section
    2.2.3 lists the fields that are recommended for all profiles. Fields

    that are 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 sub-sections for required and
    recommended fields; each sub-section 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.              Expires November 2004              [Page 11]


Internet Draft        File Format for Internet Fax              May 2004


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

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
    sub-section 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) which describe the profiles
    that uses 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

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.


Buckley et al.              Expires November 2004              [Page 12]


Internet Draft        File Format for Internet Fax              May 2004


     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)

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 utilizes 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.


Buckley et al.              Expires November 2004              [Page 13]


Internet Draft        File Format for Internet Fax              May 2004


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)

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 insure 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

Buckley et al.              Expires November 2004              [Page 14]


Internet Draft        File Format for Internet Fax              May 2004


     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
     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,

Buckley et al.              Expires November 2004              [Page 15]


Internet Draft        File Format for Internet Fax              May 2004


     not a Baseline TIFF field.
     No default.

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 conflict
    exists between fields in the GlobalParametersIFD and in the image
    IFDs, then the data in the image IFD shall prevail.

Buckley et al.              Expires November 2004              [Page 16]


Internet Draft        File Format for Internet Fax              May 2004


    Among the GlobalParametersIFD entries is a new ProfileType field
    which 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
     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.

Buckley et al.              Expires November 2004              [Page 17]


Internet Draft        File Format for Internet Fax              May 2004


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

    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 sub- section 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)



Buckley et al.              Expires November 2004              [Page 18]


Internet Draft        File Format for Internet Fax              May 2004


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
     using 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.

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



Buckley et al.              Expires November 2004              [Page 19]


Internet Draft        File Format for Internet Fax              May 2004


     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

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


Buckley et al.              Expires November 2004              [Page 20]


Internet Draft        File Format for Internet Fax              May 2004


        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.

    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 scan lines 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 want
    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 sub-section.

3.4.1. RTC Exclusion

    Implementations which wish 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 which 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 which do not include RTCs and SHOULD be able to
    process files which do include RTCs.


Buckley et al.              Expires November 2004              [Page 21]


Internet Draft        File Format for Internet Fax              May 2004


3.5. File Structure

    The TIFF header, described in Section 2.1.1, contains two bytes which
    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 that offset to the first IFD is 8. The headers values are
    shown in the following table:

           +--------+-------------------+--------+-----------+
           | 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 it has
    offsets to 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 contains 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, etc.
    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.              Expires November 2004              [Page 22]


Internet Draft        File Format for Internet Fax              May 2004


                    +-----------------------+
                    |         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 is 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 comprise 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 in the table, certain fields which
    have a value that is a sequence of flag bits are shown taking integer
    values that correspond 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.              Expires November 2004              [Page 23]


Internet Draft        File Format for Internet Fax              May 2004


       +---------------------------+--------------------------------+
       | 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 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.              Expires November 2004              [Page 24]


Internet Draft        File Format for Internet Fax              May 2004


    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 use
    of TIFF-F. 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 usage 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"
    which 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 which 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.              Expires November 2004              [Page 25]


Internet Draft        File Format for Internet Fax              May 2004


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 which 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, 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

    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




Buckley et al.              Expires November 2004              [Page 26]


Internet Draft        File Format for Internet Fax              May 2004


    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 measures.
     Default = 2 (field may be omitted if this is the value)

SamplesPerPixel(277) = 1.
SHORT
     RequiredByTIFFBaseline
     1 = monochrome, bilevel 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

    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



Buckley et al.              Expires November 2004              [Page 27]


Internet Draft        File Format for Internet Fax              May 2004


     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 size [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        |
                                      +---------------------------+


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



Buckley et al.              Expires November 2004              [Page 28]


Internet Draft        File Format for Internet Fax              May 2004


     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 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.

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 scan lines. A

Buckley et al.              Expires November 2004              [Page 29]


Internet Draft        File Format for Internet Fax              May 2004


    "good" scan line is defined as a line that, when decoded, contains
    the correct number of pixels. Conversely, a "bad" scan line is
    defined as a line that, when decoded, comprises an incorrect number
    of pixels.

BadFaxLines(326)                                           SHORT or
LONG
     The number of "bad" scan lines 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 if "bad" lines encountered during reception are stored in
     the data, or if "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
    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 if 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



Buckley et al.              Expires November 2004              [Page 30]


Internet Draft        File Format for Internet Fax              May 2004


    strips, a TIFF reader need not load the entire image into memory,
    thus 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.

    Facsimile data appears on the phone line in bit-reversed order
    relative to its description in ITU-T Recommendation T.4.  Therefore,
    a wide majority of 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 that 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



Buckley et al.              Expires November 2004              [Page 31]


Internet Draft        File Format for Internet Fax              May 2004


    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 common
    practice 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
    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.





Buckley et al.              Expires November 2004              [Page 32]


Internet Draft        File Format for Internet Fax              May 2004


    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, historical TIFF-F has required readers and writers to
    be able to handle multi-page TIFF-F files.  Based on the experience
    of various TIFF-F implementors, it has been seen that the
    implementation of 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
    page of the document.  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, 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 strip offsets for each strip of image are defined from
    within each IFD.   Where possible, another simplifying guideline for
    the writing of TIFF-F files is to specify 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). The use of a single
    image strip per page is very useful 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 which require the use of "streaming"
    techniques (see section 4.4.7).  In the event 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 that are related to
    strips.

    A third simplifying guideline is that each IFD SHOULD be placed in
    the TIFF-F file structure at a point which precedes the image which
    the IFD describes.

    In addition, a fourth simplifying guideline for TIFF-F writers and
    readers is to place the actual image data in a physical order within
    the TIFF file structure which is consistent with the logical page
    order.  In practice, TIFF-F readers will need to use the strip



Buckley et al.              Expires November 2004              [Page 33]


Internet Draft        File Format for Internet Fax              May 2004


    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 at the top of the
    page.

    TIFF-F writers MAY make a fifth 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
    (writers MAY rather than SHOULD use it) compared to the other
    guidelines given here to reflect past practices for TIFF-F.

    In the case of the minimal profile, which is also the minimal subset

    of Profile F, the SHOULD's and MAY's of these guidelines become
    SHALL's (see Section 3.5).

    So, a TIFF-F file which is structured using the guidelines of this
    section will essentially be composed of a linked list of IFDs,
    presented in ascending page order, which in turn each point to a
    single page of image data (one strip per page), where the pages of
    image data are also placed in a logical page order 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.  While TIFF-F may also possibly
    be used as a file format for cases such as streaming applications,
    assumptions may be required that differ from those provided in this
    section (e.g., the entire size and number of pages within the image
    are not known in advance).  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. This means that the "Uncompressed" bit in T4Options or
    T6Options must be set to 0.






Buckley et al.              Expires November 2004              [Page 34]


Internet Draft        File Format for Internet Fax              May 2004


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 that wish to have the maximum flexibility in reading
    TIFF-F files should support all three of these compression methods
    (MH, MR and MMR).

    For the case of resolution, 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, 400 x 400 in dots per
    inch based units.  At the same time, support was added for metric
    dimensions which are 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 writer, since 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 to not
    support the use of these higher resolutions.

    Per [T.4], it is permissible for applications to treat the following
    XResolution values as being equivalent: <204,200> and <400,408>.  In
    a similar respect, the following YResolution values may also be
    treated as being 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.

    In a similar respect, the optional support of metric based
    resolutions in the TIFF-F reader (i.e. 77 x 38.5 cm) is included for
    completeness, since 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



Buckley et al.              Expires November 2004              [Page 35]


Internet Draft        File Format for Internet Fax              May 2004


    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 such 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.

4.5.4. EOL

    As illustrated in FIGURE 1/T.4 in [T.4], facsimile documents encoded
    with Modified Huffman begin with an EOL, which in TIFF-F may be byte-
    aligned. The last line of the image is not terminated by an EOL.  In
    a similar 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 which wish 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 which need 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 which include the RTC sequence in MH/MR image
    data. Therefore, TIFF-F readers MUST be able to process files which
    do not include RTCs and SHOULD be able to process files which do
    include RTCs.




Buckley et al.              Expires November 2004              [Page 36]


Internet Draft        File Format for Internet Fax              May 2004


4.5.6 Use of EOFB for T.6 Compressed Images

    TIFF-F pages which are 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.

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 |
        +------------------------------------------------------------+





Buckley et al.              Expires November 2004              [Page 37]


Internet Draft        File Format for Internet Fax              May 2004


        +------------------------------------------------------------+
        | 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                  |
        +---------------------------+--------------------------------+
        | 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                                           |
        +---------------------------+--------------------------------+







Buckley et al.              Expires November 2004              [Page 38]


Internet Draft        File Format for Internet Fax              May 2004


        +---------------------------+--------------------------------+
        | 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               |
        +---------------------------+--------------------------------+
        | 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                        |
        +---------------------------+--------------------------------+




Buckley et al.              Expires November 2004              [Page 39]


Internet Draft        File Format for Internet Fax              May 2004


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

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

    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.

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).

Buckley et al.              Expires November 2004              [Page 40]


Internet Draft        File Format for Internet Fax              May 2004


     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.)

     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 Section 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.     |
        +---------------------------+--------------------------------+


Buckley et al.              Expires November 2004              [Page 41]


Internet Draft        File Format for Internet Fax              May 2004

        +---------------------------+--------------------------------+
        | 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                  |
        +---------------------------+--------------------------------+
        | 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     |
        +---------------------------+--------------------------------+

Buckley et al.              Expires November 2004              [Page 42]


Internet Draft        File Format for Internet Fax              May 2004


        +---------------------------+--------------------------------+
        | 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                        |
        +---------------------------+--------------------------------+

6. Profile C - Base Color Fax profile

6.1. Overview

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

    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)

Buckley et al.              Expires November 2004              [Page 43]


Internet Draft        File Format for Internet Fax              May 2004


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

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 using 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 Sec. 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

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.

Buckley et al.              Expires November 2004              [Page 44]


Internet Draft        File Format for Internet Fax              May 2004


NOTE: The functional equivalence of inch-based and metric-based resolu-
tions is maintained, per Annex E.6.5 in [T.4]. See table in Sec. 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.

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

Buckley et al.              Expires November 2004              [Page 45]


Internet Draft        File Format for Internet Fax              May 2004


     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,
     A 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 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


Buckley et al.              Expires November 2004              [Page 46]


Internet Draft        File Format for Internet Fax              May 2004


     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].

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 asterisks are 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"   |
        +---------------------------+--------------------------------+







Buckley et al.              Expires November 2004              [Page 47]


Internet Draft        File Format for Internet Fax              May 2004


        +------------------------------------------------------------+
        | 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               |
        +---------------------------+--------------------------------+
        | 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)       |
        +---------------------------+--------------------------------+







Buckley et al.              Expires November 2004              [Page 48]


Internet Draft        File Format for Internet Fax              May 2004


        +---------------------------+--------------------------------+
        | 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                  |
        +---------------------------+--------------------------------+
        | 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 or Profile L of TIFF

    for facsimile. Implementations of this profile are required to also
    implement Profiles S and C.







Buckley et al.              Expires November 2004              [Page 49]


Internet Draft        File Format for Internet Fax              May 2004


7.1. Overview

    This profile, specified in [T.43] and [T.4] Annex G, uses JBIG to
    losslessly code three types of color and grayscale images: 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 palette or mapped 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.

    Enabling T.43 color maps in TIFF requires the extension field
    Indexed, defined in [TTN1], and the PhotometricInterpretation field
    value 10, 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| PerPixel |  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,


Buckley et al.              Expires November 2004              [Page 50]


Internet Draft        File Format for Internet Fax              May 2004


    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.

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












Buckley et al.              Expires November 2004              [Page 51]


Internet Draft        File Format for Internet Fax              May 2004


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.

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.









Buckley et al.              Expires November 2004              [Page 52]


Internet Draft        File Format for Internet Fax              May 2004


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.

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.              Expires November 2004              [Page 53]


Internet Draft        File Format for Internet Fax              May 2004


         +--------------------+--------------------------------------+
         | 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.              Expires November 2004              [Page 54]


Internet Draft        File Format for Internet Fax              May 2004


         +--------------------+--------------------------------------+
         | 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 or Profile M
    of TIFF for facsimile. 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, while spatial resolution of 400 pixels per inch may be
    best for the black-and- white text, 200 pixel 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 using the TIFF format to yield a data
    structure which 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 if output pixels come from the Foreground layer or the


Buckley et al.              Expires November 2004              [Page 55]


Internet Draft        File Format for Internet Fax              May 2004


    Background layer. When the Mask layer pixel value is 1, the
    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 consists 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
    with each stripe 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 allowed
    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
    allowed values are 100 and 300. The Foreground and Background layer
    resolutions can be independently set of each other.





Buckley et al.              Expires November 2004              [Page 56]


Internet Draft        File Format for Internet Fax              May 2004


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
    because 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 that are referenced by the
    SubIFDs field in the Primary IFD.  There are many possible ways to
    represent the Background and Foreground layer images: (1) the
    SubIFD field of the Primary IFD is an array of pointers to all

Buckley et al.              Expires November 2004              [Page 57]


Internet Draft        File Format for Internet Fax              May 2004


    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 using (3), as shown in the example below. Furthermore,
    the child IFDs representing the Background and Foreground layer
    images 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.

    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



Buckley et al.              Expires November 2004              [Page 58]


Internet Draft        File Format for Internet Fax              May 2004


    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 using 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.

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


Buckley et al.              Expires November 2004              [Page 59]


Internet Draft        File Format for Internet Fax              May 2004


    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 8.2.3.

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.



Buckley et al.              Expires November 2004              [Page 60]


Internet Draft        File Format for Internet Fax              May 2004

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.

    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.


Buckley et al.              Expires November 2004              [Page 61]


Internet Draft        File Format for Internet Fax              May 2004


    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 insure 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.

    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-sized strips. Only one of the
    two fields, StripRowCounts and RowsPerStrip, may be used in an IFD.




Buckley et al.              Expires November 2004              [Page 62]


Internet Draft        File Format for Internet Fax              May 2004


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, describing the layer to which
    the image belongs and the order in which it is imaged.

    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 to only 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 insure 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 since 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.




Buckley et al.              Expires November 2004              [Page 63]


Internet Draft        File Format for Internet Fax              May 2004


8.4. Rules and Requirements for Images

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

    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 the binary data representations 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 the color
       representations 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.



Buckley et al.              Expires November 2004              [Page 64]


Internet Draft        File Format for Internet Fax              May 2004


    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).

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 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 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.              Expires November 2004              [Page 65]


Internet Draft        File Format for Internet Fax              May 2004


      +------------------+-----------------------------------------+
      | 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.              Expires November 2004              [Page 66]


Internet Draft        File Format for Internet Fax              May 2004


      +------------------+-----------------------------------------+
      | 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.              Expires November 2004              [Page 67]


Internet Draft        File Format for Internet Fax              May 2004


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.














































Buckley et al.              Expires November 2004              [Page 68]


Internet Draft        File Format for Internet Fax              May 2004



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 that 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", 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.

    [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




Buckley et al.              Expires November 2004              [Page 69]


Internet Draft        File Format for Internet Fax              May 2004


    [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,
    ftp://ftp.adobe.com/pub/adobe/devrelations/
    devtechnotes/pdffiles/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 Rafferty J., "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://www.adobe.com/supportservice/devrelations/PDFS/TN/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 Rafferty, J., "Tag Image

    File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type
    Registration", RFC 3250, September 2002

    The ITU-T Recommendations are available at http://www.itu.ch.

11.2 Informative references

    [GUIDE] Cancio, V., Moldovan, M., Tamura, H., and Wing, D.,
    "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", work in progress, draft-ietf-vpim-vpimv2r2-05.txt,
    February 2002







Buckley et al.              Expires November 2004              [Page 70]


Internet Draft        File Format for Internet Fax              May 2004


12. Authors' Addresses

    Robert Buckley                     Dennis Venable
    Xerox Corporation                  Xerox Corporation
    Mailstop 0128-30E                  Mailstop 0128-27E
    800 Phillips Road                  800 Phillips Road
    Webster, NY 14580, USA             Webster, NY 14580, USA
    Voice: +1-585-422-1282             Voice: +1-585-422-3138
    Fax: +1-585-265-8871               Fax: +1-585-422-6117
    Email: rbuckley@crt.xerox.com      Email: dvenable@crt.xerox.com

    Lloyd McIntyre
    10328 S. Stelling Road
    Cupertino, CA 95014 USA
    Voice: +1-408-725-1624
    Email: lloyd10328@pacbell.net

    Glenn S. Parsons                   James Rafferty
    Nortel Networks                    Brooktrout Technology
    P.O. Box 3511, Station C           410 First Avenue
    Ottawa, Ontario K1Y 4H7, Canada    Needham, MA 02494 USA
    Phone: +1-613-763-7582             Phone: +1-781-433-9462
    Fax: +1-613-763-2697               Fax: +1-781-433-9268
    Email:                             Email: jraff@brooktrout.com
    gparsons@nortelnetworks.com


























Buckley et al.              Expires November 2004              [Page 71]


Internet Draft        File Format for Internet Fax              May 2004


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.              Expires November 2004              [Page 72]


Internet Draft        File Format for Internet Fax              May 2004


  +----------+---------+----------+--------+---------+--------+--------+
  | 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.              Expires November 2004              [Page 73]


Internet Draft        File Format for Internet Fax              May 2004


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.              Expires November 2004              [Page 74]


Internet Draft        File Format for Internet Fax              May 2004


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.              Expires November 2004              [Page 75]


Internet Draft        File Format for Internet Fax              May 2004


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

 +----------+---------+----------+--------+---------+--------+--------+












































Buckley et al.              Expires November 2004              [Page 76]


Internet Draft        File Format for Internet Fax              May 2004

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            |
    +----+---------+-------------------------------------------------+
    | 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  |
    +----+---------+-------------------------------------------------+

Buckley et al.              Expires November 2004              [Page 77]


Internet Draft        File Format for Internet Fax              May 2004


Full Copyright Statement

    Copyright (C) The Internet Society (2003).  All Rights Reserved.

    This document and translations of it may be copied and furnished to
    others, and derivative works that comment on or otherwise explain it
    or assist in its implementation may be prepared, copied, published
    and distributed, in whole or in part, without restriction of any
    kind, provided that the above copyright notice and this paragraph are
    included on all such copies and derivative works.  However, this
    document itself may not be modified in any way, such as by removing
    the copyright notice or references to the Internet Society or other
    Internet organizations, except as needed for the purpose of
    developing Internet standards in which case the procedures for
    copyrights defined in the Internet Standards process must be
    followed, or as required to translate it into languages other than
    English.

    The limited permissions granted above are perpetual and will not be
    revoked by the Internet Society or its successors or assigns.

    This document and the information contained herein is provided on an
    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
    HEREI     WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Buckley et al.              Expires November 2004              [Page 78]