RFC 2879
Content Feature Schema for Internet Fax (V2)
Content Feature Schema for Internet Fax (V2) 📠✨
Okay bestie, this is the RFC that defines how Internet fax machines tell each other what they can actually do 📠💖. It's from August 2000, it's a Standards Track spec from the Network Working Group, and it's written by G. Klyne (Content Technologies) and L. McIntyre (Xerox Corporation). It's RFC 2879, and it obsoletes RFC 2531 🦋. Let's get into it!
Status of This Memo
This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💅.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. 🌸
Abstract
Okay so this document defines a content media feature schema for Internet fax 📠🎀.
It's a profile of the media feature registration mechanisms [1,2,3], and it's used for capability identification between extended Internet fax systems [5] ✨. It replaces and updates the feature schema that was defined in RFC 2531 💜.
Table of Contents
1. Introduction .............................................2
1.1 Organization of this document ........................3
1.2 Terminology and document conventions .................3
1.3 Discussion of this document ..........................4
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 .....................................7
3.6 Color model ..........................................8
3.7 Image coding ........................................11
3.8 MRC mode ............................................12
4. Examples ................................................13
4.1 Simple mode Internet fax system ....................13
4.2 High-end black-and-white Internet fax system.........14
4.3 Grey-scale Internet fax system ......................14
4.4 Full-color Internet fax system (JPEG only) ..........15
4.5 Full-color Internet fax system (JPEG and JBIG) ......16
4.6 Full-color Internet fax system (MRC) ................17
4.7 Sender and receiver feature matching ................19
5. IANA Considerations .....................................21
6. Security Considerations .................................21
6.1 Capability descriptions and mechanisms ..............21
6.2 Specific threats ....................................21
7. Acknowledgements ........................................22
8. References ..............................................22
9. Authors' Addresses ......................................24
Appendix A: Feature registrations ..........................25
A.1 Image size ..........................................25
A.2 Resolution aspect ratio .............................27
A.3 Color levels ........................................28
A.4 Color space ........................................30
A.5 CIELAB color illuminant .............................33
A.6 CIELAB color depth ..................................35
A.7 CIELAB color gamut ..................................37
A.8 Image file structure ................................39
A.9 Image data coding ...................................41
A.10 Image coding constraint ............................43
A.11 JBIG stripe size .................................. 44
A.12 Image interleave ...................................46
A.13 Color subsampling ..................................47
A.14 MRC availability and mode ..........................49
A.15 MRC maximum stripe size ............................50
Appendix B: TIFF mode descriptions .........................52
Appendix C: Changes from RFC 2531 ..........................57
Full Copyright Statement ...................................581. Introduction 🧚
This document defines a content media feature schema for Internet fax, so it's the vibe check for fax capabilities 📠✨.
It's a profile of the media feature registration mechanisms [1,2,3], used for capability identification between extended Internet fax systems [5]. It replaces and updates the feature schema defined in RFC 2531 🌈.
The media feature description mechanisms don't describe any specific mechanism for communicating capability information. They do presume that any such mechanism will transfer textual values 💅. So in combination with this feature schema, they specify a textual format for describing Internet Fax capability information 🎀.
The range of capabilities that can be indicated is based on the ones 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 referencing 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, according to their capabilities 🔥.
Appendix A holds 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" describes 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 therefore to 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 🎀.
"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. 🙈
1.3 Discussion of this document 💬
Discussion of this document should happen on the Internet fax mailing list, which is hosted by the Internet Mail Consortium (IMC). Please send comments about this document to:
ietf-fax@imc.orgTo subscribe to this list, send a message with the body 'subscribe' to "ietf-fax-request@imc.org" 💌.
To see what's gone on before you subscribed, check out the mailing list archive at:
http://www.imc.org/ietf-fax/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, which 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 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 corresponding capabilities may use these tags too 💜.
The feature tags below are the ones an extended Internet fax system is expected to recognize, as in its ability or non-ability to handle them 🫶.
Definitive descriptions of feature tags are given by reference to their registration, according to 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. 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 [2]) operates so that tag is effectively ignored. 🙃
3.1 Image size 📏
Feature tag name Legal values
---------------- ------------
size-x <Rational> (>0)
size-y <Rational> (>0)Reference: this document, Appendix A.
These feature values indicate a rendered document size in inches 📐.
Where the actual size is measured in millimetres, a conversion factor of 10/254 may be applied to 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 is listed. There are some restrictions on their use, though 🚧: (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
continuousReference: "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 ✨
okay bestie, paper size time 📄🎀 these are the only legal values, so no getting creative 💅
Feature tag name Legal values
---------------- ------------
paper-size A4
A3
B4
letter
legalReference: "Media Features for Display, Print, and Fax" [3].
3.5 Color capability 🌈
this one is about how a device handles color, like a broad vibe check 💖 It's how you'd pick between a few data resources without getting lost in the weeds ✨
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 big idea here is to give a broad indication of the color handling capabilities that might be used, for example, to pick from a small number of available data resources 🦋
The value of this feature also hints at the more detailed color handling features that might apply, which we get to in the next section 🧚
Binary means blank-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 say how many distinct colors are available.
NOTE: This option does NOT let you indicate any specific or named color. Some devices might use different intensity levels instead of different hues to tell things apart 🙈
In the context of Internet fax, Limited is read as one-bit-per-color-sample (RGB, CMY or CMYK), depending on which color space is used 🍓
Mapped means pixel color values are mapped, in some specifiable way, to a multi-component color space 🗺️ The color-levels tag MAY be used to say how many distinct colors are available. If it's missing, then sufficient levels to display a photographic image SHOULD be assumed 📸
Grey means 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 💜
3.6 Color model 💅🌸
okay this is the big one, so get comfy 🫶 Here's the full table, verbatim:
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)
color-illuminant <token> (per ITU T.4 [13], E.6.7)
D50
D65
D75
SA
SC
F2
F7
F11
CTnnnn (see below)
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.
Here's the general model for handling an image (color and non-color both), seen from a receiver's point of view. There's a similar model going the other way, 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) 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 SO many variables you can apply at each stage of processing a color image, and any of them MAY 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 on a Web page 🌐
The color feature framework here lets you describe capabilities at a range of granularity 🔍 Feature tags that correspond to implied (or "don't care" or "unknown") feature values MAY simply be omitted from a capability description. Easy!
Grey scale and bi-level images are handled in this framework as a special case, with a 1-component color model 🩶 These features are used for describing color capabilities:
color-levels indicates the number of distinct values for each picture element, and it applies to all but bi-level images. For bi-level images, a value of 2 is implied 🖤
color-space is mainly used with Mapped and Full, but could be used with other modes if the exact color or color model 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 they indicate a color space defined by the receiving device 📟 Calibrated color spaces assume a rendering system that's 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, along with 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: Although they look like separate concepts, the color model and color space can't really be separated. In the end, a color model (RGB, CMY, etc.) has to be defined with respect to some color space 🧠
color-illuminant indicates a CIE illuminant, using the same general form Group 3 fax uses for this purpose (as defined in ITU T.4 [13], section E.6.7) ☀️ When the illuminant is given by its color temperature, the token string CTnnnn is used, where nnnn is a decimal number that's the color temperature in Kelvins. For example, CT7500 means an illuminant color temperature of 7500K 🌡️
NOTE: ITU T.4 uses a binary representation for color temperature values.
In practice, a lot of the illuminant detail here will probably go unused by Internet fax 🙈 The only value likely to get specified is D50, which is the default color illuminant for Group 3 fax ✨
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. You'd use these with palletized color, or with full color where each color component has a different number of possible values 🧚
Color depth values are about how color values are represented, NOT the resolution of a scanning or rendering device 💅 So if 256 different L-component values can be represented, the assertion (CIELAB-L-depth<=256) is used, even if a receiving device can only render 100 distinct luminance values. (Color rendering resolution is not covered by this memo.) 📝
The CIELAB-x-min and CIELAB-x-max values indicate a color gamut, which is 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
okay so this is where the image data gets its outfit and its moves 💅 here's the whole lineup, verbatim:
Feature tag name Legal values
---------------- ------------
image-file- TIFF
structure TIFF-limited
TIFF-minimal
TIFF-MRC
TIFF-MRC-limited
(may be extended by further registrations)
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)Reference: this document, appendix A.
image-file-structure is the wrapper bestie 🎀 it defines how the coded image data gets wrapped and formatted. Here are the options:
TIFFmeans the image data is enclosed and tagged using TIFF structures, as described in Adobe's definition of TIFF [20]. Iconic classic. 👑TIFF-limitedmeans the image data is structured using TIFF, but with limits on where Image File Descriptors (IFDs) get placed, as listed in section 4.4.6 of RFC 2301 [7]. Restrictions, but make it cute 🦋TIFF-minimalmeans it's a TIFF format that meets the IFD placement, byte ordering and bit ordering requirements of the "minimal black and white mode" from section 3.5 of RFC 2301 [7], also known as TIFF-S. It's giving minimalist queen 🧚TIFF-MRCuses a TIFF image structure [20] plus a sub-IFD structure, described for the "Mixed Raster Content mode" in section 8.1.2 of RFC 2301 [7], also known as TIFF-M. This gives you a file structure for composite images built with the MRC model from T.44 [15] (see tagMRC-mode). Layers on layers, obsessed 🌈TIFF-MRC-limitedis the same asTIFF-MRC, except the primary IFD (the top-level ones, as opposed to sub-IFDs) placement is constrained the same way asTIFF-limited. Main character energy with a little rule-following 💜
image-coding describes how the raw image data gets compressed and coded as a sequence of bits. These are generic tags that can apply to a bunch of file formats and usage environments, so they're pretty flexible ✨
image-coding-constraint describes how the raw image data coding method gets constrained so it fits 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 tells you 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, so it's basically the "anything goes" option 🙈
NOTE: there are several image coding options here, and not all are required in all circumstances. Specifyingimage-file-structureby itself usually isn't enough to describe what a recipient can do. A general rule is that you should give enough detail to exclude any unsupported features. For extended Internet fax,image-file-structureandimage-codingshould always be specified, together with any of the additional values described above that are needed to clearly show which feature tag values are supported and which aren't. (See also the examples in section 4.) Be specific, bestie, no vague vibes 💀
3.8 MRC mode
This section is all about MRC (mixed raster content) 🌸 here are the tags:
Feature tag name Legal values
---------------- ------------
MRC-mode <Integer> (0..7) (per ITU T.44 [15])
MRC-max-stripe-size <Integer>Reference: this document, appendix A.
The MRC-mode feature shows whether MRC image format capability is available. A zero value means MRC isn't available, and a non-zero value is the maximum MRC mode number that's available 🦋
An MRC formatted document is actually a collection of several images, and each one is described by its own feature collection. An MRC-capable receiver is presumed to be able to accept any combination of contained images that follows both the MRC construction rules and the image-coding capabilities declared elsewhere. Trust, but make sure the capabilities match 🫶
Inside an MRC-formatted document, multi-level coders are used for foreground and background images (the odd-numbered layers: 1, 3, 5, and so on), and bi-level coders are used for mask layers (the even-numbered layers: 2, 4, 6, and so on). MRC format also puts constraints on which resolutions you can use. Rules are rules, babe 📏
The MRC-max-stripe-size feature may be used with MRC coding, and it tells you the maximum number of scan lines in each MRC stripe. The legal constraints are:
(MRC-max-stripe-size<=256)
(MRC-max-stripe-size>=0)These values are upper bounds on the stripe size. The actual value can vary between stripes, and the actual size for each stripe is shown in the image data. So the limit is a ceiling, not a fixed number 💜
4. Examples ✨
The level of detail captured here matches what's used for capability identification in Group 3 facsimile. Let's look at some real examples, I'm so excited 🎀
4.1 Simple mode Internet fax system
This example describes the capabilities of a typical simple mode Internet fax system. Note that TIFF profile S is required to be supported by a system like this. Non-negotiable, honestly 💅
(& (image-file-structure=TIFF-minimal)
(MRC-mode=0)
(color=Binary)
(image-coding=MH) (MRC-mode=0)
(| (& (dpi=204) (dpi-xyratio=[204/98,204/196]) )
(& (dpi=200) (dpi-xyratio=[200/100,1]) ) )
(size-x<=2150/254)
(paper-size=A4)
(ua-media=stationery) )4.2 High-end black-and-white Internet fax system
This one includes support for B/W JBIG and is equivalent to what people sometimes call "Super G3," except with Internet fax functionality added on top. Upgrade energy 🚀
(& (image-file-structure=TIFF)
(MRC-mode=0)
(color=Binary)
(| (& (dpi=204) (dpi-xyratio=[204/98,204/196]) )
(& (dpi=200) (dpi-xyratio=[200/100,1]) )
(& (dpi=300) (dpi-xyratio=1) ) )
(| (image-coding=[MH,MR,MMR])
(& (image-coding=JBIG)
(image-coding-constraint=JBIG-T85)
(JBIG-stripe-size=128) ) )
(size-x<=2150/254)
(paper-size=[letter,A4,B4]) )
(ua-media=stationery) )4.3 Grey-scale Internet fax system
This is the previous example, extended to handle grey scale multi-level images. Keeping with Group 3 fax, this example requires equal x- and y- resolutions for a multi-level image. Symmetry is everything 🌈
(& (image-file-structure=TIFF)
(MRC-mode=0)
(| (& (color=Binary)
(| (image-coding=[MH,MR,MMR])
(& (image-coding=JBIG)
(image-coding-constraint=JBIG-T85)
(JBIG-stripe-size=128) ) )
(| (& (dpi=204) (dpi-xyratio=[204/98,204/196]) )
(& (dpi=200) (dpi-xyratio=[200/100,1]) )
(& (dpi=300) (dpi-xyratio=1) ) )
(& (color=Grey)
(color-levels<=256)
(color-space-CIELAB)
(color-illuminant=D50)
(CIELAB-L-min>=0)
(CIELAB-L-max<=100)
(| (& (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) ) )
(size-x<=2150/254)
(paper-size=[letter,A4,B4]) )
(ua-media=stationery) )4.4 Full-color Internet fax system (JPEG only)
This adds 24-bit full-color to the previous example. Full glam, full color 🌸🍓
(& (image-file-structure=TIFF)
(MRC-mode=0)
(| (& (color=Binary)
(image-coding=[MH,MR,MMR])
(| (& (dpi=204) (dpi-xyratio=[204/98,204/196]) )
(& (dpi=200) (dpi-xyratio=[200/100,1]) )
(& (dpi=300) (dpi-xyratio=1) ) ) )
(& (color=grey)
(image-coding=JPEG)
(image-coding-constraint=JPEG-T4E)
(color-levels<=256)
(color-space=CIELAB)
(color-illuminant=D50)
(CIELAB-L-min>=0)
(CIELAB-L-max<=100)
(dpi=[100,200,300]) (dpi-xyratio=1) )
(& (color=full)
(image-coding=JPEG)
(image-coding-constraint=JPEG-T4E)
(color-subsampling=["1:1:1","4:1:1"])
(color-levels<=16777216)
(color-space=CIELAB)
(color-illuminant=D50)
(CIELAB-L-min>=0)
(CIELAB-L-max<=100)
(CIELAB-a-min>=-85)
(CIELAB-a-max<=85)
(CIELAB-b-min>=-75)
(CIELAB-b-max<=125)
(dpi=[100,200,300]) (dpi-xyratio=1) ) )
(size-x<=2150/254)
(paper-size=[letter,A4,B4]) )
(ua-media=stationery) )4.5 Full-color Internet fax system (JPEG and JBIG) 🎨
okay so this one takes the last example and gives it a glow-up ✨ it adds limited CMY(K), RGB, and 16-bit mapped color, all using JBIG coding. the whole thing is wrapped in a TIFF file structure, so it's giving full rainbow energy 🌈
(& (image-file-structure=TIFF)
(MRC-mode=0)
(| (& (color=Binary)
(| (image-coding=[MH,MR,MMR])
(& (image-coding=JBIG)
(image-coding-constraint=JBIG-T85)
(JBIG-stripe-size=128) ) )
(| (& (dpi=204) (dpi-xyratio=[204/98,204/196]) )
(& (dpi=200) (dpi-xyratio=[200/100,1]) )
(& (dpi=300) (dpi-xyratio=1) ) ) )
(& (color=Limited)
(image-coding=JBIG)
(image-coding-constraint=JBIG-T43)
(JBIG-stripe-size=128)
(image-interleave=stripe)
(| (& (color-space=[Device-RGB,Device-CMY])
(color-levels<=8) )
(& (color-space=Device-CMYK)
(color-levels<=16) ) )
(dpi=[100,200,300]) (dpi-xyratio=1) )
(& (color=Mapped)
(image-coding=JBIG)
(image-coding-constraint=JBIG-T43)
(JBIG-stripe-size=128)
(image-interleave=stripe)
(color-levels<=65536)
(color-space=CIELAB)
(color-illuminant=D50)
(CIELAB-L-min>=0)
(CIELAB-L-max<=100)
(CIELAB-a-min>=-85)
(CIELAB-a-max<=85)
(CIELAB-b-min>=-75)
(CIELAB-b-max<=125)
(dpi=[100,200,300]) (dpi-xyratio=1) )
(& (color=grey)
(| (& (image-coding=JPEG)
(image-coding-constraint=JPEG-T4E) )
(& (image-coding=JBIG)
(image-coding-constraint=JBIG-T43)
(JBIG-stripe-size=128)
(image-interleave=stripe) ) )
(color-levels<=256)
(color-space=CIELAB)
(color-illuminant=D50)
(CIELAB-L-min>=0)
(CIELAB-L-max<=100)
(dpi=[100,200,300]) (dpi-xyratio=1) )
(& (color=full)
(| (& (image-coding=JPEG)
(image-coding-constraint=JPEG-T4E)
(color-subsampling=["1:1:1","4:1:1"]) )
(& (image-coding=JBIG)
(image-coding-constraint=JBIG-T43)
(JBIG-stripe-size=128)
(image-interleave=stripe) ) )
(color-levels<=16777216)
(color-space=CIELAB)
(color-illuminant=D50)
(CIELAB-L-min>=0)
(CIELAB-L-max<=100)
(CIELAB-a-min>=-85)
(CIELAB-a-max<=85)
(CIELAB-b-min>=-75)
(CIELAB-b-max<=125)
(dpi=[100,200,300]) (dpi-xyratio=1) ) )
(size-x<=2150/254)
(paper-size=[letter,A4,B4]) )
(ua-media=stationery) )4.6 Full-color Internet fax system (MRC) 🧩
this one adds MRC image structures on top of the previous example, so it's like the whole outfit but layered 🧥✨
(& (image-file-structure=TIFF-MRC)
(MRC-mode<=1) (MRC-max-stripe-size>=0)
(| (& (color=binary)
(| (image-coding=[MH,MR,MMR])
(& (image-coding=JBIG)
(image-coding-constraint=JBIG-T85)
(JBIG-stripe-size=128) ) )
(| (& (dpi=204) (dpi-xyratio=[204/98,204/196]) )
(& (dpi=200) (dpi-xyratio=[200/100,1]) )
(& (dpi=[300,400]) (dpi-xyratio=1) ) ) )
(& (color=limited)
(| (& (color-space=[Device-RGB,Device-CMY])
(color-levels<=8) ) )
(| (& (color-space=Device-CMYK)
(color-levels<=16) ) )
(image-coding=JBIG)
(image-coding-constraint=JBIG-T43)
(JBIG-stripe-size=128)
(image-interleave=stripe)
(dpi=[100,200,300,400]) (dpi-xyratio=1) )
(& (color=mapped)
(color-levels<=65536)
(image-coding=JBIG)
(image-coding-constraint=JBIG-T43)
(JBIG-stripe-size=128)
(image-interleave=stripe)
(color-space=CIELAB)
(CIELAB-L-min>=0)
(CIELAB-L-max<=100)
(CIELAB-a-min>=-85)
(CIELAB-a-max<=85)
(CIELAB-b-min>=-75)
(CIELAB-b-max<=125) ) )
(color-illuminant=D50)
(dpi=[100,200,300,400]) (dpi-xyratio=1) )
(& (color=grey)
(| (& (image-coding=JPEG)
(image-coding-constraint=JPEG-T4E) )
(& (image-coding=JBIG)
(image-coding-constraint=JBIG-T43)
(JBIG-stripe-size=128)
(image-interleave=stripe) ) )
(color-space=CIELAB)
(color-levels<=256)
(color-illuminant=D50)
(CIELAB-L-min>=0)
(CIELAB-L-max<=100)
(dpi=[100,200,300,400]) (dpi-xyratio=1) )
(& (color=full)
(| (& (image-coding=JPEG)
(image-coding-constraint=JPEG-T4E)
(color-subsampling=["1:1:1","4:1:1"]) )
(& (image-coding=JBIG)
(image-coding-constraint=JBIG-T43)
(JBIG-stripe-size=128)
(image-interleave=stripe) ) )
(color-levels<=16777216)
(color-space=CIELAB)
(color-illuminant=D50)
(CIELAB-L-min>=0)
(CIELAB-L-max<=100)
(CIELAB-a-min>=-85)
(CIELAB-a-max<=85)
(CIELAB-b-min>=-75)
(CIELAB-b-max<=125)
(dpi=[100,200,300,400]) (dpi-xyratio=1) ) )
(size-x<=2550/254)
(Paper-size=[Letter,A4,B4])
(ua-media=stationery) )4.7 Sender and receiver feature matching 🤝
okay this is my favorite bit 🥹 it's about sending a doc to an enhanced black-and-white fax system. here's what the receiver can handle:
(& (| (& (dpi=200) (dpi-xyatio=200/100) )
(& (dpi=200) (dpi-xyratio=1) )
(& (dpi=300) (dpi-xyratio=1) )
(& (dpi=400) (dpi-xyratio=1) ) )
(color=Binary)
(| (& (paper-size=A4) (ua-media=[stationery,transparency]) )
(& (paper-size=B4) (ua-media=continuous) ) )
(image-coding=[MH,MR,JBIG]) )now the document itself. the sender has it in three possible formats: A4 high resolution, B4 low resolution, and A4 high resolution color. they look like this:
(& (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) )those three can be squished into one composite statement with a logical-OR (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 basically no gain in doing that right now 🤷♀️
the composite description can be matched against the receiver capabilities, following the rules in [2], and the result is:
(| (& (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]) ) )some key tea about the matching process 🫖:
- the color document option gets eliminated because the receiver can't handle either color (that's the
(color=Mapped)) or JPEG coding (that's the(image-coding=JPEG)) 🙅♀️ - the high resolution version with
(dpi=300)has to be send using(image-coding=JBIG), because that's the only coding of the image data the receiver can use for high resolution docs. (the available 300dpi codings here are MMR and JBIG, and the receiver does MH, MR and JBIG.) - the low-resolution version can go out with either MH or MR coding, since the receiver can deal with either one for low resolution docs 💖
- the high resolution variant is only available for A4, so that's the paper-size used there. same deal for the low resolution version, which gets sent on B4 paper 📄
- even though the sender might not understand the
ua-mediafeature tag and doesn't mention it, the matching rules keep the constraint that the B4 doc gets rendered with(ua-media=continuous), and the A4 doc may be rendered with(ua-media=[stationery,transparency])🧚
last thing, and it's important 🚨: when you match an MRC document description, the description of each component sub-image has to match the capabilities of the intended receiver.
5. IANA Considerations 📋
okay so appendix A of this doc repeats the descriptions of feature tags that came from RFC 2531 [22], with some small revisions 🔁. they've been registered in the "IETF tree", following the procedure described in section 3.1.1 of "Media Feature Tag Registration Procedure" [1]. so basically these feature tags are subject to the "IETF Consensus" policies described in RFC 2434 [21] 📚.
appendix section A.5 introduces one new feature tag (color-illuminant) that should be registered following the same procedure. an ASN.1 identifier should be assigned for this new tag and then replaced in the body of the registration 🆔.
6. Security Considerations 🚨🔐
the points raised below are on top of the general security considerations for extended Internet fax [5], and the others discussed in [2,8,11,12,13]. this part is serious, bestie, so pay attention 👀.
6.1 Capability descriptions and mechanisms 🕵️♀️
negotiation mechanisms reveal information about one party to other parties. this can raise privacy concerns, and it may allow a malicious party to make better guesses about the presence of specific security holes 😬.
most of these concerns are about capability info getting into the hands of someone who might abuse it. this document specifies capabilities that help a sender figure out which image characteristics the recipient can process, but it does NOT specify mechanisms for publishing them. so implementers and users should take care that the mechanisms they use make sure capabilities are revealed only to appropriate persons, systems and agents 🔒.
⚠️ capability info is a bit like your diary. only share it with people you actually trust.
6.2 Specific threats 💀
- Unsolicited bulk mail: if it's known that a recipient can process certain types of images, they may be targeted by bulk mailers that want to send those images 📬. ick.
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 that some of the features described here are based on: Larry Masinter, Al Gilman, Koen Holtman 🌸.
8. References 📚✨
okay bestie, this is the bibliography, aka the list of every other doc this one leans on. it's giving research paper energy 🤓💅
[1] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag Registration Procedure", 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 T.30 Feature Mapping", RFC 2880, July 2000.
[5] Masinter, L. and D. Wing, RFC 2532, "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 (1999), International Telecommunications Union, March 1999
[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) 🌈
[12] Klyne, G., "Protocol-independent Content Negotiation Framework", RFC 2703, September 1999.
[13] "Standardization of Group 3 facsimile terminals for document transmission", ITU-T Recommendation T.4 (1999), 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.
[22] Klyne, G. and L. McIntyre, "Content feature schema for Internet fax", RFC 2531, March 1999.
9. Authors' Addresses 🫶
meet the people behind the spec! 🧚
Graham Klyne
Content Technologies Ltd.
1220 Parkview,
Arlington Business Park
Theale
Reading, RG7 4SA
United Kingdom.
Phone: +44 118 930 1300
Fax: +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
Fax: +1-650-845-2340
EMail: Lloyd.McIntyre@pahv.xerox.comAppendix A: Feature registrations 🎀
okay this is the fun part, the registry entries for the feature tags. every one has the same little checklist so you know exactly what you're getting 📋💖
A.1 Image size 📏
- Media Feature tag name(s):
size-xsize-y
- ASN.1 identifiers associated with these feature tags:
size-x: 1.3.6.1.8.1.7
size-y: 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]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]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 (palletized) 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)
- 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 (i.e. not both as equalities).
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. 🙈
- 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:
okay so this one is all about the color space 🎨✨ and a color space value actually tells you two things:
- the color model used to represent a color value, including the number of color components
- a mapping between color values and their physical realizations
Device color spaces are for when the general color representation matters, but the exact rendering is left up to the device 💅. Device color spaces defined here have values of the form Device-xxx. Calibrated color spaces are for a rendering system that's calibrated to some indicated definition and can process device-independent color info accordingly 🦋.
- 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)the CIELAB one is so iconic 😭. 'Color-space=CIELAB' means the CIE L*a*b* colour space, using the 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 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:
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 needed. 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 applicable. These principles let sender/receiver feature matching work when exact color matching isn't required ✨.
- Security considerations:
- Privacy concerns, related to exposure of personal information: where feature matching is used to select content that fits the physical abilities of a user, unusual values for this feature tag might give away 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 failed color space match for an application or document that doesn't need 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
A.5 CIELAB color illuminant 💡
- Media Feature tag name(s):
color-illuminant
- ASN.1 identifier associated with this feature tag:
1.3.6.1.8.1.29
- Summary of the media features indicated:
this feature indicates a color illuminant 🔦. It tweaks the color space calibration so it reflects different sources of light. A color-illuminant value would normally only be used with a calibrated color space, so don't go pairing it with a device one 🙈.
- Values appropriate for use with this feature tag:
Token
CIELAB illuminant D50
values: D65
D75
SA
SC
F2
F7
F11
Defined by color CTnnnn where 'nnnn' is a decimal
temperature: representation of the illuminant
color temperature in Kelvins.
(may be extended by further registrations)NOTE: The default color illuminant for Group 3 fax is D50.
- 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 detailed 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:
to describe rendering or scanning capabilities, or to describe capabilities assumed by a document for which exact color handling capabilities are required:
(& (color-space=CIELAB) (color-illuminant=D50) )- Related standards or documents:
- CIELAB color illuminant representations are described in ITU T.4 [13], Annex E.6.7.
- Interoperability considerations:
a color-handling receiver that supports a calibrated color space should indicate any constraint on the illuminants it can handle 🧐. If there's no color-illuminant constraint, a receiver is presumed to accept and deal with any specified illuminant value, so it's all good bestie 💖.
- 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.6 CIELAB color depth 🎀
- Media Feature tag name(s):
CIELAB-L-depthCIELAB-a-depthCIELAB-b-depth
- ASN.1 identifiers associated with these feature tags:
CIELAB-L-depth:1.3.6.1.8.1.12CIELAB-a-depth:1.3.6.1.8.1.13CIELAB-b-depth:1.3.6.1.8.1.14
- Summary of the media features indicated:
these feature tags indicate a color depth capability 🌸. That's the level of detail to which an individual CIELAB color component can be specified. They define how many distinct values are possible for each of the color components L*, a* and b*.
Typically, this feature gets used with color=mapped, and maybe color=grey or color=full, to show how many distinct colors can be represented 🍓.
NOTE: this feature tag describes the number of values that can be represented for a color component, and does not necessarily indicate the number of distinct values that can be rendered or resolved by a system. Don't mix up "can be represented" with "can actually be seen" 👀.
- 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 on 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:
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]
- The memo "Media Features for Display, Print, and Fax" [3] defines a feature (
- 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.7 CIELAB color gamut 🌈
- Media Feature tag name(s):
CIELAB-L-minCIELAB-L-maxCIELAB-a-minCIELAB-a-maxCIELAB-b-minCIELAB-b-max
- ASN.1 identifiers associated with these feature tags:
CIELAB-L-min: 1.3.6.1.8.1.15
CIELAB-L-max: 1.3.6.1.8.1.16
CIELAB-a-min: 1.3.6.1.8.1.17
CIELAB-a-max: 1.3.6.1.8.1.18
CIELAB-b-min: 1.3.6.1.8.1.19
CIELAB-b-max: 1.3.6.1.8.1.20- Summary of the media features indicated:
Okay so these tags are all about the range of colours a device can handle 🎨✨. You give a minimum and maximum for each colour component in a CIELAB colour space, and that's your whole gamut bestie 💅.
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 🦋.
NOTE: colour component values are assumed to be rational numbers, so a limited gamut does not necessarily indicate limited colour resolution. Not the same thing, bestie!! 🙈
- 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:
- Colour image printing and display applications, where the data resource used may depend upon detailed colour handling capabilities of the recipient 🖨️
- Scanning applications, where the data transferred may depend upon the detailed colour 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-a-min=-35)
(CIELAB-a-max=+55)
(CIELAB-b-min=-45)
(CIELAB-b-max=+65) )- Related standards or documents:
- CIELAB colour 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 colour 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 colour 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. 🔐 This one's kinda serious, so please keep it in mind 🫶.
- Related feature tags:
color [3]
color-space [this document]- Related media types or data formats:
TIFF-FX [7]- Intended usage:
- Internet fax
- Colour image scanning/rendering applications
- Author/Change controller:
IETF
A.8 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's described by separate feature tags (image-coding, etc.), so don't mix them up, bestie 🙅♀️.
- Values appropriate for use with this feature tag:
Token
Image file TIFF
structure TIFF-limited
options: TIFF-minimal
TIFF-MRC
TIFF-MRC-limited
(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, so keep those separate 🧩.
The following tag values are defined here:
TIFFindicates image data enclosed and tagged using TIFF structures described in Adobe's definition of TIFF [20] 🍓.TIFF-limitedindicates image data structured using TIFF, but with limitations on the placement of Image File Descriptors (IFDs) within the file, which are indicated in section 4.4.6 of RFC 2301 [7] 📍.TIFF-minimalindicates a TIFF image format that meets the IFD placement, byte ordering and bit ordering requirements of the "minimal black and white mode" described in section 3.5 of RFC 2301 [7], also known as TIFF-S ⚫⚪.TIFF-MRCuses a TIFF image structure [20] augmented with a sub-IFD structure, described for the "Mixed Raster Content mode" in section 8.1.2 of RFC 2301 [7], also known as TIFF-M (see also tagMRC-mode) 🧁.TIFF-MRC-limitedis the same asTIFF-MRC, except that the IFD placement is constrained as forTIFF-limited💜.
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]
MRC-mode [this document]- Related media types or data formats:
TIFF-FX [7]
TIFF V6.0 (Adobe) [20]- Intended usage:
- Internet fax
- Image scanning/rendering applications
- Author/Change controller:
IETF
A.9 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. Different thing, same vibe 💅.
- 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 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.10 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 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]- Related media types or data formats:
TIFF-FX [7]- Intended usage:
- Internet fax
- Color image scanning/rendering applications
- Author/Change controller:
IETF
A.11 JBIG stripe size 💖
Okay bestie, this one is a usage constraint for JBIG image coding (image-coding=JBIG). It says how big each stripe of an image can be, except the last one. 🦋
A stripe of a JBIG image is a delimited horizontal band of compressed image data. You can decompress it on its own, without needing the data around it. ✨
- Media Feature tag name(s):
JBIG-stripe-size
- ASN.1 identifier associated with these feature tags:
1.3.6.1.8.1.24
- 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:
- 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. 🙈
Bestie, an unlimited stripe means the WHOLE page has to sit in memory on the receiving end. That's a lot of RAM energy 😭
- 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
A.12 Image interleave 🧚
This feature tells you about an image interleave capability. It's giving layered, color-plane vibes. 🎀
It can be used with JBIG images (image-coding=JBIG) to say that color planes are interleaved either by stripes or by entire image planes. 🌸
- Media Feature tag name(s):
image-interleave
- ASN.1 identifier associated with this feature tag:
1.3.6.1.8.1.25
- 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 or 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]
- Related media types or data formats:
- TIFF-FX [7]
- Intended usage:
- Internet fax
- Color image scanning/rendering applications 💜
- Author/Change controller:
- IETF
A.13 Color subsampling 🍓
This tag says whether color information may be subsampled with respect to luminance data. Like, is the color getting a little less detail than the brightness? Yes, that's the vibe. 👑
It's used with continuous color images (color=full), with color spaces that have separate luminance and color components (like color-space=LAB), and with image file structures that support color subsampling. ✨
- Media Feature tag name(s):
color-subsampling
- ASN.1 identifier associated with this feature tag:
1.3.6.1.8.1.26
- 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 one set of color component
samples for each 4 luminance samples.
(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 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=[LAB,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.14 MRC availability and mode 🦋
This feature is all about MRC (mixed raster content) image format capability. It tells you whether MRC is available at all, and if it is, which MRC mode is available. 🎀
A zero value means MRC is not available. A non-zero value, in the range 1..7, is the MRC mode number that's available. 💅
An MRC formatted document is basically a collection of several images. Each one gets its own feature collection. An MRC-capable receiver is assumed to be able to accept any combination of the contained images that follow the MRC construction rules. Each of those images has to match its 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 (that is, the odd-numbered layers: 1, 3, 5, etc.). Bi-level coders are used for mask layers (that is, the even-numbered layers: 2, 4, 6, etc.). 🌸
- Media Feature tag name(s):
MRC-mode
- ASN.1 identifier associated with this feature tag:
1.3.6.1.8.1.27
- 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. 🫶
- 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.15 MRC maximum stripe size 🔥
Last one in this part, and it's a cute one. This tag is used with MRC coding (MRC-mode>=1) and tells you the maximum number of scan lines in each MRC stripe. 🌈
The value you get is an upper bound on the stripe size. The actual value can change from stripe to stripe, and the real size for each stripe is written in the image data itself. 🧚
- Media Feature tag name(s):
MRC-max-stripe-size
- ASN.1 identifier associated with this feature tag:
1.3.6.1.8.1.28
- 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<=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
Appendix B: TIFF mode descriptions ✨
Okay bestie, this appendix is the cheat sheet 🌸 It describes the TIFF modes from RFC 2301 [7] as feature set expressions, written in the format from "A syntax for describing media feature sets" [2] and using the feature schema this document introduces. Think of them as examples of which feature combos you need for each TIFF profile in RFC 2301. 🦋
TIFF-S has no optional bits, so it's just one feature set, no drama. Everything else comes as (TIFF-x-base) and (TIFF-x-full), which are the minimum and full sets for each profile. 💅
(TIFF-S) :-
(& (image-file-structure=TIFF-S)
(color=Binary)
(image-coding=MH) (MRC-mode=0)
(| (& (dpi=200)
(dpi-xyratio=[200/100,200/200])
(size-x=1728/200) )
(& (dpi=204)
(dpi-xyratio=[204/98,204/196]
(size-x=1728/204) ) )
(paper-size=A4) )
(TIFF-F-base) :-
(& (image-file-structure=TIFF-F)
(color=Binary)
(image-coding=MH) (MRC-mode=0)
(dpi=204)
(dpi-xyratio=[204/98,204/196])
(size-x=1728/204)
(paper-size=A4) )
(TIFF-F-full) :-
(& (image-file-structure=TIFF-F)
(color=Binary)
(image-coding=[MH,MR,MMR]) (MRC-mode=0)
(| (& (dpi=200)
(dpi-xyratio=[200/100,200/200])
(size-x=[1728/200,2048/200,2432/200]) )
(& (dpi=204)
(dpi-xyratio=[204/98,204/196,204/391])
(size-x=[1728/204,2048/204,2432/204]) )
(& (dpi=300)
(dpi-xyratio=300/300)
(size-x=[2592/300,3072/300,3648/300]) )
(& (dpi=400)
(dpi-xyratio=400/400)
(size-x=[3456/400,4096/400,4864/400]) )
(& (dpi=408)
(dpi-xyratio=408/391)
(size-x=[3456/408,4096/408,4864/408]) ) )
(paper-size=[A4, B4, A3, letter, legal]) )
(TIFF-J-base) :-
(& (image-file-structure=TIFF-J)
(color=Binary)
(MRC-mode=0)
(image-coding=JBIG)
(image-coding-constraint=JBIG-T85)
(JBIG-stripe-size=128)
(dpi=204)
(dpi-xyratio=[204/98,204/196])
(size-x=1728/204)
(paper-size=A4) )
(TIFF-J-full) :-
(& (image-file-structure=TIFF-J)
(color=Binary)
(MRC-mode=0)
(image-coding=JBIG)
(image-coding-constraint=JBIG-T85)
(JBIG-stripe-size>0)
(| (& (dpi=200)
(dpi-xyratio=[200/100,200/200])
(size-x=[1728/200,2048/200,2432/200]) )
(& (dpi=204)
(dpi-xyratio=[204/98,204/196,204/391])
(size-x=[1728/204,2048/204,2432/204]) )
(& (dpi=300)
(dpi-xyratio=300/300)
(size-x=[2592/300,3072/300,3648/300]) )
(& (dpi=400)
(dpi-xyratio=400/400)
(size-x=[3456/400,4096/400,4864/400]) )
(& (dpi=408)
(dpi-xyratio=408/391)
(size-x=[3456/408,4096/408,4864/408]) ) )
(paper-size=[A4, B4, A3, letter, legal]) )
(TIFF-C-base) :-
(& (image-file-structure=TIFF-C)
(color=grey)
(color-levels<=256)
(MRC-mode=0)
(image-coding=JPEG) (image-coding-constraint=JPEG-T4E)
(color-space=CIELAB)
(CIELAB-L-depth<=101)
(CIELAB-L-min>=0)
(CIELAB-L-max<=100)
(color-illuminant=D50)
(dpi=200) (dpi-xyratio=1)
(size-x=864/100)
(paper-size=A4) )
(TIFF-C-full) :-
(& (image-file-structure=TIFF-C)
(image-coding=JPEG) (image-coding-constraint=JPEG-T4E)
(color-space=CIELAB)
(| (& (color=grey)
(color-levels<=4096)
(CIELAB-L-depth<=4096) )
(& (color=full)
(color-levels<=68719476736)
(color-subsampling=["4:1:1","1:1:1"])
(CIELAB-L-depth<=4096)
(CIELAB-a-depth<=4096)
(CIELAB-b-depth<=4096) ) )
(MRC-mode=0)
(dpi=[100,200,300,400]) (dpi-xyratio=1)
(size-x=[864/100,1024/100,1216/100])
(paper-size=[A4, B4, A3, letter, legal]) )
(TIFF-L-base) :-
(& (image-file-structure=TIFF-L)
(MRC-mode=0)
(image-coding=JBIG)
(image-coding-constraint=JBIG-T43)
(JBIG-stripe-size=128)
(image-interleave=stripe)
(color=grey)
(color-levels<=256)
(color-space=CIELAB)
(CIELAB-L-depth=101)
(CIELAB-L-min>=0)
(CIELAB-L-max<=100)
(color-illuminant=D50)
(dpi=200) (dpi-xyratio=1)
(size-x=864/100)
(paper-size=A4) )
(TIFF-L-full) :-
(& (image-file-structure=TIFF-L)
(MRC-mode=0)
(image-coding=JBIG)
(image-coding-constraint=JBIG-T43)
(JBIG-stripe-size>0)
(image-interleave=[stripe, plane])
(| (& (color=limited)
(color-levels<=8)
(color-space=[Device-RGB, Device-CMY] ) )
(& (color=limited)
(color-levels<=16)
(color-space=Device-CMYK) )
(& (color=mapped)
(color-levels<=65536)
(color-space=CIELAB)
(CIELAB-L-depth<=4096)
(CIELAB-a-depth<=4096)
(CIELAB-b-depth<=4096) )
(& (color=grey)
(color-levels<=4096)
(color-space=CIELAB)
(CIELAB-L-depth<=4096) )
(& (color=full)
(color-space=CIELAB)
(color-levels<=68719476736)
(CIELAB-L-depth<=4096)
(CIELAB-a-depth<=4096)
(CIELAB-b-depth<=4096)
(CIELAB-L-min>=0) ) )
(dpi=[100,200,300,400]) (dpi-xyratio=1)
(size-x=[864/100,1024/100,1216/100])
(paper-size=[A4, B4, A3, letter, legal]) )
(TIFF-M-base) :-
(& (image-file-structure=TIFF-M)
(MRC-mode>=1)
(MRC-max-stripe-size<=256) )
(TIFF-M-full) :-
(& (image-file-structure=TIFF-M)
(MRC-mode>=1) )Support for multiple TIFF profiles can be shown by joining their expressions with the OR operator, like (| (TIFF-F) (TIFF-S) (TIFF-J) ), which means the receiver supports all the black-and-white modes. 🖤
TIFF-M is a composite mode, so it has to be paired with some other mode to say what a receiver can actually do. For example:
(| (TIFF-M-base)
(TIFF-S) (TIFF-J-full) (TIFF-C-base) (TIFF-L-full) )Every sub-image in an MRC image has to match the capabilities listed, AND also any extra limits the MRC structure puts on it, like a bi-level mask layer, and so on. Check section A.13 and section 3.7 for the details. 🧚
Appendix C: Changes from RFC 2531 🍓
Here's the changelog, bestie 📜
00a 23-Jun-1999 Updated Appendix B with more complete TIFF-FX
profile descriptions. Added note to section 3.5
clarifying the meaning of (color=limited) in the
context of Internet fax. Added note to section
3.6 and A.6 to clarify interpretation of color
depth. In A.6, noted that color gamut is not the
same as color resolution; fixed example. Split
section 3.7 into two sections, dealing with simple
image coding options and MRC composite image
options. Added new feature tag 'color-illuminant'
(sections 3.6, A.5). Added cross-references from
TIFF-M image file structure to MRC-mode tag.
Updated introduction and references.
00b 10-Aug-1999 Bring examples into line with T.30 mapping
document [4], and reorganize to make the
expression structure less complex. Add details of
mailing list for discussion. Added JPEG-only
colour example. Change definition of image-file-
structure tag to indicate more precisely what is
being defined, and to draw out the distinction
between a file structure to contain MRC images
(image-file-structure), and the MRC image model
(MRC-mode).
01a 01-Oct-1999 Update author's address and some references.
01b 05-Jan-2000 Incorporate last-call review comments (all
editorial).Quick recap: 00a made the TIFF-FX profiles way more complete and added color-illuminant, 00b tidied up the examples and split apart image-file-structure from MRC-mode, and 01a and 01b were mostly housekeeping 🌈
Full Copyright Statement 💜
Okay, legal stuff, but make it cute 🎀 The copyright belongs to The Internet Society, and it's dated 2000, with all rights reserved. You can copy this document and share it with other people, and you can write derivative works that comment on or explain it, or help people implement it. You can publish and distribute those too, in whole or in part, with no restrictions of any kind. The one catch is that the copyright notice and this paragraph have to stay on every copy and every derivative work. 🦋
BUT you can't modify this document itself in any way. That covers taking out the copyright notice or the references to the Internet Society or other Internet organizations. The only exceptions are when it's needed for developing Internet standards, in which case you have to follow the copyright procedures in the Internet Standards process, or when you're translating it into languages other than English. 🙈
The permissions above are perpetual, and the Internet Society and its successors or assigns will never revoke them. 💖
Also, this document and the information in it are provided "AS IS," 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. 💀
Acknowledgement 🫶
Last one, and it's a sweet one 🌸 Funding for the RFC Editor function is currently provided by the Internet Society. ✨
📦 where this page comes from
- ietf: rfc2879 2000-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms