File Format for Internet Fax
RFC 3949
| Document | Type |
RFC
- Draft Standard
(February 2005)
IPR
Obsoletes RFC 2301
Was
draft-ietf-fax-tiff-fx
(fax WG)
|
|
|---|---|---|---|
| Authors | Dr. Dennis L. Venable, James Rafferty , Glenn Parsons , Lloyd McIntyre , Robert Buckley | ||
| Last updated | 2018-12-20 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Scott Hollenbeck | |
| Send notices to | (None) |
RFC 3949
quot; |
+--------------------+--------------------------------------+
| FillOrder** | 1: Most significant bit first |
| | 2: Least significant bit first |
+--------------------+--------------------------------------+
| ImageDescription* | {ASCII}: A string describing the |
| | contents of the image |
+--------------------+--------------------------------------+
| ImageWidth | 864, 1024, 1216, 1728**, 2048, 2432, |
| | 2592, 3072, 3456, 3648, 4096, 4864 |
+--------------------+--------------------------------------+
| ImageLength** | n: total number of scanlines in image|
+--------------------+--------------------------------------+
| NewSubFileType | 2**: Bit 1 identifies single page of |
| | a multi-page document |
+--------------------+--------------------------------------+
Buckley, et al. Standards Track [Page 58]
RFC 3949 File Format for Internet Fax February 2005
+--------------------+--------------------------------------+
| Orientation | 1**-8, Default 1 |
+--------------------+--------------------------------------+
| PhotometricInter- | 2: RGB |
| pretation | 5: CMYK |
| | 10**: ITULAB |
+--------------------+--------------------------------------+
| ResolutionUnit** | 2: inch |
+--------------------+--------------------------------------+
| RowsPerStrip** | n: number of scanlines per TIFF strip|
+--------------------+--------------------------------------+
| SamplesPerPixel | 1**: L* (lightness) |
| | 3: LAB, RGB, CMY |
| | 4: CMYK |
+--------------------+--------------------------------------+
| Software* | {ASCII}: name & release number of |
| | creator software |
+--------------------+--------------------------------------+
| StripByteCounts** | <n>: number or bytes in TIFF strip |
+--------------------+--------------------------------------+
| StripOffsets** | <n>: offset from beginning of file to|
| | each TIFF strip |
+--------------------+--------------------------------------+
| XResolution | 100, 200**, 300, 400 (pixels/inch) |
+--------------------+--------------------------------------+
| YResolution | equal to XResolution (pixels must be |
| | square) |
+--------------------+--------------------------------------+
| Extension Fields |
+--------------------+--------------------------------------+
| DocumentName* | {ASCII}: name of scanned document |
+--------------------+--------------------------------------+
| PageNumber** | n,m: page number followed by total |
| | page count |
+--------------------+--------------------------------------+
| Indexed | 0: not a palette-color image |
| | 1: palette-color image |
+--------------------+--------------------------------------+
| New Fields |
+--------------------+--------------------------------------|
| Decode | minL, maxL, mina, maxa, minb, maxb: |
| | minimum and maximum values for L*a*b*|
+--------------------+--------------------------------------+
| GlobalParameters | IFD: global parameters IFD |
| IFD* | |
+-----------------------------------------------------------+
Buckley, et al. Standards Track [Page 59]
RFC 3949 File Format for Internet Fax February 2005
+--------------------+--------------------------------------+
| ProfileType* | n: type of data stored in TIFF file |
+--------------------+--------------------------------------+
| FaxProfile* | n: ITU-compatible fax profile |
+--------------------+--------------------------------------+
| CodingMethods* | n: compression algorithms used in |
| | file |
+--------------------+--------------------------------------+
| VersionYear* | byte sequence: year of ITU fax std |
+--------------------+--------------------------------------+
8. Profile M: Mixed Raster Content Profile
This section defines the Mixed Raster Content profile of TIFF for
facsimile, designated Profile M. Implementations of this profile are
required to implement Profiles S and C and may optionally implement
Profiles F, J and L.
8.1. Overview
Unlike previous fax profiles, which use a single coding method and
resolution for an entire fax page, Mixed Raster Content [T.44]
enables different coding methods and resolutions within a single
page. For example, consider a page that contains black-and-white
text, which is best coded with MMR or JBIG; a color bar chart, best
coded with JBIG; and a scanned color image, best coded with JPEG.
Similarly, although spatial resolution of 400 pixels per inch may be
best for the black-and-white text, 200 pixels per inch is usually
sufficient for a color image.
Rather than applying one coding method and resolution to all
elements, MRC allows multiple coders and resolutions within a page.
By itself, MRC does not define any new coding methods or resolutions.
Instead it defines a 3-layer image model for structuring and
combining the scanned image data. The MRC 3-layer model has been
applied here with the TIFF format to yield a data structure that
differs from [T.44], though it applies the same coding methods, uses
the same compressed image data streams, and is consistent with the
TIFF principle of a single IFD per image.
8.1.1. MRC 3-layer model
The 3 layers of the MRC model are Foreground and Background, which
are both multi-level, and Mask, which is bi-level. Each layer may
appear only once on a page and is coded independently of the other
two layers. The final image is obtained by using the Mask layer to
determine whether output pixels come from the Foreground layer or the
Background layer. When the Mask layer pixel value is 1, the
Buckley, et al. Standards Track [Page 60]
RFC 3949 File Format for Internet Fax February 2005
corresponding pixel from the Foreground layer is selected; when it is
0, the corresponding pixel from the Background layer is selected.
Details are given in the Introduction of [T.44].
In our earlier example, the shape of the black-and-white text and the
mask for the color chart could be in the Mask layer, the color of the
chart and text in the Foreground layer, and the color image in the
Background layer. If a Mask layer pixel has a value of 1, the final
image pixel will be, depending on the pixel location, from either the
color chart or text color in the Foreground layer. If a Mask layer
pixel has a value of 0, the final image pixel will be from the color
image in the Background layer.
Each layer is an image and, when present, is represented by at least
one IFD in a TIFF file. This is consistent with TIFF, which provides
fields to define the attributes, such as resolution, image size, bits
per sample, etc., of a single image or layer. The distribution of
content among layers is determined by the writer, as is the choice of
coding method, color encoding, and spatial resolution for a layer.
Not all pages, and not all parts of a page, require 3 layers. If a
page has of only one layer, then that layer is the primary image
whether it is a Background, Mask, or Foreground layer. If there is
more than one layer, then the Mask must be one of the layers, in
which case it is the primary image. In all cases, the primary image
must be page size.
MRC [T.44] allows a page to be transmitted as a series of stripes,
each consisting of 1, 2 or 3 layers. The number of scanlines in each
stripe can vary over the page. Although [T.44] does not allow
overlap between images of a single layer, the MRC profile permits
overlapping IFDs when one of the IFDs is used only to define a
default image color. According to [T.4] Annex H, stripes having more
than 1 layer SHOULD NOT be more than 256 lines in length unless the
capability to receive longer stripes has been negotiated.
Furthermore, color fax also requires the spatial resolutions of
Background and Foreground images to be legal fax values that are also
integer factors of the Mask image resolution. For example, if the
Mask-Layer resolution is 400 pixels per inch, then allowable
resolutions for the Foreground and Background layers are 100, 200, or
400 pixels per inch; if the Mask is at 300 pixels per inch, then
allowable values are 100 and 300. The Foreground and Background
layer resolutions can be set independently of each other.
Buckley, et al. Standards Track [Page 61]
RFC 3949 File Format for Internet Fax February 2005
8.1.2. A TIFF Representation for the MRC 3-layer model
In the TIFF representation of the 3-layer MRC model, each page is
represented by a single IFD, called the Primary IFD. The nextIFD
offset associated with a Primary IFD will point to the Primary IFD of
the next page. If the page consists of a single layer, then the
Primary IFD represents that layer. If more than one layer is
present, the Primary IFD represents the Mask layer and the other
layers are represented by a set of child IFDs that are referenced
through the SubIFD extension field [TTN1] of the Primary IFD. To
distinguish MRC-specific SubIFDs from other SubIFDs, the
NewSubFileType field MUST have Bit 4 ON, indicating an MRC-related
IFD. A new ImageLayer field is also introduced that consists of two
values that identify the layer (Foreground, Background, or Mask) and
the order within the layer (first, second, ... image of the layer);
see Section 8.2.3.
In Profile M, the Primary IFD represents a complete layer and
corresponds to the primary image described in Section 8.1.1. There
must be no other MRC-related IFDs or SubIFDs that contain image data
corresponding to the layer represented by the Primary IFD.
MRC [T.44] allows a page to be transmitted as a series of stripes. A
strip within an IFD in a Profile M file represents a stripe in a
[T.44] data stream. The [T.44] stripes of the Primary image are
represented by a single, multiple-strip IFD; the [T.44] stripes of
other layers are represented as multiple, single-strip IFDs.
The layer represented by the Primary IFD may consist of strips of
image data, but all the strips must be part of the single Primary
IFD. For example, if the page consisted of only the Background
layer, then all strips associated with the Background layer must be
treated as a single image. Because MRC allows stripes with variable
numbers of scanlines, a reader MUST support StripRowCounts field, as
a writer may use it in place of the RowsPerStrip field to support a
variable number of scanlines in each strip of the Primary IFD. In
accordance with [TTN2], each strip shall be independently encoded,
but coding parameters may not change between strips.
Layers other than the layer represented by the Primary IFD store each
strip as a separate IFD, allowing the coding parameters to change
from strip to strip as described by the MRC standard [T.44]. In all
cases, if the Mask layer exists, it shall be represented by a single
IFD and a single set of coding parameters.
The use of SubIFDs to store child IFDs is described in [TTN1]. When
the Mask is the primary image, the Background and Foreground layer
images are represented with child IFDs referenced by the SubIFDs
Buckley, et al. Standards Track [Page 62]
RFC 3949 File Format for Internet Fax February 2005
field in the Primary IFD. There are multiple ways to organize the
images of the Background and Foreground layer images: (1) the SubIFD
field of the Primary IFD is an array of pointers to all child image
IFDs, one entry per child image; (2) the SubIFD field is a single
pointer to a linked list of all child image IFDs; (3) the SubIFD
field is an array of two pointers, where the first pointer is to a
linked list of all Background layer image IFDs, and the second
pointer is to a linked list of all Foreground layer image IFDs. A
Profile M writer SHOULD structure the Background and Foreground layer
images by using (3), as shown in the example below. Furthermore, the
child IFDs representing the images of the Background and Foreground
layers SHOULD be ordered in the file in the same order as they occur
on the page. However, a Profile M reader must scan all available
child IFDs to locate and identify IFDs associated with MRC layers.
(nextIFD)
PRIMARY IFD PAGE 0 -----------------------> PRIMARY IFD PAGE 1--> ...
ImageLayer = [2,1]
NewSubFileType = 18
SubIFD[0] ---------------------- SubIFD[1]
| |
V V
Child IFD Child IFD
ImageLayer = [1,1] ImageLayer [3,1]
NewSubFileType = 16 NewSubFileType 16
| |
|(nextIFD) |(nextIFD)
V V
Child IFD Child IFD
ImageLayer = [1,2] ImageLayer [3,2]
NewSubFileType = 16 NewSubFileType 16
| |
|(nextIFD) |(nextIFD)
V V
Child IFD Child IFD
ImageLayer = [1,3] ImageLayer [3,3]
NewSubFileType = 16 NewSubFileType 16
| |
|(nextIFD) |(nextIFD)
V V
0 0
The XPosition and YPosition TIFF fields specify the offset to the
upper left corner of the IFD in resolution units, which are inches in
Profile M; see Section 8.2.2. The Primary IFD must not use XPosition
or YPosition fields.
Buckley, et al. Standards Track [Page 63]
RFC 3949 File Format for Internet Fax February 2005
MRC [T.44] allows the specification of a default image color that is
to be applied in the event no image data is transmitted for a given
stripe and layer. The new field ImageBaseColor is used to store
default image color specifications in Profile M, see 8.2.3. By
setting the StripByteCounts array to zero values, an IFD defining a
default color but containing no encoded image data can be specified.
ImageBaseColor can also be used in IFDs that contain encoded image
data. In that case, the fields of the IFD must accurately reflect
the encoding of the image data. If the StripByteCount entry for a
given strip is 0, then the ImageBaseColor is used for that strip. If
the encoded image data is ITU L*a*b, the ImageBaseColor is
interpreted with the encoding parameters of the image data. If the
image data is not ITU L*a*b*, the ImageBaseColor is interpreted as
8-bit ITU L*a*b*; see Section 8.2.3.
8.2. Required TIFF Fields
This section describes the TIFF fields required, in addition to those
in Section 2.2.1, to represent MRC fax images. Since MRC stores fax
data as a collection of images corresponding to layers or parts of
layers, the coding methods, color encodings, and spatial resolutions
used by previous profiles apply to Profile M. Therefore, the
descriptions here will typically reference the appropriate earlier
sections. Fields and values specific to Profile M are pointed out.
8.2.1. Baseline Fields
ImageWidth(256).
SHORT or LONG
Same page widths as Profile C, the base color profile; see Section
6.2.1. In Profile M, the width of a Foreground or Background
image in the coded data stream may be less than the page width,
unless the Background or Foreground is the primary image, in which
case the width of the coded data stream is the page width. The
ImageWidth field will always store the actual width of the coded
data.
NewSubFileType(254) = 16, 18.
LONG
For Profile M, the NewSubFileType field has two bits that are
required. Bit 1 indicates a single page of a multi-page document
and must be set for the Primary IFD; Bit 4 indicates the MRC
imaging model as described in ITU-T Recommendation T.44 [T.44] and
must be set for Primary IFDs and all MRC-specific child IFDs.
Buckley, et al. Standards Track [Page 64]
RFC 3949 File Format for Internet Fax February 2005
BitsPerSample(258) = 1, 2-8, 9-12
SHORT
SamplesPerPixel(277) = 1, 3, 4.
SHORT
Compression(259) = 1, 3, 4, 7, 9, 10.
SHORT
For Mask layer, see Sections 4.2.1 and 5.2.1. For Foreground and
Background layers, see Sections 6.2.1 and 7.2.1 Compression=1 is
not used by previous profiles. An IFD used only to specify the
default image color for a layer and strip will not have any
encoded image data associated with it, i.e., the StripByteCounts
field will contain a 0. Since no image data exists in the IFD,
the Compression field shall be set to 1, indicating no
compression. A Compression field value of 1 is not allowed for
any other IFDs.
FillOrder(266) = 1 , 2.
SHORT
RequiredByTIFFBaseline
Profile M readers must be able to read data in both bit orders,
but the vast majority of facsimile products store data LSB first,
exactly as it appears on the telephone line
1 = Most Significant Bit first.
2 = Least Significant Bit first.
PhotometricInterpretation(262) = 0, 2, 10.
SHORT
For Mask layer, 0. For Foreground and Background layers, see
Sections 6.2.1 and 7.2.1.
ResolutionUnit(296) = 2.
SHORT
The unit of measure for resolution. 2 = inch.
ITU-T standards only specify inch-based resolutions for color fax
Default = 2 (field may be omitted if this is the value).
StripByteCounts(279)
SHORT or LONG
In Profile M, it is permissible for the StripByteCounts value for
a given strip to have a zero entry. This means there is no
encoded image data corresponding to that strip. Instead, the
current default image color should be used for the strip. The
standard default image colors are black for the Foreground layer
and White for the Background layer. The ImageBaseColor field can
be used to specify other default colors; see Section 8.2.3.
Buckley, et al. Standards Track [Page 65]
RFC 3949 File Format for Internet Fax February 2005
XResolution(282) = 100, 200, 300, 400.
RATIONAL
YResolution(283) = 100, 200, 300, 400.
RATIONAL
The resolution of the image is expressed in pixels per resolution
unit. In pixels per inch, allowed XResolution values for all
layers are 100, 200, 300, and 400. Color fax requires the pixels
to be square, hence YResolution must equal XResolution for all
layers. The resolution of Background and Foreground layers must
each be an integer factor of the Primary image, which is the Mask
layer, when it is present; see Section 8.4.
8.2.2. Extension Fields
ChromaSubSampling(530).
SHORT
ChromaPositioning(531).
SHORT
For Foreground and Background layers, see Section 6.2.2.
Indexed(346) = 0, 1.
SHORT
For Foreground and Background layers: 1 indicates a palette-color
image; see Section 7.2.2.
T4Options(292) = 0, 1, 4, 5.
SHORT
T6Options(293) = 0.
SHORT
For Mask layer, see Section 4.2.2.
SubIFDs(330).
IFD
Count = number of child IFDs. Each value is an offset from the
beginning of the TIFF file to a child IFD [TTN1].
XPosition(286).
RATIONAL
YPosition(287).
RATIONAL
Specifies the horizontal and vertical offsets of the top left of
the IFD from the top left of the Primary IFD in resolution units.
For example, if the Primary IFD is at 400 pixels per inch, and a
foreground layer IFD is at 200 pixels per inch and located at
pixel coordinate (345, 678) with respect to the Primary IFD, the
XPosition value is 345/400 and the YPosition value is 678/400 in
inches.
Buckley, et al. Standards Track [Page 66]
RFC 3949 File Format for Internet Fax February 2005
The Primary IFD does not use the XPosition or YPosition fields.
The XPosition and YPosition values must be specified for MRC child
IFDs; there is no default value.
8.2.3. New Fields
Decode(433).
SRATIONAL
For Foreground and Background layers, see Section 6.2.3.
T82Options(435)
LONG
For Mask layer, see Section 5.2.3.
ImageBaseColor(434).
SHORT
Count = SamplesPerPixel
In areas of an image layer where no image data is available (i.e.,
where no strips are defined, or where the StripByteCounts entry for
a given strip is 0), the color specified by ImageBaseColor will be
used.
If the ImageBaseColor field is used in an IFD that contains image
data encoded in ITU L*a*b*, then the ImageBaseColor will be
interpreted with the color-encoding parameters of the image data
(i.e., color gamut, illuminant, bit/sample, and decode). If the
ImageBaseColor field is used in an IFD that contains image data that
is not encoded in ITU L*a*b, then the ImageBaseColor SHALL be
interpreted as 8 bits/sample, 3 samples/pixel ITU L*a*b*. If the
ImageBaseColor field is used in an IFD that contains no encoded
image data, then the ImageBaseColor SHALL be interpreted as 8
bits/sample, 3 samples/pixel ITU L*a*b*. If the fax data stream
requires a different encoding, then transferring the default color
value between a TIFF file and fax data stream requires a color
conversion.
A [T.44] stripe may contain a Foreground or Background image less
than full stripe size, with the rest of the stripe assuming a
default image color. In this case, the default image color is imaged
first, followed by the image data. In Profile M, this is represented
as a child IFD containing no encoded image data but specifying the
default image color in the ImageBaseColor field. A second child IFD
contains the image data. To ensure the default image color is imaged
first, the order value in the ImageLayer field of the IFD defining
the ImageBaseColor field MUST have a lower value than the order
value in the ImageLayer field of the IFD defining the image data.
Buckley, et al. Standards Track [Page 67]
RFC 3949 File Format for Internet Fax February 2005
To define a child IFD specifying a ImageBaseColor but containing no
encoded image data, create an IFD with the following settings.
ImageLayer[0]: specified layer
ImageLayer[1]: less than any other IFDs corresponding
to the same layer and strip.
RowsPerStrip: strip height
ImageLength: strip height
ImageWidth: full image width
BitsPerSample: 8
PhotometricInterpretation: 10 (ITULAB)
SamplesPerPixel: 3
Compression: 1 (none)
X/YResolution: that of the Primary IFD
XPosition: 0
YPosition: the offset from the top of the page to
the beginning of the strip in the
resolution units of inches
StripByteCounts: single 0 value
StripOffsets: single 0 entry
NewSubFileType: bit 4 O (MRC)
ImageBaseColor: desired color in 8 bit ITULAB
For the Foreground layer image, the default value for the
ImageBaseColor field is black. For other cases, including the
Background layer image, the default value is white.
StripRowCounts(559).
LONG
Count = number of strips.
The number of scanlines stored in a strip. Profile M allows each
fax strip to store a different number of scanlines. For strips
with more than one layer, the maximum strip size is either 256
scanlines or full page size. The 256 maximum SHOULD be used
unless the capability to receive longer strips has been
negotiated. This field replaces RowsPerStrip for IFDs with
variable-size strips. Only one of the two fields, StripRowCounts
and RowsPerStrip, may be used in an IFD.
ImageLayer (34732).
LONG
Count = 2.
Image layers are defined such that layer 1 is the Background
layer, layer 3 is the Foreground layer, and layer 2 is the Mask
layer, which selects pixels from the Background and Foreground
layers. The ImageLayer tag contains two values, which describe
the layer to which the image belongs and the order in which it is
imaged.
Buckley, et al. Standards Track [Page 68]
RFC 3949 File Format for Internet Fax February 2005
ImageLayer[0] = 1, 2, 3.
1: Image is a Background image, i.e., the image that will appear
whenever the Mask contains a value of 0. Background images
typically contain low-resolution, continuous-tone imagery.
2: Image is the Mask layer. In MRC, if the Mask layer is present,
it must be the Primary IFD and be full page in extent.
3: Image is a Foreground image, i.e., the image that will appear
whenever the Mask contains a value of 1. The Foreground image
generally defines the color of text or lines but may also
contain high-resolution imagery.
ImageLayer[1]:
1: first image to be imaged in this layer
2: second image to be imaged in this layer
3: ...
In Profile M, more than one image can exist in a single layer.
ImageLayer[1] specifies the order in which images within a single
layer are to be imaged. This insures that overlapping images
within a single layer are imaged correctly.
If an IFD contains no encoded image data and is used only to
specify the ImageBaseColor field, the value of ImageLayer[1] must
be less than that of any other IFD corresponding to the same layer
and strip to ensure the image data is interpreted as on top of the
default color.
In Profile M, it is possible to have only a single layer. For
example, if a page contains only a single continuous-tone
photograph, then only the Background layer would occur. In this
case, the Background layer will be stored as the Primary IFD.
ImageLayer[0] will be 1, indicating Background; ImageLayer[1] will
be 1, as there can be no other IFDs associated with that layer.
No Mask layer will exist.
8.3. Recommended TIFF Fields
See Sections 2.2.3. and 2.2.4.
8.4. Rules and Requirements for Images
Profile M defines a fundamental set of rules for images in the 3
layer representation.
Buckley, et al. Standards Track [Page 69]
RFC 3949 File Format for Internet Fax February 2005
1. If more than one layer exists, then the binary Mask layer SHALL be
present and be the primary image. The Mask layer SHALL support
the binary data representations defined in Section 3 and MAY
support those defined in Sections 4 and 5, with the exception that
PhotometricInterpretation MUST be 0. If only one layer exists,
then the image corresponding to that layer is the primary image.
2. The Primary IFD defines and extends to the entire page boundary;
all attached model images cannot extend beyond the Primary image.
Resolution differences may cause some pixels to "hang over" the
page boundary, but no new pixels should exist completely beyond
the page extent.
3. The Background and Foreground images SHALL support the color
representations defined in Section 6 and MAY support those defined
in Section 7. These images MAY optionally cover only a portion of
the strip or page.
4. Each Primary IFD and each MRC-specific SubIFD must have an
ImageLayer field to specify which layer the IFD belongs to, and
the imaging order of that IFD within the layer.
5. Each Primary IFD must have a NewSubFileType field value set to 18,
indicating a single page of a multi-page document (bit 1) and MRC
(bit 4).
6. Each MRC-specific child IFD must have a NewSubFileType field value
set to 16, indicating MRC (bit 4).
7. In MRC fax, each layer is transmitted as a sequence of strips. If
the page consists of a single layer, then all strips shall be
stored in the single Primary IFD. In this case, coding parameters
cannot change between strips. If the page consists of more than
one layer, then all strips of the Mask layer shall be stored in
the single Primary IFD. All strips of the Foreground/Background
layers SHALL be stored in separate IFDs, referenced by the Primary
IFD's SubIFD field, containing an ImageLayer field with
ImageLayer[0] identifying either Background (layer 1) or
Foreground (layer 3), and Imagelayer[1] identifying order in which
images within a single layer are to be imaged. The TIFF XPosition
and YPosition fields are used to indicate the placement of these
images with respect to the primary image.
8. When the Mask image is present, the resolution of Background and
Foreground images must each be an integer factor of the Mask
image. For example, if the Mask image is 400 pixels/inch, then
the Background or Foreground image may be at 400 pixels/inch
(400/1), 200 pixels/inch (400/2), or 100 pixels/inch (400/4).
Buckley, et al. Standards Track [Page 70]
RFC 3949 File Format for Internet Fax February 2005
8.5. Profile M: MRC Fax Profile Summary
Recommended fields are shown with an asterisk (*).
Required fields or values are shown with a double asterisk (**). If
the double asterisk is on the field name, then all the listed values
are required of implementations; if the double asterisk is in the
Values column, then only the values suffixed with a double asterisk
are required of implementations.
+------------------+-----------------------------------------+
| Baseline Fields | Values |
+------------------+-----------------------------------------+
| BitsPerSample | 1**: binary mask, RGB, CMY(K) |
| | 2 - 8**: bits per color sample |
| | 9 - 12: optional 12 bits/sample |
+------------------+-----------------------------------------+
| Compression | 1: None (ImageBaseColor IFD only) |
| | 3**: Modified Huffman and Modified READ |
| | 4: Modified Modified READ |
| | 7**: JPEG |
| | 9: JBIG, per T.85 |
| | 10: JBIG, per T.43 |
+------------------+-----------------------------------------+
| DateTime* | {ASCII): date/time in the 24-hour format|
| | "YYYY:MM:DD HH:MM:SS" |
+------------------+-----------------------------------------+
| FillOrder** | 1: Most significant bit first |
| | 2: Least significant bit first |
+------------------+-----------------------------------------+
| ImageDescription*| {ASCII}: A string describing the |
| | contents of the image. |
+------------------+-----------------------------------------+
| ImageWidth | 864, 1024, 1216, 1728**, 2048, 2432, |
| | 2592, 3072, 3456, 3648, 4096, 4864 |
| | Note: legal widths for the Primary IFD. |
+------------------+-----------------------------------------+
| ImageLength** | n: total number of scanlines in image |
+------------------+-----------------------------------------+
| NewSubFileType** | 16, 18: |
| | Bit 1 indicates single page of a multi- |
| | page document on Primary IFD |
| | Bit 4 indicates MRC model |
+------------------+-----------------------------------------+
Buckley, et al. Standards Track [Page 71]
RFC 3949 File Format for Internet Fax February 2005
+------------------+-----------------------------------------+
| Orientation | 1**-8, Default 1 |
+------------------+-----------------------------------------+
| PhotometricInter | 0**: WhiteIsZero (Mask Layer) |
| pretation | 2: RGB |
| | 10**: ITULAB |
+------------------+-----------------------------------------+
| ResolutionUnit** | 2: inch |
+------------------+-----------------------------------------+
| RowsPerStrip | n: number or scanlines per strip |
+------------------+-----------------------------------------+
| SamplesPerPixel | 1**: L* (lightness) |
| | 3: RGB, LAB, CMY |
| | 4: CMYK |
+------------------+-----------------------------------------+
| Software* | {ASCII}: name & release number of |
| | creator software |
+------------------+-----------------------------------------+
| StripByteCounts**| <n>: number or bytes in each strip |
+------------------+-----------------------------------------+
| StripOffsets** | <n>: offset from beginning of file to |
| | each TIFF strip |
+------------------+-----------------------------------------+
| XResolution | 100, 200**, 300, 400 (written in |
| | pixels/inch) |
+------------------+-----------------------------------------+
| YResolution | equal to XResolution (pixels must be |
| | square) |
+------------------+-----------------------------------------+
| Extension Fields |
+------------------+-----------------------------------------+
| T4Options | 0**: required if Compression is Modified|
| | Huffman, EOLs not byte aligned |
| | 1: required if Compression 2D Modified |
| | READ, EOLs are not byte aligned |
| | 4**: required if Compression Modified |
| | Huffman, EOLs byte aligned |
| | 5: required if Compression 2D Modified |
| | READ, EOLs are byte aligned |
+------------------+-----------------------------------------+
| T6Options | 0: required if Compression is 2D |
| | Modified Modified READ |
+------------------+-----------------------------------------+
| DocumentName* | {ASCII}: name of scanned document |
+------------------+-----------------------------------------+
| PageNumber** | n,m: page number followed by total page |
| | count |
+------------------+-----------------------------------------+
Buckley, et al. Standards Track [Page 72]
RFC 3949 File Format for Internet Fax February 2005
+------------------+-----------------------------------------+
| ChromaSubSampling| (1,1), (2, 2)** |
| | (1, 1): equal numbers of lightness and |
| | chroma samples horizontally & vertically|
| | (2, 2): twice as many lightness samples |
| | as chroma horizontally and vertically |
+------------------+-----------------------------------------+
| ChromaPositioning| 1: centered |
+------------------+-----------------------------------------+
| Indexed | 0: not a palette-color image |
| | 1: palette-color image |
+------------------+-----------------------------------------+
| SubIFDs | <IFD>: byte offset to FG/BG IFDs |
+------------------+-----------------------------------------+
| XPosition | horizontal offset in primary IFD |
| | resolution units |
+------------------+-----------------------------------------+
| YPosition | vertical offset in primary IFD |
| | resolution units |
+------------------+-----------------------------------------+
| New Fields |
+------------------+-----------------------------------------+
| Decode | minL, maxL, mina, maxa, minb, maxb: |
| | minimum and maximum values for L*a*b* |
+------------------+-----------------------------------------+
| ImageBaseColor | a,b,c: background color in ITULAB |
+------------------+-----------------------------------------+
| StripRowCounts | <n>: number of scanlines in each strip |
+------------------+-----------------------------------------+
| ImageLayer | n, m: layer number, imaging sequence |
| | (e.g., strip number) |
+------------------+-----------------------------------------+
| T82Options | 0: T.85 profile of T.82 coding |
+------------------+-----------------------------------------+
| GlobalParameters | IFD: global parameters IFD |
| IFD* | |
+------------------+-----------------------------------------+
| ProfileType* | n: type of data stored in TIFF file |
+------------------+-----------------------------------------+
| FaxProfile* | n: ITU-compatible fax profile |
+------------------+-----------------------------------------+
| CodingMethods* | n: compression algorithms used in file |
+------------------+-----------------------------------------+
| ModeNumber* | n: version of T.44 standard |
+------------------+-----------------------------------------+
| VersionYear* | byte sequence: year of ITU fax standard |
+------------------+-----------------------------------------+
Buckley, et al. Standards Track [Page 73]
RFC 3949 File Format for Internet Fax February 2005
9. MIME content-types image/tiff and image/tiff-fx
The MIME content-types image/tiff and image/tiff-fx are used for
TIFF-FX encoded image data, as defined in this document. [TIFF-REG]
and [TIFF-FX-REG] describe the registration of these MIME content-
types.
10. Security Considerations
This document describes a file format for Internet fax, which is a
series of profiles of TIFF for facsimile. As such, it does not
create any security issues not already identified in [TIFF-REG], in
its use of fields as defined in [TIFF]. There are also new TIFF
fields defined within this specification, but they are of a purely
descriptive nature, so no new security risks are incurred.
Further, the encoding specified in this document does not in any way
preclude the use of any Internet security protocol to encrypt,
authenticate, or non-repudiate TIFF-encoded facsimile messages.
11. References
11.1. Normative References
[REQ] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[T.4] ITU-T Recommendation T.4, Standardization of group 3
facsimile apparatus for document transmission, October
1997.
[T.6] ITU-T Recommendation T.6, Facsimile coding schemes and
coding control functions for group 4 facsimile
apparatus, November 1988
[T.30] ITU-T Recommendation T.30 - Procedures for Document
Facsimile Transmission in the General Switched
Telephone Network, June 1996
[T.42] ITU-T Recommendation T.42, Continuous-tone colour
representation method for facsimile, February 1996
[T.43] ITU-T Recommendation T.43, Colour and gray-scale image
representations using lossless coding scheme for
facsimile, February 1997
[T.44] ITU-T Recommendation T.44, Mixed Raster Content (MRC),
April 1999.
Buckley, et al. Standards Track [Page 74]
RFC 3949 File Format for Internet Fax February 2005
[T.81] ITU-T Recommendation T.81, Information technology -
Digital compression and coding of continuous-tone still
images - Requirements and guidelines, September 1992
[T.85] ITU-T Recommendation T.85, Application profile for
Recommendation T.82 - Progressive bi-level image
compression (JBIG coding scheme) for facsimile
apparatus, August 1995
[T.82] ITU-T Recommendation T.82, Information technology -
Coded representation of picture and audio information -
Progressive bi-level image compression, March 1995
[TIFF] Tag Image File Format, Revision 6.0, Adobe Developers
Association, June 3, 1992,
http://partners.adobe.com/public/developers/en/tiff/
TIFF6.pdf
The TIFF 6.0 specification dated June 3, 1992
specification (c) 1986-1988, 1992 Adobe Systems
Incorporated. All Rights Reserved.
[TIFF-F0] TIFF Class F specification, Apr 28, 1990,
ftp://ftp.faximum.com/pub/documents/tiff_f.txt
[TIFF-REG] Parsons, G. and J. Rafferty, "Tag Image File Format
(TIFF) - image/tiff MIME Sub-type Registration", RFC
3302, September 2002.
[TTN1] Adobe PageMaker 6.0 TIFF Technical Notes, Sept. 14,
1995,
http://partners.adobe.com/public/developers/en/tiff/
TIFFPM6.pdf
[TTN2] Draft TIFF Technical Note 2, Replacement TIFF/JPEG
specification, March 17, 1995,
ftp://ftp.uu.net/graphics/jpeg/
[TIFF-FX-REG] McIntyre, L., Parsons, G., and J. Rafferty, "Tag Image
File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME
Sub-type Registration", RFC 3250, September 2002.
Buckley, et al. Standards Track [Page 75]
RFC 3949 File Format for Internet Fax February 2005
11.2. Informative References
[GUIDE] Cancio, V., Moldovan, M., Tamura, H., and D. Wing,
"Implementers Guide for Facsimile Using Internet Mail",
RFC 3249, September 2002.
[TIFF-F] Parsons, G. and J. Rafferty, "Tag Image File Format
(TIFF) - F Profile for Facsimile", RFC 2306, March
1998.
[VPIM 2] Vaudreuil G. and G. Parsons, "Voice Profile for
Internet Mail - version 2 (VPIMv2)", RFC 3801, June
2004.
Buckley, et al. Standards Track [Page 76]
RFC 3949 File Format for Internet Fax February 2005
Annex A: Summary of TIFF Fields for Internet Fax
This annex includes tables which list by profile the TIFF fields used
in the proposed fax file format. The fields are organized into 3
categories:
1) TIFF Baseline Fields
2) TIFF Extension Fields
3) New Fields.
The tables include the allowed values for each fax profile. Entries
other than explicit numbers are described by:
n - single number
n, m - 2 numbers
a, b, c - 3 numbers
r - rational number
<n> - array of numbers
<b> - byte sequence
{ASCII} - string
IFD - IFD byte offset
<IFD> - array of IFD byte offsets
A blank entry in the table indicates that the field is not used by
that particular fax profile.
Table A.1 TIFF Baseline Fields
+---------------------------------------------------------+
| Fax Profile |
+---------------------------------------------------------|
| Minimal | Extended | JBIG | Lossy |Lossless| Mixed |
+----------| B&W | B&W | B&W | Color | Color | Raster |
| TIFF | | | | | | Content|
| Field | S | F | J | C | L | M |
+----------+---------+----------+--------+---------+--------+--------+
| BitsPer | 1 | 1 | 1 | 8 | 1, 2-8 | 1, 2-8 |
| Sample | | | | | 9-12 | 9-12 |
+----------+---------+----------+--------+---------+--------+--------+
| Compres- | 3 | 3, 4 | 9 | 7 | 10 | 3, 4, 7|
| sion | | | | | | 9,10 |
+----------+---------+----------+--------+---------+--------+--------+
| DateTime | | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII}|
+----------+---------+----------+--------+---------+--------+--------+
| FillOrder| 2 | 1, 2 | 1, 2 | 1, 2 | 1, 2 | 1,2 |
+----------+---------+----------+--------+---------+--------+--------+
Buckley, et al. Standards Track [Page 77]
RFC 3949 File Format for Internet Fax February 2005
+----------+---------+----------+--------+---------+--------+--------+
| ImageDes-| | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII}|
| cription | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Image- | n | n | n | n | n | n |
| Length | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Image- | 1728 | 1728, 2048, 2432 | 864, 1024, 1216, 1728, |
| Width | | 2592, 3072, 3456 | 2048, 2432, 2592, 3072, |
| | | 3648, 4096, 4864 | 3456, 3648, 4096, 4864 |
| | | Note, for the Mixed Raster Content M profile |
| | | these widths apply to the Primary IFD. |
+----------+---------+----------+--------+---------+--------+--------+
| NewSub- | 2 | 2 | 2 | 2 | 2 | 16, 18 |
| FileType | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Orien- | 1 | 1-8 | 1-8 | 1-8 | 1-8 | 1-8 |
| tation | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Photo- | 0 | 0, 1 | 0, 1 | 10 | 2, 5, | 0, |
| metric- | | | | | 10 | 2, |
| Interp- | | | | | | 10 |
| retation | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Resolu- | 2 | 2, 3 | 2, 3 | 2, 3 | 2, 3 | 2, 3 |
| tionUnit | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| RowsPer- | n | n | n | n | n | n |
| Strip | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Samples- | 1 | 1 | 1 | 1, 3 | 1, 3, 4| 1, 3, 4|
| PerPixel | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Software | | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII}|
+----------+---------+----------+--------+---------+--------+--------+
| Strip- | n | <n> | <n> | <n> | <n> | <n> |
| Byte- | | | | | | |
| Counts | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Strip- | n | <n> | <n> | <n> | <n> | <n> |
| Offsets | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| XResolu- | 204 | 200, 204, 300 | 100, 200, 300, 400 |
| tion | 200 | 400, 408 | |
+----------+---------+----------+--------+---------+--------+--------+
| YResolu- | 98, 196 | 98, 196, 100, 200 | 100, 200, 300, 400 |
| tion | 100,200 | 300, 391, 400 | |
+----------+---------+----------+--------+---------+--------+--------+
Buckley, et al. Standards Track [Page 78]
RFC 3949 File Format for Internet Fax February 2005
Table A.2 TIFF Extension Fields
+---------------------------------------------------------+
| Fax Profile |
+---------------------------------------------------------|
| Minimal | Extended | JBIG | Lossy |Lossless| Mixed |
+----------| B&W | B&W | B&W | Color | Color | Raster |
| TIFF | | | | | | Content|
| Field | S | F | J | C | L | M |
+----------+---------+----------+--------+---------+--------+--------+
| Chroma- | | | | 1 | | 1 |
| Position-| | | | | | |
| ing | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Chroma- | | | | <1, 1> | | <1, 1> |
| SubSampl-| | | | <2, 2> | | <2, 2> |
| ing | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Document-| | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII}|
| Name | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Indexed | | | | | 0,1 | 0,1 |
+----------+---------+----------+--------+---------+--------+--------+
| Page- | n, m | n, m | n, m | n, m | n, m | n, m |
| Number | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| SubIFDs | | | | | | <IFD> |
+----------+---------+----------+--------+---------+--------+--------+
| T4Options| 0, 4 | 0, 1, | | | | 0, 1, |
| | | 4, 5 | | | | 4, 5 |
+----------+---------+----------+--------+---------+--------+--------+
| T6Options| | 0 | | | | 0 |
+----------+---------+----------+--------+---------+--------+--------+
| XPosition| | | | | | r |
+----------+---------+----------+--------+---------+--------+--------+
| YPosition| | | | | | r |
+----------+---------+----------+--------+---------+--------+--------+
Buckley, et al. Standards Track [Page 79]
RFC 3949 File Format for Internet Fax February 2005
Table A.3 New Fields
+---------------------------------------------------------+
| Fax Profile |
+---------------------------------------------------------|
| Minimal | Extended | JBIG | Lossy |Lossless| Mixed |
+----------| B&W | B&W | B&W | Color | Color | Raster |
| TIFF | | | | | | Content|
| Field | S | F | J | C | L | M |
+----------+---------+----------+--------+---------+--------+--------+
| BadFax- | | n | | | | |
| Lines | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| CleanFax-| | 0, 1, 2 | | | | |
| Data | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Coding- | | | n | n | n | n |
| Method | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Consecu- | | n | | | | |
| tiveBad- | | | | | | |
| FaxLines | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Decode | | | | <r> | <r> | <r> |
+----------+---------+----------+--------+---------+--------+--------+
| Fax- | | | n | n | n | n |
| Profile | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Global- | | IFD | IFD | IFD | IFD | IFD |
| Parame- | | | | | | |
| tersIFD | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Image- | | | | | | n, m |
| Layer | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| T82- | | | n | | | n |
| Options | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Image- | | | | | | <n> |
| BaseColor| | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Mode- | | | | | | n |
| Number | | | | | | |
+----------+---------+----------+--------+---------+--------+--------|
| Profile- | | | n | n | n | n |
| Type | | | | | | |
+--------------------------------------------------------------------+
Buckley, et al. Standards Track [Page 80]
RFC 3949 File Format for Internet Fax February 2005
+----------+---------+----------+--------+---------+--------+--------+
| Strip- | | | | | | <n> |
| RowCounts| | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Version- | | | | <b> |<b> | |
| Year | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
Annex B: List of technical edits to RFC2301
This Annex lists technical differences between this document and
RFC 2301, the Proposed Standard File Format for Internet Fax.
+----+---------+-------------------------------------------------+
| No.| Section | Technical Edit |
+----+---------+-------------------------------------------------+
| 1. | 5.2.1 | Added FillOrder=1 to Profile J |
+----+---------+-------------------------------------------------+
| 2. | 6.2.1 | Constrained ResolutionUnit to 2 (i.e., inch) for|
| | 7.2.1 | all color profiles, per ITU-T Recommendations |
| | 8.2.1 | |
+----+---------+-------------------------------------------------+
| 3. | 7.2.1 | Deleted ColorMap field; it re-encoded the color |
| | 7.4 | palette already in the T.43 data stream |
+----+---------+-------------------------------------------------+
| 4. | 7.2.2 | Changed TAG value of Indexed field from 364 to |
| | | 346 to agree with Section 8.2.2 and Ref. [TTN1] |
+----+---------+-------------------------------------------------+
| 5. | 8.2.1 | Added text clarifying the use of ImageWidth |
| | | when Background or Foreground layer is Primary |
| | | IFD |
+----+---------+-------------------------------------------------+
| 6. | 8.2.3 | Changed field name from DefaultImageColor to |
| | | ImageBaseColor; |
+----+---------+-------------------------------------------------+
| 7. | 8.2.1 | Added Compression=1 for ImageBaseColor IFDs |
+----+---------+-------------------------------------------------+
| 8. | 5.2.1 | Redefined compression = 9 to be T.82 (JBIG); |
| | 5.2.3 | added T82Options field, with a default value (0)|
| | | corresponding to the T.85 application profile |
+----+---------+-------------------------------------------------+
| 9. | 4.3.3 | Added GlobalParametersIFD, ProfileType, |
| | 4.7 | FaxProfile and CodingMethod to the New Fields |
| | | portion of Profile F, per Sec. 2.2.4 |
+----+---------+-------------------------------------------------+
Buckley, et al. Standards Track [Page 81]
RFC 3949 File Format for Internet Fax February 2005
+----+---------+-------------------------------------------------+
| 10.| 6.2.1 | Deleted BitsPerSample=12 as an option when |
| |6.2.3,6.4| Compression=7 due to lack of interop testing. |
| |Table A.1| |
+----+---------+-------------------------------------------------+
| 11.|8.2.1,8.4| Deleted PhotometricInterpretation=5 in Profile M|
| |Table A.1| due to insufficient interop testing. |
+----+---------+-------------------------------------------------+
| 12.|7.2.1,7.4| Deleted BitsPerSample=13-16 for Palette-color |
| |8.2.1,8.5| due to lack of interop testing. |
| |Table A.1| |
+----+---------+-------------------------------------------------+
| 13.| Annex B | Deleted Annex B due to discontinued use of |
| | | application parameter; Annex C renamed Annex B |
+----+---------+-------------------------------------------------+
Authors' Addresses
Robert Buckley
Xerox Corporation
Mailstop 0128-30E
800 Phillips Road
Webster, NY 14580, USA
Phone: +1-585-422-1282
Fax: +1-585-422-2636
EMail: rbuckley@crt.xerox.com
Dennis Venable
Xerox Corporation
Mailstop 0128-27E
800 Phillips Road
Webster, NY 14580, USA
Phone: +1-585-422-3138
Fax: +1-585-422-6117
EMail: dvenable@crt.xerox.com
Buckley, et al. Standards Track [Page 82]
RFC 3949 File Format for Internet Fax February 2005
Lloyd McIntyre
10328 S. Stelling Road
Cupertino, CA 95014 USA
Phone: +1-408-725-1624
EMail: lloyd10328@pacbell.net or
Lloyd_McIntyre@Dell.com
Glenn W. Parsons
Nortel Networks
P.O. Box 3511, Station C
Ottawa, ON K1Y 4H7, Canada
Phone: +1-613-763-7582
Fax: +1-613-967-5060
EMail: gparsons@nortel.com
James Rafferty
Brooktrout Technology
410 First Avenue
Needham, MA 02494 USA
Phone: +1-781-433-9462
Fax: +1-781-433-9268
EMail: jraff@brooktrout.com
Buckley, et al. Standards Track [Page 83]
RFC 3949 File Format for Internet Fax February 2005
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Buckley, et al. Standards Track [Page 84]