From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2531.txt | 2859 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2859 insertions(+) create mode 100644 doc/rfc/rfc2531.txt (limited to 'doc/rfc/rfc2531.txt') 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 (>0) + size-y (>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 (>0) + dpi-xyratio (>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 (>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 (>0) + CIELAB-a-depth + CIELAB-b-depth + CIELAB-L-min + 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 + image-interleave Stripe + Plane + color-subsampling "1:1:1" (no color subsampling) + "4:1:1" (4:1:1 color subsampling) + MRC-mode (0..7) (per ITU T.44 [15]) + MRC-max-stripe-size + + 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, + , 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] + -- cgit v1.2.3