RFC 2531

Content Feature Schema for Internet Fax

📅 published March 1999, from ietf

RFC 2531: Content Feature Schema for Internet Fax 📠💖

okay bestie, let's get into it 🫶 this one comes from the Network Working Group, and it's a Standards Track doc, so it's a real protocol spec and not just vibes. G. Klyne (from 5GM/Content Technologies) and L. McIntyre (from Xerox Corporation) wrote it, and it's dated March 1999. The header doesn't list anything it obsoletes or updates, so it's standing on its own 🌸

Status of this Memo

so this is an Internet standards track protocol for the whole Internet community, and it's literally asking for discussion and suggestions to make it better 🌈 if you want the current standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1) ✨ and the distribution of this memo is unlimited 💅

Copyright (C) The Internet Society (1999). All Rights Reserved. 🎀

Abstract

the big idea 💡 this doc defines a content feature schema, which is a profile of the media feature registration mechanisms [1,2,3]. it's used for capability identification between extended Internet fax systems [5] 📠

it doesn't describe any specific mechanisms for sending capability info around, but it does assume that whatever mechanism is used will transfer textual values. what it does do is specify a textual format for describing Internet fax capability information 🦋

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

1. Introduction 🌷

this section basically repeats the vibe of the abstract, so you're already halfway there bestie 🫶 the doc defines a content feature schema that's a profile of the media feature registration mechanisms [1,2,3], used for capability identification between extended Internet fax systems [5].

same deal as before: no specific mechanisms for communicating capability info, just the assumption that textual values get transferred, and a textual format for describing Internet fax capability information ✨

the capabilities that can be indicated are based on what's covered by the TIFF file format for Internet fax [7] and Group 3 facsimile [6]. there's also a companion document [4] that describes the relationship and mapping between this schema and Group 3 fax capabilities 🍓

1.1 Organization of this document 🗂️

Section 2 gives the overall syntax for fax feature descriptions, by pointing at the media feature registration and syntax documents [1,2] 💅

Section 3 lists the feature tags that extended Internet fax systems are supposed to recognize and process, depending on their capabilities 🧚

Appendix A has extra feature tag registrations for media features that are specific to fax and don't already have a registration. they're presented in the form that the media feature registration procedure [1] asks for 📋

1.2 Terminology and document conventions 📖

"extended Internet fax system" is the term for 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's used to indicate system capabilities and figure out the form of the data being transferred. it covers both one-way and two-way transfers of capability information 🔁

"capability identification" is a specific kind of capability exchange where a receiving system gives capability information to a sending system 🫶

"capability description" is a collection of data, in some specific format, that describes the capabilities of some communicating entity. it can 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]. that 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 gives you a base vocabulary of features that correspond to media handling capabilities. The feature set syntax gives you 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 lists and briefly describes a bunch of feature tags defined for use with extended Internet fax systems and applications. other systems and applications that support the matching capabilities can use these tags too ✨

the feature tags below are the ones that an extended Internet fax system is expected to recognize, along with whether it can or can't handle them 👑

the definitive descriptions of the feature tags are found by following their registration under the media feature registration procedure [1] (some of which are appended to this document) 📎

NOTE: Having a feature tag in this list doesn't mean that an extended Internet fax system must have that capability. What it means is that the system must recognize the feature tag and deal with it according to the capabilities it does have 💅

Also, an extended Internet fax system isn't prevented from recognizing and offering additional feature tags. The list below is meant to be a basic vocabulary that all extended Internet fax systems can use in a consistent way 🦋

If an unrecognized or unused feature tag is received, the feature set matching rule (described in RFC2533 [2]) works so that the 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 get 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 gets listed. but there are some restrictions on their use: (a) 100dpi resolution can be used only 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 a 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 🌈

okay so color handling is giving rainbow energy 🌈 and this tag is the broad vibe check. Here's the table of legal values:

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

The goal here is to give a broad indication of the color handling a device can do, so you can pick out a few options from a small set of available data resources without getting lost in the details. 💅

The value of this feature also hints at which more detailed color features might apply. Those are in the next section. ✨

'Binary' means black-and-white, or some other bi-level capability. 🖤 No further qualifying feature tags are required.

'Limited' means a small number of distinct, fixed colors, like what you'd get from a highlight printer, a pen plotter, or a limited color display. 🖍️ The 'color-levels' tag should be used to indicate how many distinct colors are available.

NOTE: No ability to indicate any specific or named color is implied by this option.

Some devices use different intensity levels instead of different hues to tell things apart. Lowkey clever! 🧠

'Mapped' means pixel color values are mapped, in some specifiable way, onto a multi-component color space. 🗺️ The 'color-levels' tag may be used to indicate how many distinct colors are available. If it's missing, sufficient levels to display a photographic image should be assumed. 📸

'Grey' means a continuous tone grey-scale capability. 🩶

'Full' means 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. It's giving layers, bestie 🧅

3.6 Color model 🎨

The table of color model feature tags:

      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.

Okay so here's the general model for handling images, color or not. It's described from the receiver's point of view, but there's a similar model running the other way for the scan/send side. 📥📤

          raw bit        pixel         color         physical
          stream  -(A)-> values -(B)-> values -(C)-> rendition
  • "raw bit stream" is a stream of coded bits 🔢
  • (A) is 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) is 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) is how the color values relate to a physical color. This involves interpreting 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). 🧩
  • "physical rendition" is a color value physically realized on a display, printer or other device. 🖨️

There are a LOT of variables at each stage of processing a color image, and any of them could be critical to handling that image properly in some situations. 😵‍💫 In other situations, many of the variables may be implied (to some level of approximation) by the application using them, like color images published on a Web page. 🌐

The color feature framework is meant to let you describe capability at a range of granularity. Feature tags that correspond to implied (or "don't care" or "unknown") feature values can simply be left out of a capability description. 🫶

Grey scale and bi-level images are handled in this framework as a special case, with a 1-component color model. The following features describe color capabilities:

'color-levels' indicates the number of distinct values for each picture element. It 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 matters. There are two kinds of color space to tell apart: device-dependent and calibrated. Device-dependent spaces are named here as 'Device-xxx', and indicate a color space defined by the receiving device. Calibrated color spaces assume a rendering system that is calibrated against an indicated definition, and that can process 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 it may support. 🪞 A calibrated color space should be used when precise color matching is required and there's no specific knowledge of the receiving system.

NOTE: In practice, although they seem like separate concepts, the color model and color space can't 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 how many different values are possible for the L*, a* and b* color components respectively. They only matter when colors 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 (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 🖼️

The table of image coding feature tags:

      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. 📦 The options here are the various profiles of TIFF-FX, per RFC 2301 [7]. They apply to the overall formatting of the image data (TIFF file format, byte ordering, bit ordering, etc.) and don't define specific image coding issues, which are covered by other aspects of the TIFF-FX profile specifications. 🗂️

'image-coding' describes how the raw image data is compressed and coded as a sequence of bits. These are generic tags that can apply to a range of file formats and usage environments. 🧃

'image-coding-constraint' describes how the raw image data coding method is constrained to fit a particular operating environment. The options 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. It indicates the number of scan lines in each stripe except the last one in an image. The legal constraints are:

   (JBIG-stripe-size=128)
   (JBIG-stripe-size>=0)

The latter is equivalent to no restriction. 🚫

The 'MRC-mode' feature indicates whether MRC (mixed raster content) image format capability is available, and which MRC mode is available. A zero value means MRC is not available. A non-zero value is the available MRC mode number. 🧱

An MRC formatted document is really a collection of several images, each described by a separate feature collection. An MRC-capable receiver is presumed able to accept any combination of contained images that follow 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. It 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 are 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. 📐

NOTE: there are many image coding options here, and not all are required in all circumstances.

Specifying the image-file-structure tag value alone is not normally enough to describe a recipient's capabilities. 🙅‍♀️ A general rule is that enough 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 the 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 aren't part of the allowed capability description syntax. They're included to explain some of the constructs used. 💬

The level of detail captured here reflects what's 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 🖤

