IETF Fax working group Graham Klyne
INTERNET DRAFT 5GM/Content Technologies
Category: Work-in-progress Lloyd McIntyre
Xerox Corporation
17 November 1998
Expires: May 1999
Content feature schema for Internet fax
<draft-ietf-fax-feature-schema-03.txt>
Status of this memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as ``work in
progress''.
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US
West Coast).
[[INTENDED STATUS: This document specifies an Internet standards
track protocol for the Internet community, and requests discussion
and suggestions for improvements. Please refer to the current
edition of the "Internet Official Protocol Standards" (STD 1) for
the standardization state and status of this protocol.
Distribution of this memo is unlimited.]]
Copyright Notice
Copyright (C) The Internet Society 1998. All Rights Reserved.
Abstract
This document defines a content feature schema that is a profile of
the media feature registration mechanisms [1,2,3] for use in
performing capability identification between extended Internet fax
systems [5].
Klyne/McIntyre Work-in-progress [Page 1]
RFC nnnn Content feature schema for Internet fax
17 November 1998
This document does not describe any specific mechanisms for
communicating capability information, but does presume that any
such mechanisms will transfer textual values. It specifies a
textual format to be used for describing Internet fax capability
information.
Table of contents
1. Introduction ............................................3
1.1 Organization of this document 3
1.2 Terminology and document conventions 3
1.3 Revision history 4
1.4 Unfinished business 5
2. Fax feature schema syntax ...............................5
3. Internet fax feature tags ...............................5
3.1 Image size 6
3.2 Resolution 6
3.3 Media type 7
3.4 Paper Size 7
3.5 Colour capability 8
3.6 Colour model 8
3.7 Image coding 11
4. Examples ................................................12
4.1 Simple mode Internet fax system 13
4.2 High-end black-and-white Internet fax system 13
4.3 Grey-scale Internet fax system 14
4.4 Full-colour Internet fax system (JPEG) 15
4.5 Full-colour Internet fax system (MRC) 15
4.6 Sender and receiver feature matching 16
5. Security considerations .................................18
5.1 Capability descriptions and mechanisms 18
5.2 Specific threats 18
6. Full copyright statement ................................18
7. Acknowledgements ........................................19
8. References ..............................................19
9. Authors' addresses ......................................21
Appendix A: Feature registrations ..........................22
A.1 Image size 22
A.2 Resolution aspect ratio 24
A.3 Colour levels 26
A.4 Colour resolution 28
A.5 Colour space 30
A.6 Colour palette 33
A.7 Colour illuminant 35
A.8 Colour gamut 37
A.9 Colour subsampling 40
A.10 Image file structure 42
A.11 Image data coding 44
A.12 Image coding constraint 46
A.13 JBIG stripe size 48
Klyne/McIntyre Work-in-progress [Page 2]
RFC nnnn Content feature schema for Internet fax
17 November 1998
A.14 Image interleave 50
A.15 MRC availability and mode 52
A.16 MRC maximum stripe size 54
Appendix B: TIFF mode descriptions .........................56
1. Introduction
This document defines a content feature schema that is a profile of
the media feature registration mechanisms [1,2,3] for use in
performing capability identification between extended Internet fax
systems [5].
This document does not describe any specific mechanisms for
communicating capability information, but does presume that any
such mechanisms will transfer textual values. It specifies a
textual format to be used for describing Internet fax capability
information.
The range of capabilities that can be indicated are based on those
covered by the TIFF file format for Internet fax [7] and Group 3
facsimile [6]. A companion document [4] describes the relationship
and mapping between this schema and Group 3 fax capabilities.
1.1 Organization of this document
Section 2 specifies the overall syntax for fax feature descriptions
by reference to the media feature registration and syntax documents
[1,2].
Section 3 enumerates the feature tags that are to be recognized and
processed by extended Internet fax systems, according to their
capabilities.
Appendix A contains additional feature tag registrations for media
features that are specific to fax and for which no applicable
registration already exists. These are presented in the form
prescribed by the media feature registration procedure [1].
1.2 Terminology and document conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The term "eifax system" is used to describe any software, device or
combination of these that conforms to the specification "Extended
Facsimile Using Internet Mail" [5].
Klyne/McIntyre Work-in-progress [Page 3]
RFC nnnn Content feature schema for Internet fax
17 November 1998
"capability exchange" describes any transfer of information between
communicating systems that is used to indicate system capabilities
and hence determine the form of data transferred. This term covers
both one-way and two-way transfers of capability information.
"capability identification" is a particular form of capability
exchange in which a receiving system provides capability
information to a sending system.
"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 Revision history
00a 28-Sep-1998 Initial draft.
01a 12-Oct-1998 Incorporated review comments. Described feature
tag for differential x/y resolution ratio. Added
some examples.
01b 19-Oct-1998 Updated section 3.6 on image coding. Added
Appendix B containing feature expressions for the
TIFF modes from RFC 2301.
02a 26-Oct-1998 Update examples. Add separate stripe size
features for JBIG and MRC.
02b 30-Oct-1998 Update examples. Add text clarifying the
description of MRC documents (as a set of feature
collections describing multiple contained images).
Add text describing constrains on resolution and
image coding usage within an MRC document.
02c 11-Nov-1998 Add ITU references. Added terminology:
"capability exchange", "capability identification"
and "capability description". Update JBIG and MRC
stripe size tags. Move subsampling to colour
section. Remove preferred-unit tag. Add T.4,
T.6, T.44 and T.81 references.
Klyne/McIntyre Work-in-progress [Page 4]
RFC nnnn Content feature schema for Internet fax
17 November 1998
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.
1.4 Unfinished business
- Review terminology (especially eifax).
- Review examples in light of final media-feature tags
- Locate appropriate references for esoteric colour features
- Resolve queries raised in the feature tag registrations
2. Fax feature schema syntax
The syntax for the fax feature schema is described by "A syntax for
describing media feature sets" [2]. This in turn calls upon media
feature tags that may be registered according to the procedure
described in "Media Feature Tag Registration Procedure" [1].
NOTE: Media feature registration provides a base
vocabulary of features that correspond to media handling
capabilities. The feature set syntax provides a
mechanism and format for combining these to describe
combinations of features that may be handled by eifax
systems.
3. Internet fax feature tags
This section enumerates and briefly describes a number of feature
tags that are defined for use with Extended Internet Fax (eifax)
systems and applications. These tags may be used also by other
systems and applications that support corresponding capabilities.
The feature tags presented below are those that an eifax system is
expected to recognize its ability or non-ability to handle.
Definitive descriptions of feature tags are indicated by reference
to their registration per the 'conneg' 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 eifax system must have that capability;
rather, it must recognize the feature tag and deal with
it according to the capabilities that it does have.
Klyne/McIntyre Work-in-progress [Page 5]
RFC nnnn Content feature schema for Internet fax
17 November 1998
Further, an eifax system is not prevented from
recognizing and offering additional feature tags. The
list below is intended to provide a minimum vocabulary
that all eifax 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 yield an exact inch-based value.
3.2 Resolution
Feature tag name Legal values
---------------- ------------
dpi <Integer> (>0)
dpi-xyratio <Rational> (>0)
Reference: "Media Features for Display, Print, and Fax" [3], and
this document appendix A.
If 'dpi-xyratio' is present and not equal to 1 then the horizontal
resolution (x-axis) is indicated by the 'dpi' feature value, and
the vertical resolution (y-axis) is the value of 'dpi' divided by
'dpi-xyratio'.
For example, the basic Group 3 fax resolution of 200*100dpi might
be indicated as:
(& (dpi=200) (dpi-xyratio=200/100) )
When describing resolutions for an MRC format document, the
complete set of usable resolutions is listed. However, there are
some restrictions on their use: (a) 100dpi resolution can be used
only with multi-level images, and (b) any multi-level image
resolution is required to be an integral sub-multiple of the
applicable mask resolution.
Klyne/McIntyre Work-in-progress [Page 6]
RFC nnnn Content feature schema for Internet fax
17 November 1998
3.3 Media type
Feature tag name Legal values
---------------- ------------
ua-media screen
screen-paged
stationery
transparency
envelope
envelope-plain
continuous
Reference: "Media Features for Display, Print, and Fax" [3].
NOTE: Where the recipient indicates specific support for
hard copy or soft copy media type, a sender of colour
image data may wish to adjust the colour 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].
Klyne/McIntyre Work-in-progress [Page 7]
RFC nnnn Content feature schema for Internet fax
17 November 1998
3.5 Colour capability
Feature tag name Legal values
---------------- ------------
color None (bi-level only)
Fixed (small number of fixed colours)
Grey (grey-scale only)
Mapped (palette or otherwise mapped colour)
Full (full continuous-tone colour)
Reference: "Media Features for Display, Print, and Fax" [3].
The intention here is to give a broad indication of colour handling
capabilities that might be used, for example, to select among a
small number of available data resources.
The value of this feature also gives an indication of the more
detailed colour handling features that might be applicable (see
next section).
3.6 Colour model
Feature tag name Legal values
---------------- ------------
color-levels <integer> (>2)
color-resolution <integer> (>0)
color-space Generic colour spaces:
RGB (generic RGB)
LAB (generic L*a*b*)
CMY (generic CMY)
CMYK (generic CMYK)
Specific colour spaces:
CIELAB (LAB per T.42 [9])
(may be extended by further registrations)
color-palette Custom
ITU-T43 (per T.43 [10])
(may be extended by further registrations)
color-illuminant Custom
CIED50 ([[[reference???]]])
(may be extended by further registrations)
color-gamut "lo1..hi1,lo2..hi2, ... ,loN..hiN"
"Video" [[[reference to be supplied]]]
"Hardcopy" [[[reference to be supplied]]]
(may be extended by further registrations)
Reference: this document, appendix A.
Klyne/McIntyre Work-in-progress [Page 8]
RFC nnnn Content feature schema for Internet fax
17 November 1998
[[[GK: what about tokens for intensity/hue/saturation,
and composite-video-style Luminance and two colour-
difference signals???]]]
The general model for image handling (both colour and non-colour)
is described here from a receiver's perspective; a similar model
operates in the reverse direction for a scan/send perspective:
raw bit pixel colour physical
stream -(A)-> values -(B)-> values -(C)-> rendition
- "raw bit stream" is a stream of coded bits
(A) indicates image coding/decoding (MH,MR,MMR,JPEG,JBIG,etc.)
- "pixel values" are a single numeric value per pixel
(B) indicates pixel-to-colour value mapping
- "colour values" have a separate numeric value for each colour
component (typically, 1, 3 or 4 components)
(C) indicates how the colour values are related to a physical
colour, and involves interpretation of the colour value with
respect to a colour model (e.g. RGB, LAB, CMY, CMYK) and a
colour space (which is typically device-dependent).
- "physical rendition" is a colour value physically realized on
a display, printer or other device.
There are very many variables that can be applied at each stage of
the processing of a colour image, and any one may be critical to
meaningful handling of that image in some circumstances. In other
circumstances many of the variables may be implied (to some level
of approximation) in the application that uses them (e.g. colour
images published on a Web page).
Grey scale and bi-level images are handled within this framework as
a special case, having a 1-component colour model. The following
features are suggested for describing color capabilities:
'color-levels' indicates the number of distinct values for each
pixel, and applies to all but bi-level images. For bi-level
images, a value of 2 is implied.
'color-resolution' indicates the number of different colour values
that can be rendered or physically represented. This value is
generally the same as 'color levels' except for 'Mapped'
(palettized) colour, and would not normally be specified other than
in that case.
Klyne/McIntyre Work-in-progress [Page 9]
RFC nnnn Content feature schema for Internet fax
17 November 1998
'color-space' is used mainly with 'Mapped' and 'Full', but may be
used with other modes if the exact colour used is significant. The
generic colour spaces are used to indicate a broad colour
capability colour value representation, without exactly specifying
a physical realization for each colour values. Specific colour
spaces are used for exact colour matching, and presume the
existence of calibrated colour data and rendering systems.
A colour-handling device should always indicate at least one
generic colour space capability, in addition to any specific colour
spaces that it may support. For a specific transaction, a generic
colour space requirement should be indicated if that is sufficient
for the purposes of the transaction; specific colour spaces are
intended to be used only when precise colour matching is required.
'color-palette' is used only for 'mapped' colour, and gives an
indication of the pixel-to-colour value mapping used.
The 'color-illuminant' feature is generally used when precise
colour matching is required. The value 'Custom' is used when
details of the illuminant can be carried in an image data file.
Other values refer to published specifications as indicated.
The 'color-gamut' string indicates the range of colour component
values that can be handled, either as a sequence of up to N
component value ranges in the format given (where N depends upon
the colour space used), or as a token that references an indicated
published specification.
For generic gamut matching, suitable selected tokenized values
might be used (e.g. "Video", "Hardcopy"). Specific applications
might understand the content of the gamut string and interpret
expressions like:
(color-gamut<="1..100,-75..75,-75..125")
but this is not a required feature of the generic capability
matching framework.
Klyne/McIntyre Work-in-progress [Page 10]
RFC nnnn Content feature schema for Internet fax
17 November 1998
3.7 Image coding
Feature tag name Legal values
---------------- ------------
image-file- TIFF-S
structure TIFF-F
TIFF-J
TIFF-L
TIFF-C
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 colour subsampling)
"4:1:1" (4:1:1 colour subsampling)
MRC-mode <Integer> (0..7) (per ITU T.44 [15])
MRC-max-stripe-size <Integer>
Reference: this document, appendix A.
'image-file-structure' defines how the coded image data is wrapped
and formatted. Options defined here are the various profiles of
TIFF-FX, per RFC 2301 [7]. These options apply to overall
formatting of the image data (TIFF file format, byte ordering, bit
ordering, etc.) and do not define specific image coding issues that
are covered by other aspects of the TIFF-FX profile specifications.
'image-coding' describes how the raw image data is compressed and
coded as a sequence of bits. These are generic tags that may apply
to a range of file formats and usage environments.
'image-coding-constraint' describes how the raw image data coding
method is constrained to meet a particular operating environment.
Options defined here are JBIG and JPEG coding constraints that
apply in typical Group 3 fax environments.
Klyne/McIntyre Work-in-progress [Page 11]
RFC nnnn Content feature schema for Internet fax
17 November 1998
The 'JBIG-stripe-size' feature may be used with JBIG image coding,
and indicates the number of scan lines in each stripe except the
last in an image. The legal constraints are:
(JBIG-stripe-size=128)
(JBIG-stripe-size>=0)
The latter being equivalent to no restriction.
The 'MRC-mode' feature is used to indicate the availability of MRC
(mixed raster content) image format capability, and also the MRC
mode available. A zero value indicates MRC is not available, a
non-zero value indicates the available MRC mode number.
An MRC formatted document is actually a collection of several
images, each of which is described by a separate feature
collection. Thus, an entire MRC document is characterized by a set
of feature collections --a feature set-- that must be a subset of
the capabilities of the message receiver.
Within an MRC-formatted document, multi-level coders are used for
foreground and background images (i.e. odd-numbered layers: 1, 3,
5, etc.) and bi-level coders are used for mask layers (i.e. even
numbered layers 2, 4, 6, etc.).
NOTE: an MRC formatted document may appear within a TIFF
image file structure, so this separate feature is needed
to capture the full range of possible capabilities.
The 'MRC-max-stripe-size' feature may be used with MRC coding, and
indicates the maximum number of scan lines in each MRC stripe. The
legal constraints are:
(MRC-stripe-size=[0..256])
(MRC-stripe-size>=0)
These values indicate upper bounds on the stripe size. The actual
value may vary between stripes, and the actual size for each stripe
is indicated in the image data.
4. Examples
Some of the examples contain comments introduced by '--...'. These
are not part of the allowed capability description syntax. They
are included here to explain some of the constructs used.
Klyne/McIntyre Work-in-progress [Page 12]
RFC nnnn Content feature schema for Internet fax
17 November 1998
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.
(& (dpi=200)
(dpi-xyratio=[200/100,200/200])
(grey=2) (color=0)
(paper-size=A4)
(image-coding=MH) (MRC-mode=0)
(ua-media=stationery) )
4.2 High-end black-and-white Internet fax system
This would include support for B/W JBIG and be equivalent to what
is sometimes called "Super G3", except that Internet fax
functionality would be added.
(& (| (& (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
(grey=2) (color=0)
(| (image-coding=[MH,MR,MMR])
(& (image-coding=JBIG-2-LEVEL) (JBIG-stripe-size=128) )
(MRC-mode=0)
(paper-size=[A4,B4]) )
Klyne/McIntyre Work-in-progress [Page 13]
RFC nnnn Content feature schema for Internet fax
17 November 1998
4.3 Grey-scale Internet fax system
This is the previous example extended to handle grey scale multi-
level images. In keeping with Group 3 fax, this example requires
equal x- and y- resolutions for a multi-level image.
(& (| (& (grey=2) (color=0)
(| (image-coding=[MH,MR,MMR])
(& (image-coding=JBIG-2-LEVEL)
(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) ) ) )
(& (grey<=256) (color=0)
(| (& (image-coding=JPEG)
(color-space=CIELAB) )
(& (image-coding=JBIG-M-LEVEL)
(JBIG-stripe-size=128)
(color-space=Palette)
(image-interleave=stripe) ) )
(| (& (dpi=200) (dpi-xyratio=1) )
(& (dpi=300) (dpi-xyratio=1) ) ) ) )
(MRC-mode=0)
(paper-size=[A4,B4]) )
Klyne/McIntyre Work-in-progress [Page 14]
RFC nnnn Content feature schema for Internet fax
17 November 1998
4.4 Full-colour Internet fax system (JPEG)
This adds 16-bit full-colour to the previous example.
(& (| (& (grey=2)
(| (image-coding=[MH,MR,MMR])
(& (image-coding=JBIG-2-LEVEL)
(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) ) ) )
(& (grey<=256 )
(color<=65536)
(color-subsampling=[SS-1-1-1,SS-4-1-1])
(| (& (image-coding=JPEG)
(color-space=CIELAB) )
(& (image-coding=JBIG-M-LEVEL)
(JBIG-stripe-size=128)
(color-space=Palette)
(image-interleave=stripe) ) )
(| (& (dpi=200) (dpi-xyratio=1) )
(& (dpi=300) (dpi-xyratio=1) ) ) ) )
(MRC-mode=0)
(paper-size=[A4,B4]) )
4.5 Full-colour Internet fax system (MRC)
(& (| (& (image-coding=[MH,MMR]) (MRC-mode=0)
(| (& (dpi=200) (dpi-xyratio=[200/100,1,200/400]) )
(& (dpi=300) (dpi-xyratio=1) )
(& (dpi=400) (dpi-xyratio=1) ) )
(grey=2) (color=0) )
(& (image-coding=JPEG) (MRC-mode=0)
(dpi=[100,200,300,400]) (dpi-xyratio=1)
(grey<=256)
(color<=65536)
(color-space=CIELAB)
(color-subsampling=[SS-1-1-1,SS-4-1-1])
(& (MRC-mode=1) (MRC-stripe-size=[0..256])
(image-coding=[MH,MMR,JPEG])
(grey<=256)
(color<=65536)
(color-space=CIELAB)
(color-subsampling=[SS-1-1-1,SS-4-1-1])
(dpi=[100,200,300,400])
(dpi-xyratio=1) ) )
(paper-size=[A4,B4]) )
Klyne/McIntyre Work-in-progress [Page 15]
RFC nnnn Content feature schema for Internet fax
17 November 1998
4.6 Sender and receiver feature matching
This example considers sending a document to a high-end black-and-
white fax system with the following receiver capabilities:
(& (| (& (dpi=200) (dpi-xyratio=200/100) ) -- 200*100
(& (dpi=200) (dpi-xyratio=1) ) -- 200*200
(& (dpi=300) (dpi-xyratio=1) ) -- 300*300
(& (dpi=400) (dpi-xyratio=1) ) ) -- 400*400
(grey=2) (color=0)
(| (& (paper-size=A4) (ua-media=[stationery,transparency]) )
(& (paper-size=B4) (ua-media=continuous) ) )
(image-coding=[MH,MR,JBIG-2-LEVEL]) )
Turning to the document itself, assume it is available to the
sender in three possible formats, A4 high resolution, B4 low
resolution and A4 high resolution colour, described by:
(& (dpi=300) (dpi-xyratio=1)
(grey=2)
(paper-size=A4)
(image-coding=[MMR,JBIG-2-LEVEL]) )
(& (dpi=200) (dpi-xyratio=200/100)
(grey=2)
(paper-size=B4)
(image-coding=[MH,MR]) )
(& (dpi=300) (dpi-xyratio=1)
(color<=256)
(paper-size=A4)
(image-coding=JPEG) )
These three image formats can be combined into a composite
capability statement by a logical-OR operation (to describe
format-1 OR format-2 OR format-3):
(| (& (dpi=300) (dpi-xyratio=1)
(grey=2)
(paper-size=A4)
(image-coding=[MMR,JBIG-2-LEVEL]) )
(& (dpi=200) (dpi-xyratio=200/100)
(grey=2)
(paper-size=B4)
(image-coding=[MH,MR]) )
(& (dpi=300) (dpi-xyratio=1)
(color=42)
(paper-size=A4)
(image-coding=JPEG) ) )
Klyne/McIntyre Work-in-progress [Page 16]
RFC nnnn Content feature schema for Internet fax
17 November 1998
This could be simplified, but there is little gain in doing so at
this point.
The composite document description can be matched with the receiver
capability description, according to the rules in [2], to yield the
result:
(| (& (dpi=300) (dpi-xyratio=1)
(grey=2)
(paper-size=A4)
(ua-media=[stationery,transparency])
(image-coding=JBIG-2-LEVEL) )
(& (dpi=200) (dpi-xyratio=200/100)
(grey=2)
(paper-size=B4)
(ua-media=continuous)
(image-coding=[MH,MR]) ) )
Points to note about the feature matching process:
o The colour document option is eliminated because the receiver
cannot handle either colour (indicated by '(color=0)') or JPEG
coding.
o The high resolution version of the document with '(dpi=300)' must
be send using '(image-coding=JBIG-2-LEVEL)' 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-2-LEVEL, and the receiver
capabilities are MH, MR and JBIG-2-LEVEL.)
o The low-resolution version of the document can be sent with
either MH or MR coding as the receiver can deal with either of
these for low resolution documents.
o The high resolution variant of the document is available only for
A4, so that is the paper-size used in that case. Similarly the
low resolution version is sent for B4 paper.
o Even though the sender may not understand the 'ua-media' feature
tag, and does not mention it, the matching rules preserve the
constraint that the B4 document is rendered with
'(ua-media=continuous)', and the A4 document may be rendered with
'(ua-media=[stationery,transparency])'.
Klyne/McIntyre Work-in-progress [Page 17]
RFC nnnn Content feature schema for Internet fax
17 November 1998
5. 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]
5.1 Capability descriptions and mechanisms
Negotiation mechanisms reveal information about one party to other
parties. This may raise privacy concerns, and may allow a
malicious party to make better guesses about the presence of
specific security holes.
Most of these concerns pertain to capability information getting
into the hands of someone who may abuse it. This document
specifies capabilities that help a sender to determine what image
characteristics can be processed by the recipient, not mechanisms
for their publication. Implementors and users should take care
that the mechanisms employed ensure that capabilities are revealed
only to appropriate persons, systems and agents.
5.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.
6. Full copyright statement
Copyright (C) The Internet Society 1998. 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.
Klyne/McIntyre Work-in-progress [Page 18]
RFC nnnn Content feature schema for Internet fax
17 November 1998
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.
7. Acknowledgements
The authors gratefully acknowledge the contributions of the
following persons who commented on earlier versions of this memo:
James Rafferty, Dan Wing, [[...]].
8. References
[1] "Media Feature Tag Registration Procedure"
Koen Holtman, TUE
Andrew Mutz, Hewlett-Packard
Ted Hardie, NASA
Internet draft: <draft-ietf-conneg-feature-reg-03.txt>
Work in progress, July 1998.
[2] "A syntax for describing media feature sets"
Graham Klyne, 5GM/Content Technologies
Internet draft: <draft-ietf-conneg-feature-syntax-00.txt>"
Work in progress, September 1998.
[3] "Media Features for Display, Print, and Fax"
Larry Masinter, Xerox PARC
Koen Holtman, TUE
Andrew Mutz, Hewlett-Packard
Dan Wing, Cisco Systems
Internet draft: <draft-ietf-conneg-media-features-02.txt>
Work in progress, September 1998.
[4] "Internet fax feature mapping from Group 3 fax"
Lloyd McIntyre, Xerox Corporation
Graham Klyne, 5GM/Content Technologies
Internet draft: <draft-ietf-fax-feature-T30-mapping-00.txt>
Work in progress, August 1998.
[5] "Extended Facsimile Using Internet Mail
Larry Masinter, Xerox Corporation
Dan Wing, Cisco Systems
Internet draft: <draft-ietf-fax-eifax-04.txt>
Work in progress, September 1998.
Klyne/McIntyre Work-in-progress [Page 19]
RFC nnnn Content feature schema for Internet fax
17 November 1998
[6] "Procedures for document facsimile transmission in the general
switched telephone network"
ITU-T Recommendation T.30 (1996)
International Telecommunications Union
July 1996
[7] RFC 2301, "File format for Internet fax"
L. McIntyre,
R. Buckley,
D. Venable, Xerox Corporation
S. Zilles, Adobe Systems, Inc.
G. Parsons, Northern Telecom
J. Rafferty, Human Communications
March 1998.
[8] RFC 2305, "A Simple Mode of Facsimile Using Internet Mail"
K. Toyoda
H. Ohno
J. Murai, WIDE Project
D. Wing, Cisco Systems
March 1998.
[9] "Continuous-tone colour 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] "Scenarios for the Delivery of Negotiated Content"
T. Hardie, NASA Network Information Center
Internet draft: <draft-ietf-http-negotiate-scenario-02.txt>
Work in progress, November 1997.
[12] "Requirements for protocol-independent content negotiation"
G. Klyne, Integralis Ltd.
Internet draft: <draft-ietf-conneg-requirements-00.txt>
Work in progress, March 1998.
[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)
Klyne/McIntyre Work-in-progress [Page 20]
RFC nnnn Content feature schema for Internet fax
17 November 1998
[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)
9. Authors' addresses
Graham Klyne
5th Generation Messaging Ltd. Content Technologies Ltd.
5 Watlington Street Forum 1, Station Road
Nettlebed Theale
Henley-on-Thames, RG9 5AB Reading, RG7 4RA
United Kingdom United Kingdom.
Telephone: +44 1491 641 641 +44 118 930 1300
Facsimile: +44 1491 641 611 +44 118 930 1301
E-mail: GK@ACM.ORG
Lloyd McIntyre
Xerox Corporation
Mailstop PAHV-305
3400 Hillview Ave.
Palo Alto, CA 94304 USA
Telephone: +1-650-813-6762
Facsimile: +1-650-845-2340
E-mail: Lloyd.McIntyre@pahv.xerox.com
Klyne/McIntyre Work-in-progress [Page 21]
RFC nnnn Content feature schema for Internet fax
17 November 1998
Appendix A: Feature registrations
A.1 Image size
- Media Feature tag name(s):
size-x
size-y
- ASN.1 identifiers associated with these feature tags:
[[[New assignments by IANA]]]
- 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 minimum scanned image width and
height for Group 3 fax: 215x297 mm (8.46x11.69 inches):
(size-x<=2150/254)
(size-y<=2970/254)
Klyne/McIntyre Work-in-progress [Page 22]
RFC nnnn Content feature schema for Internet fax
17 November 1998
- 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.)
- 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 (Fax Working Group)
Klyne/McIntyre Work-in-progress [Page 23]
RFC nnnn Content feature schema for Internet fax
17 November 1998
A.2 Resolution aspect ratio
- Media Feature tag name(s):
dpi-xyratio
- ASN.1 identifier associated with this feature tag:
[[[New assignments by IANA]]]
- Summary of the media features indicated:
This feature is used to indicate differential horizontal and
vertical resolution capability. In the absence of this
feature, horizontal and vertical resolutions are presumed to
be the same.
When this feature tag is specified, any declared resolution
(dpi) is presumed to apply to the horizontal axis, and the
vertical resolution is obtained by dividing that declared
resolution by the resolution ratio.
The value of this feature is a pure number, since it
represents the ratio of two resolution values.
- Values appropriate for use with this feature tag:
Rational (>0)
- The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms:
Internet fax, and other print or display applications that
must handle differential horizontal and vertical resolution
values.
- Examples of typical use:
The following example describes a fax resolution of 204 dpi
horizontally by 391 dpi vertically:
(& (dpi=204) (dpi-xyratio=204/391) )
- Related standards or documents:
The memo "Media Features for Display, Print, and Fax" [3]
describes a feature (dpi) for measuring document resolution.
Klyne/McIntyre Work-in-progress [Page 24]
RFC nnnn Content feature schema for Internet fax
17 November 1998
- 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 (Fax Working Group)
Klyne/McIntyre Work-in-progress [Page 25]
RFC nnnn Content feature schema for Internet fax
17 November 1998
A.3 Colour levels
- Media Feature tag name(s):
color-levels
- ASN.1 identifier associated with this feature tag:
[[[New assignments by IANA]]]
- Summary of the media features indicated:
This feature tag is used to indicate a number of different
pixel values that can be represented by a document or image
data.
When grey-scale or mapped (palettized) colour is used, this
may be different from the number of different colours that can
be represented through the colour-mapping function.
This feature tag is used in conjunction with the 'color'
feature, with a value other than "None". It can be used with
most kinds of document or image data (e.g. grey-scale, mapped
colour, full colour).
- 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:
Colour image printing or display applications where the data
resource used may depend upon colour handling capabilities of
the recipient.
- Examples of typical use:
To describe recipient capabilities:
(& (color=fixed) (color-levels<=6) )
(& (color=grey) (color-levels<=64) )
(& (color=mapped) (color-levels<=240) )
(& (color=full) (color-levels<=16777216) )
Klyne/McIntyre Work-in-progress [Page 26]
RFC nnnn Content feature schema for Internet fax
17 November 1998
To describe capabilities used by a document:
(& (color=fixed) (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 colour
capabilities.
- Interoperability considerations:
The actual number of colour values used by a document does
not, in general, exactly match the number that can be handled
by a recipient. To achieve a feature match, at least one must
be declared as an inequality.
It is recommended that a recipient declares the number of
colour values that it can handle as an inequality (<=), and a
data resource declares the number of colours 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-resolution [this document]
color-space [this document]
color-palette [this document]
- Intended usage:
Internet fax
Colour image scanning/rendering applications
- Author/Change controller:
IETF (Fax Working Group)
Klyne/McIntyre Work-in-progress [Page 27]
RFC nnnn Content feature schema for Internet fax
17 November 1998
A.4 Colour resolution
- Media Feature tag name(s):
color-resolution
- ASN.1 identifier associated with this feature tag:
[[[New assignments by IANA]]]
- Summary of the media features indicated:
This feature tag indicates a colour resolution capability;
i.e. the level of detail to which an individual colour can be
specified.
Typically, this feature would be used with 'color=mapped', and
possibly 'color=grey' or 'color=full', to indicate the number
of distinct colours that can be realized.
- 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:
Colour image printing and display applications where the data
resource used may depend upon colour handling capabilities of
the recipient.
Scanning applications where the data transferred may depend
upon the image generation capabilities of the originator.
- Examples of typical use:
To describe rendering or scanning capabilities:
(& (color=mapped) (color-levels<=240)
(color-resolution<=65536) )
(& (color=full) (color-levels<=16777216)
(color-resolution<=262144) )
To describe capabilities assumed by a document:
(& (color=mapped) (color-levels=200)
(color-resolution>=32768) )
(& (color=full) (color-levels=32768)
(color-resolution>=32768) )
Klyne/McIntyre Work-in-progress [Page 28]
RFC nnnn Content feature schema for Internet fax
17 November 1998
- Related standards or documents:
The memo "Media Features for Display, Print, and Fax" [3]
defines a feature (color) for indicating basic colour
capabilities.
- Related feature tags:
color [3]
color-levels [this document]
color-space [this document]
color-palette [this document]
- Intended usage:
Internet fax
Colour image scanning/rendering applications
- Author/Change controller:
IETF (Fax Working Group)
Klyne/McIntyre Work-in-progress [Page 29]
RFC nnnn Content feature schema for Internet fax
17 November 1998
A.5 Colour space
- Media Feature tag name(s):
color-space
- ASN.1 identifier associated with this feature tag:
[[[New assignments by IANA]]]
- Summary of the media features indicated:
This feature indicates a colour space supported by a device or
used by a document.
A colour space value provides two types of information:
o the representation of a colour value, including the number
of colour components
o a mapping between colour values and their physical
realizations
Generic colour space values are provided for applications
where the general colour representation used is significant,
but exact colour matching is not vital. Specific colour space
values are provided for use when exact colour matching is
important.
- Values appropriate for use with this feature tag:
Token
Generic colour RGB (generic RGB)
spaces: LAB (generic L*a*b*)
CMY (generic CMY)
CMYK (generic CMYK)
Specific colour CIELAB (LAB per T.42 [9])
spaces:
(may be extended by further registrations)
- 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 colour handling capabilities of
the recipient.
Scanning applications where the data transferred may depend
upon the image generation capabilities of the originator.
Klyne/McIntyre Work-in-progress [Page 30]
RFC nnnn Content feature schema for Internet fax
17 November 1998
- Examples of typical use:
To describe rendering or scanning capabilities:
(color-space=[LAB,CIELAB])
To describe capabilities assumed by a document for which
approximate colour reproduction is required:
(color-space=LAB)
To describe capabilities assumed by a document for which exact
colour reproduction is required:
(color-space=CIELAB)
- Related standards or documents:
RGB: [[[Reference???]]]
LAB: [[[Reference???]]]
CMY: [[[Reference???]]]
CMYK: [[[Reference???]]]
CIELAB: ITU T.42 [9]
- Interoperability considerations:
When declaring a specific colour space capability for a
scanning or rendering device, a corresponding generic
capability should also be declared so that feature matching
for applications or documents that do not require exact colour
matching can be performed.
- Security considerations:
- Privacy concerns, related to exposure of personal information:
Where feature matching is used to select content applicable
to the physical abilities of a user, unusual values for this
feature tag might give an indication of a user's restricted
abilities.
- Denial of service concerns related to consequences of
specifying incorrect values:
Failure to indicate a generic colour space capability for a
device may lead to failure to match colour space for an
application or document that does not require an exact
colour match.
Klyne/McIntyre Work-in-progress [Page 31]
RFC nnnn Content feature schema for Internet fax
17 November 1998
- Related feature tags:
color [3]
color-palette [this document]
- Related media types or data formats:
TIFF for fax [7]
- Intended usage:
Internet fax
Colour image scanning/rendering applications
- Author/Change controller:
IETF (Fax Working Group)
Klyne/McIntyre Work-in-progress [Page 32]
RFC nnnn Content feature schema for Internet fax
17 November 1998
A.6 Colour palette
- Media Feature tag name(s):
color-palette
- ASN.1 identifier associated with this feature tag:
[[[New assignments by IANA]]]
- Summary of the media features indicated:
Use with palettized colour (color=mapped), this feature
indicates a source of the mapping between pixel values and
colour values.
When a custom palette is indicated, the palette is carried
with the image data. The actual form of the palette data
within the image is not indicated by this feature, but is a
function of the image file format used.
When used with a scanning application, this feature is also
associated with a colour discrimination function that
determines the region of the colour space that is mapped to
each possible pixel value.
[[[Lloyd: please check this. I forget the exact
terminology appropriate here]]]
- Values appropriate for use with this feature tag:
Token Custom (contained within image data)
ITU-T43 (per T.43 [10])
(may be extended by further registrations)
- 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 colour 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-palette=Custom)
(color-palette=[Custom,ITU-T43])
Klyne/McIntyre Work-in-progress [Page 33]
RFC nnnn Content feature schema for Internet fax
17 November 1998
- Related standards or documents:
ITU-T43: ITU T.43 [10]
- Security considerations:
- Privacy concerns, related to exposure of personal information:
Where feature matching is used to select content applicable
to the physical abilities of a user, unusual values for this
feature tag might give an indication of a user's restricted
abilities.
- Denial of service concerns related to consequences of
specifying incorrect values:
Specifying an incorrect colour palette value could result in
data being rendered in a way that obscures some or all of
its content.
- Related feature tags:
color [3]
color-levels [this document]
color-resolution [this document]
image-file-structure [this document]
- Related media types or data formats:
TIFF for fax [7]
- Intended usage:
Internet fax
Colour image scanning/rendering applications
- Author/Change controller:
IETF (Fax Working Group)
Klyne/McIntyre Work-in-progress [Page 34]
RFC nnnn Content feature schema for Internet fax
17 November 1998
A.7 Colour illuminant
- Media Feature tag name(s):
color-illuminant
- ASN.1 identifier associated with this feature tag:
[[[New assignments by IANA]]]
- Summary of the media features indicated:
This feature indicates the source of illuminant information
used in interpreting colour values.
[[[Lloyd: a few more specifics, please???]]]
When a custom illuminant is indicated, the illuminant
information is carried with the image data. The actual form
of the illuminant information within the image is not
indicated by this feature, but is a function of the image file
format used.
[[[Lloyd: please check this. I forget the exact
terminology appropriate here]]]
- Values appropriate for use with this feature tag:
Token Custom (Contained with image data)
CIED50 (per ???)
(may be extended by further registrations)
- 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 colour 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-illuminant=Custom)
(color-illuminant=[Custom,CIED50])
Klyne/McIntyre Work-in-progress [Page 35]
RFC nnnn Content feature schema for Internet fax
17 November 1998
- Related standards or documents:
CIED50: [[[Reference???]]]
- Security considerations:
- Privacy concerns, related to exposure of personal information:
Where feature matching is used to select content applicable
to the physical abilities of a user, unusual values for this
feature tag might give an indication of a user's restricted
abilities.
- Denial of service concerns related to consequences of
specifying incorrect values:
Specifying an incorrect colour palette value could result in
data being rendered in a way that obscures some or all of
its content.
[[[Are these true, or is image rendition relatively
insensitive to illuminant???]]]
- Related feature tags:
color [3]
image-file-structure [this document]
- Related media types or data formats:
TIFF for fax [7]
- Intended usage:
Internet fax
Colour image scanning/rendering applications
- Author/Change controller:
IETF (Fax Working Group)
Klyne/McIntyre Work-in-progress [Page 36]
RFC nnnn Content feature schema for Internet fax
17 November 1998
A.8 Colour gamut
- Media Feature tag name(s):
color-gamut
- ASN.1 identifier associated with this feature tag:
[[[New assignments by IANA]]]
- Summary of the media features indicated:
This feature indicates a supported range of colour values.
Colour values are a sequence of colour components interpreted
in the context of some colour space. A colour gamut is
indicated by a possible range of values for each of the colour
components.
For generic gamut matching, suitable tokenized values may be
used (e.g. "Video", "Hardcopy").
- Values appropriate for use with this feature tag:
String
Specific gamut: "lo1..hi1,lo2..hi2, ... ,loN..hiN"
Generic gamuts: "Video" [[[reference to be supplied]]]
"Hardcopy" [[[reference to be supplied]]]
(may be extended by further registrations)
- 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 colour 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-gamut=["1..100,-75..75,-75..125","Video"])
Klyne/McIntyre Work-in-progress [Page 37]
RFC nnnn Content feature schema for Internet fax
17 November 1998
- Related standards or documents:
"Video": [[[Reference to be supplied]]]
"Hardcopy": [[[Reference to be supplied]]]
- Interoperability considerations:
When describing device or document capabilities with a
specific gamut, a generic gamut should also be indicated
unless very precise colour matching is required. This allows
feature matching to be achieved when the exact gamut of a
matching device or document is unknown.
The number of component-value ranges in a specific gamut
string must correspond to the number of components required by
the color space used.
Colour-intensive applications might choose to understand the
content of the specific gamut string and interpret expressions
like:
(color-gamut<="1..100,-75..75,-75..125")
to recognize a match with (say):
(color-gamut="20..70,-50..65,-30..100")
but this is not a required feature of a generic negotiation
framework.
- 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]
- Related media types or data formats:
TIFF for fax [7]
Klyne/McIntyre Work-in-progress [Page 38]
RFC nnnn Content feature schema for Internet fax
17 November 1998
- Intended usage:
Internet fax
Colour image scanning/rendering applications
- Author/Change controller:
IETF (Fax Working Group)
Klyne/McIntyre Work-in-progress [Page 39]
RFC nnnn Content feature schema for Internet fax
17 November 1998
A.9 Colour subsampling
- Media Feature tag name(s):
color-subsampling
- ASN.1 identifier associated with this feature tag:
[[[New assignments by IANA]]]
- Summary of the media features indicated:
This feature tag indicates whether colour information may be
subsampled with respect to luminance data.
It is used with continuous colour images (color=full), color
spaces that use separate luminance and colour components
(e.g. color-space=LAB), and image file structures that support
colour subsampling.
- Values appropriate for use with this feature tag:
String "1:1:1"
This value indicates a full set of colour
component samples for each luminance
component sample.
"4:1:1"
This value indicates a set of colour samples
for each luminance sample.
(may be extended by further registrations)
- 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 colour 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,CIALAB])
(color-subsampling=["1:1:1","4:1:1"]) )
Klyne/McIntyre Work-in-progress [Page 40]
RFC nnnn Content feature schema for Internet fax
17 November 1998
- Related feature tags:
color [3]
color-space [this document]
image-file-structure [this document]
- Related media types or data formats:
TIFF for fax [7]
- Intended usage:
Internet fax
Colour image scanning/rendering applications
- Author/Change controller:
IETF (Fax Working Group)
Klyne/McIntyre Work-in-progress [Page 41]
RFC nnnn Content feature schema for Internet fax
17 November 1998
A.10 Image file structure
- Media Feature tag name(s):
image-file-structure
- ASN.1 identifier associated with this feature tag:
[[[New assignments by IANA]]]
- Summary of the media features indicated:
This feature indicates a file structure used for transfer and
presentation of image data.
It does not indicate image data coding: that is described by
separate feature tags (image-coding, etc).
- Values appropriate for use with this feature tag:
Token
TIFF-FX profiles TIFF-S
[7]: TIFF-F
TIFF-J
TIFF-L
TIFF-C
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.
Klyne/McIntyre Work-in-progress [Page 42]
RFC nnnn Content feature schema for Internet fax
17 November 1998
In the case of TIFF for fax image data, there are a number of
image file format constraints that are imposed by the various
usage profiles defined in RFC 2301 [7]. The purpose of the
'image-file-structure' feature tag is to capture those file
format constraints.
Registration of additional image file structure tags should
focus similarly on image file structure issues, not raw image
data compression and coding. As a guide, an image file
structure may contain image data coded in a variety of ways,
and carries information to describe that coding separately
from MIME content-type labelling, etc.
- Related feature tags:
image-coding [this document]
- Related media types or data formats:
TIFF for fax [7]
TIFF V6.0 (Adobe) [[[Reference???]]]
- Intended usage:
Internet fax
Image scanning/rendering applications
- Author/Change controller:
IETF (Fax Working Group)
Klyne/McIntyre Work-in-progress [Page 43]
RFC nnnn Content feature schema for Internet fax
17 November 1998
A.11 Image data coding
- Media Feature tag name(s):
image-coding
- ASN.1 identifier associated with this feature tag:
[[[New assignments by IANA]]]
- Summary of the media features indicated:
This feature tag indicates a form of image data compression
and coding used.
It identifies a generic image coding technique used, without
regard to any specific profiling of that technique that may be
applied. Values for this feature are generally applicable
across a wide range of image transfer applications.
This information is distinct from the image file structure and
MRC information conveyed by the 'image-file-structure' tags.
- Values appropriate for use with this feature tag:
Token MH
MR
MMR
JBIG
JPEG
(may be extended by further registrations)
- The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms:
Internet fax, and other applications that transfer image data.
- 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]
JBIG: [[[Reference???]]]
JPEG: [[[Reference???]]]
Klyne/McIntyre Work-in-progress [Page 44]
RFC nnnn Content feature schema for Internet fax
17 November 1998
- 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 for fax [7]
- Intended usage:
Internet fax
Image scanning/rendering applications
- Author/Change controller:
IETF (Fax Working Group)
Klyne/McIntyre Work-in-progress [Page 45]
RFC nnnn Content feature schema for Internet fax
17 November 1998
A.12 Image coding constraint
- Media Feature tag name(s):
image-coding-constraint
- ASN.1 identifier associated with these feature tags:
[[[New assignments by IANA]]]
- 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]
Klyne/McIntyre Work-in-progress [Page 46]
RFC nnnn Content feature schema for Internet fax
17 November 1998
- 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 for fax [7]
- Intended usage:
Internet fax
Colour image scanning/rendering applications
- Author/Change controller:
IETF (Fax Working Group)
Klyne/McIntyre Work-in-progress [Page 47]
RFC nnnn Content feature schema for Internet fax
17 November 1998
A.13 JBIG stripe size
- Media Feature tag name(s):
JBIG-stripe-size
- ASN.1 identifier associated with these feature tags:
[[[New assignments by IANA]]]
- Summary of the media features indicated:
This feature is a specific usage constraint that is applied to
JBIG image coding (image-coding=JBIG), and indicates the
allowable size for each stripe of an image, except the last.
- 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: [[[Reference???]]]
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.
[[[How is stripe size of a document handled???]]]
- 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.
Klyne/McIntyre Work-in-progress [Page 48]
RFC nnnn Content feature schema for Internet fax
17 November 1998
- Related feature tags:
image-coding [this document]
image-coding-constraint [this document]
image-interleave [this document]
- Related media types or data formats:
TIFF for fax [7]
- Intended usage:
Internet fax
Colour image scanning/rendering applications
- Author/Change controller:
IETF (Fax Working Group)
Klyne/McIntyre Work-in-progress [Page 49]
RFC nnnn Content feature schema for Internet fax
17 November 1998
A.14 Image interleave
- Media Feature tag name(s):
image-interleave
- ASN.1 identifier associated with this feature tag:
[[[New assignments by IANA]]]
- Summary of the media features indicated:
This feature indicates an image interleave capability.
It may be used with (image-coding=???).
[[[Lloyd: more detail please???]]]
- 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:
[[[Need to comment on memory usage???]]]
- Related feature tags:
image-coding [this document]
JBIG-stripe-size [this document]
- Related media types or data formats:
TIFF for fax [7]
Klyne/McIntyre Work-in-progress [Page 50]
RFC nnnn Content feature schema for Internet fax
17 November 1998
- Intended usage:
Internet fax
Colour image scanning/rendering applications
- Author/Change controller:
IETF (Fax Working Group)
Klyne/McIntyre Work-in-progress [Page 51]
RFC nnnn Content feature schema for Internet fax
17 November 1998
A.15 MRC availability and mode
- Media Feature tag name(s):
MRC-mode
- ASN.1 identifier associated with this feature tag:
[[[New assignments by IANA]]]
- Summary of the media features indicated:
This feature is used to indicate the availability of MRC
(mixed raster content) image format capability, and also the
MRC mode available. A zero value indicates MRC is not
available, a non-zero value (in the range 1..7) indicates the
available MRC mode number.
An MRC formatted document is actually a collection of several
images, each of which is described by a separate feature
collection. Thus, an entire MRC document is characterized by
a set of feature collections --a feature set-- that must be
covered by the capabilities of the receiver.
NOTE: an MRC formatted document may appear within a
TIFF image file structure.
Within an MRC-formatted document, multi-level coders
are used for foreground and background images (i.e.
odd-numbered layers: 1, 3, 5, etc.) and bi-level coders
are used for mask layers (i.e. even numbered layers 2,
4, 6, etc.).
- Values appropriate for use with this feature tag:
Integer (0..7)
- The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms:
Internet fax, and other applications that transfer image data.
- Examples of typical use:
See Appendix B of this document.
- Related standards or documents:
ITU T.44 [15]
Klyne/McIntyre Work-in-progress [Page 52]
RFC nnnn Content feature schema for Internet fax
17 November 1998
- 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-maximum-stripe-size [this document]
- Related media types or data formats:
TIFF for fax [7]
- Intended usage:
Internet fax
Colour image scanning/rendering applications
- Author/Change controller:
IETF (Fax Working Group)
Klyne/McIntyre Work-in-progress [Page 53]
RFC nnnn Content feature schema for Internet fax
17 November 1998
A.16 MRC maximum stripe size
- Media Feature tag name(s):
MRC-maximum-stripe-size
- ASN.1 identifier associated with this feature tag:
[[[New assignments by IANA]]]
- Summary of the media features indicated:
This feature may be used with MRC coding (MRC-mode>=1), and
indicates the maximum number of scan lines in each MRC stripe.
The value given indicates an upper bound on the stripe size.
The actual value may vary between stripes, and the actual size
for each stripe is indicated in the image data.
- Values appropriate for use with this feature tag:
Integer (>0)
- The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms:
Internet fax, and other applications that transfer image data.
- Examples of typical use:
(MRC-stripe-size=[0..256])
(MRC-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 for fax [7]
Klyne/McIntyre Work-in-progress [Page 54]
RFC nnnn Content feature schema for Internet fax
17 November 1998
- Intended usage:
Internet fax
Colour image scanning/rendering applications
- Author/Change controller:
IETF (Fax Working Group)
Klyne/McIntyre Work-in-progress [Page 55]
RFC nnnn Content feature schema for Internet fax
17 November 1998
Appendix B: TIFF mode descriptions
This appendix contains descriptions of the TIFF modes defined by
RFC 2301 [7], presented as feature set expressions in the form
defined by "A syntax for describing media feature sets" [2] and
using the feature schema introduced by this document.
(Tiff-S) :-
(& (image-file-structure=TIFF-S)
(color=None)
(image-coding=MH) (MRC-mode=0) )
(Tiff-F) :-
(& (image-file-structure=TIFF-F)
(color=None)
(image-coding=[MH,MR,MMR]) (MRC-mode=0) )
(TIFF-J) :-
(& (image-file-structure=TIFF-J)
(color=None)
(image-coding=[MH,JBIG-2-LEVEL]) (MRC-mode=0) )
(TIFF-C) :-
(& (image-file-structure=TIFF-C)
(color=Mapped)
(image-coding=[MH,JPEG]) (MRC-mode=0) )
(TIFF-L) :-
(& (image-file-structure=TIFF-L)
(color=Mapped)
(image-coding=[MH,JPEG,JBIG-M-LEVEL]) (MRC-mode=0) )
(TIFF-M) :-
(& (image-file-structure=TIFF-M)
(color=Mapped)
(image-coding=[MH,JPEG]) (MRC-mode>=1) )
Support for multiple profiles is indicated by combining them with
the OR operator; e.g.
(| (TIFF-F) (TIFF-S) (TIFF-J) )
indicates support for all black-and-white modes.
Klyne/McIntyre Work-in-progress [Page 56]
