idnits 2.17.1 draft-ietf-conneg-W3C-ccpp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** Bad filename characters: the document name given in the document, 'draft-ietf-conneg-W3C-ccpp-02', contains other characters than digits, lowercase letters and dash. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 23 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([5], [2,3,4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 244: '...e that some particular feature MUST be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (29 July 1999) is 9037 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'A' on line 318 -- Looks like a reference, but probably isn't: 'S' on line 330 -- Looks like a reference, but probably isn't: 'R' on line 335 -- Looks like a reference, but probably isn't: 'U' on line 336 -- Looks like a reference, but probably isn't: 'XML' on line 808 == Unused Reference: '7' is defined on line 1125, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1132, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF media feature registration WG Graham Klyne 2 Internet draft Content Technologies/5GM 3 29 July 1999 4 Expires: January 2000 6 W3C Composite Capability/Preference Profiles 7 9 Status of this memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or to cite them other than as ``work in 23 progress''. 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) 1999, The Internet Society 35 Abstract 37 This document suggests some possible areas for extending the IETF 38 'conneg' working group's capability description framework, 39 described in [2,3,4]. The suggested areas for extension have been 40 motivated by WWW Consortium (W3C) work on Composite 41 Capability/Preference Profiles (CCPP) [5] that parallels some 42 aspects of the IETF 'conneg' work. 44 This is presented as a discussion document, with a view to maybe 45 integrating some of these ideas into ongoing 'conneg' work, and to 46 indicate some areas for ongoing collaboration between the IETF and 47 W3C in the area of content description. 49 W3C Composite Capability/Preference Profiles 51 Table of contents 53 1. Introduction.............................................2 54 1.1 Structure of this document ...........................3 55 1.2 Discussion of this document ..........................3 56 2. Tag-independent content negotiation......................3 57 2.1 WWW resource transfer scenario .......................4 58 2.2 Conclusions ..........................................4 59 2.3 Consequences .........................................5 60 3. Assumed feature values...................................5 61 3.1 Unifying "required" and "default" values .............6 62 3.2 Message transmission model ...........................7 63 3.3. Problem summary .....................................8 64 3.4 Proposed extension to 'conneg' framework .............9 65 3.4.1 Assumed values construct.........................9 66 3.4.2 End of chain indicator...........................10 67 3.4.3 Extended form of conjunction.....................10 68 3.5 Additional reduction rules ...........................10 69 3.6 Extended canonicalization rules ......................11 70 3.7 Examples .............................................12 71 3.7.1 The "font" problem...............................12 72 3.7.2 Resolution dependent font........................14 73 3.7.3 Combining default values.........................14 74 4. XML representation of capability descriptions............16 75 5. Mapping between RDF and media features...................17 76 5.1 An alternative RDF representation ....................20 77 6. Conclusions..............................................21 78 7. Security considerations..................................21 79 8. Full copyright statement.................................22 80 9. Acknowledgements.........................................22 81 10. References..............................................22 82 11. Author's address........................................24 83 Appendix A. Amendment history ............................24 85 1. Introduction 87 This document suggests some possible areas for extending the IETF 88 'conneg' working group's capability description framework, 89 described in [2,3,4]. The suggested areas for extension have been 90 motivated by WWW Consortium (W3C) work on Composite 91 Capability/Preference Profiles (CCPP) [5] that parallels some 92 aspects of IETF 'conneg' work. 94 This is presented as a discussion document, with a view to maybe 95 integrating some of these ideas into ongoing 'conneg' work, and to 96 indicate some areas for ongoing collaboration between the IETF and 97 W3C in the area of content description. 99 W3C Composite Capability/Preference Profiles 101 1.1 Structure of this document 103 The main part of this draft addresses the following main areas: 105 Section 2 discusses tag-independent negotiation procedures, one of 106 the goals of the 'conneg' work, with particular reference to WWW 107 operations 109 Section 3 suggests a framework for describing "assumed" feature 110 values. 112 Section 4 explores an approach to using XML to carry capability 113 information structured according to the 'conneg' framework. 115 Section 5 suggests an approach to mapping between RDF [6] and 116 'conneg' media feature registrations and representations. 118 [Author's commentary and meta-discussion about the ideas 119 expressed in this memo is included in paragraphs that are 120 indented and enclosed in square brackets, like this.] 122 1.2 Discussion of this document 124 Discussion of this document should take place on the content 125 negotiation and media feature registration mailing list hosted by 126 the Internet Mail Consortium (IMC): 128 Please send comments regarding this document to: 130 ietf-medfree@imc.org 132 To subscribe to this list, send a message with the body 'subscribe' 133 to "ietf-medfree-request@imc.org". 135 To see what has gone on before you subscribed, please see the 136 mailing list archive at: 138 http://www.imc.org/ietf-medfree/ 140 2. Tag-independent content negotiation 142 One can imagine two extremes of content negotiation procedure: 144 o One in which the decisions about whether the features in a data 145 resource match some set of capabilities are made in full 146 knowledge of the exact meaning of every feature and capability. 148 o The other, in which the matching decision is made without any 149 knowledge of the particular features concerned. 151 W3C Composite Capability/Preference Profiles 153 A practical procedure is likely to lie somewhere between these 154 extremes. Here, we argue that a procedure that minimizes the 155 required knowledge of particular feature tags is likely to be more 156 useful than one which depends heavily upon such knowledge. 158 This approach is described here as "tag-independent negotiation": 159 negotiation that can proceed without specific knowledge of the tags 160 used to describe various media features of the participating 161 entities. 163 2.1 WWW resource transfer scenario 165 Consider a WWW transaction scenario that involves content 166 negotiation: 168 Resource-1 ->- +--------+ +--------+ ->- Plugin-1 169 \ | Origin | | | / 170 Resource-2 ->----| Server |--<--->--| Client |---->- Plugin-2 171 / | | | | \ 172 Resource-3 ->- +--------+ +--------+ ->- Plugin-3 174 In this scenario, the active negotiation takes place between the 175 origin server and the receiving client. 177 The resources available to the origin server are possibly passive 178 data files, with no opportunity for interaction between data 179 resource and server. 181 The plugins available to the browser may well be dispatched as 182 separate programs, with limited opportunity for ongoing interaction 183 between the plugin and the client. Also, there may be a high 184 overhead associated with activating a plugin, so it is not 185 desirable to activate one or more plugins simply to determine 186 whether a data resource is acceptable to that plugin. 188 2.2 Conclusions 190 In an environment like WWW where new and changed features are 191 deployed on a regular basis, it is clearly not desirable that 192 detailed knowledge be hard-coded into either the origin server or 193 the client software. This would rather defeat the idea of 194 extending functionality through plugins and data resource 195 abstractions. 197 Thus, to avoid early obsolescence of both server and client 198 implementations, we seek a negotiation framework that permits a 199 data resource to describe itself to the origin server, a plugin to 200 describe itself to a browser, and allows the server and browser to 201 conduct negotiations without any further knowledge. 203 W3C Composite Capability/Preference Profiles 205 There are doubtless some cases where the degree of negotiating 206 flexibility indicated here is not essential: "Internet appliances" 207 and other dedicated devices spring to mind. But even for such 208 devices, it can be argued that the flexibility of tag-independent 209 negotiation will simplify their configuration. 211 2.3 Consequences 213 Some consequences of the conclusion just outlined are: 215 o The capability description should be able to describe 216 dependencies between content features in such a way that they can 217 be handled by the negotiation protocol. 219 o The vocabulary used to describe content features should avoid 220 having multiple ways to describe the same capabilities, as 221 reconciliation of these would require specific knowledge about 222 the tags used. 224 3. Assumed feature values 226 [This section describes a possible approach to dealing 227 with "assumed" or "default" feature values. It is 228 intended to show that incorporation of such ideas into 229 the 'conneg' framework is possible, and does not claim 230 that the proposal offered is the best way to proceed, or 231 even a good way to proceed.] 233 The W3C CC/PP [5] work embodies a concept that is not currently 234 supported in the IETF 'conneg' framework [3]; namely the 235 construction of a set of capability and preference values from a 236 number of separate sources (e.g. hardware platform defaults, 237 software platform defaults, user preferences). Also, there is a 238 desire to have a compact way to represent a small number of 239 differences from some baseline set of capabilities. What is not 240 covered by this work, that the IETF 'conneg' work can supply, is a 241 framework for actually combining the various information sources. 243 Also, there is an identified capability gap in the IETF 'conneg' 244 work: the ability to indicate that some particular feature MUST be 245 supplied by a communicating counter-party. This has been 246 characterized as the "font problem": how can a sender require that 247 some particular font is supported by a recipient? Currently the 248 'conneg' framework operates to effectively ignore a request for an 249 unknown font, or other unrecognized feature. 251 W3C Composite Capability/Preference Profiles 253 3.1 Unifying "required" and "default" values 255 The two situations we wish to describe are: 257 (A) "required" values: given two feature set descriptions, the 258 feature set match is to fail if one of them does not define a 259 value for a feature tag tested by the other. This is 260 exemplified by the "fonts" problem: if a data resource uses 261 some font indicated by the feature tag "Font-obscure", and the 262 receiver does not explicitly declare an ability to deal with 263 that font, then we should assume that the feature sets do not 264 match. As currently defined, the 'conneg' algebraic framework 265 [3] would allow a feature set match in the absence of an 266 explicit denial of such support. 268 (B) "override" and "default" values: given two feature set 269 descriptions that contain different constraints involving some 270 feature tag, the constraint from one of the feature sets is to 271 override the constraint in the other. This is exemplified by 272 the scenario outlined in the W3 CC/PP draft [5], in which a 273 hardware manufacturer may supply a default profile for a 274 device which can then be overridden by local user preferences. 276 A mechanism that can address both of these requirements is one 277 which allows a feature set description to indicate "assumed" values 278 for a given feature. 280 Case (A): 281 A data resource requires a given font to be available, and its 282 feature set description provides "assumed" values for the font 283 availability that are used only if the recipient does not 284 itself reference that feature. Thus, if the data resource 285 indicates: 286 (Font-obscure=TRUE) 287 Assume: (Font-obscure=FALSE) 288 and the recipient does not supply a constraint for 'Font- 289 obscure', then the assumed value is used to force a feature 290 set match failure. 292 Case (B): 293 A hardware platform capability description consists entirely 294 of assumed feature values. When combined with user 295 preferences, these provide values for those features that are 296 not mentioned in the user preferences. 298 The ideas here can be extended to deal with combinations of more 299 than two feature sets. 301 W3C Composite Capability/Preference Profiles 303 The assumed value idea breaks a number of assumptions of the 304 current 'conneg' algebraic model [3], which is based on a 305 simplified predicate algebra. The sections that follow reconcile 306 this idea with the existing framework. 308 3.2 Message transmission model 310 The following discussion is based on a message transmission model 311 that assumes multiple feature set constraints. The following 312 example is from [1], section 3.1: 314 The life of a data resource may be viewed as: 315 (C) (T) (F) 316 [A]-->--[S]-->--[R]-->--[U] 317 where: 318 [A] = author of document 319 (C) = original document content 320 [S] = message sending system 321 (T) = transmitted data file (representation of (C)) 322 [R] = receiving system 323 (F) = formatted (rendered) document data (presentation of (C)) 324 [U] = user or consumer of a document 326 Here, it is [S] and [R] who exchange negotiation metadata to 327 decide the form of (T), so these elements are the focus of our 328 attention. 330 Negotiation metadata provided by [S] would take account of 331 available document content (C) (e.g. availability of resource 332 variants) as well as its own possible ability to offer that 333 content in variety of formats. 335 Negotiation metadata provided by [R] would similarly take account 336 of the needs and preferences of its user [U] as well as its own 337 capabilities to process and render received data. 339 This example suggests a generic framework within which negotiation 340 is conducted: a chain of entities, each of which may impose some 341 constraint(s) on the message features that can usefully be 342 transferred: 344 [.]-->--[E1]-->--[E2]-->-- ... -->--[En]-->--[.] 346 '[.]' here indicate begin and end of the chain, and '[Ei]' are 347 entities that may impose feature constraints. If the constraint 348 predicate associated with '[Ei]' is 'FCi', then the composite 349 feature constraint for the entire chain is the conjunction of the 350 individual constraints (using 'conneg' notation [3]): 352 (& FC1 FC2 ... FCn ) 354 W3C Composite Capability/Preference Profiles 356 3.3. Problem summary 358 The 'conneg' algebraic framework depends on combining feature sets 359 by set intersection (i.e. a logical AND of the predicates that 360 describe feature sets). 362 For the purposes of this discussion, all feature set expressions 363 are reduced to disjunctive normal form: thus, every feature set is 364 described as a disjunction (union) of one or more subsets, each of 365 which is described by a conjunction of atomic feature comparisons; 366 e.g. 368 (| (& (size=s1) (resolution=r1) (color=c1) ) 369 (& (size=s2) (resolution=r2) (grey=g2) ) ) 371 This is without loss of generality: the combining framework 372 description [3] shows how more complex expressions can be reduced 373 to this canonical form. 375 Now consider the following observations: 377 (1) all atomic feature comparisons have the form '(ftag relop 378 fvalue)', where 'ftag' is a feature tag that uniquely 379 identifies a feature, 'relop' is a comparison operator and 380 'fvalue' is a particular value associated with the feature 381 tag. 383 (2) The conjunction operator is symmetric: 385 (& A B) == (& B A) 387 (3) The conjunction operator is associative: 389 (& A (& B C) ) == (& (& A B) C) 391 This property is important because it means that the feature 392 sets are not required to be combined in any specific order. 393 This point is raised in the CC/PP memo [5], and this is a 394 property that should be preserved. 396 (4) The assumed value mechanism outlined above is inherently anti- 397 symmetric. One of the feature sets used takes precedence over 398 the other: 400 (Assume: A B) != (Assume: B A) 402 (5) The assumed value mechanism, by its very nature, is sensitive 403 to the particular feature tags used. 405 W3C Composite Capability/Preference Profiles 407 (6) Assumed values should be used only when an explicit constraint 408 for a feature tag cannot be found. For example, if a data 409 resource has the requirement: 411 (Font-obscure=TRUE) 413 and also indicates an assumed value: 415 Assume: (Font-obscure=FALSE) 417 The assumed value must be ignored if the recipient asserts: 419 (Font-obscure=TRUE) 421 This requirement is captured without imposing an order of 422 evaluation on the feature set matching process (because such 423 imposition is considered to make the entire process more 424 complex and error-prone). 426 (7) A feature set constraint must be reduced to the predicate form 427 currently defined by the 'conneg' framework [3] (i.e. all 428 default values must be eliminated) before a feature collection 429 (i.e. some specific feature values) can be tested with it. 431 3.4 Proposed extension to 'conneg' framework 433 Two extensions to the 'conneg' algebraic framework are proposed: 435 (a) a "assumed values" construct 437 (b) an "end-of-chain" indicator 439 and revision of the conjunction '(&...)' and other processing rules 440 to take account of these new constructs. 442 3.4.1 Assumed values construct 444 This is expressed as: 446 (+ FC ) 448 where 'FC' is a list of one or more feature constraint expressions. 449 For an expression in the canonical disjunctive normal form, each is 450 an atomic feature value constraint (i.e. contains a single feature 451 comparison). 453 W3C Composite Capability/Preference Profiles 455 3.4.2 End of chain indicator 457 This is expressed as: 459 (.) 461 3.4.3 Extended form of conjunction 463 The canonical form of a conjunction is extended to allow: 465 (& ... (+ FL) FC (+ FR) ... ) 467 That is, it contains separate, optional assumed value constructs to 468 the left- and right- of any expression in the conjunction. 469 Referring to the message transmission chain model, these correspond 470 to assumed values that are applied "upstream" and "downstream" 471 along the chain. For example, when feature sets along a chain are 472 combined: 474 (& FC1 (& (+ FL2) FC2 (+FR2) ) FC3 ) 476 the 'FL2' assumed values applied to 'FC1', and values 'FR2' are 477 applied to 'FC3'. 479 Assumed value constructs can appear anywhere in a conjunction, and 480 the additional rules below indicate how to process these into the 481 canonical form. 483 The '(.)' construct can appear at the left or right hand end of a 484 conjunction: 486 (& (.) FC (.) ) 488 It may not appear anywhere else in a conjunction. Additional 489 processing rules (below) show how these can be used to eliminate 490 assumed value constructs from a conjunction, thus reducing it to a 491 simple predicate form. 493 3.5 Additional reduction rules 495 The aim of these rules is to allow assumed values to propagate 496 along the message transfer chain until either (a) it is determined 497 they are redundant, or (b) the assumed values are used as actual 498 feature constraints which can be evaluated in the normal way. 500 The following rules assume that all feature constraints are atomic; 501 i.e. they refer to a single feature tag. The next section contains 502 rules for canonicalization of complex predicates to a form with 503 just atomic feature constraints. 505 W3C Composite Capability/Preference Profiles 507 Note that if there are any assumed value constructs present in a 508 conjunction, re-ordering of the component constraints is allowed 509 only according to reordering rule below. 511 (a) Re-ordering of assumed value constraints: 512 (& ... (+FC1) FC2 ... ) ---> (& ... FC2 (+FC1) ... ) 513 (& ... FC1 (+FC2) ... ) ---> (& ... (+FC2) FC1 ... ) 514 (& ... (+FC1) (+FC2) ... ) ---> (& ... (+FC2) (+FC1) ... ) 515 ONLY IF: FC1 and FC2 reference different feature tags. 517 (b) Assumed value elimination: 518 (& ... FC1 (+FC2) FC3 ... ) ---> (& ... FC1 FC3 ... ) 519 ONLY IF: FC1, FC2 and FC3 reference the same feature tag, 521 Two extended forms of this rule allow multiple assumed values 522 to be eliminated: 523 (& ... FC1 ... (+FC2) FC3 ... ) ---> (& ... FC1 FC3 ... ) 524 (& ... FC1 (+FC2) ... FC3 ... ) ---> (& ... FC1 FC3 ... ) 525 ONLY IF: FC1, FC2 and FC3 reference the same feature tag, 527 (c) Default resolution: 528 (& (.) (+FC1) ... ) ---> (& (.) FC1 ... ) 529 (& ... (+FC1) (.) ) ---> (& ... FC1 (.) ) 530 ONLY IF: the conjunction does not contain any non-assumed 531 constraint referencing the same feature tag. 533 3.6 Extended canonicalization rules 535 The above reduction rules assume a canonical form of predicate 536 expressions. The canonicalization rules described for the 'conneg' 537 framework [3] must be extended to handle assumed value constructs. 539 The main goal of these additional rules is to push assumed values 540 "down" in the expression so that they are contained within all 541 disjunctions and conjunctions, and themselves contain only atomic 542 feature constraints. 544 (a) Separate default constructs: 545 (+ FC1 FC2 ... ) ---> (+FC1) (+FC2) ... 546 Following repeated application of this rule, all default 547 constructs contain just one feature predicate expression 548 (conjunction, disjunction or atomic). 550 (b) Move assumed value into conjunction: 551 (+ (& FC1 FC2 ... ) ) ---> (& (+FC1) (+FC2) ... ) 553 W3C Composite Capability/Preference Profiles 555 (c) Move assumed value into disjunction: 556 (+ (| FC1 FC2 ... ) ) ---> (| (+FC1) (+FC2) ... ) 558 (d) Flatten assumed value nests: 559 (+ ... (+FC1) ... ) ---> (+ ... FC1 ... ) 561 3.7 Examples 563 Expressions in the following examples assume left is "upstream" in 564 the message flow. 566 3.7.1 The "font" problem 568 Sender/data resource description: 570 (& (Font-1=TRUE) (Font-2=TRUE) 571 (+ (Font-1=FALSE) (Font-2=FALSE) ) ) 573 Recipient description: 575 (& (Font-1=TRUE) (Font-3=TRUE) ) 577 Combine these to obtain the full transmission path description 578 (recall that feature sets are matched by combining them with 579 '(&...)', and left is upstream in the transmission path): 581 (& (.) 582 (& (Font-1=TRUE) (Font-2=TRUE) // Sender.. 583 (+ (Font-1=FALSE) (Font-2=FALSE) ) ) 584 (& (Font-1=TRUE) (Font-3=TRUE) ) // Receiver.. 585 (.) ) 587 What follows is a sequence of rewriting rule applications that show 588 how this expression is processed to eliminate the (+...) constructs 589 and, in the process, the receiver's lack of support for 'Font-2' 590 causes the feature set match to fail. 592 --> [expand (+...)] 594 (& (.) 595 (& (Font-1=TRUE) (Font-2=TRUE) 596 (+ (Font-1=FALSE) ) (+ (Font-2=FALSE) ) ) 597 (& (Font-1-TRUE) (Font-2=TRUE) (Font-4=TRUE) ) 598 (.) ) 600 W3C Composite Capability/Preference Profiles 602 --> [flatten (&...(&...)...)] 604 (& (.) 605 (Font-1=TRUE) (Font-2=TRUE) 606 (+ (Font-1=FALSE) ) (+ (Font-2=FALSE) ) 607 (Font-1-TRUE) (Font-2=TRUE) (Font-4=TRUE) ) 608 (.) ) 610 --> [collect features, being careful to preserve ordering of 611 constraints with the same feature tag]: 613 (& (.) 614 (Font-1=TRUE) (+ (Font-1=FALSE) ) (Font-1=TRUE) 615 (Font-2=TRUE) (+ (Font-2=FALSE) ) 616 (Font-3=TRUE) ) 617 (.) ) 619 --> [eliminate un-needed default] 621 (& (.) 622 (Font-1=TRUE) (Font-1=TRUE) 623 (Font-2=TRUE) (+ (Font-2=FALSE) ) 624 (Font-3=TRUE) ) 625 (.) ) 627 --> [Resolve non-eliminated default: move to end, then use (+...) 628 (.) rewriting rule] 630 (& (.) 631 (Font-1=TRUE) (Font-1=TRUE) 632 (Font-2=TRUE) (Font-2=FALSE) 633 (Font-3=TRUE) ) 634 (.) ) 636 --> [Combine (&...) with same tag: 638 (& (.) 639 (Font-1=TRUE) 640 (FALSE) 641 (Font-3=TRUE) 642 (.) ) 644 Which leaves a conjunction containing FALSE, indicating that there 645 is no feature set matching all the capability constraints. 647 Note that the receiver's (Font-3=TRUE) was not eliminated because 648 it did not use the (+...) mechanism to say, in effect, that the 649 sender must use it. 651 W3C Composite Capability/Preference Profiles 653 3.7.2 Resolution dependent font 655 A slightly more complex example might be: 657 Sender/data resource description: 659 (| (& (dpi>=100) (Font-simple=TRUE) (+ (Font-simple=FALSE) ) ) 660 (& (dpi>=300) (Font-fancy=TRUE) (+ (Font-fancy=FALSE) ) ) ) 662 This would match the recipient capabilities: 663 (& (dpi=100) (Font-simple=TRUE) ) 664 or 665 (& (dpi=300) (Font-simple=TRUE) (Font-fancy=TRUE) ) 667 But it would not match the recipient capability: 668 (& (dpi=100) (Font-fancy=TRUE) ) 670 3.7.3 Combining default values 672 Finally, note there is a possibility to use nested '(& ... (.) )' 673 constructs for defaults which are restricted to a particular entity 674 in the transmission chain, for example (which is the type of 675 scenario discussed in the CC/PP draft): 677 (& 678 (& (+ ) 679 (.) ) ... ) 681 Using the "indirect references" example from the CC/PP memo [5], we 682 could construct a framework like this: 684 (& (& (Hardware-defaults) (+ (Hardware-defaults) ) 685 (Hardware-platform) (.) ) 686 (& (Software-defaults) (+ (Software-defaults) ) 687 (Software-platform) (.) ) 688 (EpocEmail) 689 (EpocCalendar) 690 (UserPreferences) 691 (.) ) 693 W3C Composite Capability/Preference Profiles 695 where: 697 (Hardware-defaults) :- 698 (& (Vendor="Nokia") 699 (Model="2160") 700 (Type="PDA") 701 (ScreenSize="800x600x24") 702 (CPU="PPC") 703 (Keyboard="Yes") 704 (Speaker="Yes") 705 (Memory="16Mb) ) 707 (Hardware-platform) :- 708 (Memory="32Mb") 710 (Software-defaults) :- 711 (& (OS="EPOC1.0") 712 (HTMLVersion="4.0") 713 (JavaScriptVersion="4.0") 714 (WAPVersion="1.0") 715 (WMLScriptVersion="1.0") ) 717 (Software-platform) :- 718 (& (Sound="Off") 719 (Images="Off") ) 721 (EpocEmail) :- 722 (& (Version="EpocEmail1.0") 723 (HTMLVersion="4.0") ) 725 (EpocCalendar) :- 726 (& (Version="EpocCalendar1.0") 727 (HTMLVersion="4.0") ) 729 end 731 The repetition of '(Hardware-defaults)' and '(Software-defaults)' 732 is needed to force application of the default value through 733 reduction rule 2.5(b), "Assumed value elimination". This is, 734 however, a little clumsy and suggests introduction of a new 735 construct and reduction rule. 737 The new construct, a default end of chain indicator, is expressed 738 as: 740 (*) 742 and its purpose is to force elimination of any unused default 743 value, using the following rule. 745 W3C Composite Capability/Preference Profiles 747 Default value elimination: 748 (& (*) ... (+FC1) FC2 ... ) ---> (& (*) ... FC2 ... ) 749 ONLY IF: FC1 and FC2 reference the same feature tag. 751 Thus, the above feature set expression could be re-written as: 753 (& (& (*) (+ (Hardware-defaults) ) (Hardware-platform) (.) ) 754 (& (*) (+ (Software-defaults) ) (Software-platform) (.) ) 755 (EpocEmail) 756 (EpocCalendar) 757 (UserPreferences) 758 (.) ) 760 where 762 (etc.) 764 4. XML representation of capability descriptions 766 The 'conneg' feature set description framework is well-suited to 767 being expressed in XML. The previously given example: 769 (| (& (dpi>=100) (Font-simple=TRUE) (+ (Font-simple=FALSE) ) ) 770 (& (dpi>=300) (Font-fancy=TRUE) (+ (Font-fancy=FALSE) ) ) ) 772 might be represented (in conjunction with an appropriate XML tag 773 definitions) using something like the following XML: 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 792 [I am not expert in XML, and the above is almost 793 certainly flawed. But I do believe that it is possible 794 to use XML broadly in this way, and would welcome further 795 comment from any XML cognoscenti.] 797 W3C Composite Capability/Preference Profiles 799 5. Mapping between RDF and media features 801 The following extract is from the RDF Model and Syntax 802 specification: 804 "This document introduces a model for representing RDF metadata 805 as well as a syntax for encoding and transporting this metadata 806 in a manner that maximizes the interoperability of independently 807 developed web servers and clients. The syntax presented here 808 uses the Extensible Markup Language [XML]: one of the goals of 809 RDF is to make it possible to specify semantics for data based on 810 XML in a standardized, interoperable manner. [...] It is also 811 important to understand that this XML syntax is only one possible 812 syntax for RDF, and that alternate ways to represent the same RDF 813 data model may emerge." 815 It is interesting to note that the 'conneg' feature expression 816 framework shares with the RDF framework this clear intent to 817 separate the data model from its representative syntax. 819 In this section, the RDF data model is explored and related to the 820 'conneg' feature registration namespace. The RDF data model is 821 very rich compared with that used by 'conneg', so should easily be 822 capable of representing the concepts used. 824 IETF 'conneg' deals with the following value-sets: 826 Feature-tag ::= Token 827 Feature-value ::= Integer 828 | Rational 829 | Boolean 830 | Token 831 | String 832 Feature-collection ::= MAP OF Feature-tag TO Feature-value 833 Feature-set ::= SET OF Feature-collection 835 (A MAP is a mapping from some domain to some range, which 836 associates exactly one range value with each domain value.) 838 Further, a "Feature-set" is described by a collection of feature 839 value assertions: 841 Feature-assertion ::= ( "&", SEQUENCE OF Feature-assertion ) 842 | ( "|", SEQUENCE OF Feature-assertion ) 843 | ( "!", Feature-assertion ) 844 | Atomic-assertion 845 Atomic-assertion ::= ( Relation, Feature-tag, Feature-value ) 846 Relation ::= "EQ" | "GE" | "LE" 848 W3C Composite Capability/Preference Profiles 850 A "Feature-collection" can be represented directly as an RDF 851 resource, where each feature tag/value pair is an RDF property name 852 and string value. 854 A "Feature-set" does not have such an obvious RDF representation. 855 However, the characterization of RDF as having "predicates" that 856 associate some "object value" with a "resource" suggests a 857 representation. Atomic feature value assertions are also 858 predicates that relate a feature tag with a value. 860 Thus, to fit the RDF model, we can model a feature as an RDF 861 "resource", with a tag and one or more value assertions. The 862 following example models a simple description of a VGA display, 863 which using 'conneg' notation would be: 865 (& (pix-x<=640) (pix-y<=480) (color<=256) ) 867 This display might be described by the following RDF: 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 888 In this example, the multiple feature values within a "Feature- 889 assertion" are taken to be implicitly ANDed together. Other 890 representations are possible. All 'conneg'-related tags are 891 assumed to be defined in a 'conneg' namespace. 893 W3C Composite Capability/Preference Profiles 895 To take a slightly more complex 'conneg' example: 897 (| (& (pix-x<=800) (pix-y<=600) (color<=256) ) 898 (& (pix-x<=640) (pix-y<=480) (color<=65536) ) ) 900 This might be represented as: 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 943 [I am not expert in RDF, and fully expect there are ways 944 in which the above might to improved. At this stage, the 946 W3C Composite Capability/Preference Profiles 948 key ideas I wish to test are: (a) that feature 949 collections can be modelled directly as RDF resource 950 descriptions, (b) that feature sets must be modelled as 951 resources in their own right, and (c) that atomic value 952 assertions should use the RDF "predicate" form to 953 indicate the kind of constraint that is being applied.] 955 5.1 An alternative RDF representation 957 [This is an alternative, and more complete, RDF 958 representation suggested by Franklin Reynolds of Nokia; 959 this takes an approach of encoding all the CONNEG-related 960 information as XML element data, rather than using 961 element names and parameters to capture some of the 962 structure.] 964 It is worth noting that XML/RDF is not really intended to be 965 written or read by humans. It is intended as a machine readable 966 format for metadata. One could imagine an CONNEG algebra to 967 XML/RDF compiler. 969 An XML/RDF parser has been published by W3C [9], and has been used 970 to test some ideas for representing CONNEG expressions in RDF. 972 XML/RDF provides a rich knowledge representation framework, but it 973 does *not* currently support numeric data types, numeric relations 974 or a full complement of logical relations. One approach is to 975 provide a CONNEG vocabulary that defines terms for those relations. 977 Consider the following example CONNEG feature list: 979 (& (pix-x<=640) 980 (pix-y<=480) 981 (color<=256) ) 983 A reasonable XML/RDF translation is: 985 987 992 994 995 AND 996 997 640 999 W3C Composite Capability/Preference Profiles 1001 LE 1002 1003 1004 480 1005 LE 1006 1007 1008 256 1009 LE 1010 1011 1013 1014 1016 This encoding has some nice properties: 1018 o It separates the CONNEG vocabulary that defines relations from 1019 the feature vocabulary. This is important because support for 1020 multiple feature vocabularies is required. 1022 o "feature-description" and "feature" statements nest in a 1023 relatively natural and human readable manner. 1025 o The W3C parser finds this version acceptable. 1027 6. Conclusions 1029 One of the goals of these proposals is to allow the 'conneg' work 1030 to integrate effectively with ongoing work that is being undertaken 1031 by W3C. 1033 Some constructs and handling rules have been suggested that I 1034 believe capture the required concepts embodied in the W3C work, and 1035 provide a way to manipulate them consistently within the 'conneg' 1036 framework. 1038 7. Security considerations 1040 In general, these proposals are not believed to raise any security 1041 considerations not already inherent in the 'conneg', 'RDF' or 1042 'CC/PP' work. 1044 One area can be seen where further consideration of security 1045 concerns might be required. The use of URLs, per CC/PP, to locate 1046 'conneg' feature set descriptions might open up some exposure to 1047 privacy or denial of service attacks on the referenced description. 1049 W3C Composite Capability/Preference Profiles 1051 8. Full copyright statement 1053 Copyright (C) The Internet Society 1999. All Rights Reserved. 1055 This document and translations of it may be copied and furnished to 1056 others, and derivative works that comment on or otherwise explain 1057 it or assist in its implementation may be prepared, copied, 1058 published and distributed, in whole or in part, without restriction 1059 of any kind, provided that the above copyright notice and this 1060 paragraph are included on all such copies and derivative works. 1061 However, this document itself may not be modified in any way, such 1062 as by removing the copyright notice or references to the Internet 1063 Society or other Internet organizations, except as needed for the 1064 purpose of developing Internet standards in which case the 1065 procedures for copyrights defined in the Internet Standards process 1066 must be followed, or as required to translate it into languages 1067 other than English. 1069 The limited permissions granted above are perpetual and will not be 1070 revoked by the Internet Society or its successors or assigns. 1072 This document and the information contained herein is provided on 1073 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1074 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1075 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1076 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1077 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1079 9. Acknowledgements 1081 The complete, tested example of RDF representation for 'conneg' 1082 feature expressions (section 5.1), along with many other useful 1083 thoughts, was provided by Franklin Reynolds of Nokia. 1085 10. References 1087 [1] "Requirements for protocol-independent content negotiation" 1088 G. Klyne, Integralis Ltd. 1089 Internet draft: 1090 Work in progress, March 1998. 1091 [[[Last-called for informational RFC: replace RFC reference]]] 1093 [2] RFC 2506, "Media Feature Tag Registration Procedure" 1094 Koen Holtman, TUE 1095 Andrew Mutz, Hewlett-Packard 1096 Ted Hardie, NASA 1097 March 1999. 1099 W3C Composite Capability/Preference Profiles 1101 [3] RFC 2533, "A syntax for describing media feature sets" 1102 Graham Klyne, 5GM/Content Technologies 1103 March 1999. 1105 [4] RFC 2534, "Media Features for Display, Print, and Fax" 1106 Larry Masinter, Xerox PARC 1107 Koen Holtman, TUE 1108 Andrew Mutz, Hewlett-Packard 1109 Dan Wing, Cisco Systems 1110 March 1999. 1112 [5] "Composite Capability/Preference Profiles (CC/PP): 1113 A user side framework for content negotiation" 1114 Franklin Reynolds, Nokia Research 1115 W3C Note 1116 November 1998 1118 [6] "Resource Description Framework (RDF) Model and Syntax 1119 Specification" 1120 Ora Lassila, Nokia Research Centre 1121 Ralph R Swick, World Wide Web Consortium 1122 W3C working draft: 1123 October 1998 1125 [7] "Resource Description Framework (RDF) Schema Specification" 1126 Dan Brickley, University of Bristol 1127 R. V. Guha, Netscape 1128 Andrew Layman, Microsoft 1129 W3C working draft: 1130 August 1998. 1132 [8] "Extensible Markup Language (XML) 1.0" 1133 Tim Bray, Textuality and Netscape 1134 Jean Paoli, Microsoft 1135 C. M. Sperberg-McQueen, University of Illinois at Chicago 1136 W3C Recommendation: 1137 February 1998. 1139 [9] XML/RDF parser 1140 1142 W3C Composite Capability/Preference Profiles 1144 11. Author's address 1146 Graham Klyne 1147 Content Technologies Ltd. 5th Generation Messaging Ltd. 1148 Forum 1 5 Watlington Street 1149 Station Road Nettlebed 1150 Theale Henley-on-Thames 1151 Reading, RG7 4RA RG9 5AB 1152 United Kingdom United Kingdom. 1154 Telephone: +44 118 930 1300 +44 1491 641 641 1156 Facsimile: +44 118 930 1301 +44 1491 641 611 1158 E-mail: GK@ACM.ORG 1160 Appendix A. Amendment history 1162 [[[Please remove this section on final publication]]] 1164 00a 19-Oct-1998 1165 Document initially created. 1167 00b 20-Oct-1998 1168 Added sections on tag-independent negotiation, XML syntax 1169 and RDF mapping. 1171 00c 31-Oct-1998 1172 Fixed up section numbers. 1174 01a 15-Dec-1998 1175 Minor editorial revisions for re-issue. Updated CC/PP 1176 reference to published W3C Note. 1178 02a 29-Jul-1999 1179 Add in alternative RDF example. Add reference to W3C RDF 1180 parser. Update references. Update copyright year. 1181 Update introductory boilerplate. Add disclaimer 1182 regarding the suitability of proposals in section 3. 1183 Used indented [...] paragraphs for author's commentary on 1184 the ideas in this memo. Various minor corrections.