okay so this one is giving "Super G3" energy 💅 It would include support for B/W JBIG, and it's basically what people call Super G3, except with Internet fax functionality added on top ✨

      (& (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 leveled up to handle grey scale multi-level images 🌈 Since it's keeping with Group 3 fax, it requires equal x- and y- resolutions for a multi-level image, no exceptions bestie 🧚

      (& (| (& (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 one adds 16-bit full-color on top of the previous example, so now we're really eating 🍓

      (& (| (& (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])
               (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 💜

okay this is my favourite one because it's basically matchmaking 💘 It looks at 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]) )

Now for the document itself. Let's say the sender has it 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 mashed together into one composite capability statement with a logical-OR operation, so it means format-1 OR format-2 OR format-3:

      (& (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's little gain in doing so at this point 🙈

The composite document description can then be matched against the receiver capability description, following the rules in [2], and that gives us:

      (& (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 👀

  • 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)).
  • The high resolution version of the document with (dpi=300) must be sent 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.)
  • 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.
  • 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.
  • 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]).

Last but not least: when matching an MRC document description, the description of each component sub-image must match the capabilities of the intended receiver. no shortcuts 🫶

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]. In other words, 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 then 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]. Please read these carefully, this part is serious 😭

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 come down to capability information ending up in the hands of someone who might abuse it. This document specifies capabilities that help a sender work out which image characteristics can be processed by the recipient. It does not specify mechanisms for publishing them. Implementors and users should take care that the mechanisms they use reveal capabilities only to appropriate persons, systems and agents 🔒

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. the spam era is real, bestie 📧

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. thank you all, you're iconic 👑

8. References 📚

These are the references the whole gang leans on, so I'm keeping every single one with all its details, bestie. 🫶

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

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

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

9. Authors' Addresses 🖊️

Here are the two lovely humans who wrote this, with their contact details kept exactly as they appear. 💅

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

Appendix A: Feature registrations ✨

This appendix is where the feature tags get officially registered, so it's giving official-paperwork realness. 👑

A.1 Image size 📏

Media Feature tag name(s): size-x and size-y.

ASN.1 identifiers associated with these feature tags: 1.3.6.1.8.1.7 and 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)

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], and dpi-xyratio [this document].

Intended usage: Common

Author/Change controller: IETF

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.

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], and 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:

okay so this tag tells you how many different pixel color values an image's data can use. 🎨

When mapped (palettized) color is used, this is usually NOT the same as the number of colors the color mapping function can actually represent. Not the same thing, bestie! 🙈

This tag only works together with a color feature that has a value other than Binary. 💜

  • Values appropriate for use with this feature tag: Integer (>=2)
  • The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms:

Color image printing or display apps, where the data you get might depend on what colors the recipient can handle. 🖨️✨

  • 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 a document uses doesn't usually match exactly what a recipient can handle, ngl. 🥺 To get a feature match, at least one side has to declare its number as an inequality.

It is recommended that a recipient declares the number of color values it can handle as an inequality (<=), and that a data resource declares the number of colors 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 pick content that fits a user's physical abilities, unusual values for this feature tag might hint at a user's restricted abilities. 🫶 Be careful with that info, bestie!
  • 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, and a color space value gives you two kinds of info:

  • the color model used to represent a color value, including how many color components it has
  • a mapping between color values and how they actually look when physically rendered

Device color spaces are for when the general color representation matters, but exact color rendering is left up to the device. Device color spaces defined here have values of the form Device- xxx. 🖥️

Calibrated color space values are for a rendering system that's calibrated against some indicated definition and can process device-independent color info accordingly. Very precise, very iconic. 👑

  • Values appropriate for use with this feature tag:
Token
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 apps, where the data you get might depend on the recipient's color handling capabilities. 🖨️
    • Scanning apps, where the data transferred might depend on the originator's image generation capabilities. 📠
  • 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]
  • Interoperability considerations:

A color-handling receiver should indicate any appropriate device color space capability, in addition to any calibrated color spaces it may support. 💜

Calibrated color spaces are meant for when precise color matching is required. Otherwise, if it applies, a device color space (color-space=Device-xxx) should be indicated. 🌸

Documents where exact color matching isn't important should indicate a device color space capability, if that applies to them. 🦋

These principles let sender/receiver feature matching happen when exact color matching isn't required. Bestie, it's all about compromise! 🫶

  • Security considerations:
    • Privacy concerns, related to exposure of personal information: Where feature matching is used to pick content that fits a user's physical abilities, unusual values for this feature tag might hint at a user's restricted abilities. 🙈
    • Denial of service concerns related to consequences of specifying incorrect values: Failing to indicate a generic color space capability for a device may lead to a failure to match color space for an application or document that doesn't need an exact color match. 💀 Don't skip it!
  • 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

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, which is basically the level of detail you can specify for each individual CIELAB color component. 🔍 They define how many distinct values are possible for each of the color components L*, a* and b*.

Typically this gets used with color=mapped, and maybe color=grey or color=full, to show how many distinct colors can actually 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 apps, where the data you get might depend on the recipient's color handling capabilities. 🖨️
    • Scanning apps, where the data transferred might depend on the originator's image generation capabilities. 📠
  • 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) )

(& (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

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: okay so these features are giving supported color range 🌈. Basically they tell you the minimum and maximum value used for each color component in a CIELAB color space. It's the whole range, bestie, no cap.

'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: this one is lowkey for two main vibes 🖨️📠
    • Color image printing and display applications, where the data resource used may depend on the detailed color handling capabilities of the recipient.
    • Scanning applications, where the data transferred may depend on 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 you're describing a recipient's capabilities, the minimum and maximum color component values that can be rendered should be indicated by inequalities, like in the examples above. When you're 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 that fits a user's physical abilities, unusual values for this feature tag might give an indication of a user's restricted abilities. > Please be careful with this one, it's a real privacy leak.
  • Related feature tags: 🎀
color                 [3]
color-space           [this document]
  • Related media types or data formats: TIFF-FX [7] 🗂️
  • Intended usage: Internet fax, and 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 one tells you the file structure used for transferring and presenting image data. 📁 It does NOT tell you how the image data is coded, bestie. That's the job of separate feature tags (like image-coding, etc.).
  • Values appropriate for use with this feature tag: 🍓
Token
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.

For TIFF-FX image data, there are a bunch of image file format constraints imposed by the various usage profiles defined in RFC 2301 [7]. The whole point of the 'image-file-structure' feature tag is to capture those file format constraints. Main character energy 🎬

Registering additional image file structure tags should focus in a similar way 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 it carries information that describes 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]
  • Intended usage: Internet fax, and 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 tells you which form of image data compression and coding is used. 🗜️ It names a generic image coding technique, without caring about any specific profiling of that technique that might be applied on top. Values for this feature are generally applicable across a wide range of image transfer applications, so it's giving versatile ✨

This information is distinct from the image file structure and MRC information conveyed by the 'image-file-structure' tags, so don't mix them up, babe 🙈

  • 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. 📠
  • 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 set up the correct conditions for interoperability between systems, you have to establish the capabilities to handle the generic image coding technique and the specific image coding constraints.
  • 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, and 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 🔢
  • Summary of the media features indicated: this feature tag narrows down the 'image-coding' feature with a specific profile or usage constraints 🎯. Values for this feature are generally specific to a given value of 'image-coding', and also to some restricted application or class of applications. Very precise, very iconic 💅
  • 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: 🫶 same deal as image-coding. To set up the correct conditions for interoperability between systems, you have to establish the capabilities to handle the generic image coding technique and the specific image coding constraints.
  • Related feature tags: 🎀
image-coding             [this document]
JBIG-stripe-size         [this document]
image-interleave         [this document]
  • Related media types or data formats: TIFF-FX [7] 🗂️
  • Intended usage: Internet fax, and 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:

okay so this one is a usage constraint that only applies to JBIG image coding (image-coding=JBIG). It tells you the allowed size for each stripe of an image, except the last stripe ✨

a stripe of a JBIG image is a delimited horizontal band of compressed image data that can be decompressed separately from the data around it. literally so cute 🧚

  • 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)
  • 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:

for Internet fax, the specific constraints a receiver is allowed to have are the ones in the examples above. no cap 💅

⚠️ bestie, a stripe size that isn't limited (JBIG-stripe-size>0) means the whole page of image data gets encoded as one single unit. that can seriously demand a lot of memory on the receiving system, because the entire stripe has to be buffered in memory. 💀
  • Interoperability considerations:

to set up the right conditions for systems to talk to each other, the ability 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

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 shows that an image interleave capability exists 👑

it may be used with JBIG images (image-coding=JBIG) to indicate color plane interleaving of either stripes or entire image planes. the vibes are very organized ngl 🍓

  • 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:
🚨 okay this one is a lot. specifying a plane interleave means an entire page of image data must be buffered in order to generate render the image. that can put considerable demands on the memory of a sending or receiving system. bestie check your RAM 🙈
  • Related feature tags:
    • image-coding [this document]
    • JBIG-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.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 tag tells you whether color information is allowed to be subsampled compared to the luminance data. it's giving sampling drama 🎀

it gets used with continuous color images (color=full), color spaces that split out luminance and color components (like color-space=LAB), and image file structures that support color subsampling.

  • Values appropriate for use with this feature tag:
    • String "1:1:1": this one means there's a full set of color component samples for every luminance component sample. full send 🫶
    • String "4:1:1": this one means there's a set of color samples for each luminance sample. lowkey more efficient vibes ✨
    • (may be extended by further registrations)
  • 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 on the color handling capabilities of the recipient 🖨️
    • Scanning applications, where the data transferred may depend on 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
  • Summary of the media features indicated:

this feature tells you whether MRC (mixed raster content) image format capability is available, plus which MRC mode is available. a zero value means MRC isn't available, and a non-zero value (in the range 1..7) is the number of the available MRC mode. main character energy 👑

an MRC formatted document is really a collection of several images, and each one gets described by its own separate feature collection. an MRC-capable receiver is presumed to be able to accept any combination of contained images that follow the MRC construction rules, where each image matches the separately declared resolution, color capability, color model, image coding, and any other capabilities. it's so organized I'm obsessed 🫶

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 (that's the odd-numbered layers: 1, 3, 5, etc.), and bi-level coders are used for mask layers (the 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 set up the right conditions for systems to talk to each other, the ability to handle the MRC mode and any contained image coding techniques must be established 🤝

  • 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 one can be used with MRC coding (MRC-mode>=1), and it indicates the maximum number of scan lines in each MRC stripe ✨

the value you give is 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 itself 🦋

  • 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:
(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 the ones given as examples above. periodt 💅

  • 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

Appendix B: TIFF mode descriptions ✨

Okay bestie, this appendix is basically a cheat sheet 🧚 for the TIFF modes from RFC 2301 [7]. Each one is written as a feature set expression, using the format from "A syntax for describing media feature sets" [2] and the feature schema this document introduced. 💖

These are illustrations of the feature set combos that the matching TIFF profiles from RFC 2301 need. Here they are:

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

These feature sets are the minimum requirements for each TIFF mode, not the whole story 🌸. So MR and MMR image coding aren't mandatory with TIFF mode F. If you want them, you add them by combining the (TIFF-F) expression with (image-coding=MR) and/or (image-coding=MMR). Easy peasy! 💅

The same goes for the grey and colour TIFF modes (C, L and M). Limited, mapped or full colour aren't mandatory there either. You'd signal them by combining the right expression with (color=limited), (color=mapped) and/or (color=full). 🌈

TIFF profile M is a composite structure, and it's giving buffet 🍓. It can pull in image data coding options from other profiles. The description above only lists the mandatory features, and you can layer other options on top by combining TIFF-M with them. For example, you could add color=limited, mapped or full, and image-coding=MR, MMR or JBIG. ✨

You can also show support for several TIFF profiles at once by combining their expressions with the OR operator. Something like this:

(| (TIFF-F) (TIFF-S) (TIFF-J) )

That one indicates support for all black-and-white modes. Iconic! 🖤

Appendix C: Revision history 🦋

The revision history is a table, so it stays exactly as written. Slay the record keeping 👑

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

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.

The copyright notice is legal text that has to stay word-for-word, so here it is exactly as written. No glow-up allowed on this one 🙈

   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.
📦 where this page comes from