Content Feature Schema for Internet Fax

image-file-structure and image-coding are kept as separate feature tags because an image file structure (e.g. a TIFF-FX profile) imposes file-format constraints independently of the raw compression technique. An image file structure may contain image data coded in a variety of ways, and these concerns are orthogonal.

MRC-mode is defined as a separate feature tag distinct from image-file-structure because an MRC formatted document may appear within a TIFF file structure, so the combination of file structure and MRC capability cannot be collapsed into a single tag without losing expressive power.

The color feature framework is designed to support capability description at varying levels of granularity: feature tags corresponding to implied, "don't care", or unknown values may simply be omitted from a capability description. This avoids requiring exhaustive enumeration of all color parameters in simple cases.

The document deliberately excludes normative language (MUST/SHOULD/MAY) and defers normative statements to the main fax protocol draft (RFC 2532), treating this document as a feature vocabulary specification rather than a behavioral specification.

Appendix B provides formal feature-set expressions for TIFF-FX profiles TIFF-S through TIFF-M using the feature schema from this document. These expressions represent minimum mandatory requirements; additional codings and color modes may be combined with OR/AND operators to describe extended capabilities.

For color-levels matching, it is recommended that a recipient declares the number of color values it can handle as an inequality (<=) and a data resource declares the number it uses as an equality, so that feature matching can succeed when actual document color count does not exactly equal receiver capacity.

For interoperability with non-fax applications that use only pixel-based measurements, pixel dimensions (pix-x, pix-y from RFC 2534) may be declared in addition to the physical inch-based size-x/size-y measurements defined in this document.

When interoperating with an application that does not recognize dpi-xyratio, resolution matching may be performed on horizontal resolution only, causing aspect ratio information to be silently lost.

An extended Internet fax system must recognize every feature tag in the enumerated list and handle it according to its actual capabilities. Presence of a tag in the list does not require the capability itself; unrecognized or unused feature tags received are effectively ignored per RFC 2533 matching rules.

For extended Internet fax, image-file-structure and image-coding should always be specified together, along with additional values needed to clearly indicate which feature tag values are supported and which are not. Specifying image-file-structure alone is not normally sufficient to describe recipient capabilities.

Where feature matching selects content based on a user's physical abilities, unusual values for color-levels, color-space, or CIELAB gamut tags might reveal a user's restricted visual abilities to third parties observing the capability exchange.

privacy

color-levels (Integer >2) indicates the number of distinct pixel color values. color-space takes token values Device-RGB, Device-CMY, Device-CMYK, or CIELAB (per ITU T.42). CIELAB depth tags (CIELAB-L-depth, CIELAB-a-depth, CIELAB-b-depth) indicate distinct values per color component; gamut tags (CIELAB-[L,a,b]-[min,max]) indicate the supported range of CIELAB component values.

color-subsampling takes string values "1:1:1" (full color samples per luminance sample) or "4:1:1" (reduced color samples). It is used with continuous color images (color=Full), color spaces with separate luminance and chrominance (e.g. CIELAB), and file structures that support subsampling.

dpi (Integer >0) indicates resolution; dpi-xyratio (Rational >0) expresses the ratio of horizontal to vertical resolution. When dpi-xyratio is present and not equal to 1, dpi indicates horizontal resolution and vertical resolution equals dpi divided by dpi-xyratio.

image-coding takes token values MH, MR, MMR, JBIG, or JPEG and describes the raw image compression technique. image-coding-constraint further qualifies the coding method with profile-specific values JBIG-T85 (bi-level per ITU T.85), JBIG-T43 (multi-level per ITU T.43), or JPEG-T4E (per ITU T.4 Annex E).

image-file-structure takes token values TIFF-S, TIFF-F, TIFF-J, TIFF-C, TIFF-L, or TIFF-M (TIFF-FX profiles per RFC 2301), describing how coded image data is wrapped and formatted. This is explicitly distinct from image data coding, which is captured by separate tags.

image-interleave takes token values Stripe or Plane and is used with JBIG (image-coding=JBIG) to indicate color plane interleaving. Plane interleave requires buffering an entire page of image data, placing heavy memory demands on sender or receiver.

JBIG-stripe-size (Integer >0) indicates the number of scan lines per JBIG stripe except the last. Legal constraints are JBIG-stripe-size=128 (fixed stripe) or JBIG-stripe-size>=0 (no restriction, meaning the entire page is one stripe, placing heavy memory demands on the receiver).

MRC-max-stripe-size (Integer >0) indicates the maximum scan lines per MRC stripe when MRC-mode>=1. Legal constraints are MRC-max-stripe-size=[0..256] or MRC-max-stripe-size>=0; actual stripe size may vary per stripe and is indicated in the image data.

MRC-mode (Integer 0..7) indicates Mixed Raster Content availability and mode per ITU T.44: 0 means MRC is unavailable; 1-7 indicate the available MRC mode number. An MRC document is a collection of multiple images each described by a separate feature collection; multi-level coders are used for odd-numbered layers and bi-level coders for even-numbered mask layers.

paper-size indicates supported paper dimensions with values: A4, A3, B4, letter, legal. Defined by reference to RFC 2534 "Media Features for Display, Print, and Fax".

size-x and size-y are Rational (>0) feature tags indicating rendered document dimensions in inches (horizontal and vertical respectively). Where actual size is in millimetres, a conversion factor of 10/254 yields an exact inch-based value.

The color feature tag takes values Binary (bi-level), Limited (small fixed palette), Mapped (palettized), Grey (continuous grey-scale), or Full (continuous tone color). It provides a broad indication of color handling capability and guides use of additional color feature tags.

The fax feature schema syntax is defined by RFC 2533 "A syntax for describing media feature sets", which in turn uses media feature tags registered per RFC 2506. Capability descriptions are expressed as textual feature-set expressions combining registered tags.

ua-media indicates the media type with values: screen, screen-paged, stationery, transparency, envelope, envelope-plain, continuous. A sender of color image data may adjust color components based on the indicated hard copy or soft copy medium.

Appendix A registers fourteen feature tags in the IETF tree under "IETF Consensus" policy (RFC 2434): size-x, size-y, dpi-xyratio, color-levels, color-space, CIELAB-L/a/b-depth, CIELAB-L/a/b-min/max, image-file-structure, image-coding, image-coding-constraint, JBIG-stripe-size, image-interleave, color-subsampling, MRC-mode, MRC-max-stripe-size. ASN.1 OIDs under 1.3.6.1.8.1.* are assigned for each.

registry

Capability negotiation reveals information about one party to others, potentially allowing a malicious party to make better guesses about specific security holes. Implementors should ensure that capability information is revealed only to appropriate persons, systems, and agents through the mechanisms employed.

security

If a recipient's ability to process certain image types is known, they may be targeted by bulk mailers sending such images. This is an unsolicited bulk mail threat specific to capability disclosure.

security