summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2531.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2531.txt')
-rw-r--r--doc/rfc/rfc2531.txt2859
1 files changed, 2859 insertions, 0 deletions
diff --git a/doc/rfc/rfc2531.txt b/doc/rfc/rfc2531.txt
new file mode 100644
index 0000000..01487ab
--- /dev/null
+++ b/doc/rfc/rfc2531.txt
@@ -0,0 +1,2859 @@
+
+
+
+
+
+
+Network Working Group G. Klyne
+Request for Comments: 2531 5GM/Content Technologies
+Category: Standards Track L. McIntyre
+ Xerox Corporation
+ March 1999
+
+
+ Content Feature Schema for Internet Fax
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+Abstract
+
+ This document defines a content feature schema that is a profile of
+ the media feature registration mechanisms [1,2,3] for use in
+ performing capability identification between extended Internet fax
+ systems [5].
+
+ This document does not describe any specific mechanisms for
+ communicating capability information, but does presume that any such
+ mechanisms will transfer textual values. It specifies a textual
+ format to be used for describing Internet fax capability information.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 1]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+Table of Contents
+
+ 1. Introduction .............................................3
+ 1.1 Organization of this document............................3
+ 1.2 Terminology and document conventions.....................3
+ 2. Fax feature schema syntax ................................4
+ 3. Internet fax feature tags ................................4
+ 3.1 Image size...............................................5
+ 3.2 Resolution...............................................5
+ 3.3 Media type...............................................6
+ 3.4 Paper Size...............................................6
+ 3.5 Color capability.........................................6
+ 3.6 Color model..............................................8
+ 3.7 Image coding............................................10
+ 4. Examples ................................................12
+ 4.1 Simple mode Internet fax system.........................12
+ 4.2 High-end black-and-white Internet fax system............12
+ 4.3 Grey-scale Internet fax system..........................13
+ 4.4 Full-color Internet fax system..........................13
+ 4.5 Full-color Internet fax system (MRC)....................14
+ 4.6 Sender and receiver feature matching....................15
+ 5. IANA Considerations .....................................17
+ 6. Security Considerations .................................17
+ 6.1 Capability descriptions and mechanisms..................17
+ 6.2 Specific threats........................................18
+ 7. Acknowledgements ........................................18
+ 8. References ..............................................18
+ 9. Authors' Addresses ......................................21
+ Appendix A: Feature registrations ..........................22
+ A.1 Image size..............................................22
+ A.2 Resolution aspect ratio.................................24
+ A.3 Color levels............................................25
+ A.4 Color space.............................................27
+ A.5 CIELAB color depth......................................30
+ A.6 CIELAB color gamut......................................32
+ A.7 Image file structure....................................34
+ A.8 Image data coding.......................................36
+ A.9 Image coding constraint.................................38
+ A.10 JBIG stripe size.......................................39
+ A.11 Image interleave.......................................41
+ A.12 Color subsampling......................................42
+ A.13 MRC availability and mode..............................43
+ A.14 MRC maximum stripe size................................45
+ Appendix B: TIFF mode descriptions .........................47
+ Appendix C: Revision history ...............................49
+ Full Copyright Statement ...................................51
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 2]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+1. Introduction
+
+ This document defines a content feature schema that is a profile of
+ the media feature registration mechanisms [1,2,3] for use in
+ performing capability identification between extended Internet fax
+ systems [5].
+
+ This document does not describe any specific mechanisms for
+ communicating capability information, but does presume that any such
+ mechanisms will transfer textual values. It specifies a textual
+ format to be used for describing Internet fax capability information.
+
+ The range of capabilities that can be indicated are based on those
+ covered by the TIFF file format for Internet fax [7] and Group 3
+ facsimile [6]. A companion document [4] describes the relationship
+ and mapping between this schema and Group 3 fax capabilities.
+
+1.1 Organization of this document
+
+ Section 2 specifies the overall syntax for fax feature descriptions
+ by reference to the media feature registration and syntax documents
+ [1,2].
+
+ Section 3 enumerates the feature tags that are to be recognized and
+ processed by extended Internet fax systems, according to their
+ capabilities.
+
+ Appendix A contains additional feature tag registrations for media
+ features that are specific to fax and for which no applicable
+ registration already exists. These are presented in the form
+ prescribed by the media feature registration procedure [1].
+
+1.2 Terminology and document conventions
+
+ The term "extended Internet fax system" is used to describe any
+ software, device or combination of these that conforms to the
+ specification "Extended Facsimile Using Internet Mail" [5].
+
+ "capability exchange" describes any transfer of information between
+ communicating systems that is used to indicate system capabilities
+ and hence determine the form of data transferred. This term covers
+ both one-way and two-way transfers of capability information.
+
+ "capability identification" is a particular form of capability
+ exchange in which a receiving system provides capability information
+ to a sending system.
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 3]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ "capability description" is a collection of data presented in some
+ specific format that describes the capabilities of some communicating
+ entity. It may exist separately from any specific capability
+ exchange mechanism.
+
+ NOTE: Comments like this provide additional nonessential
+ information about the rationale behind this document. Such
+ information is not needed for building a conformant
+ implementation, but may help those who wish to understand the
+ design in greater depth.
+
+2. Fax feature schema syntax
+
+ The syntax for the fax feature schema is described by "A syntax for
+ describing media feature sets" [2]. This in turn calls upon media
+ feature tags that may be registered according to the procedure
+ described in "Media Feature Tag Registration Procedure" [1].
+
+ NOTE: Media feature registration provides a base vocabulary of
+ features that correspond to media handling capabilities. The
+ feature set syntax provides a mechanism and format for combining
+ these to describe combinations of features. This memo indicates
+ those features that may be associated with extended Internet fax
+ systems.
+
+3. Internet fax feature tags
+
+ This section enumerates and briefly describes a number of feature
+ tags that are defined for use with extended Internet fax systems and
+ applications. These tags may be used also by other systems and
+ applications that support corresponding capabilities.
+
+ The feature tags presented below are those that an extended Internet
+ fax system is expected to recognize its ability or non-ability to
+ handle.
+
+ Definitive descriptions of feature tags are indicated by reference to
+ their registration per the media feature registration procedure [1]
+ (some of which are appended to this document)
+
+ NOTE: The presence of a feature tag in this list does not mean
+ that an extended Internet fax system must have that capability;
+ rather, it must recognize the feature tag and deal with it
+ according to the capabilities that it does have.
+
+
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 4]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ Further, an extended Internet fax system is not prevented from
+ recognizing and offering additional feature tags. The list below
+ is intended to provide a basic vocabulary that all extended
+ Internet fax systems can use in a consistent fashion.
+
+ If an unrecognized or unused feature tag is received, the feature
+ set matching rule (described in RFC2533 [2]) operates so that tag
+ is effectively ignored.
+
+3.1 Image size
+
+ Feature tag name Legal values
+ ---------------- ------------
+ size-x <Rational> (>0)
+ size-y <Rational> (>0)
+
+ Reference: this document, Appendix A.
+
+ These feature values indicate a rendered document size in inches.
+
+ Where the actual size is measured in millimetres, a conversion
+ factor of 10/254 may be applied to yield an exact inch-based value.
+
+3.2 Resolution
+
+ Feature tag name Legal values
+ ---------------- ------------
+ dpi <Integer> (>0)
+ dpi-xyratio <Rational> (>0)
+
+ Reference: "Media Features for Display, Print, and Fax" [3], and this
+ document appendix A.
+
+ If 'dpi-xyratio' is present and not equal to 1 then the horizontal
+ resolution (x-axis) is indicated by the 'dpi' feature value, and the
+ vertical resolution (y-axis) is the value of 'dpi' divided by 'dpi-
+ xyratio'.
+
+ For example, the basic Group 3 fax resolution of 200*100dpi might be
+ indicated as:
+
+ (& (dpi=200) (dpi-xyratio=200/100) )
+
+ When describing resolutions for an MRC format document, the complete
+ set of usable resolutions is listed. However, there are some
+ restrictions on their use: (a) 100dpi resolution can be used only
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 5]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ with multi-level images, and (b) any multi-level image resolution is
+ required to be an integral sub-multiple of the applicable mask
+ resolution.
+
+3.3 Media type
+
+ Feature tag name Legal values
+ ---------------- ------------
+ ua-media screen
+ screen-paged
+ stationery
+ transparency
+ envelope
+ envelope-plain
+ continuous
+
+ Reference: "Media Features for Display, Print, and Fax" [3].
+
+ NOTE: Where the recipient indicates specific support for hard copy
+ or soft copy media type, a sender of color image data may wish to
+ adjust the color components (e.g. per the related rules of ITU
+ recommendation T.42 [9]) to improve rendered image quality on that
+ medium.
+
+3.4 Paper Size
+
+ Feature tag name Legal values
+ ---------------- ------------
+ paper-size A4
+ A3
+ B4
+ letter
+ legal
+
+ Reference: "Media Features for Display, Print, and Fax" [3].
+
+3.5 Color capability
+
+ Feature tag name Legal values
+ ---------------- ------------
+ color Binary (bi-level only)
+ Limited (a limited number of colors)
+ Mapped (palette or otherwise mapped color)
+ Grey (grey-scale only)
+ Full (full continuous-tone color)
+
+
+ Reference: "Media Features for Display, Print, and Fax" [3].
+
+
+
+Klyne & McIntyre Standards Track [Page 6]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ The intention here is to give a broad indication of color handling
+ capabilities that might be used, for example, to select among a small
+ number of available data resources.
+
+ The value of this feature also gives an indication of the more
+ detailed color handling features that might be applicable (see next
+ section).
+
+ 'Binary' indicates black-and-white, or other bi-level capability. No
+ further qualifying feature tags are required.
+
+ 'Limited' indicates a small number of distinct fixed colors, such as
+ might be provided by a highlight printer, pen plotter or limited
+ color display. The 'color-levels' tag should be used to indicate the
+ number of distinct colors available.
+
+ NOTE: No ability to indicate any specific or named color is
+ implied by this option.
+
+ Some devices might use different intensity levels rather than
+ different hues for distinction.
+
+ 'Mapped' indicates that pixel color values are mapped in some
+ specifiable way to a multi-component color space. The 'color-levels'
+ tag may be used to indicate the number of distinct colors available;
+ in its absence, sufficient levels to display a photographic image
+ should be assumed.
+
+ 'Grey' indicates a continuous tone grey-scale capability.
+
+ 'Full' indicates full continuous tone color capability.
+
+ For 'Mapped', 'Grey' and 'Full' color, additional feature tags
+ (section 3.6) may be used to further qualify the color reproduction.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 7]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+3.6 Color model
+
+ Feature tag name Legal values
+ ---------------- ------------
+ color-levels <integer> (>2)
+ color-space Device-RGB (device RGB)
+ Device-CMY (device CMY)
+ Device-CMYK (device CMYK)
+ CIELAB (LAB per T.42 [9])
+ (may be extended by further registrations)
+
+ CIELAB-L-depth <integer> (>0)
+ CIELAB-a-depth
+ CIELAB-b-depth
+ CIELAB-L-min <integer>
+ CIELAB-L-max
+ CIELAB-a-min
+ CIELAB-a-max
+ CIELAB-b-min
+ CIELAB-b-max
+
+ Reference: this document, appendix A.
+
+ The general model for image handling (both color and non-color) is
+ described here from a receiver's perspective; a similar model
+ operates in the reverse direction for a scan/send perspective:
+
+ raw bit pixel color physical
+ stream -(A)-> values -(B)-> values -(C)-> rendition
+
+ - "raw bit stream" is a stream of coded bits
+
+ (A) indicates image coding/decoding (MH,MR,MMR,JPEG,JBIG,etc.)
+
+ - "pixel values" are a single numeric value per picture element
+ that designates the color of that element.
+
+ (B) indicates pixel-to-color value mapping
+
+ - "color values" have a separate numeric value for each color
+ component (i.e. L*, a*, b* in the case of CIELAB indicated
+ above.)
+
+ (C) indicates how the color values are related to a physical
+ color. This involves interpretation of the color value with
+ respect to a color model (e.g. RGB, L*a*b*, CMY, CMYK) and a
+ color space (which is typically recipient-dependent).
+
+
+
+
+Klyne & McIntyre Standards Track [Page 8]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ - "physical rendition" is a color value physically realized on a
+ display, printer or other device.
+
+ There are many variables that can be applied at each stage of the
+ processing of a color image, and any may be critical to meaningful
+ handling of that image in some circumstances. In other circumstances
+ many of the variables may be implied (to some level of approximation)
+ in the application that uses them (e.g. color images published on a
+ Web page).
+
+ The color feature framework described here is intended to allow
+ capability description at a range of granularity: feature tags which
+ correspond to implied (or "don't care" or "unknown") feature values
+ may simply be omitted from a capability description.
+
+ Grey scale and bi-level images are handled within this framework as a
+ special case, having a 1-component color model. The following
+ features are used for describing color capabilities:
+
+ 'color-levels' indicates the number of distinct values for each
+ picture element, and applies to all but bi-level images. For bi-
+ level images, a value of 2 is implied.
+
+ 'color-space' is used mainly with 'Mapped' and 'Full', but could be
+ used with other modes if the exact color used is significant. Two
+ kinds of color space can be distinguished: device-dependent and
+ calibrated. Device dependent spaces are named here as 'Device-xxx',
+ and are used to indicate a color space that is defined by the
+ receiving device. Calibrated color spaces presume the existence of a
+ rendering system that is calibrated with respect to an indicated
+ definition, and is capable of processing the device-independent color
+ information accordingly.
+
+ A color-handling receiver should indicate any appropriate device
+ color space capability in addition to any calibrated color spaces
+ that it may support. A calibrated color space should be used when
+ precise color matching is required in the absence of specific
+ knowledge of the receiving system.
+
+ NOTE: In practice, although they appear to be separate concepts,
+ the color model and color space cannot be separated. In the final
+ analysis, a color model (RGB, CMY, etc.) must be defined with
+ respect to some color space.
+
+ 'CIELAB-L-depth', 'CIELAB-a-depth' and 'CIELAB-b-depth' indicate the
+ number of different values that are possible for the L*, a* and b*
+ color components respectively, and are significant only when colors
+
+
+
+
+Klyne & McIntyre Standards Track [Page 9]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ are represented in a CIELAB color space. These features would be
+ used with palettized color, or with full color where each color
+ component has a different number of possible values.
+
+ The 'CIELAB-x-min' and 'CIELAB-x-max' values indicate a color gamut
+ (i.e. a range of color values that are used or may be rendered). A
+ gamut may be indicated in terms of the CIELAB color space even when
+ colors are represented in some other space.
+
+3.7 Image coding
+
+ Feature tag name Legal values
+ ---------------- ------------
+ image-file- TIFF-S
+ structure TIFF-F
+ TIFF-J
+ TIFF-C
+ TIFF-L
+ TIFF-M
+ (may be extended by further registrations,
+ to cover non-TIFF image file structures)
+ image-coding MH
+ MR
+ MMR
+ JBIG
+ JPEG
+ (may be extended by further registrations)
+ image-coding- JBIG-T85 (bi-level, per ITU T.85)
+ constraint JBIG-T43 (multi-level, per ITU T.43)
+ JPEG-T4E (per ITU T.4, Annex E)
+ (may be extended by further registrations)
+ JBIG-stripe-size <Integer>
+ image-interleave Stripe
+ Plane
+ color-subsampling "1:1:1" (no color subsampling)
+ "4:1:1" (4:1:1 color subsampling)
+ MRC-mode <Integer> (0..7) (per ITU T.44 [15])
+ MRC-max-stripe-size <Integer>
+
+ Reference: this document, appendix A.
+
+ 'image-file-structure' defines how the coded image data is wrapped
+ and formatted. Options defined here are the various profiles of
+ TIFF-FX, per RFC 2301 [7]. These options apply to overall formatting
+ of the image data (TIFF file format, byte ordering, bit ordering,
+ etc.) and do not define specific image coding issues that are covered
+ by other aspects of the TIFF-FX profile specifications.
+
+
+
+
+Klyne & McIntyre Standards Track [Page 10]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ 'image-coding' describes how the raw image data is compressed and
+ coded as a sequence of bits. These are generic tags that may apply
+ to a range of file formats and usage environments.
+
+ 'image-coding-constraint' describes how the raw image data coding
+ method is constrained to meet a particular operating environment.
+ Options defined here are JBIG and JPEG coding constraints that apply
+ in typical Group 3 fax environments.
+
+ The 'JBIG-stripe-size' feature may be used with JBIG image coding,
+ and indicates the number of scan lines in each stripe except the last
+ in an image. The legal constraints are:
+
+ (JBIG-stripe-size=128)
+ (JBIG-stripe-size>=0)
+
+ The latter being equivalent to no restriction.
+
+ The 'MRC-mode' feature is used to indicate the availability of MRC
+ (mixed raster content) image format capability, and also the MRC mode
+ available. A zero value indicates MRC is not available, a non-zero
+ value indicates the available MRC mode number.
+
+ An MRC formatted document is actually a collection of several images,
+ each of which is described by a separate feature collection. An
+ MRC-capable receiver is presumed to be capable of accepting any
+ combination of contained images that conform to the MRC construction
+ rules and declared image-coding capabilities.
+
+ Within an MRC-formatted document, multi-level coders are used for
+ foreground and background images (i.e. odd-numbered layers: 1, 3, 5,
+ etc.) and bi-level coders are used for mask layers (i.e. even
+ numbered layers 2, 4, 6, etc.).
+
+ NOTE: an MRC formatted document may appear within a TIFF image
+ file structure, so this separate feature is needed to capture the
+ full range of possible capabilities.
+
+ The 'MRC-max-stripe-size' feature may be used with MRC coding, and
+ indicates the maximum number of scan lines in each MRC stripe. The
+ legal constraints are:
+
+ (MRC-max-stripe-size=[0..256])
+ (MRC-max-stripe-size>=0)
+
+ These values indicate upper bounds on the stripe size. The actual
+ value may vary between stripes, and the actual size for each stripe
+ is indicated in the image data.
+
+
+
+Klyne & McIntyre Standards Track [Page 11]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ NOTE: there are many image coding options here, and not all are
+ required in all circumstances.
+
+ Specification of the image-file-structure tag value alone is not
+ normally sufficient to describe the capabilities of a recipient.
+ A general rule is that sufficient detail should be provided to
+ exclude any unsupported features.
+
+ For extended Internet fax, image-file-structure and image-coding
+ should always be specified, together with additional values
+ described above as needed to clearly indicate which feature tag
+ values are supported and which are not. (See also the examples in
+ section 4.)
+
+4. Examples
+
+ Some of the examples contain comments introduced by '--...'. These
+ are not part of the allowed capability description syntax. They are
+ included here to explain some of the constructs used.
+
+ The level of detail captured here reflects that used for capability
+ identification in Group 3 facsimile.
+
+4.1 Simple mode Internet fax system
+
+ This example describes the capabilities of a typical simple mode
+ Internet fax system. Note that TIFF application S is required to be
+ supported by such a system.
+
+ (& (color=Binary)
+ (image-file-structure=TIFF-S)
+ (dpi=200)
+ (dpi-xyratio=[200/100,200/200])
+ (paper-size=A4)
+ (image-coding=MH) (MRC-mode=0)
+ (ua-media=stationery) )
+
+4.2 High-end black-and-white Internet fax system
+
+ This would include support for B/W JBIG and be equivalent to what is
+ sometimes called "Super G3", except that Internet fax functionality
+ would be added.
+
+
+
+
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 12]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ (& (color=Binary)
+ (image-file-structure=[TIFF-S,TIFF-F,TIFF-J])
+ (| (& (dpi=200) (dpi-xyratio=200/100) ) -- 200*100
+ (& (dpi=200) (dpi-xyratio=1) ) -- 200*200
+ (& (dpi=204) (dpi-xyratio=204/391) ) -- 204*391
+ (& (dpi=300) (dpi-xyratio=1) ) ) -- 300*300
+ (| (image-coding=[MH,MR,MMR])
+ (& (image-coding=JBIG)
+ (image-coding-constraint=JBIG-T85)
+ (JBIG-stripe-size=128) ) )
+ (MRC-mode=0)
+ (paper-size=[A4,B4]) )
+
+4.3 Grey-scale Internet fax system
+
+ This is the previous example extended to handle grey scale multi-
+ level images. In keeping with Group 3 fax, this example requires
+ equal x- and y- resolutions for a multi-level image.
+
+ (& (| (& (color=Binary)
+ (image-file-structure=[TIFF-S,TIFF-F,TIFF-J])
+ (| (image-coding=[MH,MR,MMR])
+ (& (image-coding=JBIG)
+ (image-coding-constraint=JBIG-T85)
+ (JBIG-stripe-size=128) ) )
+ (| (& (dpi=200) (dpi-xyratio=200/100) )
+ (& (dpi=200) (dpi-xyratio=1) )
+ (& (dpi=204) (dpi-xyratio=204/391) )
+ (& (dpi=300) (dpi-xyratio=1) ) ) )
+ (& (color=Grey)
+ (image-file-structure=[TIFF-C,TIFF-L])
+ (color-levels<=256)
+ (color-space-CIELAB)
+ (| (& (image-coding=JPEG)
+ (image-coding-constraint=JPEG-T4E) )
+ (& (image-coding=JBIG)
+ (image-coding-constraint=JBIG-T43)
+ (JBIG-stripe-size=128)
+ (image-interleave=stripe) ) )
+ (dpi=[100,200,300])
+ (dpi-xyratio=1) ) )
+ (MRC-mode=0)
+ (paper-size=[A4,B4]) )
+
+4.4 Full-color Internet fax system
+
+ This adds 16-bit full-color to the previous example.
+
+
+
+
+Klyne & McIntyre Standards Track [Page 13]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ (& (| (& (color=Binary)
+ (image-file-structure=[TIFF-S,TIFF-F,TIFF-J])
+ (| (image-coding=[MH,MR,MMR])
+ (& (image-coding=JBIG)
+ (image-coding-constraint=JBIG-T85)
+ (JBIG-stripe-size=128) ) )
+ (| (& (dpi=200) (dpi-xyratio=200/100) )
+ (& (dpi=200) (dpi-xyratio=1) )
+ (& (dpi=204) (dpi-xyratio=204/391) )
+ (& (dpi=300) (dpi-xyratio=1) ) ) )
+ (& (| (& (color=Grey) (color-levels<=256) )
+ (& (color=Full) (color-levels<=65536)
+ (color-subsampling=["1:1:1","4:1:1"]) ) )
+ (image-file-structure=[TIFF-C,TIFF-L])
+ (color-space=CIELAB)
+ (| (& (image-coding=JPEG)
+ (image-coding-constraint=JPEG-T4E) )
+ (& (image-coding=JBIG)
+ (image-coding-constraint=JBIG-T43)
+ (JBIG-stripe-size=128)
+ (image-interleave=stripe) ) )
+ (dpi=[100,200,300])
+ (dpi-xyratio=1) ) )
+ (MRC-mode=0)
+ (paper-size=[A4,B4]) )
+
+4.5 Full-color Internet fax system (MRC)
+
+ (& (| (& (color=Binary)
+ (image-file-structure=[TIFF-S,TIFF-F,TIFF-J])
+ (MRC-mode=0)
+ (image-coding=[MH,MMR])
+ (| (& (dpi=200) (dpi-xyratio=[200/100,1]) )
+ (& (dpi=204) (dpi-xyratio=204/391) )
+ (& (dpi=300) (dpi-xyratio=1) )
+ (& (dpi=400) (dpi-xyratio=1) ) ) )
+ (& (image-file-structure=[TIFF-C,TIFF-L])
+ (| (& (color=Grey) (color-levels<=256) )
+ (& (color=Full) (color-levels<=65536)
+ (color-subsampling=["1:1:1","4:1:1"]) ) )
+ (color-space=CIELAB)
+ (MRC-mode=0)
+ (image-coding=JPEG)
+ (image-coding-constraint=JPEG-T4E)
+ (dpi=[100,200,300,400])
+ (dpi-xyratio=1) )
+ (& (image-file-structure=TIFF-M)
+ (MRC-mode=1) (MRC-max-stripe-size=[0..256])
+
+
+
+Klyne & McIntyre Standards Track [Page 14]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ (image-coding=[MH,MMR,JPEG])
+ (| (color=Binary)
+ (& (color=Grey) (color-levels<=256) )
+ (& (color=Full) (color-levels<=65536)
+ (color-subsampling=["1:1:1","4:1:1"]) ) )
+ (color-space=CIELAB)
+ (dpi=[100,200,300,400])
+ (dpi-xyratio=1) ) )
+ (paper-size=[A4,B4]) )
+
+4.6 Sender and receiver feature matching
+
+ This example considers sending a document to a high-end black-and-
+ white fax system with the following receiver capabilities:
+
+ (& (| (& (dpi=200) (dpi-xyratio=200/100) ) -- 200*100
+ (& (dpi=200) (dpi-xyratio=1) ) -- 200*200
+ (& (dpi=300) (dpi-xyratio=1) ) -- 300*300
+ (& (dpi=400) (dpi-xyratio=1) ) ) -- 400*400
+ (color=Binary)
+ (| (& (paper-size=A4) (ua-media=[stationery,transparency]) )
+ (& (paper-size=B4) (ua-media=continuous) ) )
+ (image-coding=[MH,MR,JBIG]) )
+
+ Turning to the document itself, assume it is available to the sender
+ in three possible formats, A4 high resolution, B4 low resolution and
+ A4 high resolution color, described by:
+
+ (& (dpi=300) (dpi-xyratio=1)
+ (color=Binary)
+ (paper-size=A4)
+ (image-coding=[MMR,JBIG]) )
+
+ (& (dpi=200) (dpi-xyratio=200/100)
+ (color=Binary)
+ (paper-size=B4)
+ (image-coding=[MH,MR]) )
+
+ (& (dpi=300) (dpi-xyratio=1)
+ (color=Mapped) (color-levels<=256)
+ (paper-size=A4)
+ (image-coding=JPEG) )
+
+ These three image formats can be combined into a composite capability
+ statement by a logical-OR operation (to describe format-1 OR format-2
+ OR format-3):
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 15]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ (& (dpi=300) (dpi-xyratio=1)
+ (color=Binary)
+ (paper-size=A4)
+ (image-coding=[MMR,JBIG]) )
+ (& (dpi=200) (dpi-xyratio=200/100)
+ (color=Binary)
+ (paper-size=B4)
+ (image-coding=[MH,MR]) )
+ (& (dpi=300) (dpi-xyratio=1)
+ (color=Mapped) (color-levels=42)
+ (paper-size=A4)
+ (image-coding=JPEG) ) )
+
+ This could be simplified, but there is little gain in doing so at
+ this point.
+
+ The composite document description can be matched with the receiver
+ capability description, according to the rules in [2], to yield the
+ result:
+
+ (& (dpi=300) (dpi-xyratio=1)
+ (color=Binary)
+ (paper-size=A4)
+ (ua-media=[stationery,transparency])
+ (image-coding=JBIG) )
+ (& (dpi=200) (dpi-xyratio=200/100)
+ (color=Binary)
+ (paper-size=B4)
+ (ua-media=continuous)
+ (image-coding=[MH,MR]) ) )
+
+ Points to note about the feature matching process:
+
+ o The color document option is eliminated because the receiver
+ cannot handle either color (indicated by '(color=Mapped)') or JPEG
+ coding (indicated by '(image-coding=JPEG)').
+
+ o The high resolution version of the document with '(dpi=300)' must
+ be send using '(image-coding=JBIG)' because this is the only
+ available coding of the image data that the receiver can use for
+ high resolution documents. (The available 300dpi document codings
+ here are MMR and JBIG, and the receiver capabilities are MH, MR
+ and JBIG.)
+
+ o The low-resolution version of the document can be sent with either
+ MH or MR coding as the receiver can deal with either of these for
+ low resolution documents.
+
+
+
+
+Klyne & McIntyre Standards Track [Page 16]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ o The high resolution variant of the document is available only for
+ A4, so that is the paper-size used in that case. Similarly the
+ low resolution version is sent for B4 paper.
+
+ o Even though the sender may not understand the 'ua-media' feature
+ tag, and does not mention it, the matching rules preserve the
+ constraint that the B4 document is rendered with '(ua-
+ media=continuous)', and the A4 document may be rendered with '
+ (ua-media=[stationery,transparency])'.
+
+ Finally, note that when matching an MRC document description, the
+ description of each component sub-image must match the capabilities
+ of the intended receiver.
+
+5. IANA Considerations
+
+ Appendix A of this document calls for registrations of feature tags
+ in the "IETF tree", as defined in section 3.1.1 of "Media Feature Tag
+ Registration Procedure" [1] (i.e. these feature tags are subject to
+ the "IETF Consensus" policies described in RFC 2434 [21]).
+
+ ASN.1 identifiers should be assigned for each of these registered
+ feature tags and replaced in the body of the registration.
+
+6. Security Considerations
+
+ The points raised below are in addition to the general security
+ considerations for extended Internet fax [5], and others discussed in
+ [2,8,11,12,13]
+
+6.1 Capability descriptions and mechanisms
+
+ Negotiation mechanisms reveal information about one party to other
+ parties. This may raise privacy concerns, and may allow a malicious
+ party to make better guesses about the presence of specific security
+ holes.
+
+ Most of these concerns pertain to capability information getting into
+ the hands of someone who may abuse it. This document specifies
+ capabilities that help a sender to determine what image
+ characteristics can be processed by the recipient, not mechanisms for
+ their publication. Implementors and users should take care that the
+ mechanisms employed ensure that capabilities are revealed only to
+ appropriate persons, systems and agents.
+
+
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 17]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+6.2 Specific threats
+
+ 1. Unsolicited bulk mail: if it is known that a recipient can
+ process certain types of images, they may be targeted by bulk
+ mailers that want to send such images.
+
+7. Acknowledgements
+
+ The authors gratefully acknowledge the contributions of the following
+ persons who commented on earlier versions of this memo: James
+ Rafferty, Dan Wing, Robert Buckley, Mr Ryuji Iwazaki. The following
+ contributed ideas upon which some of the features described here have
+ been based: Larry Masinter, Al Gilman, Koen Holtman.
+
+8. References
+
+ [1] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag
+ Registration Procedure", BCP 31, RFC 2506, March 1999.
+
+ [2] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC
+ 2533, March 1999.
+
+ [3] Masinter, L., Holtman, K., Mutz, A. and D. Wing, "Media Features
+ for Display, Print, and Fax", RFC 2534, March 1999.
+
+ [4] McIntyre, L. and G. Klyne, "Internet fax feature mapping from
+ Group 3 fax", Work in Progress.
+
+ [5] Masinter, L. and D. Wing, "Extended Facsimile Using Internet
+ Mail", RFC 2532, March 1999.
+
+ [6] "Procedures for document facsimile transmission in the general
+ switched telephone network", ITU-T Recommendation T.30 (1996),
+ International Telecommunications Union, July 1996.
+
+ [7] McIntyre, L., Buckley, R., Venable, D., Zilles, S., Parsons, G.
+ and J. Rafferty, "File format for Internet fax", RFC 2301, March
+ 1998.
+
+ [8] Toyoda, K., Ohno, H., Murai, J. and D. Wing, "A Simple Mode of
+ Facsimile Using Internet Mail", RFC 2305, March 1998.
+
+ [9] "Continuous-tone color representation method for facsimile"
+ ITU-T Recommendation T.42 (1996), International
+ Telecommunications Union, (Covers custom illuminant, gamut).
+
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 18]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ [10] "Colour and gray-scale image representation using lossless
+ coding scheme for facsimile", ITU-T Recommendation T.43 (1997),
+ International Telecommunications Union. (Covers JBIG for
+ colour/grey images).
+
+ [11] Hardie, T., "Scenarios for the Delivery of Negotiated Content",
+ Work in Progress.
+
+ [12] Klyne, G., "Requirements for protocol-independent content
+ negotiation", Work in Progress.
+
+ [13] "Standardization of Group 3 facsimile terminals for document
+ transmission", ITU-T Recommendation T.4 (1996), International
+ Telecommunications Union, (Covers basic fax coding formats: MH,
+ MR).
+
+ [14] "Facsimile coding schemes and coding control functions for Group
+ 4 facsimile apparatus", ITU Recommendation T.6, International
+ Telecommunications Union, (Commonly referred to as the MMR
+ standard; covers extended 2-D fax coding format).
+
+ [15] "Mixed Raster Content (MRC)", ITU-T Recommendation T.44,
+ International Telecommunications Union.
+
+ [16] "Information technology - Digital compression and coding of
+ continuous-tone still image - Requirements and guidelines",
+ ITU-T Recommendation T.81 (1992) | ISO/IEC 10918-1:1993,
+ International Telecommunications Union, (Commonly referred to as
+ JPEG standard).
+
+ [17] "Information technology - Coded representation of picture and
+ audio information - Progressive bi-level image compression",
+ ITU-T Recommendation T.82 (1993) | ISO/IEC 11544:1993,
+ International Telecommunications Union, (Commonly referred to as
+ JBIG1 standard).
+
+ [18] "Application profile for Recommendation T.82 - Progressive bi-
+ level image compression (JBIG1 coding scheme for facsimile
+ apparatus)", ITU-T Recommendation T.85 (1995), International
+ Telecommunications Union, (Covers bi-level JBIG).
+
+ [19] "Colorimeter, 2nd ed.", CIE Publication No. 15.2, 1986.
+ (Defines CIELAB color space; use with fax is further
+ constrained by T.42 [9].)
+
+
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 19]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ [20] Tag Image File Format, Revision 6.0, Adobe Developers
+ Association,
+ <ftp://ftp.adobe.com/pub/adobe/devrelations/devtechnotes
+ /pdffiles/tiff6.pdf>, June 1992.
+
+ [21] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+ Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 20]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+9. Authors' Addresses
+
+ Graham Klyne
+ 5th Generation Messaging Ltd. Content Technologies Ltd.
+ 5 Watlington Street Forum 1, Station Road
+ Nettlebed Theale
+ Henley-on-Thames, RG9 5AB Reading, RG7 4RA
+ United Kingdom United Kingdom.
+
+ Phone: +44 1491 641 641 +44 118 930 1300
+ Facsimile: +44 1491 641 611 +44 118 930 1301
+ EMail: GK@ACM.ORG
+
+
+ Lloyd McIntyre
+ Xerox Corporation
+ Mailstop PAHV-121
+ 3400 Hillview Ave.
+ Palo Alto, CA 94304 USA
+
+ Phone: +1-650-813-6762
+ Facsimile: +1-650-845-2340
+ EMail: Lloyd.McIntyre@pahv.xerox.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 21]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+Appendix A: Feature registrations
+
+A.1 Image size
+
+ - Media Feature tag name(s):
+
+ size-x
+ size-y
+
+ - ASN.1 identifiers associated with these feature tags:
+
+ 1.3.6.1.8.1.7
+ 1.3.6.1.8.1.8
+
+ - Summary of the media features indicated:
+
+ These feature tags indicate the size of a displayed, printed or
+ otherwise rendered document image; they indicate horizontal
+ (size-x) and vertical (size-y) dimensions.
+
+ The unit of measure is inches (to be consistent with the
+ measure of resolution defined by the feature tag 'dpi').
+
+ Where the actual size is available in millimetres, a conversion
+ factor of 10/254 may be applied to yield an exact inch-based
+ value.
+
+ - Values appropriate for use with these feature tags:
+
+ Rational (>0)
+
+ - The feature tag is intended primarily for use in the following
+ applications, protocols, services, or negotiation mechanisms:
+
+ Print and display applications where different media choices
+ will be made depending on the size of the recipient device.
+
+ - Examples of typical use:
+
+ This example describes the maximum scanned image width and
+ height for Group 3 fax: 215x297 mm (8.46x11.69 inches):
+
+ (size-x<=2150/254)
+ (size-y<=2970/254)
+
+
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 22]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ - Related standards or documents:
+
+ The memo "Media Features for Display, Print, and Fax" [3]
+ describes features (pix-x, pix-y) for measuring document size
+ in pixels.
+
+ Fax applications should declare physical dimensions using the
+ features defined here.
+
+ - Considerations particular to use in individual applications,
+ protocols, services, or negotiation mechanisms:
+
+ Where no physical size is known or available, but a pixel size
+ is known, a notional size should be declared based upon known
+ pixel dimensions and a notional resolution of (say) 100dpi
+
+ For example, to describe a 640x480 pixel display:
+
+ (& (size-x<=640/100) (size-y<=480/100) (dpi=100) )
+
+ The notional 100dpi resolution is used as it represents a
+ fairly typical resolution for a pixel-limited display.
+ Reducing the rational numbers to canonical form gives the
+ following equivalent expression:
+
+ (& (size-x<=32/5) (size-y<=24/5) (dpi=100) )
+
+ - Interoperability considerations:
+
+ For interoperability with other (non-fax) applications that use
+ only pixel-based measurements, pixel dimensions (pix-x, pix-y)
+ may be declared in addition to physical measurements.
+
+ - Related feature tags:
+
+ pix-x [3]
+ pix-y [3]
+ dpi [3]
+ dpi-xyratio [this document]
+
+ - Intended usage:
+
+ Common
+
+ - Author/Change controller:
+
+ IETF
+
+
+
+
+Klyne & McIntyre Standards Track [Page 23]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+A.2 Resolution aspect ratio
+
+ - Media Feature tag name(s):
+
+ dpi-xyratio
+
+ - ASN.1 identifier associated with this feature tag:
+
+ 1.3.6.1.8.1.9
+
+ - Summary of the media features indicated:
+
+ This feature is used to indicate differential horizontal and
+ vertical resolution capability. In the absence of this
+ feature, horizontal and vertical resolutions are presumed to be
+ the same.
+
+ When this feature tag is specified, any declared resolution
+ (dpi) is presumed to apply to the horizontal axis, and the
+ vertical resolution is obtained by dividing that declared
+ resolution by the resolution ratio.
+
+ The value of this feature is a pure number, since it represents
+ the ratio of two resolution values.
+
+ - Values appropriate for use with this feature tag:
+
+ Rational (>0)
+
+ - The feature tag is intended primarily for use in the following
+ applications, protocols, services, or negotiation mechanisms:
+
+ Internet fax, and other print or display applications that must
+ handle differential horizontal and vertical resolution values.
+
+ - Examples of typical use:
+
+ The following example describes a fax resolution of 204 dpi
+ horizontally by 391 dpi vertically:
+
+ (& (dpi=204) (dpi-xyratio=204/391) )
+
+ - Related standards or documents:
+
+ The memo "Media Features for Display, Print, and Fax" [3]
+ describes a feature (dpi) for measuring document resolution.
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 24]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ - Interoperability considerations:
+
+ When interoperating with an application that does not recognize
+ the differential resolution feature, resolution matching may be
+ performed on the basis of the horizontal resolution only, so
+ aspect ratio information may be lost.
+
+ - Related feature tags:
+
+ dpi [3]
+ size-x [this document]
+ size-y [this document]
+
+ - Intended usage:
+
+ Internet fax
+
+ - Author/Change controller:
+
+ IETF
+
+A.3 Color levels
+
+ - Media Feature tag name(s):
+
+ color-levels
+
+ - ASN.1 identifier associated with this feature tag:
+
+ 1.3.6.1.8.1.10
+
+ - Summary of the media features indicated:
+
+ This feature tag is used to indicate a number of different
+ image data pixel color values.
+
+ When mapped (palettized) color is used, this is generally
+ different from the number of different colors that can be
+ represented through the color mapping function.
+
+ This feature tag is used in conjunction with a 'color' feature
+ having a value other than 'Binary'.
+
+ - Values appropriate for use with this feature tag:
+
+ Integer (>=2)
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 25]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ - The feature tag is intended primarily for use in the following
+ applications, protocols, services, or negotiation mechanisms:
+
+ Color image printing or display applications where the data
+ resource used may depend upon color handling capabilities of
+ the recipient.
+
+ - Examples of typical use:
+
+ To describe recipient capabilities:
+ (& (color=limited) (color-levels<=6) )
+ (& (color=grey) (color-levels<=64) )
+ (& (color=mapped) (color-levels<=240) )
+ (& (color=full) (color-levels<=16777216) )
+
+ To describe capabilities used by a document:
+ (& (color=limited) (color-levels=4) )
+ (& (color=grey) (color-levels=48) )
+ (& (color=mapped) (color-levels=100) )
+ (& (color=full) (color-levels=32768) )
+
+ - Related standards or documents:
+
+ The memo "Media Features for Display, Print, and Fax" [3]
+ describes a feature (color) for indicating basic color
+ capabilities.
+
+ - Interoperability considerations:
+
+ The actual number of color values used by a document does not,
+ in general, exactly match the number that can be handled by a
+ recipient. To achieve a feature match, at least one must be
+ declared as an inequality.
+
+ It is recommended that a recipient declares the number of color
+ values that it can handle as an inequality (<=), and a data
+ resource declares the number of colors that it uses with an
+ equality, as shown in the examples above.
+
+ - Security considerations:
+
+ - Privacy concerns, related to exposure of personal information:
+ Where feature matching is used to select content applicable to
+ the physical abilities of a user, unusual values for this
+ feature tag might give an indication of a user's restricted
+ abilities.
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 26]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ - Related feature tags:
+
+ color [3]
+ color-space [this document]
+
+ - Intended usage:
+
+ Internet fax
+ Color image scanning/rendering applications
+
+ - Author/Change controller:
+
+ IETF
+
+A.4 Color space
+
+ - Media Feature tag name(s):
+
+ color-space
+
+ - ASN.1 identifier associated with this feature tag:
+
+ 1.3.6.1.8.1.11
+
+ - Summary of the media features indicated:
+
+ This feature indicates a color space.
+
+ A color space value provides two types of information:
+ o the color model used to represent a color value, including
+ the number of color components
+ o a mapping between color values and their physical
+ realizations
+
+ Device color space values are defined for applications where
+ the general color representation used is significant, but exact
+ color rendering is left to the device used. Device color
+ spaces defined here have values of the form 'Device- xxx'.
+
+ Calibrated color space values are provided for use with a
+ rendering system that is calibrated with respect to some
+ indicated definition, and capable of processing device-
+ independent color information accordingly.
+
+ - Values appropriate for use with this feature tag:
+
+ Token
+
+
+
+
+Klyne & McIntyre Standards Track [Page 27]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ Device color Device-RGB (device dependent RGB)
+ spaces: Device-CMY (device dependent CMY)
+ Device-CMYK (device dependent CMYK)
+
+ Calibrated color CIELAB (per T.42 [9])
+ space:
+
+ (may be extended by further registrations)
+
+ 'Color-space=CIELAB' indicates the CIE L*a*b* colour space,
+ using CIED50 illuminant and its perfectly diffuse reflecting
+ white point (per T.42 [9]).
+
+ - The feature tag is intended primarily for use in the following
+ applications, protocols, services, or negotiation mechanisms:
+
+ Color image printing and display applications where the data
+ resource used may depend upon color handling capabilities of
+ the recipient.
+
+ Scanning applications where the data transferred may depend
+ upon the image generation capabilities of the originator.
+
+ - Examples of typical use:
+
+ To describe rendering or scanning capabilities:
+
+ (color-space=[Device-RGB,CIELAB])
+
+ To describe capabilities assumed by a document for which
+ approximate color reproduction is required:
+
+ (color-space=Device-RGB)
+
+ To describe capabilities assumed by a document for which exact
+ color reproduction is required:
+
+ (color-space=CIELAB)
+
+ - Related standards or documents:
+
+ CIELAB color space is defined in [19]
+
+ CIELAB use for fax is described in ITU T.42 [9]
+
+
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 28]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ - Interoperability considerations:
+
+ A color-handling receiver should indicate at any appropriate
+ device color space capability, in addition to any calibrated
+ color spaces that it may support.
+
+ Calibrated color spaces are intended to be used when precise
+ color matching is required; otherwise, if applicable, a device
+ color space (color-space=Device-xxx) should be indicated.
+
+ Documents for which exact color matching is not important
+ should indicate a device color space capability, if applicable.
+
+ These principles allow sender/receiver feature matching to be
+ achieved when exact color matching is not required.
+
+ - Security considerations:
+
+ - Privacy concerns, related to exposure of personal
+ information:
+ Where feature matching is used to select content applicable
+ to the physical abilities of a user, unusual values for this
+ feature tag might give an indication of a user's restricted
+ abilities.
+
+ - Denial of service concerns related to consequences of
+ specifying incorrect values:
+ Failure to indicate a generic color space capability for a
+ device may lead to failure to match color space for an
+ application or document that does not require an exact color
+ match.
+
+ - Related feature tags:
+
+ color [3]
+
+ - Related media types or data formats:
+
+ TIFF-FX [7]
+
+ - Intended usage:
+
+ Internet fax
+ Color image scanning/rendering applications
+
+ - Author/Change controller:
+
+ IETF
+
+
+
+Klyne & McIntyre Standards Track [Page 29]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+A.5 CIELAB color depth
+
+ - Media Feature tag name(s):
+
+ CIELAB-L-depth
+ CIELAB-A-depth
+ CIELAB-B-depth
+
+ - ASN.1 identifiers associated with these feature tags:
+
+ 1.3.6.1.8.1.12
+ 1.3.6.1.8.1.13
+ 1.3.6.1.8.1.14
+
+ - Summary of the media features indicated:
+
+ These feature tags indicate a color depth capability; i.e. the
+ level of detail to which an individual CIELAB color component
+ can be specified. They define the number of distinct values
+ possible for each of the color components L*, a* and b*.
+
+ Typically, this feature would be used with 'color=mapped', and
+ possibly 'color=grey' or 'color=full', to indicate the number
+ of distinct colors that can be realized.
+
+ - Values appropriate for use with these feature tags:
+
+ Integer (>0)
+
+ - These feature tags are intended primarily for use in the
+ following applications, protocols, services, or negotiation
+ mechanisms:
+
+ Color image printing and display applications where the data
+ resource used may depend upon color handling capabilities of
+ the recipient.
+
+ Scanning applications where the data transferred may depend
+ upon the image generation capabilities of the originator.
+
+ - Examples of typical use:
+
+ To describe rendering or scanning capabilities:
+
+ (& (color=mapped) (color-levels<=240)
+ (CIELAB-L-depth<=128)
+ (CIELAB-a-depth<=128)
+ (CIELAB-b-depth<=128) )
+
+
+
+Klyne & McIntyre Standards Track [Page 30]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ (& (color=full) (color-levels<=16777216)
+ (CIELAB-L-depth<=256)
+ (CIELAB-a-depth<=128)
+ (CIELAB-b-depth<=128) )
+
+ To describe capabilities assumed by a document:
+
+ (& (color=mapped) (color-levels=200)
+ (CIELAB-L-depth=32)
+ (CIELAB-a-depth=32)
+ (CIELAB-b-depth=32) )
+ (& (color=full) (color-levels=32768)
+ (CIELAB-L-depth=128)
+ (CIELAB-a-depth=32)
+ (CIELAB-b-depth=32) )
+
+ - Related standards or documents:
+
+ The memo "Media Features for Display, Print, and Fax" [3]
+ defines a feature (color) for indicating basic color
+ capabilities.
+
+ CIELAB color space is defined in [19]
+
+ CIELAB use for fax is described in ITU T.42 [9]
+
+ - Related feature tags:
+
+ color [3]
+ color-levels [this document]
+ color-space [this document]
+
+ - Intended usage:
+
+ Internet fax
+ Color image scanning/rendering applications
+
+ - Author/Change controller:
+
+ IETF
+
+
+
+
+
+
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 31]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+A.6 CIELAB color gamut
+
+ - Media Feature tag name(s):
+
+ CIELAB-L-min
+ CIELAB-L-max
+ CIELAB-a-min
+ CIELAB-a-max
+ CIELAB-b-min
+ CIELAB-b-max
+
+ - ASN.1 identifiers associated with these feature tags:
+
+ 1.3.6.1.8.1.15
+ 1.3.6.1.8.1.16
+ 1.3.6.1.8.1.17
+ 1.3.6.1.8.1.18
+ 1.3.6.1.8.1.19
+ 1.3.6.1.8.1.20
+
+ - Summary of the media features indicated:
+
+ These feature indicate a supported range of color values, by
+ indicating minimum and maximum values used for each color
+ component in a CIELAB color space.
+
+ 'CIELAB-L-min' and 'CIELAB-L-max' are the minimum and maximum
+ values of the L* component.
+
+ 'CIELAB-a-min' and 'CIELAB-a-max' are the minimum and maximum
+ values of the a* component.
+
+ 'CIELAB-b-min' and 'CIELAB-b-max' are the minimum and maximum
+ values of the b* component.
+
+ - Values appropriate for use with this feature tag:
+
+ Rational
+
+ - The feature tag is intended primarily for use in the following
+ applications, protocols, services, or negotiation mechanisms:
+
+ Color image printing and display applications where the data
+ resource used may depend upon detailed color handling
+ capabilities of the recipient.
+
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 32]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ Scanning applications where the data transferred may depend
+ upon the detailed color image generation capabilities of the
+ originator.
+
+ - Examples of typical use:
+
+ To describe rendering or scanning capabilities:
+
+ (& (CIELAB-L-min>=0)
+ (CIELAB-L-max<=100)
+ (CIELAB-a-min>=-75)
+ (CIELAB-a-max<=+75)
+ (CIELAB-b-min>=-85)
+ (CIELAB-b-max<=+85) )
+
+ To describe capabilities required by a document:
+
+ (& (CIELAB-L-min=20)
+ (CIELAB-L-max=80)
+ (CIELAB-L-min=-35)
+ (CIELAB-L-max=+55)
+ (CIELAB-L-min=-45)
+ (CIELAB-L-max=+65) )
+
+ - Related standards or documents:
+
+ CIELAB color space is defined in [19]
+
+ CIELAB use for fax is described in ITU T.42 [9]
+
+ - Interoperability considerations:
+
+ When describing a recipient's capabilities, the minimum and
+ maximum color component values that can be rendered should be
+ indicated by inequalities as shown in the examples above.
+
+ When describing a document, the actual minimum and maximum
+ color component values used should be indicated, as shown
+ above.
+
+ - Security considerations:
+
+ - Privacy concerns, related to exposure of personal
+ information:
+ Where feature matching is used to select content applicable
+ to the physical abilities of a user, unusual values for this
+ feature tag might give an indication of a user's restricted
+ abilities.
+
+
+
+Klyne & McIntyre Standards Track [Page 33]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ - Related feature tags:
+
+ color [3]
+ color-space [this document]
+
+ - Related media types or data formats:
+
+ TIFF-FX [7]
+
+ - Intended usage:
+
+ Internet fax
+ Color image scanning/rendering applications
+
+ - Author/Change controller:
+
+ IETF
+
+A.7 Image file structure
+
+ - Media Feature tag name(s):
+
+ image-file-structure
+
+ - ASN.1 identifier associated with this feature tag:
+
+ 1.3.6.1.8.1.21
+
+ - Summary of the media features indicated:
+
+ This feature indicates a file structure used for transfer and
+ presentation of image data.
+
+ It does not indicate image data coding: that is described by
+ separate feature tags (image-coding, etc.).
+
+ - Values appropriate for use with this feature tag:
+
+ Token
+
+
+
+
+
+
+
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 34]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ TIFF-FX profiles TIFF-S
+ [7]: TIFF-F
+ TIFF-J
+ TIFF-C
+ TIFF-L
+ TIFF-M
+
+ (may be extended by further registrations,
+ to cover non-TIFF image file structures)
+
+ - The feature tag is intended primarily for use in the following
+ applications, protocols, services, or negotiation mechanisms:
+
+ Internet fax, and other print or display applications that
+ transfer image data.
+
+ - Examples of typical use:
+
+ See Appendix B of this memo.
+
+ - Considerations particular to use in individual applications,
+ protocols, services, or negotiation mechanisms:
+
+ This tag is intended to provide information about an image file
+ structure. Information about image data coding is provided by
+ other tags.
+
+ In the case of TIFF-FX image data, there are a number of image
+ file format constraints that are imposed by the various usage
+ profiles defined in RFC 2301 [7]. The purpose of the 'image-
+ file-structure' feature tag is to capture those file format
+ constraints.
+
+ Registration of additional image file structure tags should
+ focus similarly on image file structure issues, not raw image
+ data compression and coding. As a guide, an image file
+ structure may contain image data coded in a variety of ways,
+ and carries information to describe that coding separately from
+ MIME content-type labelling, etc.
+
+ - Related feature tags:
+
+ image-coding [this document]
+
+ - Related media types or data formats:
+
+ TIFF-FX [7]
+ TIFF V6.0 (Adobe) [20]
+
+
+
+Klyne & McIntyre Standards Track [Page 35]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ - Intended usage:
+
+ Internet fax
+ Image scanning/rendering applications
+
+ - Author/Change controller:
+
+ IETF
+
+A.8 Image data coding
+
+ - Media Feature tag name(s):
+
+ image-coding
+
+ - ASN.1 identifier associated with this feature tag:
+
+ 1.3.6.1.8.1.22
+
+ - Summary of the media features indicated:
+
+ This feature tag indicates a form of image data compression and
+ coding used.
+
+ It identifies a generic image coding technique used, without
+ regard to any specific profiling of that technique that may be
+ applied. Values for this feature are generally applicable
+ across a wide range of image transfer applications.
+
+ This information is distinct from the image file structure and
+ MRC information conveyed by the 'image-file-structure' tags.
+
+ - Values appropriate for use with this feature tag:
+
+ Token MH
+ MR
+ MMR
+ JBIG
+ JPEG
+
+ (may be extended by further registrations)
+
+ - The feature tag is intended primarily for use in the following
+ applications, protocols, services, or negotiation mechanisms:
+
+ Internet fax, and other applications that transfer image data.
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 36]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ - Examples of typical use:
+
+ See Appendix B of this memo.
+
+ - Related standards or documents:
+
+ MH, MR: ITU T.4 [13]
+ MMR: ITU T.6 [14]
+ JPEG: ITU T.81 [16]
+ JBIG: ITU T.82 [17]
+
+ - Interoperability considerations:
+
+ To establish the correct conditions for interoperability
+ between systems, capabilities to handle the generic image
+ coding technique and the specific image coding constraints must
+ be established.
+
+ - Related feature tags:
+
+ image-coding-constraint [this document]
+ JBIG-stripe-size [this document]
+ image-interleave [this document]
+
+ - Related media types or data formats:
+
+
+ TIFF-FX [7]
+
+ - Intended usage:
+
+ Internet fax
+ Image scanning/rendering applications
+
+ - Author/Change controller:
+
+ IETF
+
+A.9 Image coding constraint
+
+ - Media Feature tag name(s):
+
+ image-coding-constraint
+
+ - ASN.1 identifier associated with these feature tags:
+
+ 1.3.6.1.8.1.23
+
+
+
+
+Klyne & McIntyre Standards Track [Page 37]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ - Summary of the media features indicated:
+
+ This feature tag qualifies the 'image-coding' feature with a
+ specific profile or usage constraints.
+
+ Values for this feature are generally specific to some given
+ value of 'image-coding' and also to some restricted application
+ or class of applications.
+
+ - Values appropriate for use with this feature tag:
+
+ Token JBIG-T85 (bi-level, per ITU T.85)
+ JBIG-T43 (multi-level, per ITU T.43)
+ JPEG-T4E (per ITU T.4, Annex E)
+
+ (may be extended by further registrations)
+
+ - The feature tag is intended primarily for use in the following
+ applications, protocols, services, or negotiation mechanisms:
+
+ Internet fax, and other applications that transfer image data.
+
+ The specific values for this feature indicated above are
+ intended for use with Internet fax.
+
+ - Examples of typical use:
+
+ See Appendix B of this memo.
+
+ - Related standards or documents:
+
+ JBIG-T85: ITU T.85 [18]
+ JBIG-T43: ITU T.43 [10]
+ JPEG-T4E: ITU T.4 Annex E [13]
+
+ - Interoperability considerations:
+
+ To establish the correct conditions for interoperability
+ between systems, capabilities to handle the generic image
+ coding technique and the specific image coding constraints must
+ be established.
+
+ - Related feature tags:
+
+ image-coding [this document]
+ JBIG-stripe-size [this document]
+ image-interleave [this document]
+
+
+
+
+Klyne & McIntyre Standards Track [Page 38]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ - Related media types or data formats:
+
+ TIFF-FX [7]
+
+ - Intended usage:
+
+ Internet fax
+ Color image scanning/rendering applications
+
+ - Author/Change controller:
+
+ IETF
+
+A.10 JBIG stripe size
+
+ - Media Feature tag name(s):
+
+ JBIG-stripe-size
+
+ - ASN.1 identifier associated with these feature tags:
+
+ 1.3.6.1.8.1.24
+
+ - Summary of the media features indicated:
+
+ This feature is a specific usage constraint that is applied to
+ JBIG image coding (image-coding=JBIG), and indicates the
+ allowable size for each stripe of an image, except the last.
+
+ A stripe of a JBIG image is a delimited horizontal band of
+ compressed image data that can be decompressed separately from
+ the surrounding data.
+
+ - Values appropriate for use with this feature tag:
+
+ Integer (>0)
+
+ - The feature tag is intended primarily for use in the following
+ applications, protocols, services, or negotiation mechanisms:
+
+ Internet fax, and other applications that transfer image data.
+
+ - Examples of typical use:
+
+ (JBIG-stripe-size=128)
+ (JBIG-stripe-size>0)
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 39]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ - Related standards or documents:
+
+ JBIG: ITU T.82 [17]
+ JBIG-T85: ITU T.85 [18]
+ JBIG-T43: ITU T.43 [10]
+
+ - Considerations particular to use in individual applications,
+ protocols, services, or negotiation mechanisms:
+
+ In the case of Internet fax, the specific constraints allowed
+ for a receiver are those given as examples above.
+
+ Specifying a stripe size that is not limited (JBIG-stripe-
+ size>0) means that an entire page of image data is encoded as a
+ single unit. This may place considerable demands on the memory
+ of a receiving system, as the entire stripe needs to be
+ buffered in memory.
+
+ - Interoperability considerations:
+
+ To establish the correct conditions for interoperability
+ between systems, capabilities to handle the generic image
+ coding technique and the specific image coding constraints must
+ be established.
+
+ - Related feature tags:
+
+ image-coding [this document]
+ image-coding-constraint [this document]
+ image-interleave [this document]
+
+ - Related media types or data formats:
+
+ TIFF-FX [7]
+
+ - Intended usage:
+
+ Internet fax
+ Color image scanning/rendering applications
+
+ - Author/Change controller:
+
+ IETF
+
+
+
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 40]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+A.11 Image interleave
+
+ - Media Feature tag name(s):
+
+ image-interleave
+
+ - ASN.1 identifier associated with this feature tag:
+
+ 1.3.6.1.8.1.25
+
+ - Summary of the media features indicated:
+
+ This feature indicates an image interleave capability.
+
+ It may be used with JBIG images (image-coding=JBIG) to indicate
+ color plane interleaving of either stripes or entire image
+ planes.
+
+ - Values appropriate for use with this feature tag:
+
+ Token Stripe
+ Plane
+
+ - The feature tag is intended primarily for use in the following
+ applications, protocols, services, or negotiation mechanisms:
+
+ Internet fax, and other applications that transfer image data.
+
+ - Examples of typical use:
+
+ (image-interleave=stripe)
+ (image-interleave=[stripe,plane])
+
+ - Considerations particular to use in individual applications,
+ protocols, services, or negotiation mechanisms:
+
+ Specifying a plane interleave means that an entire page of
+ image data must be buffered in order to generate render the
+ image. This may place considerable demands on the memory of a
+ sending or receiving system.
+
+ - Related feature tags:
+
+ image-coding [this document]
+ JBIG-stripe-size [this document]
+
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 41]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ - Related media types or data formats:
+
+ TIFF-FX [7]
+
+ - Intended usage:
+
+ Internet fax
+ Color image scanning/rendering applications
+
+ - Author/Change controller:
+
+ IETF
+
+A.12 Color subsampling
+
+ - Media Feature tag name(s):
+
+ color-subsampling
+
+ - ASN.1 identifier associated with this feature tag:
+
+ 1.3.6.1.8.1.26
+
+ - Summary of the media features indicated:
+
+ This feature tag indicates whether color information may be
+ subsampled with respect to luminance data.
+
+ It is used with continuous color images (color=full), color
+ spaces that use separate luminance and color components (e.g.
+ color-space=LAB), and image file structures that support color
+ subsampling.
+
+ - Values appropriate for use with this feature tag:
+
+ String "1:1:1"
+ This value indicates a full set of color
+ component samples for each luminance
+ component sample.
+
+ "4:1:1"
+ This value indicates a set of color samples
+ for each luminance sample.
+
+ (may be extended by further registrations)
+
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 42]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ - The feature tag is intended primarily for use in the following
+ applications, protocols, services, or negotiation mechanisms:
+
+ Color image printing and display applications where the data
+ resource used may depend upon color handling capabilities of
+ the recipient.
+
+ Scanning applications where the data transferred may depend
+ upon the image generation capabilities of the originator.
+
+ - Examples of typical use:
+
+ (& (color=full) (color-space=[Device-RGB,CIELAB])
+ (color-subsampling=["1:1:1","4:1:1"]) )
+
+ - Related feature tags:
+
+ color [3]
+ color-space [this document]
+ image-file-structure [this document]
+
+ - Related media types or data formats:
+
+ TIFF-FX [7]
+
+ - Intended usage:
+
+ Internet fax
+ Color image scanning/rendering applications
+
+ - Author/Change controller:
+
+ IETF
+
+A.13 MRC availability and mode
+
+ - Media Feature tag name(s):
+
+ MRC-mode
+
+ - ASN.1 identifier associated with this feature tag:
+
+ 1.3.6.1.8.1.27
+
+
+
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 43]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ - Summary of the media features indicated:
+
+ This feature is used to indicate the availability of MRC (mixed
+ raster content) image format capability, and also the MRC mode
+ available. A zero value indicates MRC is not available, a
+ non-zero value (in the range 1..7) indicates the available MRC
+ mode number.
+
+ An MRC formatted document is actually a collection of several
+ images, each of which is described by a separate feature
+ collection. An MRC-capable receiver is presumed to be capable
+ of accepting any combination of contained images that conform
+ to the MRC construction rules, where each such image matches
+ the separately declared resolution, color capability, color
+ model, image coding, and any other capabilities.
+
+ NOTE: an MRC formatted document may appear within a TIFF
+ image file structure.
+
+ Within an MRC-formatted document, multi-level coders are
+ used for foreground and background images (i.e. odd-
+ numbered layers: 1, 3, 5, etc.) and bi-level coders are used
+ for mask layers (i.e. even numbered layers 2, 4, 6, etc.).
+
+ - Values appropriate for use with this feature tag:
+
+ Integer (0..7)
+
+ - The feature tag is intended primarily for use in the following
+ applications, protocols, services, or negotiation mechanisms:
+
+ Internet fax, and other applications that transfer image data.
+
+ - Examples of typical use:
+
+ See Appendix B of this document.
+
+ - Related standards or documents:
+
+ ITU T.44 [15]
+
+ - Interoperability considerations:
+
+ To establish the correct conditions for interoperability
+ between systems, capabilities to handle the MRC mode and any
+ contained image coding techniques must be established.
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 44]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ - Related feature tags:
+
+ image-coding [this document]
+ MRC-max-stripe-size [this document]
+
+ - Related media types or data formats:
+
+ TIFF-FX [7]
+
+ - Intended usage:
+
+ Internet fax
+ Color image scanning/rendering applications
+
+ - Author/Change controller:
+
+ IETF
+
+A.14 MRC maximum stripe size
+
+ - Media Feature tag name(s):
+
+ MRC-max-stripe-size
+
+ - ASN.1 identifier associated with this feature tag:
+
+ 1.3.6.1.8.1.28
+
+ - Summary of the media features indicated:
+
+ This feature may be used with MRC coding (MRC-mode>=1), and
+ indicates the maximum number of scan lines in each MRC stripe.
+
+ The value given indicates an upper bound on the stripe size.
+ The actual value may vary between stripes, and the actual size
+ for each stripe is indicated in the image data.
+
+ - Values appropriate for use with this feature tag:
+
+ Integer (>0)
+
+ - The feature tag is intended primarily for use in the following
+ applications, protocols, services, or negotiation mechanisms:
+
+ Internet fax, and other applications that transfer image data.
+
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 45]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ - Examples of typical use:
+
+ (MRC-max-stripe-size=[0..256])
+ (MRC-max-stripe-size>=0)
+
+ - Considerations particular to use in individual applications,
+ protocols, services, or negotiation mechanisms:
+
+ For Internet fax, the legal constraints for an image receiver
+ are those given as examples above.
+
+ - Related feature tags:
+
+ MRC-mode [this document]
+
+ - Related media types or data formats:
+
+ TIFF-FX [7]
+
+ - Intended usage:
+
+ Internet fax
+ Color image scanning/rendering applications
+
+ - Author/Change controller:
+
+ IETF
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 46]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+Appendix B: TIFF mode descriptions
+
+ This appendix contains descriptions of the TIFF modes defined by RFC
+ 2301 [7], presented as feature set expressions in the form defined by
+ "A syntax for describing media feature sets" [2] and using the
+ feature schema introduced by this document.
+
+ These may be taken as illustrations of the feature set combinations
+ that are required for the corresponding TIFF profiles described by
+ RFC 2301.
+
+ (Tiff-S) :-
+ (& (image-file-structure=TIFF-S)
+ (color=Binary)
+ (image-coding=MH) (MRC-mode=0) )
+
+ (Tiff-F) :-
+ (& (image-file-structure=TIFF-F)
+ (color=Binary)
+ (image-coding=MH) (MRC-mode=0) )
+
+ (TIFF-J) :-
+ (& (image-file-structure=TIFF-J)
+ (color=Binary)
+ (image-coding=JBIG) (MRC-mode=0) )
+
+ (TIFF-C) :-
+ (& (image-file-structure=TIFF-C)
+ (color=Grey)
+ (image-coding=JPEG) (MRC-mode=0) )
+
+ (TIFF-L) :-
+ (& (image-file-structure=TIFF-L)
+ (color=Grey)
+ (image-coding=JBIG) (MRC-mode=0) )
+
+ (TIFF-M) :-
+ (& (image-file-structure=TIFF-M)
+ (color=[Binary,Grey])
+ (image-coding=[MH,JPEG]) (MRC-mode>=1) )
+
+ The feature sets described above are minimum requirements for the
+ corresponding TIFF modes. Thus, MR and MMR image coding are not
+ mandatory with TIFF mode F, and would be indicated by combining the
+ expression for (TIFF-F) with (image-coding=MR) and/or (image-
+ coding=MMR).
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 47]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ Similarly, limited, mapped or full color are not mandatory with the
+ grey/color TIFF modes (C, L and M), and would be indicated by
+ combining the corresponding expression with (color=limited),
+ (color=mapped) and/or (color=full).
+
+ TIFF profile M is a composite structure that can combine image data
+ coding options from other profiles: the description above indicates
+ mandatory features; other options may be indicated by combining
+ TIFF-M with other options (e.g. color= limited, mapped or full, and
+ image-coding= MR, MMR or JBIG).
+
+ Support for multiple TIFF profiles may be indicated by combining
+ their expressions with the OR operator; e.g.
+
+ (| (TIFF-F) (TIFF-S) (TIFF-J) )
+
+ indicates support for all black-and-white modes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 48]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+Appendix C: Revision history
+
+ 00a 28-Sep-1998 Initial draft.
+
+ 01a 12-Oct-1998 Incorporated review comments. Described feature
+ tag for differential x/y resolution ratio. Added
+ some examples.
+
+ 01b 19-Oct-1998 Updated section 3.6 on image coding. Added
+ Appendix B containing feature expressions for the
+ TIFF modes from RFC 2301.
+
+ 02a 26-Oct-1998 Update examples. Add separate stripe size features
+ for JBIG and MRC.
+
+ 02b 30-Oct-1998 Update examples. Add text clarifying the
+ description of MRC documents (as a set of feature
+ collections describing multiple contained images).
+ Add text describing constrains on resolution and
+ image coding usage within an MRC document.
+
+ 02c 11-Nov-1998 Add ITU references. Added terminology: "capability
+ exchange", "capability identification" and
+ "capability description". Update JBIG and MRC
+ stripe size tags. Move subsampling to colour
+ section. Remove preferred-unit tag. Add T.4, T.6,
+ T.44 and T.81 references.
+
+ 02d 16-Nov-1998 Update colour handling features, reflecting
+ proposed changes to the media features memo [3].
+ Update the image coding capability framework.
+ Updated TIFF mode descriptions in Appendix B.
+
+ 03a 17-Nov-1998 Replace use of 'pix-x', 'pix-y' with 'size-x', '
+ size-y'. Add registrations in Appendix A.
+
+ 03b 08-Dec-1998 Remove normative language and reference to RFC2119
+ (normative statements will be in the main fax
+ protocol draft). Revise structure of colour
+ features, and removed color-palette feature. Define
+ colour feature tags specific to CIELAB model and
+ colour space.
+
+ 04a 14-Dec-1998 Update examples to reflect revised feature tags.
+ Revise description of MRC document in section 3.7.
+ Clarified interpretation of 'color=fixed'. Change
+ feature value 'color=fixed' to 'color=limited'.
+
+
+
+
+Klyne & McIntyre Standards Track [Page 49]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+ 05a 04-Jan-1999 Incorporate WG last-call comments: change
+ references to MRC-stripe-size to MRC-max-stripe-
+ size; similarly references to MRC-maximum-stripe-
+ size. Change "eifax" to "extended Internet fax".
+ Added guidance note for image coding feature usage.
+ Added IANA consideration comments to Appendix A.
+
+ 05b 08-Jan-1999 Added new section for IANA considerations; removed
+ references to fax working group from registration
+ change control sections. Remove JPEG from TIFF-L
+ auxiliary predicate. Clarify description of MRC
+ receiver capabilities in section A.13. Remove '
+ color=full' from (TIFF-C) and (TIFF-M) predicates,
+ and add some explanatory text. Remove
+ 'color=limited' from (TIFF-L) predicate.
+
+ 05c 08-Jan-1999 Minor revisions to TIFF profile illustrations and
+ descripions in Appendix B. Reformatted description
+ of 'color=limited' in section 3.5 to clarify that
+ this does not indicate support for specific named
+ colors.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 50]
+
+RFC 2531 Content Feature Schema for Internet Fax March 1999
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klyne & McIntyre Standards Track [Page 51]
+