(& (Pix-x=800) (Pix-y=600) (Res Res-x Res-y) );q=0.9
(& (Pix-x=640) (Pix-y=480) (Res Res-x Res-y) );q=0.8 )
where
(Res Res-x Res-y) :-
(| (& (Res-x=150) (Res-y=150) )
(& (Res-x=150) (Res-y=300) )
(& (Res-x=300) (Res-y=300) )
(& (Res-x=300) (Res-y=600) )
(& (Res-x=600) (Res-y=600) ) )
end
Note that the formal parameters of "Res", "Res-x" and "Res-y",
prevent the body of the named predicate from referencing similarly-
named feature values.
6.2 Unit designations
In some exceptional cases, there may be differing conventions for the
units of measurement of a given feature. For example, resolution is
commonly expressed as dots per inch (dpi) or dots per centimetre
(dpcm) in different applications (e.g. printing vs faxing).
In such cases, a unit designator may be appended to a feature value
according to the conventions indicated below (see also [3]). These
considerations apply only to features with numeric values.
Every feature tag has a standard unit of measurement. Any expression
of a feature value that uses this unit is given without a unit
designation -- this is the normal case. When the feature value is
expressed in some other unit, a unit designator is appended to the
numeric feature value.
The registration of a feature tag indicates the standard unit of
measurement for a feature, and also any alternate units and
corresponding unit designators that may be used, according to RFC
2506 [3].
Thus, if the standard unit of measure for resolution is 'dpcm', then
the feature predicate '(res=200)' would be used to indicate a
resolution of 200 dots-per-centimetre, and '(res=72dpi)' might be
used to indicate 72 dots-per-inch.
Unit designators are accommodated by the following extension to the
feature predicate syntax:
fvalue =/ number *WSP token
When performing feature set matching, feature comparisons with and
without unit designators, or feature comparisons with different unit
designators, are treated as if they were different features. Thus,
the feature predicate '(res=200)' would not, in general, fail to
match with the predicate '(res=200dpi)'.
NOTE: A protocol processor with specific knowledge of the feature
and units concerned might recognize the relationship between the
feature predicates in the above example, and fail to match these
predicates.
This appears to be a natural behaviour in this simple example, but
can cause additional complexity in more general cases.
Accordingly, this is not considered to be required or normal
behaviour. It is presumed that an application concerned will
ensure consistent feature processing by adopting a consistent unit
for any given feature.
6.3 Unknown feature value data types
This memo has dealt with feature values that have well-understood
comparison properties: numbers, with equality, less-than, greater-
than relationships, and other values with equality relationships
only.
Some feature values may have comparison operations that are not
covered by this framework. For example, strings containing multi-
part version numbers: "x.y.z". Such feature comparisons are not
covered by this memo.
Specific applications may recognize and process feature tags that are
associated with such values. Future work may define ways to
introduce new feature value data types in a way that allows them to
be used by applications that do not contain built-in knowledge of
their properties.
7. Examples and additional comments
7.1 Worked example
This example considers sending a document to a high-end black-and-
white fax system with the following receiver capabilities:
(& (dpi=[200,300])
(grey=2) (color=0)
(image-coding=[MH,MR]) )
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)
(grey=2)
(image-coding=MR) )
(& (dpi=200)
(grey=2)
(image-coding=[MH,MMR]) )
(& (dpi=300) (dpi-xyratio=1)
(color<=256)
(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)
(grey=2)
(image-coding=MR) )
(& (dpi=200)
(grey=2)
(image-coding=[MH,MMR]) )
(& (dpi=300)
(color<=256)
(image-coding=JPEG) ) )
The composite document description can be matched with the receiver
capability description by combining the capability descriptions with
a logical AND operation:
(& (& (dpi=[200,300])
(grey=2) (color=0)
(image-coding=[MH,MR]) )
(| (& (dpi=300)
(grey=2)
(image-coding=MR) )
(& (dpi=200)
(grey=2)
(image-coding=[MH,MMR]) )
(& (dpi=300)
(color<=256)
(image-coding=JPEG) ) ) )
--> Expand value-set notation:
(& (& (| (dpi=200) (dpi=300) )
(grey=2) (color=0)
(| (image-coding=MH) (image-coding=MR) ) )
(| (& (dpi=300)
(grey=2)
(image-coding=MR) )
(& (dpi=200)
(grey=2)
(| (image-coding=MH) (image-coding=MMR) ) )
(& (dpi=300)
(color<=256)
(image-coding=JPEG) ) ) )
--> Flatten nested '(&...)':
(& (| (dpi=200) (dpi=300) )
(grey=2) (color=0)
(| (image-coding=MH) (image-coding=MR) )
(| (& (dpi=300)
(grey=2)
(image-coding=MR) )
(& (dpi=200)
(grey=2)
(| (image-coding=MH) (image-coding=MMR) ) )
(& (dpi=300)
(color<=256)
(image-coding=JPEG) ) ) )
--> (distribute '(&...)' over inner '(|...)'):
(& (| (dpi=200) (dpi=300) )
(grey=2) (color=0)
(| (image-coding=MH) (image-coding=MR) )
(| (& (dpi=300) (grey=2) (image-coding=MR) )
(& (dpi=200) (grey=2) (image-coding=MH) )
(& (dpi=200) (grey=2) (image-coding=MMR) )
(& (dpi=300) (color<=256) (image-coding=JPEG) ) ) )
--> continue to distribute '(&...)' over '(|...)', and flattening
nested '(&...)' and '(|...)' ...:
(| (& (dpi=200) (grey=2) (color=0) (image-coding=MH)
(| (& (dpi=300) (grey=2) (image-coding=MR) )
(& (dpi=200) (grey=2) (image-coding=MH) )
(& (dpi=200) (grey=2) (image-coding=MMR) )
(& (dpi=300) (color<=256) (image-coding=JPEG) ) ) )
(& (dpi=200) (grey=2) (color=0) (image-coding=MR)
(| (& (dpi=300) (grey=2) (image-coding=MR) )
(& (dpi=200) (grey=2) (image-coding=MH) )
(& (dpi=200) (grey=2) (image-coding=MMR) )
(& (dpi=300) (color<=256) (image-coding=JPEG) ) ) )
(& (dpi=300) (grey=2) (color=0) (image-coding=MH)
(| (& (dpi=300) (grey=2) (image-coding=MR) )
(& (dpi=200) (grey=2) (image-coding=MH) )
(& (dpi=200) (grey=2) (image-coding=MMR) )
(& (dpi=300) (color<=256) (image-coding=JPEG) ) ) )
(& (dpi=300) (grey=2) (color=0) (image-coding=MR)
(| (& (dpi=300) (grey=2) (image-coding=MR) )
(& (dpi=200) (grey=2) (image-coding=MH) )
(& (dpi=200) (grey=2) (image-coding=MMR) )
(& (dpi=300) (color<=256) (image-coding=JPEG) ) ) ) )
--> ... until normal form is achieved:
(| (& (dpi=200) (grey=2) (color=0) (image-coding=MH)
(dpi=300) (grey=2) (image-coding=MR) )
(& (dpi=200) (grey=2) (color=0) (image-coding=MR)
(dpi=300) (grey=2) (image-coding=MR) )
(& (dpi=300) (grey=2) (color=0) (image-coding=MH)
(dpi=300) (grey=2) (image-coding=MR) )
(& (dpi=300) (grey=2) (color=0) (image-coding=MR)
(dpi=300) (grey=2) (image-coding=MR) )
(& (dpi=200) (grey=2) (color=0) (image-coding=MH)
(dpi=200) (grey=2) (image-coding=MH) )
(& (dpi=200) (grey=2) (color=0) (image-coding=MR)
(dpi=200) (grey=2) (image-coding=MH) )
(& (dpi=300) (grey=2) (color=0) (image-coding=MH)
(dpi=200) (grey=2) (image-coding=MH) )
(& (dpi=300) (grey=2) (color=0) (image-coding=MR)
(dpi=200) (grey=2) (image-coding=MH) )
(& (dpi=200) (grey=2) (color=0) (image-coding=MH)
(dpi=200) (grey=2) (image-coding=MMR) )
(& (dpi=200) (grey=2) (color=0) (image-coding=MR)
(dpi=200) (grey=2) (image-coding=MMR) )
(& (dpi=300) (grey=2) (color=0) (image-coding=MH)
(dpi=200) (grey=2) (image-coding=MMR) )
(& (dpi=300) (grey=2) (color=0) (image-coding=MR)
(dpi=200) (grey=2) (image-coding=MMR) )
(& (dpi=200) (grey=2) (color=0) (image-coding=MH)
(dpi=300) (color<=256) (image-coding=JPEG) ) ) )
(& (dpi=200) (grey=2) (color=0) (image-coding=MR)
(dpi=300) (color<=256) (image-coding=JPEG) ) ) )
(& (dpi=300) (grey=2) (color=0) (image-coding=MH)
(dpi=300) (color<=256) (image-coding=JPEG) ) ) )
(& (dpi=300) (grey=2) (color=0) (image-coding=MR)
(dpi=300) (color<=256) (image-coding=JPEG) ) )
--> Group terms in each conjunction by feature tag:
(| (& (dpi=200) (dpi=300) (grey=2) (grey=2) (color=0)
(image-coding=MH) (image-coding=MR) )
(& (dpi=200) (dpi=300) (grey=2) (grey=2) (color=0)
(image-coding=MR) (image-coding=MR) )
:
(etc.)
:
(& (dpi=300) (dpi=300) (grey=2) (color=0) (color<=256)
(image-coding=MR) (image-coding=JPEG) ) )
--> Combine feature tag comparisons and eliminate unsatisfiable
conjunctions:
(| (& (dpi=300) (grey=2) (color=0) (image-coding=MR) )
(& (dpi=200) (grey=2) (color=0) (image-coding=MH) ) )
Thus, we see that this combination of sender and receiver options can
transfer a bi-level image, either at 300dpi using MR coding, or at
200dpi using MH coding.
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 sent using '(image-coding=MR)' 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 MH, and the receiver capabilities are
MH and MR.)
7.2 A note on feature tag scoping
This section contains some additional commentary on the
interpretation of feture set predicates. It does not extend or
modify what has been described previously. Rather, it attempts to
clarify an area of possible misunderstanding.
The essential fact that needs to be established here is:
Within a given feature collection, each feature tag may have only
one value.
This idea is explained below in the context of using the media
feature framework to describe the characteristics of transmitted
image data.
In this context, we have the requirement that any feature tag value
must apply to the entire image, and cannot have different values for
different parts of an image. This is a consequence of the way that
the framework of feature predicates is used to describe different
possible images, such as the different images that can be rendered by
a given recipient.
This idea is illustrated here using an example of a flawed feature
set description based on the TIFF image format defined for use by
Internet fax [13]:
(& (& (MRC-mode=1) (stripe-size=256) )
(| (& (image-coding=JBIG-2-LEVEL) (stripe-size=128) )
(image-coding=[MH,MR,MMR]) ) )
This example is revealing because the 'stripe-size' attribute is
applied differently to different attributes on an MRC-formatted data:
it can be applied to the MRC format as a whole, and it can be applied
separately to a JBIG image that may appear as part of the MRC data.
One might imagine that this example describes a stripe size of 256
when applied to the MRC image format, and a separate stripe size of
128 when applied to a JBIG-2-LEVEL coded image within the MRC-
formatted data. But it doesn't work that way: the predicates used
obey the normal laws of Boolean logic, and would be transformed as
follows:
--> [flatten nested (&...)]:
(& (MRC-mode=1) (stripe-size=256)
(| (& (image-coding=JBIG-2-LEVEL) (stripe-size=128) )
(image-coding=[MH,MR,MMR]) ) )
--> [Distribute (&...) over (|...)]:
(| (& (MRC-mode=1) (stripe-size=256)
(& (image-coding=JBIG-2-LEVEL) (stripe-size=128) ) )
(& (MRC-mode=1) (stripe-size=[0..256])
(image-coding=[MH,MR,MMR]) ) )
--> [Flatten nested (&...) and group feature tags]:
(| (& (MRC-mode=1)
(stripe-size=256)
(stripe-size=128)
(image-coding=JBIG-2-LEVEL) )
(& (MRC-mode=1)
(stripe-size=256)
(image-coding=[MH,MR,MMR]) ) )
Examination of this final expression shows that it requires both '
stripe-size=128' and 'stripe-size=256' within the same conjunction.
This is manifestly false, so the entire conjunction must be false,
reducing the entire predicate expression to:
(& (MRC-mode=1)
(stripe-size=256)
(image-coding=[MH,MR,MMR]) ) )
This indicates that no MRC formatted data containing a JBIG-2-LEVEL
coded image is permitted within the feature set, which is not what
was intended in this case.
The only way to avoid this in situations when a given characteristic
has different constraints in different parts of a resource is to use
separate feature tags. In this example, 'MRC-stripe-size' and '
JBIG-stripe-size' could be used to capture the intent:
(& (& (MRC-mode=1) (MRC-stripe-size=256) )
(| (& (image-coding=JBIG-2-LEVEL) (JBIG-stripe-size=128) )
(image-coding=[MH,MR,MMR]) ) )
which would reduce to:
(| (& (MRC-mode=1)
(MRC-stripe-size=256)
(JBIG-stripe-size=128)
(image-coding=JBIG-2-LEVEL) )
(& (MRC-mode=1)
(MRC-stripe-size=256)
(image-coding=[MH,MR,MMR]) ) )
The property of the capability description framework explicated above
is captured by the idea of a "feature collection" which (in this
context) describes the feature values that apply to a single
resource. Within a feature collection, each feature tag may have no
more than one value.
The characteristics of an image sender or receiver are described by a
"Feature set", which is formally a set of feature collections. Here,
the feature set predicate is applied to some image feature collection
to determine whether or not it belongs to the set that can be handled
by an image receiver.
8. Security Considerations
Some security considerations for content negotiation are raised in
[1,2,3].
The following are primary security concerns for capability
identification mechanisms:
o Unintentional disclosure of private information through the
announcement of capabilities or user preferences.
o Disruption to system operation caused by accidental or
malicious provision of incorrect capability information.
o Use of a capability identification mechanism might be used to
probe a network (e.g. by identifying specific hosts used, and
exploiting their known weaknesses).
The most contentious security concerns are raised by mechanisms which
automatically send capability identification data in response to a
query from some unknown system. Use of directory services (based on
LDAP [7], etc.) seem to be less problematic because proper
authentication mechanisms are available.
Mechanisms that provide capability information when sending a message
are less contentious, presumably because some intention can be
inferred that person whose details are disclosed wishes to
communicate with the recipient of those details. This does not,
however, solve problems of spoofed supply of incorrect capability
information.
The use of format converting gateways may prove problematic because
such systems would tend to defeat any message integrity and
authenticity checking mechanisms that are employed.
9. Acknowledgements
Thanks are due to Larry Masinter for demonstrating the breadth of the
media feature issue, and encouraging the development of some early
thoughts.
Many of the ideas presented derive from the "Transparent Content
Negotiation in HTTP" work of Koen Holtman and Andy Mutz [4].
Early discussions of ideas with the IETF HTTP and FAX working groups
led to further useful inputs from Koen Holtman, Ted Hardie and Dan
Wing. The debate later moved to the IETF 'conneg' working group,
where Al Gilman and Koen Holtman were particularly helpful in
refining the feature set algebra. Ideas for dealing with preferences
and specific units were suggested by Larry Masinter.
This work was supported by Content Technologies Ltd and 5th
Generation Messaging Ltd.
10. References
[1] Hardie, T., "Scenarios for the Delivery of Negotiated Content",
Work in Progress.
[2] Klyne, G., "Requirements for protocol-independent content
negotiation", Work in Progress.
[3] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag
Registration Procedure", BCP 31, RFC2506, March 1999.
[4] Holtman, K. and A. Mutz, "Transparent Content Negotiation in
HTTP", RFC2295, March 1998.
[5] "Programming in Prolog" (2nd edition), W. F. Clocksin and C. S.
Mellish, Springer Verlag, ISBN 3-540-15011-0 / 0-387-15011-0,
1984.
[6] Masinter, L., Holtman, K., Mutz, A., and D. Wing, "Media
Features for Display, Print, and Fax", RFC2534, March 1999.
[7] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC2251, December 1997.
[8] Howes, T., "The String Representation of LDAP Search Filters",
RFC2254, December 1997.
[9] Fielding, R., Gettys, J., Mogul, J., Frytyk, H. and T. Berners-
Lee, "Hyptertext Transfer Protocol -- HTTP/1.1", RFC2068,
January 1997.
[10] Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC2234, November 1997.
[11] "Logic, Algebra and Databases", Peter Gray, Ellis Horwood
Series: Computers and their Applications, ISBN 0-85312-709-3/0-
85312-803-3 (Ellis Horwood Ltd), ISBN 0-470-20103-7/0-470-
20259-9 (Halstead Press), 1984.
[12] "Logic and its Applications", Edmund Burk and Eric Foxley,
Prentice Hall, Series in computer science, ISBN 0-13-030263-5,
1996.
[13] McIntyre, L., Buckley, R., Venable, D., Zilles, S., Parsons, G.
and J. Rafferty, "File Format for Internet Fax", RFC2301, March
1998.
[14] Apache content negotiation algorithm,
<http://www.apache.org/docs/content-negotiation.html>
11. Author's Address
Graham Klyne
Content Technologies Ltd. 5th Generation Messaging Ltd.
Forum 1 5 Watlington Street
Station Road Nettlebed
Theale Henley-on-Thames
Reading, RG7 4RA RG9 5AB
United Kingdom United Kingdom.
Phone: +44 118 930 1300 +44 1491 641 641
Facsimile: +44 118 930 1301 +44 1491 641 611
EMail: GK@ACM.ORG
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.