draft-ietf-conneg-W3C-ccpp-00.txt   draft-ietf-conneg-W3C-ccpp-01.txt 
IETF media feature registration WG Graham Klyne IETF media feature registration WG Graham Klyne
Internet draft Content Technologies/5GM Internet draft Content Technologies/5GM
20 October 1998 15 December 1998
W3C Composite Capability/Preference Profiles W3C Composite Capability/Preference Profiles
<draft-ietf-conneg-W3C-ccpp-00.txt> <draft-ietf-conneg-W3C-ccpp-01.txt>
Status of this memo Status of this memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
skipping to change at page 2, line 5 skipping to change at page 2, line 5
This document suggests some possible areas for extending the IETF This document suggests some possible areas for extending the IETF
'conneg' working group's capability description framework, 'conneg' working group's capability description framework,
described in [2,3,4]. The suggested areas for extension have been described in [2,3,4]. The suggested areas for extension have been
motivated by WWW Consortium (W3C) work on Composite motivated by WWW Consortium (W3C) work on Composite
Capability/Preference Profiles (CCPP) [5] that parallels some Capability/Preference Profiles (CCPP) [5] that parallels some
aspects of IETF 'conneg' work. aspects of IETF 'conneg' work.
It is presented as a discussion document, with a view to maybe It is presented as a discussion document, with a view to maybe
integrating some of these ideas into ongoing 'conneg' work. integrating some of these ideas into ongoing 'conneg' work.
Internet draft 20 October 1998 Internet draft 15 December 1998
W3C Composite Capability/Preference Profiles W3C Composite Capability/Preference Profiles
Table of contents Table of contents
1. Introduction.............................................2 1. Introduction.............................................2
1.1 Structure of this document ...........................3 1.1 Structure of this document ...........................3
1.2 Discussion of this document ..........................3 1.2 Discussion of this document ..........................3
1.3 Amendment history ....................................3 1.3 Amendment history ....................................3
2. Tag-independent content negotiation......................4 2. Tag-independent content negotiation......................4
2.1 WWW resource transfer scenario .......................4 2.1 WWW resource transfer scenario .......................4
2.2 Conclusions ..........................................5 2.2 Conclusions ..........................................5
2.3 Consequences .........................................5 2.3 Consequences .........................................5
3. Assumed feature values...................................5 3. Assumed feature values...................................5
3.1 Unifying "required" and "default" values .............6 3.1 Unifying "required" and "default" values .............6
3.2 Message transmission model ...........................7 3.2 Message transmission model ...........................7
3.3. Problem summary .....................................8 3.3. Problem summary .....................................8
3.4 Proposed extension to 'conneg' framework .............9 3.4 Proposed extension to 'conneg' framework .............10
3.4.1 Assumed values construct.........................9 3.4.1 Assumed values construct.........................10
3.4.2 End of chain indicator...........................9 3.4.2 End of chain indicator...........................10
3.4.3 Extended form of conjunction.....................10 3.4.3 Extended form of conjunction.....................10
3.5 Additional reduction rules ...........................10 3.5 Additional reduction rules ...........................11
3.6 Extended canonicalization rules ......................11 3.6 Extended canonicalization rules ......................12
3.7 Examples .............................................11 3.7 Examples .............................................12
3.7.1 The "font" problem...............................12 3.7.1 The "font" problem...............................12
3.7.2 Resolution dependent font........................13 3.7.2 Resolution dependent font........................14
3.7.3 Combining default values.........................14 3.7.3 Combining default values.........................15
4. XML representation of capability descriptions............15 4. XML representation of capability descriptions............17
5. Mapping between RDF and media features...................16 5. Mapping between RDF and media features...................17
6. Conclusions..............................................20 6. Conclusions..............................................21
x. Security considerations..................................20 7. Security considerations..................................21
x. Full copyright statement.................................20 8. Full copyright statement.................................22
x. Acknowledgements.........................................21 9. Acknowledgements.........................................22
x. References...............................................21 10. References..............................................22
x. Author's address.........................................22 11. Author's address........................................24
1. Introduction 1. Introduction
This document suggests some possible areas for extending the IETF This document suggests some possible areas for extending the IETF
'conneg' working group's capability description framework, 'conneg' working group's capability description framework,
described in [2,3,4]. The suggested areas for extension have been described in [2,3,4]. The suggested areas for extension have been
motivated by WWW Consortium (W3C) work on Composite motivated by WWW Consortium (W3C) work on Composite
Capability/Preference Profiles (CCPP) [5] that parallels some Capability/Preference Profiles (CCPP) [5] that parallels some
aspects of IETF 'conneg' work. aspects of IETF 'conneg' work.
It is presented as a discussion document, with a view to maybe It is presented as a discussion document, with a view to maybe
integrating some of these ideas into ongoing 'conneg' work. integrating some of these ideas into ongoing 'conneg' work.
Internet draft 20 October 1998 Internet draft 15 December 1998
W3C Composite Capability/Preference Profiles W3C Composite Capability/Preference Profiles
1.1 Structure of this document 1.1 Structure of this document
The main part of this draft addresses the following main areas: The main part of this draft addresses the following main areas:
Section 2 discusses tag-independent negotiation procedures, one of Section 2 discusses tag-independent negotiation procedures, one of
the goals of the 'conneg' work, with particular reference to WWW the goals of the 'conneg' work, with particular reference to WWW
operations operations
skipping to change at page 4, line 5 skipping to change at page 3, line 52
1.3 Amendment history 1.3 Amendment history
00a 19-Oct-1998 00a 19-Oct-1998
Document initially created. Document initially created.
00b 20-Oct-1998 00b 20-Oct-1998
Added sections on tag-independent negotiation, XML syntax Added sections on tag-independent negotiation, XML syntax
and RDF mapping. and RDF mapping.
Internet draft 20 October 1998 00c 31-Oct-1998
Fixed up section numbers.
01a 15-Dec-1998
Minor editorial revisions for re-issue. Updated CC/PP
reference to published W3C Note.
Internet draft 15 December 1998
W3C Composite Capability/Preference Profiles W3C Composite Capability/Preference Profiles
2. Tag-independent content negotiation 2. Tag-independent content negotiation
One can imagine two extremes of content negotiation procedure: One can imagine two extremes of content negotiation procedure:
o One in which the decisions about whether the features in a data o One in which the decisions about whether the features in a data
data resource match some set of capabilities are made in full data resource match some set of capabilities are made in full
knowledge of the exact meaning of every feature and capability. knowledge of the exact meaning of every feature and capability.
skipping to change at page 5, line 5 skipping to change at page 5, line 5
data files, with no opportunity for interaction between data data files, with no opportunity for interaction between data
resource and server. resource and server.
The plugins available to the browser may well be dispatched as The plugins available to the browser may well be dispatched as
separate programs, with limited opportunity for ongoing interaction separate programs, with limited opportunity for ongoing interaction
between the plugin and the client. Also, there may be a high between the plugin and the client. Also, there may be a high
overhead associated with activating a plugin, so it is not overhead associated with activating a plugin, so it is not
desirable to activate one or more plugins simply to determine desirable to activate one or more plugins simply to determine
whether a data resource is acceptable to that plugin. whether a data resource is acceptable to that plugin.
Internet draft 20 October 1998 Internet draft 15 December 1998
W3C Composite Capability/Preference Profiles W3C Composite Capability/Preference Profiles
2.2 Conclusions 2.2 Conclusions
In an environment like WWW where new and changed features are In an environment like WWW where new and changed features are
deployed on a regular basis, it is clearly not desirable that deployed on a regular basis, it is clearly not desirable that
detailed knowledge be hard-coded into either the origin server or detailed knowledge be hard-coded into either the origin server or
the client software. This would rather defeat the idea of the client software. This would rather defeat the idea of
extending functionality through plugins and data resource extending functionality through plugins and data resource
abstractions. abstractions.
skipping to change at page 5, line 27 skipping to change at page 5, line 27
Thus, to avoid early obsolesence of servers and clients, we seek a Thus, to avoid early obsolesence of servers and clients, we seek a
negotiation framwork that permits a data resource to describe negotiation framwork that permits a data resource to describe
itself to the origin server, a plugin to describe itself to a itself to the origin server, a plugin to describe itself to a
browser, and allows the server and browser to conduct negotiations browser, and allows the server and browser to conduct negotiations
without any further knowledge. without any further knowledge.
There are doubtless some cases where the degree of negotiating There are doubtless some cases where the degree of negotiating
flexibility indicated here is not essential: "Internet appliances" flexibility indicated here is not essential: "Internet appliances"
and other dedicated devices spring to mind. But even for such and other dedicated devices spring to mind. But even for such
devices, it can be argued that the flexibility of tag-independent devices, it can be argued that the flexibility of tag-independent
negotiation will simplify configuration of such devices. negotiation will simplify their configuration.
2.3 Consequences 2.3 Consequences
Some consequences of the conclusion just outlined are: Some consequences of the conclusion just outlined are:
o The capability description should be able to describe o The capability description should be able to describe
dependencies between content features in such a way that they can dependencies between content features in such a way that they can
be handled by the negotiation protocol. be handled by the negotiation protocol.
o The vocabulary used to describe content features should avoid o The vocabulary used to describe content features should avoid
skipping to change at page 5, line 52 skipping to change at page 6, line 5
The W3C CC/PP [5] work embodies a concept that is not currently The W3C CC/PP [5] work embodies a concept that is not currently
supported in the IETF 'conneg' framework [3]; namely the supported in the IETF 'conneg' framework [3]; namely the
construction of a set of capability and preference values from a construction of a set of capability and preference values from a
number of separate sources (e.g. hardware platform defaults, number of separate sources (e.g. hardware platform defaults,
software platform defaults, user preferences). Also, there is a software platform defaults, user preferences). Also, there is a
desire to have a compact way to represent a small number of desire to have a compact way to represent a small number of
differences from some baseline set of capabilities. What is not differences from some baseline set of capabilities. What is not
covered by this work, that the IETF 'conneg' work can supply, is a covered by this work, that the IETF 'conneg' work can supply, is a
framework for actually combining the various information sources. framework for actually combining the various information sources.
Internet draft 15 December 1998
W3C Composite Capability/Preference Profiles
Also, there is an identified capability gap in the IETF 'conneg' Also, there is an identified capability gap in the IETF 'conneg'
work: the ability to indicate that some particular feature must be work: the ability to indicate that some particular feature MUST be
supplied by a communicating counterparty. This has been supplied by a communicating counterparty. This has been
charactirized as the "font problem": how can a sender require that charactirized as the "font problem": how can a sender require that
some particular font is supported by a recipient? Currently the some particular font is supported by a recipient? Currently the
Internet draft 20 October 1998
W3C Composite Capability/Preference Profiles
'conneg' framework operates to effectively ignore a request for an 'conneg' framework operates to effectively ignore a request for an
unknown font, or other unrecognized feature. unknown font, or other unrecognized feature.
3.1 Unifying "required" and "default" values 3.1 Unifying "required" and "default" values
The two situations we wish to describe are: The two situations we wish to describe are:
(A) "required" values: given two feature set descriptions, the (A) "required" values: given two feature set descriptions, the
feature set match is to fail if one of them does not define a feature set match is to fail if one of them does not define a
value for a feature tag tested by the other. This is value for a feature tag tested by the other. This is
skipping to change at page 6, line 50 skipping to change at page 7, line 5
feature set description provides "assumed" values for the font feature set description provides "assumed" values for the font
availability that are used only if the recipient does not availability that are used only if the recipient does not
itself reference that feature. Thus, if the data resource itself reference that feature. Thus, if the data resource
indicates: indicates:
(Font-obscure=TRUE) (Font-obscure=TRUE)
Assume: (Font-obscure=FALSE) Assume: (Font-obscure=FALSE)
and the recipient does not supply a constraint for 'Font- and the recipient does not supply a constraint for 'Font-
obscure', then the assumed value is used to force a feature obscure', then the assumed value is used to force a feature
set match failure. set match failure.
Internet draft 15 December 1998
W3C Composite Capability/Preference Profiles
Case (B): Case (B):
A hardware platform capability description consists entirely A hardware platform capability description consists entirely
of assumed feature values. When combined with user of assumed feature values. When combined with user
preferences, these provide values for those features that are preferences, these provide values for those features that are
not mentioned in the user preferences. not mentioned in the user preferences.
The ideas here can be extended to deal with combinations of more The ideas here can be extended to deal with combinations of more
than two feature sets. than two feature sets.
Internet draft 20 October 1998
W3C Composite Capability/Preference Profiles
The assumed value idea breaks a number of assumptions of the The assumed value idea breaks a number of assumptions of the
current 'conneg' algebraic model [3], which is based pretty much on current 'conneg' algebraic model [3], which is based pretty much on
simplified predicate algebra. The sections that follow reconcile simplified predicate algebra. The sections that follow reconcile
this idea with the existing framework. this idea with the existing framework.
3.2 Message transmission model 3.2 Message transmission model
The following discussion is based on a message transmission model The following discussion is based on a message transmission model
that assumes multiple feature set constraints. The following that assumes multiple feature set constraints. The following
example is from [1], section 3.1: example is from [1], section 3.1:
skipping to change at page 7, line 44 skipping to change at page 8, line 5
Negotiation metadata provided by [S] would take account of Negotiation metadata provided by [S] would take account of
available document content (C) (e.g. availability of resource available document content (C) (e.g. availability of resource
variants) as well as its own possible ability to offer that variants) as well as its own possible ability to offer that
content in variety of formats. content in variety of formats.
Negotiation metadata provided by [R] would similarly take account Negotiation metadata provided by [R] would similarly take account
of the needs and preferences of its user [U] as well as its own of the needs and preferences of its user [U] as well as its own
capabilities to process and render received data. capabilities to process and render received data.
Internet draft 15 December 1998
W3C Composite Capability/Preference Profiles
This example suggests a generic framework within which negotiation This example suggests a generic framework within which negotiation
is conducted: a chain of entities, each of which may impose some is conducted: a chain of entities, each of which may impose some
constraint(s) on the message features that can usefully be constraint(s) on the message features that can usefully be
transferred: transferred:
[.]-->--[E1]-->--[E2]-->-- ... -->--[En]-->--[.] [.]-->--[E1]-->--[E2]-->-- ... -->--[En]-->--[.]
'[.]' are used here indicate specific begin and end points of the '[.]' are used here indicate specific begin and end points of the
chain, and '[Ei]' are entities that may impose feaure constraints. chain, and '[Ei]' are entities that may impose feaure constraints.
If the feature constraint predicate associated with '[Ei]' is If the feature constraint predicate associated with '[Ei]' is
'FCi', then the composite feature constraint for the entire chain 'FCi', then the composite feature constraint for the entire chain
is the conjunction of the individual constraints: is the conjunction of the individual constraints:
(& FC1 FC2 ... FCn ) (& FC1 FC2 ... FCn )
Internet draft 20 October 1998
W3C Composite Capability/Preference Profiles
using the notation of [3]. using the notation of [3].
3.3. Problem summary 3.3. Problem summary
The 'conneg' algebraic framework depends on combining feature sets The 'conneg' algebraic framework depends on combining feature sets
by set intersection (i.e. a logical AND of the predicates that by set intersection (i.e. a logical AND of the predicates that
describe feature sets). describe feature sets).
For the purposes of this discussion, all feature set expressions For the purposes of this discussion, all feature set expressions
are reduced to disjunctive normal form: thus, every feature set is are reduced to disjunctive normal form: thus, every feature set is
skipping to change at page 8, line 41 skipping to change at page 9, line 5
(1) all atomic feature comparisons have the form '(ftag relop (1) all atomic feature comparisons have the form '(ftag relop
fvalue)', where 'ftag' is a feature tag that uniquely fvalue)', where 'ftag' is a feature tag that uniquely
identifies a feature, 'relop' is a comparison operator and identifies a feature, 'relop' is a comparison operator and
'fvalue' is a particular value associated with the feature 'fvalue' is a particular value associated with the feature
tag. tag.
(2) The conjunction operator is symmetric: (2) The conjunction operator is symmetric:
(& A B) == (& B A) (& A B) == (& B A)
Internet draft 15 December 1998
W3C Composite Capability/Preference Profiles
(3) The conjunction operator is associative: (3) The conjunction operator is associative:
(& A (& B C) ) == (& (& A B) C) (& A (& B C) ) == (& (& A B) C)
This property is important because it means that the feature This property is important because it means that the feature
sets are not required to be combined in any specific order. sets are not required to be combined in any specific order.
This point is raised in the CC/PP memo [5], and this is a This point is raised in the CC/PP memo [5], and this is a
property that should be preserved. property that should be preserved.
(4) The assumed value mechanism outlined above is inherrently (4) The assumed value mechanism outlined above is inherrently
anti-symmetric. One of the feature sets used takes precedence anti-symmetric. One of the feature sets used takes precedence
over the other: over the other:
(Assume: A B) != (Assume: B A) (Assume: A B) != (Assume: B A)
(5) The assumed value mechanism, by its very nature, is sensitive (5) The assumed value mechanism, by its very nature, is sensitive
to the particular feature tags used. to the particular feature tags used.
Internet draft 20 October 1998
W3C Composite Capability/Preference Profiles
(6) Assumed values should be used only when an explicit constraint (6) Assumed values should be used only when an explicit constraint
for a feature tag cannot be found. For example, if a data for a feature tag cannot be found. For example, if a data
resource has the requirement: resource has the requirement:
(Font-obscure=TRUE) (Font-obscure=TRUE)
and also indicates an assumed value: and also indicates an assumed value:
Assume: (Font-obscure=FALSE) Assume: (Font-obscure=FALSE)
skipping to change at page 9, line 32 skipping to change at page 10, line 5
This requirement is captured without imposing an order of This requirement is captured without imposing an order of
evaluation on the feature set matching process (because such evaluation on the feature set matching process (because such
imposition is considered to make the entire process more imposition is considered to make the entire process more
complex and error-prone). complex and error-prone).
(7) A feature set constraint must be reduced to the predicate form (7) A feature set constraint must be reduced to the predicate form
currently defined by the 'conneg' framework [3] (i.e. all currently defined by the 'conneg' framework [3] (i.e. all
default values must be eliminated) before a feature collection default values must be eliminated) before a feature collection
(i.e. some specific feature values) can be tested with it. (i.e. some specific feature values) can be tested with it.
Internet draft 15 December 1998
W3C Composite Capability/Preference Profiles
3.4 Proposed extension to 'conneg' framework 3.4 Proposed extension to 'conneg' framework
Two extensions to the 'conneg' algebraic framework are proposed: Two extensions to the 'conneg' algebraic framework are proposed:
(a) a "assumed values" construct (a) a "assumed values" construct
(b) an "end-of-chain" indicator (b) an "end-of-chain" indicator
and revision of the conjunction '(&...)' and other processing rules and revision of the conjunction '(&...)' and other processing rules
to take account of these new constructs. to take account of these new constructs.
skipping to change at page 10, line 5 skipping to change at page 10, line 34
where 'FC' is a list of one or more feature constraint expressions. where 'FC' is a list of one or more feature constraint expressions.
For an expression in the canonical disjunctive normal form, each is For an expression in the canonical disjunctive normal form, each is
an atomic feature value constraint (i.e. contains a single feature an atomic feature value constraint (i.e. contains a single feature
comparison). comparison).
3.4.2 End of chain indicator 3.4.2 End of chain indicator
This is expressed as: This is expressed as:
Internet draft 20 October 1998
W3C Composite Capability/Preference Profiles
(.) (.)
3.4.3 Extended form of conjunction 3.4.3 Extended form of conjunction
The canonical form of a conjunction is extended to allow: The canonical form of a conjunction is extended to allow:
(& ... (+ FL) FC (+ FR) ... ) (& ... (+ FL) FC (+ FR) ... )
That is, it contains separate, optional assumed value constructs to That is, it contains separate, optional assumed value constructs to
the left- and right- of any expression in the conjunction. the left- and right- of any expression in the conjunction.
skipping to change at page 10, line 32 skipping to change at page 11, line 5
(& FC1 (& (+ FL2) FC2 (+FR2) ) FC3 ) (& FC1 (& (+ FL2) FC2 (+FR2) ) FC3 )
the 'FL2' assumed values applied to 'FC1', and values 'FR2' are the 'FL2' assumed values applied to 'FC1', and values 'FR2' are
applied to 'FC3'. applied to 'FC3'.
Assumed value constructs can appear anywhere in a conjunction, and Assumed value constructs can appear anywhere in a conjunction, and
the additional rules below indicate how to process these into the the additional rules below indicate how to process these into the
canonical form. canonical form.
Internet draft 15 December 1998
W3C Composite Capability/Preference Profiles
The '(.)' construct can appear at the left or right hand end of a The '(.)' construct can appear at the left or right hand end of a
conjunction: conjunction:
(& (.) FC (.) ) (& (.) FC (.) )
It may not appear anywhere else in a conjunction. Additional It may not appear anywhere else in a conjunction. Additional
processing rules (below) show how these can be used to eliminate processing rules (below) show how these can be used to eliminate
assumed value constructs from a conjunction, thus reducing it to a assumed value constructs from a conjunction, thus reducing it to a
simple predicate form. simple predicate form.
skipping to change at page 11, line 5 skipping to change at page 11, line 34
The following rules assume that all feature constraints are atomic; The following rules assume that all feature constraints are atomic;
i.e. they refer to a single feature tag. The next section contains i.e. they refer to a single feature tag. The next section contains
rules for canonicalization of complex predicates to a form with rules for canonicalization of complex predicates to a form with
just atomic feature constraints. just atomic feature constraints.
Note that if there are any assumed value constructs present in a Note that if there are any assumed value constructs present in a
conjunction, re-ordering of the component constraints is allowed conjunction, re-ordering of the component constraints is allowed
only according to reordering rule below. only according to reordering rule below.
Internet draft 20 October 1998
W3C Composite Capability/Preference Profiles
(a) Re-ordering of assumed value constraints: (a) Re-ordering of assumed value constraints:
(& ... (+FC1) FC2 ... ) ---> (& ... FC2 (+FC1) ... ) (& ... (+FC1) FC2 ... ) ---> (& ... FC2 (+FC1) ... )
(& ... FC1 (+FC2) ... ) ---> (& ... (+FC2) FC1 ... ) (& ... FC1 (+FC2) ... ) ---> (& ... (+FC2) FC1 ... )
(& ... (+FC1) (+FC2) ... ) ---> (& ... (+FC2) (+FC1) ... ) (& ... (+FC1) (+FC2) ... ) ---> (& ... (+FC2) (+FC1) ... )
ONLY IF: FC1 and FC2 reference different feature tags. ONLY IF: FC1 and FC2 reference different feature tags.
(b) Assumed value elimination: (b) Assumed value elimination:
(& ... FC1 (+FC2) FC3 ... ) ---> (& ... FC1 FC3 ... ) (& ... FC1 (+FC2) FC3 ... ) ---> (& ... FC1 FC3 ... )
ONLY IF: FC1, FC2 and FC3 reference the same feature tag, ONLY IF: FC1, FC2 and FC3 reference the same feature tag,
Two extended forms of this rule allow multiple assumed values Two extended forms of this rule allow multiple assumed values
to be eliminated: to be eliminated:
(& ... FC1 ... (+FC2) FC3 ... ) ---> (& ... FC1 FC3 ... ) (& ... FC1 ... (+FC2) FC3 ... ) ---> (& ... FC1 FC3 ... )
(& ... FC1 (+FC2) ... FC3 ... ) ---> (& ... FC1 FC3 ... ) (& ... FC1 (+FC2) ... FC3 ... ) ---> (& ... FC1 FC3 ... )
ONLY IF: FC1, FC2 and FC3 reference the same feature tag, ONLY IF: FC1, FC2 and FC3 reference the same feature tag,
(c) Default resolution: (c) Default resolution:
(& (.) (+FC1) ... ) ---> (& FC1 ... ) (& (.) (+FC1) ... ) ---> (& FC1 ... )
(& ... (+FC1) (.) ) ---> (& ... FC1 ) (& ... (+FC1) (.) ) ---> (& ... FC1 )
Internet draft 15 December 1998
W3C Composite Capability/Preference Profiles
3.6 Extended canonicalization rules 3.6 Extended canonicalization rules
The above reduction rules assume a canonical form of predicate The above reduction rules assume a canonical form of predicate
expressions. The canonicalization rules described for the 'conneg' expressions. The canonicalization rules described for the 'conneg'
framework [3] must be extended to handle assumed value constructs. framework [3] must be extended to handle assumed value constructs.
The main goal of these additional rules is to push assumed values The main goal of these additional rules is to push assumed values
"down" in the expression so that they are contained within all "down" in the expression so that they are contained within all
disjunctions and conjunctions, and themselves contain only atomic disjunctions and conjunctions, and themselves contain only atomic
feature constraints. feature constraints.
skipping to change at page 12, line 5 skipping to change at page 12, line 39
(+ (| FC1 FC2 ... ) ) ---> (| (+FC1) (+FC2) ... ) (+ (| FC1 FC2 ... ) ) ---> (| (+FC1) (+FC2) ... )
(d) Flatten assumed value nests: (d) Flatten assumed value nests:
(+ ... (+FC1) ... ) ---> (+ ... FC1 ... ) (+ ... (+FC1) ... ) ---> (+ ... FC1 ... )
3.7 Examples 3.7 Examples
Expressions in the following examples assume left is "upstream" in Expressions in the following examples assume left is "upstream" in
the message flow. the message flow.
Internet draft 20 October 1998
W3C Composite Capability/Preference Profiles
3.7.1 The "font" problem 3.7.1 The "font" problem
Sender/data resource description: Sender/data resource description:
(& (Font-1=TRUE) (Font-2=TRUE) (& (Font-1=TRUE) (Font-2=TRUE)
(+ (Font-1=FALSE) (Font-2=FALSE) ) ) (+ (Font-1=FALSE) (Font-2=FALSE) ) )
Recipient description: Recipient description:
(& (Font-1=TRUE) (Font-3=TRUE) ) (& (Font-1=TRUE) (Font-3=TRUE) )
Internet draft 15 December 1998
W3C Composite Capability/Preference Profiles
Combine these to obtain the full transmission path description Combine these to obtain the full transmission path description
(recall that feature sets are matched by combining them with (recall that feature sets are matched by combining them with
'(&...)', and left is upstream in the transmission path): '(&...)', and left is upstream in the transmission path):
(& (.) (& (.)
(& (Font-1=TRUE) (Font-2=TRUE) // Sender.. (& (Font-1=TRUE) (Font-2=TRUE) // Sender..
(+ (Font-1=FALSE) (Font-2=FALSE) ) ) (+ (Font-1=FALSE) (Font-2=FALSE) ) )
(& (Font-1=TRUE) (Font-3=TRUE) ) // Receiver.. (& (Font-1=TRUE) (Font-3=TRUE) ) // Receiver..
(.) ) (.) )
skipping to change at page 13, line 5 skipping to change at page 13, line 48
--> [collect features, being careful to preserve ordering of --> [collect features, being careful to preserve ordering of
constraints with the same feature tag]: constraints with the same feature tag]:
(& (.) (& (.)
(Font-1=TRUE) (+ (Font-1=FALSE) ) (Font-1=TRUE) (Font-1=TRUE) (+ (Font-1=FALSE) ) (Font-1=TRUE)
(Font-2=TRUE) (+ (Font-2=FALSE) ) (Font-2=TRUE) (+ (Font-2=FALSE) )
(Font-3=TRUE) ) (Font-3=TRUE) )
(& (.) (& (.)
Internet draft 20 October 1998
W3C Composite Capability/Preference Profiles
--> [eliminate un-needed default] --> [eliminate un-needed default]
(& (.) (& (.)
(Font-1=TRUE) (Font-1=TRUE) (Font-1=TRUE) (Font-1=TRUE)
(Font-2=TRUE) (+ (Font-2=FALSE) ) (Font-2=TRUE) (+ (Font-2=FALSE) )
(Font-3=TRUE) ) (Font-3=TRUE) )
(& (.) (& (.)
Internet draft 15 December 1998
W3C Composite Capability/Preference Profiles
--> [Resolve non-eliminated default: move to end, then use (+...) --> [Resolve non-eliminated default: move to end, then use (+...)
(.) rewriting rule] (.) rewriting rule]
(& (.) (& (.)
(Font-1=TRUE) (Font-1=TRUE) (Font-1=TRUE) (Font-1=TRUE)
(Font-2=TRUE) (Font-2=FALSE) (Font-2=TRUE) (Font-2=FALSE)
(Font-3=TRUE) ) (Font-3=TRUE) )
(& (.) (& (.)
--> [Combine (&...) with same tag: --> [Combine (&...) with same tag:
skipping to change at page 14, line 5 skipping to change at page 15, line 5
(& (dpi>=300) (Font-fancy=TRUE) (+ (Font-fancy=FALSE) ) ) ) (& (dpi>=300) (Font-fancy=TRUE) (+ (Font-fancy=FALSE) ) ) )
This would match the recipient capalities: This would match the recipient capalities:
(& (dpi=100) (Font-simple=TRUE) ) (& (dpi=100) (Font-simple=TRUE) )
or or
(& (dpi=300) (Font-simple=TRUE) (Font-fancy=TRUE) ) (& (dpi=300) (Font-simple=TRUE) (Font-fancy=TRUE) )
But it would not match the recipient capability: But it would not match the recipient capability:
(& (dpi=100) (Font-fancy=TRUE) ) (& (dpi=100) (Font-fancy=TRUE) )
Internet draft 20 October 1998 Internet draft 15 December 1998
W3C Composite Capability/Preference Profiles W3C Composite Capability/Preference Profiles
3.7.3 Combining default values 3.7.3 Combining default values
Finally, note there is a possibility to use nested '(& ... (.) )' Finally, note there is a possibility to use nested '(& ... (.) )'
constructs for defaults which are restricted to a particular entity constructs for defaults which are restricted to a particular entity
in the transmission chain, for example (which is the type of in the transmission chain, for example (which is the type of
scenario discussed in the CC/PP draft): scenario discussed in the CC/PP draft):
(& <sender> (& <sender>
skipping to change at page 15, line 5 skipping to change at page 16, line 5
(& (OS="EPOC1.0") (& (OS="EPOC1.0")
(HTMLVersion="4.0") (HTMLVersion="4.0")
(JavaScriptVersion="4.0") (JavaScriptVersion="4.0")
(WAPVersion="1.0") (WAPVersion="1.0")
(WMLScriptVersion="1.0") ) (WMLScriptVersion="1.0") )
(Software-platform) :- (Software-platform) :-
(& (Sound="Off") (& (Sound="Off")
(Images="Off") ) (Images="Off") )
Internet draft 20 October 1998 Internet draft 15 December 1998
W3C Composite Capability/Preference Profiles W3C Composite Capability/Preference Profiles
(EpocEmail) :- (EpocEmail) :-
(& (Version="EpocEmail1.0") (& (Version="EpocEmail1.0")
(HTMLVersion="4.0") ) (HTMLVersion="4.0") )
(EpocCalendar) :- (EpocCalendar) :-
(& (Version="EpocCalendar1.0") (& (Version="EpocCalendar1.0")
(HTMLVersion="4.0") ) (HTMLVersion="4.0") )
skipping to change at page 16, line 5 skipping to change at page 17, line 5
(& (*) (+ (Software-defaults) ) (Software-platform) (.) ) (& (*) (+ (Software-defaults) ) (Software-platform) (.) )
(EpocEmail) (EpocEmail)
(EpocCalendar) (EpocCalendar)
(UserPreferences) (UserPreferences)
(.) ) (.) )
where where
(etc.) (etc.)
Internet draft 20 October 1998 Internet draft 15 December 1998
W3C Composite Capability/Preference Profiles W3C Composite Capability/Preference Profiles
4. XML representation of capability descriptions 4. XML representation of capability descriptions
The 'conneg' feature set description framework is well-suited to The 'conneg' feature set description framework is well-suited to
being expressed in XML. The previously given example: being expressed in XML. The previously given example:
(| (& (dpi>=100) (Font-simple=TRUE) (+ (Font-simple=FALSE) ) ) (| (& (dpi>=100) (Font-simple=TRUE) (+ (Font-simple=FALSE) ) )
(& (dpi>=300) (Font-fancy=TRUE) (+ (Font-fancy=FALSE) ) ) ) (& (dpi>=300) (Font-fancy=TRUE) (+ (Font-fancy=FALSE) ) ) )
skipping to change at page 17, line 5 skipping to change at page 18, line 5
as well as a syntax for encoding and transporting this metadata as well as a syntax for encoding and transporting this metadata
in a manner that maximizes the interoperability of independently in a manner that maximizes the interoperability of independently
developed web servers and clients. The syntax presented here developed web servers and clients. The syntax presented here
uses the Extensible Markup Language [XML]: one of the goals of uses the Extensible Markup Language [XML]: one of the goals of
RDF is to make it possible to specify semantics for data based on RDF is to make it possible to specify semantics for data based on
XML in a standardized, interoperable manner. [...] It is also XML in a standardized, interoperable manner. [...] It is also
important to understand that this XML syntax is only one possible important to understand that this XML syntax is only one possible
syntax for RDF, and that alternate ways to represent the same RDF syntax for RDF, and that alternate ways to represent the same RDF
data model may emerge." data model may emerge."
Internet draft 20 October 1998 Internet draft 15 December 1998
W3C Composite Capability/Preference Profiles W3C Composite Capability/Preference Profiles
It is interesting to note that the 'conneg' feature expression It is interesting to note that the 'conneg' feature expression
framework shares with the RDF framework this clear intent to framework shares with the RDF framework this clear intent to
separate the data model from its representative syntax. separate the data model from its representative syntax.
In this section, the RDF data model is explored and related to the In this section, the RDF data model is explored and related to the
'conneg' feature registration namespace. The RDF data model is 'conneg' feature registration namespace. The RDF data model is
very rich compared with that used by 'conneg', so should easily be very rich compared with that used by 'conneg', so should easily be
capable of representing the concepts used. capable of representing the concepts used.
skipping to change at page 18, line 5 skipping to change at page 19, line 5
representation. Atomic feature value assertions are also representation. Atomic feature value assertions are also
predicates that relate a feature tag with a value. predicates that relate a feature tag with a value.
Thus, to fit the RDF model, we can model a feature as an RDF Thus, to fit the RDF model, we can model a feature as an RDF
"resource", with a tag and one or more value assertions. The "resource", with a tag and one or more value assertions. The
following example models a simple description of a VGA display, following example models a simple description of a VGA display,
which using 'conneg' notation would be: which using 'conneg' notation would be:
(& (pix-x<=640) (pix-y<=480) (color<=256) ) (& (pix-x<=640) (pix-y<=480) (color<=256) )
Internet draft 20 October 1998 Internet draft 15 December 1998
W3C Composite Capability/Preference Profiles W3C Composite Capability/Preference Profiles
This display might be described by the following RDF: This display might be described by the following RDF:
<rdf:RDF> <rdf:RDF>
<rdf:Description ID="VGA display"> <rdf:Description ID="VGA display">
<conneg:Feature-assertion> <conneg:Feature-assertion>
<conneg:Feature> <conneg:Feature>
<conneg:Feature-tag="pix-x"/> <conneg:Feature-tag="pix-x"/>
<conneg:LE="640"/> <conneg:LE="640"/>
skipping to change at page 19, line 5 skipping to change at page 20, line 5
</conneg:Feature> </conneg:Feature>
</conneg:Feature-assertion> </conneg:Feature-assertion>
</rdf:Description> </rdf:Description>
</rdf:RDF> </rdf:RDF>
In this example, the multiple feature values within a "Feature- In this example, the multiple feature values within a "Feature-
assertion" are taken to be implicitly ANDed together. Other assertion" are taken to be implicitly ANDed together. Other
representations are possible. All 'conneg'-related tags are representations are possible. All 'conneg'-related tags are
assumed to be defined in a 'conneg' namespace. assumed to be defined in a 'conneg' namespace.
Internet draft 20 October 1998 Internet draft 15 December 1998
W3C Composite Capability/Preference Profiles W3C Composite Capability/Preference Profiles
To take a slightly more complex 'conneg' example: To take a slightly more complex 'conneg' example:
(| (& (pix-x<=800) (pix-y<=600) (color<=256) ) (| (& (pix-x<=800) (pix-y<=600) (color<=256) )
(& (pix-x<=640) (pix-y<=480) (color<=65536) ) ) (& (pix-x<=640) (pix-y<=480) (color<=65536) ) )
This might be represented as: This might be represented as:
<rdf:RDF> <rdf:RDF>
skipping to change at page 20, line 5 skipping to change at page 21, line 5
<conneg:Feature-tag="color"/> <conneg:Feature-tag="color"/>
<conneg:LE="65536"/> <conneg:LE="65536"/>
</conneg:Feature> </conneg:Feature>
</conneg:Feature-assertion> </conneg:Feature-assertion>
</rdf:Description> </rdf:Description>
</conneg:OR> </conneg:OR>
</conneg:Feature-assertion> </conneg:Feature-assertion>
</rdf:Description ID="VGA display"> </rdf:Description ID="VGA display">
</rdf:RDF> </rdf:RDF>
Internet draft 20 October 1998 Internet draft 15 December 1998
W3C Composite Capability/Preference Profiles W3C Composite Capability/Preference Profiles
[[[I am not expert in RDF, but already I can see ways in which the [[[I am not expert in RDF, but already I can see ways in which the
above might to improved. At this stage, the key ideas I wish to above might to improved. At this stage, the key ideas I wish to
test are: (a) that feature collections can be modelled directly as test are: (a) that feature collections can be modelled directly as
RDL resource descriptions, (b) that feature sets must me modelled RDL resource descriptions, (b) that feature sets must be modelled
as resources in their own right, and (c) that atomic value as resources in their own right, and (c) that atomic value
assertions should use the RDF "predicate" to indicate the kind of assertions should use the RDF "predicate" to indicate the kind of
constraint that is being applied.]]] constraint that is being applied.]]]
6. Conclusions 6. Conclusions
One of the goals of these proposals is to allow the 'conneg' work One of the goals of these proposals is to allow the 'conneg' work
to integrate seamlessly with ongoing work that is being undertaken to integrate seamlessly with ongoing work that is being undertaken
by W3C. by W3C.
skipping to change at page 20, line 33 skipping to change at page 21, line 33
capture the required concepts embodied in the W3C work, and provide capture the required concepts embodied in the W3C work, and provide
a way to manipulate them consistently within the 'conneg' framework a way to manipulate them consistently within the 'conneg' framework
already proposed. already proposed.
[[[Ideally, the extensions to the conneg algebraic framework should [[[Ideally, the extensions to the conneg algebraic framework should
be subjected to some mathematical analysis to show that application be subjected to some mathematical analysis to show that application
of the rules can never yield contradictory results, and that the of the rules can never yield contradictory results, and that the
behaviour is consistent with the concept of assumed values that it behaviour is consistent with the concept of assumed values that it
tries to capture.]]] tries to capture.]]]
x. Security considerations 7. Security considerations
xxxx In general, these proposals are not believed to raise any security
considerations not already inherrent in the 'conneg', 'RDF' or
'CC/PP' work.
x. Full copyright statement One area can be seen where further consideration of security
concerns might be required. The use of URLs, per CC/PP, to locate
'conneg' feature set descriptions might open up some exposure to
privacy or denial of service attacks on the referenced description.
Internet draft 15 December 1998
W3C Composite Capability/Preference Profiles
8. Full copyright statement
Copyright (C) The Internet Society 1998. All Rights Reserved. Copyright (C) The Internet Society 1998. All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied, it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works. paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages must be followed, or as required to translate it into languages
other than English. other than English.
Internet draft 20 October 1998
W3C Composite Capability/Preference Profiles
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
x. Acknowledgements 9. Acknowledgements
xxxx xxxx
x. References 10. References
[1] "Requirements for protocol-independent content negotiation" [1] "Requirements for protocol-independent content negotiation"
G. Klyne, Integralis Ltd. G. Klyne, Integralis Ltd.
Internet draft: <draft-ietf-conneg-requirements-00.txt> Internet draft: <draft-ietf-conneg-requirements-00.txt>
Work in progress, March 1998. Work in progress, March 1998.
[2] "Media Feature Tag Registration Procedure" [2] "Media Feature Tag Registration Procedure"
Koen Holtman, TUE Koen Holtman, TUE
Andrew Mutz, Hewlett-Packard Andrew Mutz, Hewlett-Packard
Ted Hardie, NASA Ted Hardie, NASA
Internet draft: <draft-ietf-conneg-feature-reg-03.txt> Internet draft: <draft-ietf-conneg-feature-reg-03.txt>
Work in progress, July 1998. Work in progress, July 1998.
Internet draft 15 December 1998
W3C Composite Capability/Preference Profiles
[3] "A syntax for describing media feature sets" [3] "A syntax for describing media feature sets"
Graham Klyne, 5GM/Content Technologies Graham Klyne, 5GM/Content Technologies
Internet draft: <draft-ietf-conneg-feature-syntax-00.txt>" Internet draft: <draft-ietf-conneg-feature-syntax-00.txt>"
Work in progress, September 1998. Work in progress, September 1998.
[4] "Media Features for Display, Print, and Fax" [4] "Media Features for Display, Print, and Fax"
Larry Masinter, Xerox PARC Larry Masinter, Xerox PARC
Koen Holtman, TUE Koen Holtman, TUE
Andrew Mutz, Hewlett-Packard Andrew Mutz, Hewlett-Packard
Dan Wing, Cisco Systems Dan Wing, Cisco Systems
Internet draft: <draft-ietf-conneg-media-features-02.txt> Internet draft: <draft-ietf-conneg-media-features-02.txt>
Work in progress, September 1998. Work in progress, September 1998.
[5] "Composite Capability/Preference Profiles (CC/PP): [5] "Composite Capability/Preference Profiles (CC/PP):
A user side framework for content negotiation" A user side framework for content negotiation"
Franklin Reynolds, Nokia Research Franklin Reynolds, Nokia Research
W3C working draft: unpublished, but submitted to IETF content W3C Note <http://www.w3.org/TR/NOTE-CCPP/>
negotiation mailing list. Available at: November 1998
<http://www.imc.org/ietf-medfree/mail-archive/0358.html>
October 1998 (?)
Internet draft 20 October 1998
W3C Composite Capability/Preference Profiles
[6] "Resource Description Framework (RDF) Model and Syntax [6] "Resource Description Framework (RDF) Model and Syntax
Specification" Specification"
Ora Lassila, Nokia Research Centre Ora Lassila, Nokia Research Centre
Ralph R Swick, World Wide Web Consortium Ralph R Swick, World Wide Web Consortium
W3C working draft: <http://www.w3.org/TR/WD-rdf-syntax> W3C working draft: <http://www.w3.org/TR/WD-rdf-syntax>
October 1998 October 1998
[7] "Resource Description Framework (RDF) Schema Specification" [7] "Resource Description Framework (RDF) Schema Specification"
Dan Brickley, University of Bristol Dan Brickley, University of Bristol
skipping to change at page 22, line 29 skipping to change at page 24, line 5
W3C working draft: <http://www.w3.org/TR/WD-rdf-syntax> W3C working draft: <http://www.w3.org/TR/WD-rdf-syntax>
August 1998. August 1998.
[8] "Extensible Markup Language (XML) 1.0" [8] "Extensible Markup Language (XML) 1.0"
Tim Bray, Textuality and Netscape Tim Bray, Textuality and Netscape
Jean Paoli, Microsoft Jean Paoli, Microsoft
C. M. Sperberg-McQueen, University of Illinois at Chicago C. M. Sperberg-McQueen, University of Illinois at Chicago
W3C Recommendation: <http://www.w3.org/TR/REC-xml> W3C Recommendation: <http://www.w3.org/TR/REC-xml>
February 1998. February 1998.
x. Author's address Internet draft 15 December 1998
W3C Composite Capability/Preference Profiles
11. Author's address
Graham Klyne Graham Klyne
Content Technologies Ltd. 5th Generation Messaging Ltd. Content Technologies Ltd. 5th Generation Messaging Ltd.
Forum 1 5 Watlington Street Forum 1 5 Watlington Street
Station Road Nettlebed Station Road Nettlebed
Theale Henley-on-Thames Theale Henley-on-Thames
Reading, RG7 4RA RG9 5AB Reading, RG7 4RA RG9 5AB
United Kingdom United Kingdom. United Kingdom United Kingdom.
Telephone: +44 118 930 1300 +44 1491 641 641 Telephone: +44 118 930 1300 +44 1491 641 641
 End of changes. 45 change blocks. 
73 lines changed or deleted 90 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/