idnits 2.17.1 draft-ietf-conneg-W3C-ccpp-01.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-ietf-conneg-W3C-ccpp-01', 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 249: '...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 (15 December 1998) is 9264 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 322 -- Looks like a reference, but probably isn't: 'S' on line 334 -- Looks like a reference, but probably isn't: 'R' on line 339 -- Looks like a reference, but probably isn't: 'U' on line 340 -- Looks like a reference, but probably isn't: 'XML' on line 822 == Unused Reference: '7' is defined on line 1076, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1083, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- 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' Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF media feature registration WG Graham Klyne 3 Internet draft Content Technologies/5GM 4 15 December 1998 5 Expires: June 1999 7 W3C Composite Capability/Preference Profiles 8 10 Status of this memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet-Drafts 20 as reference material or to cite them other than as ``work in 21 progress''. 23 To view the entire list of current Internet-Drafts, please check 24 the "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 26 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 27 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US 28 West Coast). 30 Copyright Notice 32 Copyright (C) 1998, The Internet Society 34 Abstract 36 This document suggests some possible areas for extending the IETF 37 'conneg' working group's capability description framework, 38 described in [2,3,4]. The suggested areas for extension have been 39 motivated by WWW Consortium (W3C) work on Composite 40 Capability/Preference Profiles (CCPP) [5] that parallels some 41 aspects of IETF 'conneg' work. 43 It is presented as a discussion document, with a view to maybe 44 integrating some of these ideas into ongoing 'conneg' work. 46 Internet draft 15 December 1998 47 W3C Composite Capability/Preference Profiles 49 Table of contents 51 1. Introduction.............................................2 52 1.1 Structure of this document ...........................3 53 1.2 Discussion of this document ..........................3 54 1.3 Amendment history ....................................3 55 2. Tag-independent content negotiation......................4 56 2.1 WWW resource transfer scenario .......................4 57 2.2 Conclusions ..........................................5 58 2.3 Consequences .........................................5 59 3. Assumed feature values...................................5 60 3.1 Unifying "required" and "default" values .............6 61 3.2 Message transmission model ...........................7 62 3.3. Problem summary .....................................8 63 3.4 Proposed extension to 'conneg' framework .............10 64 3.4.1 Assumed values construct.........................10 65 3.4.2 End of chain indicator...........................10 66 3.4.3 Extended form of conjunction.....................10 67 3.5 Additional reduction rules ...........................11 68 3.6 Extended canonicalization rules ......................12 69 3.7 Examples .............................................12 70 3.7.1 The "font" problem...............................12 71 3.7.2 Resolution dependent font........................14 72 3.7.3 Combining default values.........................15 73 4. XML representation of capability descriptions............17 74 5. Mapping between RDF and media features...................17 75 6. Conclusions..............................................21 76 7. Security considerations..................................21 77 8. Full copyright statement.................................22 78 9. Acknowledgements.........................................22 79 10. References..............................................22 80 11. Author's address........................................24 82 1. Introduction 84 This document suggests some possible areas for extending the IETF 85 'conneg' working group's capability description framework, 86 described in [2,3,4]. The suggested areas for extension have been 87 motivated by WWW Consortium (W3C) work on Composite 88 Capability/Preference Profiles (CCPP) [5] that parallels some 89 aspects of IETF 'conneg' work. 91 It is presented as a discussion document, with a view to maybe 92 integrating some of these ideas into ongoing 'conneg' work. 94 Internet draft 15 December 1998 95 W3C Composite Capability/Preference Profiles 97 1.1 Structure of this document 99 The main part of this draft addresses the following main areas: 101 Section 2 discusses tag-independent negotiation procedures, one of 102 the goals of the 'conneg' work, with particular reference to WWW 103 operations 105 Section 3 suggests a framework for describing "assumed" feature 106 values. 108 Section 4 suggests an approach to using XML to carry capability 109 information structured according to the 'conneg' framework. 111 Section 5 suggests an approach to mapping between RDF [6] and 112 'conneg' media feature registrations. 114 1.2 Discussion of this document 116 Discussion of this document should take place on the content 117 negotiation and media feature registration mailing list hosted by 118 the Internet Mail Consortium (IMC): 120 Please send comments regarding this document to: 122 ietf-medfree@imc.org 124 To subscribe to this list, send a message with the body 'subscribe' 125 to "ietf-medfree-request@imc.org". 127 To see what has gone on before you subscribed, please see the 128 mailing list archive at: 130 http://www.imc.org/ietf-medfree/ 132 1.3 Amendment history 134 00a 19-Oct-1998 135 Document initially created. 137 00b 20-Oct-1998 138 Added sections on tag-independent negotiation, XML syntax 139 and RDF mapping. 141 00c 31-Oct-1998 142 Fixed up section numbers. 144 01a 15-Dec-1998 145 Minor editorial revisions for re-issue. Updated CC/PP 146 reference to published W3C Note. 148 Internet draft 15 December 1998 149 W3C Composite Capability/Preference Profiles 151 2. Tag-independent content negotiation 153 One can imagine two extremes of content negotiation procedure: 155 o One in which the decisions about whether the features in a data 156 data resource match some set of capabilities are made in full 157 knowledge of the exact meaning of every feature and capability. 159 o The other, in which the matching decision is made without any 160 knowledge of the particular features concerned. 162 A practical procedure is likely to lie somewhere between these 163 extremes. The purpose of this section is to argue that a procedure 164 that minimizes the required knowledge of particular feature tags is 165 likely to be more useful than one which depends heavily upon such 166 knowledge. 168 This approach is described here as "tag-independent negotiation": 169 negotiation that can proceed without specific knowledge of the tags 170 used to describe various media features of the participating 171 entities. 173 2.1 WWW resource transfer scenario 175 Consider a WWW transaction scenario that involves content 176 negotiation: 178 Resource-1 ->- +--------+ +--------+ ->- Plugin-1 179 \ | Origin | | | / 180 Resource-2 ->----| Server |--<--->--| Client |---->- Plugin-2 181 / | | | | \ 182 Resource-3 ->- +--------+ +--------+ ->- Plugin-3 184 In this scenario, the active negotiation takes place between the 185 origin server and the receiving client. 187 The resources available to the origin server are possibly passive 188 data files, with no opportunity for interaction between data 189 resource and server. 191 The plugins available to the browser may well be dispatched as 192 separate programs, with limited opportunity for ongoing interaction 193 between the plugin and the client. Also, there may be a high 194 overhead associated with activating a plugin, so it is not 195 desirable to activate one or more plugins simply to determine 196 whether a data resource is acceptable to that plugin. 198 Internet draft 15 December 1998 199 W3C Composite Capability/Preference Profiles 201 2.2 Conclusions 203 In an environment like WWW where new and changed features are 204 deployed on a regular basis, it is clearly not desirable that 205 detailed knowledge be hard-coded into either the origin server or 206 the client software. This would rather defeat the idea of 207 extending functionality through plugins and data resource 208 abstractions. 210 Thus, to avoid early obsolesence of servers and clients, we seek a 211 negotiation framwork that permits a data resource to describe 212 itself to the origin server, a plugin to describe itself to a 213 browser, and allows the server and browser to conduct negotiations 214 without any further knowledge. 216 There are doubtless some cases where the degree of negotiating 217 flexibility indicated here is not essential: "Internet appliances" 218 and other dedicated devices spring to mind. But even for such 219 devices, it can be argued that the flexibility of tag-independent 220 negotiation will simplify their configuration. 222 2.3 Consequences 224 Some consequences of the conclusion just outlined are: 226 o The capability description should be able to describe 227 dependencies between content features in such a way that they can 228 be handled by the negotiation protocol. 230 o The vocabulary used to describe content features should avoid 231 having multiple ways to describe the same capabilities. 233 3. Assumed feature values 235 The W3C CC/PP [5] work embodies a concept that is not currently 236 supported in the IETF 'conneg' framework [3]; namely the 237 construction of a set of capability and preference values from a 238 number of separate sources (e.g. hardware platform defaults, 239 software platform defaults, user preferences). Also, there is a 240 desire to have a compact way to represent a small number of 241 differences from some baseline set of capabilities. What is not 242 covered by this work, that the IETF 'conneg' work can supply, is a 243 framework for actually combining the various information sources. 245 Internet draft 15 December 1998 246 W3C Composite Capability/Preference Profiles 248 Also, there is an identified capability gap in the IETF 'conneg' 249 work: the ability to indicate that some particular feature MUST be 250 supplied by a communicating counterparty. This has been 251 charactirized as the "font problem": how can a sender require that 252 some particular font is supported by a recipient? Currently the 253 'conneg' framework operates to effectively ignore a request for an 254 unknown font, or other unrecognized feature. 256 3.1 Unifying "required" and "default" values 258 The two situations we wish to describe are: 260 (A) "required" values: given two feature set descriptions, the 261 feature set match is to fail if one of them does not define a 262 value for a feature tag tested by the other. This is 263 exemplified by the "fonts" problem: if a data resource uses 264 some font indicated by the feature tag "Font-obscure", and the 265 receiver does not explicitly declare an ability to deal with 266 that font, then we should assume that the feature sets do not 267 match. As currently defined, the 'conneg' algebraic framework 268 [3] would allow a feature set match in the absence of an 269 explicit denial of such support. 271 (B) "override" and "default" values: given two feature set 272 descriptions that contain different constraints involving some 273 feature tag, the constraint from one of the feature sets is to 274 override the constraint in the other. This is exemplified by 275 the scenario outlined in the W3 CC/PP draft [5], in which a 276 hardware manufacturer may supply a default profile for a 277 device which can then be overridden by local user preferences. 279 A mechanism that can address both of these requirements is one 280 which allows a feature set description to indicate "assumed" values 281 for a given feature. 283 Case (A): 284 A data resource requires a given font to be available, and its 285 feature set description provides "assumed" values for the font 286 availability that are used only if the recipient does not 287 itself reference that feature. Thus, if the data resource 288 indicates: 289 (Font-obscure=TRUE) 290 Assume: (Font-obscure=FALSE) 291 and the recipient does not supply a constraint for 'Font- 292 obscure', then the assumed value is used to force a feature 293 set match failure. 295 Internet draft 15 December 1998 296 W3C Composite Capability/Preference Profiles 298 Case (B): 299 A hardware platform capability description consists entirely 300 of assumed feature values. When combined with user 301 preferences, these provide values for those features that are 302 not mentioned in the user preferences. 304 The ideas here can be extended to deal with combinations of more 305 than two feature sets. 307 The assumed value idea breaks a number of assumptions of the 308 current 'conneg' algebraic model [3], which is based pretty much on 309 simplified predicate algebra. The sections that follow reconcile 310 this idea with the existing framework. 312 3.2 Message transmission model 314 The following discussion is based on a message transmission model 315 that assumes multiple feature set constraints. The following 316 example is from [1], section 3.1: 318 The life of a data resource may be viewed as: 319 (C) (T) (F) 320 [A]-->--[S]-->--[R]-->--[U] 321 where: 322 [A] = author of document 323 (C) = original document content 324 [S] = message sending system 325 (T) = transmitted data file (representation of (C)) 326 [R] = receiving system 327 (F) = formatted (rendered) document data (presentation of (C)) 328 [U] = user or consumer of a document 330 Here, it is [S] and [R] who exchange negotiation metadata to 331 decide the form of (T), so these elements are the focus of our 332 attention. 334 Negotiation metadata provided by [S] would take account of 335 available document content (C) (e.g. availability of resource 336 variants) as well as its own possible ability to offer that 337 content in variety of formats. 339 Negotiation metadata provided by [R] would similarly take account 340 of the needs and preferences of its user [U] as well as its own 341 capabilities to process and render received data. 343 Internet draft 15 December 1998 344 W3C Composite Capability/Preference Profiles 346 This example suggests a generic framework within which negotiation 347 is conducted: a chain of entities, each of which may impose some 348 constraint(s) on the message features that can usefully be 349 transferred: 351 [.]-->--[E1]-->--[E2]-->-- ... -->--[En]-->--[.] 353 '[.]' are used here indicate specific begin and end points of the 354 chain, and '[Ei]' are entities that may impose feaure constraints. 355 If the feature constraint predicate associated with '[Ei]' is 356 'FCi', then the composite feature constraint for the entire chain 357 is the conjunction of the individual constraints: 359 (& FC1 FC2 ... FCn ) 361 using the notation of [3]. 363 3.3. Problem summary 365 The 'conneg' algebraic framework depends on combining feature sets 366 by set intersection (i.e. a logical AND of the predicates that 367 describe feature sets). 369 For the purposes of this discussion, all feature set expressions 370 are reduced to disjunctive normal form: thus, every feature set is 371 described as a disjunction (union) of one or more subsets, each of 372 which is described by a conjunction of atomic feature comaprisons; 373 e.g. 375 (| (& (size=s1) (resolution=r1) (color=c1) ) 376 (& (size=s2) (resolution=r2) (grey=g2) ) ) 378 This is without loss of generality: the combining framework 379 description [3] shows how more complex expressions can be reduced 380 to this canonical form. 382 Now consider the following observations: 384 (1) all atomic feature comparisons have the form '(ftag relop 385 fvalue)', where 'ftag' is a feature tag that uniquely 386 identifies a feature, 'relop' is a comparison operator and 387 'fvalue' is a particular value associated with the feature 388 tag. 390 (2) The conjunction operator is symmetric: 392 (& A B) == (& B A) 394 Internet draft 15 December 1998 395 W3C Composite Capability/Preference Profiles 397 (3) The conjunction operator is associative: 399 (& A (& B C) ) == (& (& A B) C) 401 This property is important because it means that the feature 402 sets are not required to be combined in any specific order. 403 This point is raised in the CC/PP memo [5], and this is a 404 property that should be preserved. 406 (4) The assumed value mechanism outlined above is inherrently 407 anti-symmetric. One of the feature sets used takes precedence 408 over the other: 410 (Assume: A B) != (Assume: B A) 412 (5) The assumed value mechanism, by its very nature, is sensitive 413 to the particular feature tags used. 415 (6) Assumed values should be used only when an explicit constraint 416 for a feature tag cannot be found. For example, if a data 417 resource has the requirement: 419 (Font-obscure=TRUE) 421 and also indicates an assumed value: 423 Assume: (Font-obscure=FALSE) 425 The assumed value must be ignored if the recipient asserts: 427 (Font-obscure=TRUE) 429 This requirement is captured without imposing an order of 430 evaluation on the feature set matching process (because such 431 imposition is considered to make the entire process more 432 complex and error-prone). 434 (7) A feature set constraint must be reduced to the predicate form 435 currently defined by the 'conneg' framework [3] (i.e. all 436 default values must be eliminated) before a feature collection 437 (i.e. some specific feature values) can be tested with it. 439 Internet draft 15 December 1998 440 W3C Composite Capability/Preference Profiles 442 3.4 Proposed extension to 'conneg' framework 444 Two extensions to the 'conneg' algebraic framework are proposed: 446 (a) a "assumed values" construct 448 (b) an "end-of-chain" indicator 450 and revision of the conjunction '(&...)' and other processing rules 451 to take account of these new constructs. 453 3.4.1 Assumed values construct 455 This is expressed as: 457 (+ FC ) 459 where 'FC' is a list of one or more feature constraint expressions. 460 For an expression in the canonical disjunctive normal form, each is 461 an atomic feature value constraint (i.e. contains a single feature 462 comparison). 464 3.4.2 End of chain indicator 466 This is expressed as: 468 (.) 470 3.4.3 Extended form of conjunction 472 The canonical form of a conjunction is extended to allow: 474 (& ... (+ FL) FC (+ FR) ... ) 476 That is, it contains separate, optional assumed value constructs to 477 the left- and right- of any expression in the conjunction. 478 Referring to the message transmission chain model, these correspond 479 to assumed values that are applied "upstream" and "downstream" 480 along the chain. For example, when feature sets along a chain are 481 combined: 483 (& FC1 (& (+ FL2) FC2 (+FR2) ) FC3 ) 485 the 'FL2' assumed values applied to 'FC1', and values 'FR2' are 486 applied to 'FC3'. 488 Assumed value constructs can appear anywhere in a conjunction, and 489 the additional rules below indicate how to process these into the 490 canonical form. 492 Internet draft 15 December 1998 493 W3C Composite Capability/Preference Profiles 495 The '(.)' construct can appear at the left or right hand end of a 496 conjunction: 498 (& (.) FC (.) ) 500 It may not appear anywhere else in a conjunction. Additional 501 processing rules (below) show how these can be used to eliminate 502 assumed value constructs from a conjunction, thus reducing it to a 503 simple predicate form. 505 3.5 Additional reduction rules 507 The aim of these rules is to allow assumed values to propagate 508 along the message transfer chain until either (a) it is determined 509 they are redundant, or (b) the assumed values are used as actual 510 feature constraints which can be evaluated in the normal way. 512 The following rules assume that all feature constraints are atomic; 513 i.e. they refer to a single feature tag. The next section contains 514 rules for canonicalization of complex predicates to a form with 515 just atomic feature constraints. 517 Note that if there are any assumed value constructs present in a 518 conjunction, re-ordering of the component constraints is allowed 519 only according to reordering rule below. 521 (a) Re-ordering of assumed value constraints: 522 (& ... (+FC1) FC2 ... ) ---> (& ... FC2 (+FC1) ... ) 523 (& ... FC1 (+FC2) ... ) ---> (& ... (+FC2) FC1 ... ) 524 (& ... (+FC1) (+FC2) ... ) ---> (& ... (+FC2) (+FC1) ... ) 525 ONLY IF: FC1 and FC2 reference different feature tags. 527 (b) Assumed value elimination: 528 (& ... FC1 (+FC2) FC3 ... ) ---> (& ... FC1 FC3 ... ) 529 ONLY IF: FC1, FC2 and FC3 reference the same feature tag, 531 Two extended forms of this rule allow multiple assumed values 532 to be eliminated: 533 (& ... FC1 ... (+FC2) FC3 ... ) ---> (& ... FC1 FC3 ... ) 534 (& ... FC1 (+FC2) ... FC3 ... ) ---> (& ... FC1 FC3 ... ) 535 ONLY IF: FC1, FC2 and FC3 reference the same feature tag, 537 (c) Default resolution: 538 (& (.) (+FC1) ... ) ---> (& FC1 ... ) 539 (& ... (+FC1) (.) ) ---> (& ... FC1 ) 541 Internet draft 15 December 1998 542 W3C Composite Capability/Preference Profiles 544 3.6 Extended canonicalization rules 546 The above reduction rules assume a canonical form of predicate 547 expressions. The canonicalization rules described for the 'conneg' 548 framework [3] must be extended to handle assumed value constructs. 550 The main goal of these additional rules is to push assumed values 551 "down" in the expression so that they are contained within all 552 disjunctions and conjunctions, and themselves contain only atomic 553 feature constraints. 555 (a) Separate default constructs: 556 (+ FC1 FC2 ... ) ---> (+FC1) (+FC2) ... 557 Following repeated application of this rule, all default 558 constructs contain just one feature predicate expression 559 (conjunction, disjunction or atomic). 561 (b) Move assumed value into conjunction: 562 (+ (& FC1 FC2 ... ) ) ---> (& (+FC1) (+FC2) ... ) 564 (c) Move assumed value into disjunction: 565 (+ (| FC1 FC2 ... ) ) ---> (| (+FC1) (+FC2) ... ) 567 (d) Flatten assumed value nests: 568 (+ ... (+FC1) ... ) ---> (+ ... FC1 ... ) 570 3.7 Examples 572 Expressions in the following examples assume left is "upstream" in 573 the message flow. 575 3.7.1 The "font" problem 577 Sender/data resource description: 579 (& (Font-1=TRUE) (Font-2=TRUE) 580 (+ (Font-1=FALSE) (Font-2=FALSE) ) ) 582 Recipient description: 584 (& (Font-1=TRUE) (Font-3=TRUE) ) 586 Internet draft 15 December 1998 587 W3C Composite Capability/Preference Profiles 589 Combine these to obtain the full transmission path description 590 (recall that feature sets are matched by combining them with 591 '(&...)', and left is upstream in the transmission path): 593 (& (.) 594 (& (Font-1=TRUE) (Font-2=TRUE) // Sender.. 595 (+ (Font-1=FALSE) (Font-2=FALSE) ) ) 596 (& (Font-1=TRUE) (Font-3=TRUE) ) // Receiver.. 597 (.) ) 599 What follows is a sequence of rewriting rule applications that show 600 how this expression is processed to eliminate the (+...) constructs 601 and, in the process, the receiver's lack of support for 'Font-2' 602 causes the feature set match to fail. 604 --> [expand (+...)] 606 (& (.) 607 (& (Font-1=TRUE) (Font-2=TRUE) 608 (+ (Font-1=FALSE) ) (+ (Font-2=FALSE) ) ) 609 (& (Font-1-TRUE) (Font-2=TRUE) (Font-4=TRUE) ) 610 (.) ) 612 --> [flatten (&...(&...)...)] 614 (& (.) 615 (Font-1=TRUE) (Font-2=TRUE) 616 (+ (Font-1=FALSE) ) (+ (Font-2=FALSE) ) 617 (Font-1-TRUE) (Font-2=TRUE) (Font-4=TRUE) ) 618 (.) ) 620 --> [collect features, being careful to preserve ordering of 621 constraints with the same feature tag]: 623 (& (.) 624 (Font-1=TRUE) (+ (Font-1=FALSE) ) (Font-1=TRUE) 625 (Font-2=TRUE) (+ (Font-2=FALSE) ) 626 (Font-3=TRUE) ) 627 (& (.) 629 --> [eliminate un-needed default] 631 (& (.) 632 (Font-1=TRUE) (Font-1=TRUE) 633 (Font-2=TRUE) (+ (Font-2=FALSE) ) 634 (Font-3=TRUE) ) 635 (& (.) 637 Internet draft 15 December 1998 638 W3C Composite Capability/Preference Profiles 640 --> [Resolve non-eliminated default: move to end, then use (+...) 641 (.) rewriting rule] 643 (& (.) 644 (Font-1=TRUE) (Font-1=TRUE) 645 (Font-2=TRUE) (Font-2=FALSE) 646 (Font-3=TRUE) ) 647 (& (.) 649 --> [Combine (&...) with same tag: 651 (& (.) 652 (Font-1=TRUE) 653 (FALSE) 654 (Font-3=TRUE) 655 (.) ) 657 Which leaves a conjunction containing FALSE, indicating that there 658 is no feature set matching all the capability constraints. 660 Note that the receiver's (Font-3=TRUE) was not eliminated because 661 it did not use the (+...) mechanism to say, in effect, that the 662 sender must use it. 664 3.7.2 Resolution dependent font 666 A slightly more complex example might be: 668 Sender/data resource description: 670 (| (& (dpi>=100) (Font-simple=TRUE) (+ (Font-simple=FALSE) ) ) 671 (& (dpi>=300) (Font-fancy=TRUE) (+ (Font-fancy=FALSE) ) ) ) 673 This would match the recipient capalities: 674 (& (dpi=100) (Font-simple=TRUE) ) 675 or 676 (& (dpi=300) (Font-simple=TRUE) (Font-fancy=TRUE) ) 678 But it would not match the recipient capability: 679 (& (dpi=100) (Font-fancy=TRUE) ) 681 Internet draft 15 December 1998 682 W3C Composite Capability/Preference Profiles 684 3.7.3 Combining default values 686 Finally, note there is a possibility to use nested '(& ... (.) )' 687 constructs for defaults which are restricted to a particular entity 688 in the transmission chain, for example (which is the type of 689 scenario discussed in the CC/PP draft): 691 (& 692 (& (+ ) 693 (.) ) ... ) 695 Using the "indirect references" example from the CC/PP memo [5], we 696 could construct a framework like this: 698 (& (& (Hardware-defaults) (+ (Hardware-defaults) ) 699 (Hardware-platform) (.) ) 700 (& (Software-defaults) (+ (Software-defaults) ) 701 (Software-platform) (.) ) 702 (EpocEmail) 703 (EpocCalendar) 704 (UserPreferences) 705 (.) ) 707 where 709 (Hardware-defaults) :- 710 (& (Vendor="Nokia") 711 (Model="2160") 712 (Type="PDA") 713 (ScreenSize="800x600x24") 714 (CPU="PPC") 715 (Keyboard="Yes") 716 (Speaker="Yes") 717 (Memory="16Mb) ) 719 (Hardware-platform) :- 720 (Memory="32Mb") 722 (Software-defaults) :- 723 (& (OS="EPOC1.0") 724 (HTMLVersion="4.0") 725 (JavaScriptVersion="4.0") 726 (WAPVersion="1.0") 727 (WMLScriptVersion="1.0") ) 729 (Software-platform) :- 730 (& (Sound="Off") 731 (Images="Off") ) 733 Internet draft 15 December 1998 734 W3C Composite Capability/Preference Profiles 736 (EpocEmail) :- 737 (& (Version="EpocEmail1.0") 738 (HTMLVersion="4.0") ) 740 (EpocCalendar) :- 741 (& (Version="EpocCalendar1.0") 742 (HTMLVersion="4.0") ) 744 end 746 The repetition of '(Hardware-defaults)' and '(Software-defaults)' 747 is needed to force application of the default value through 748 reduction rule 2.5(b), "Assumed value elimination". This is, 749 however, a little clumsy and suggests introduction of a new 750 construct and reduction rule. 752 The new construct, a default end of chain indicator, is expressed 753 as: 755 (*) 757 and its purpose is to force elimination of any unused default 758 value, using the following rule 760 Default value elimination: 761 (& (*) ... (+FC1) FC2 ... ) ---> (& (*) ... FC2 ... ) 762 ONLY IF: FC1 and FC2 reference the same feature tag. 764 Thus, the above feature set expression could be re-written as: 766 (& (& (*) (+ (Hardware-defaults) ) (Hardware-platform) (.) ) 767 (& (*) (+ (Software-defaults) ) (Software-platform) (.) ) 768 (EpocEmail) 769 (EpocCalendar) 770 (UserPreferences) 771 (.) ) 773 where 775 (etc.) 777 Internet draft 15 December 1998 778 W3C Composite Capability/Preference Profiles 780 4. XML representation of capability descriptions 782 The 'conneg' feature set description framework is well-suited to 783 being expressed in XML. The previously given example: 785 (| (& (dpi>=100) (Font-simple=TRUE) (+ (Font-simple=FALSE) ) ) 786 (& (dpi>=300) (Font-fancy=TRUE) (+ (Font-fancy=FALSE) ) ) ) 788 might be represented (in conjunction with an appropriate XML tag 789 definitions) using something like the following XML: 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 808 [[[I am not expert in XML, and the above is almost certainly 809 flawed. But I do believe that it is possble to use XML broadly in 810 this way, and would welcome further comment from any XML 811 cognoscenti.]]] 813 5. Mapping between RDF and media features 815 The following extract is from the RDF Model and Syntax 816 specification: 818 "This document introduces a model for representing RDF metadata 819 as well as a syntax for encoding and transporting this metadata 820 in a manner that maximizes the interoperability of independently 821 developed web servers and clients. The syntax presented here 822 uses the Extensible Markup Language [XML]: one of the goals of 823 RDF is to make it possible to specify semantics for data based on 824 XML in a standardized, interoperable manner. [...] It is also 825 important to understand that this XML syntax is only one possible 826 syntax for RDF, and that alternate ways to represent the same RDF 827 data model may emerge." 829 Internet draft 15 December 1998 830 W3C Composite Capability/Preference Profiles 832 It is interesting to note that the 'conneg' feature expression 833 framework shares with the RDF framework this clear intent to 834 separate the data model from its representative syntax. 836 In this section, the RDF data model is explored and related to the 837 'conneg' feature registration namespace. The RDF data model is 838 very rich compared with that used by 'conneg', so should easily be 839 capable of representing the concepts used. 841 IETF 'conneg' deals with the following value-sets: 843 Feature-tag ::= Token 844 Feature-value ::= Integer 845 | Rational 846 | Boolean 847 | Token 848 | String 849 Feature-collection ::= FINITE MAP Feature-tag TO Feature-value 850 Feature-set ::= SET OF Feature-collection 852 Further, a "Feature-set" is described by a collection of feature 853 value assertions: 855 Feature-assertion ::= ( "&", SEQUENCE OF Feature-assertion ) 856 | ( "|", SEQUENCE OF Feature-assertion ) 857 | ( "!", Feature-assertion ) 858 | Atomic-assertion 859 Atomic-assertion ::= ( Relation, Feature-tag, Feature-value ) 860 Relation ::= "EQ" | "NE" | "GE" | "LE" 862 A "Feature-collection" can be represented directly as an RDF 863 resource, where each feature tag/value pair is an RDF property name 864 and string value. 866 A "Feature-set" does not have such an obvious RDF representation. 867 However, the characterization of RDF as having "predicates" that 868 associate some "object value" with a "resource" suggests a 869 representation. Atomic feature value assertions are also 870 predicates that relate a feature tag with a value. 872 Thus, to fit the RDF model, we can model a feature as an RDF 873 "resource", with a tag and one or more value assertions. The 874 following example models a simple description of a VGA display, 875 which using 'conneg' notation would be: 877 (& (pix-x<=640) (pix-y<=480) (color<=256) ) 879 Internet draft 15 December 1998 880 W3C Composite Capability/Preference Profiles 882 This display might be described by the following RDF: 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 903 In this example, the multiple feature values within a "Feature- 904 assertion" are taken to be implicitly ANDed together. Other 905 representations are possible. All 'conneg'-related tags are 906 assumed to be defined in a 'conneg' namespace. 908 Internet draft 15 December 1998 909 W3C Composite Capability/Preference Profiles 911 To take a slightly more complex 'conneg' example: 913 (| (& (pix-x<=800) (pix-y<=600) (color<=256) ) 914 (& (pix-x<=640) (pix-y<=480) (color<=65536) ) ) 916 This might be represented as: 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 959 Internet draft 15 December 1998 960 W3C Composite Capability/Preference Profiles 962 [[[I am not expert in RDF, but already I can see ways in which the 963 above might to improved. At this stage, the key ideas I wish to 964 test are: (a) that feature collections can be modelled directly as 965 RDL resource descriptions, (b) that feature sets must be modelled 966 as resources in their own right, and (c) that atomic value 967 assertions should use the RDF "predicate" to indicate the kind of 968 constraint that is being applied.]]] 970 6. Conclusions 972 One of the goals of these proposals is to allow the 'conneg' work 973 to integrate seamlessly with ongoing work that is being undertaken 974 by W3C. 976 I have suggested some constructs and handling rules that I believe 977 capture the required concepts embodied in the W3C work, and provide 978 a way to manipulate them consistently within the 'conneg' framework 979 already proposed. 981 [[[Ideally, the extensions to the conneg algebraic framework should 982 be subjected to some mathematical analysis to show that application 983 of the rules can never yield contradictory results, and that the 984 behaviour is consistent with the concept of assumed values that it 985 tries to capture.]]] 987 7. Security considerations 989 In general, these proposals are not believed to raise any security 990 considerations not already inherrent in the 'conneg', 'RDF' or 991 'CC/PP' work. 993 One area can be seen where further consideration of security 994 concerns might be required. The use of URLs, per CC/PP, to locate 995 'conneg' feature set descriptions might open up some exposure to 996 privacy or denial of service attacks on the referenced description. 998 Internet draft 15 December 1998 999 W3C Composite Capability/Preference Profiles 1001 8. Full copyright statement 1003 Copyright (C) The Internet Society 1998. All Rights Reserved. 1005 This document and translations of it may be copied and furnished to 1006 others, and derivative works that comment on or otherwise explain 1007 it or assist in its implementation may be prepared, copied, 1008 published and distributed, in whole or in part, without restriction 1009 of any kind, provided that the above copyright notice and this 1010 paragraph are included on all such copies and derivative works. 1011 However, this document itself may not be modified in any way, such 1012 as by removing the copyright notice or references to the Internet 1013 Society or other Internet organizations, except as needed for the 1014 purpose of developing Internet standards in which case the 1015 procedures for copyrights defined in the Internet Standards process 1016 must be followed, or as required to translate it into languages 1017 other than English. 1019 The limited permissions granted above are perpetual and will not be 1020 revoked by the Internet Society or its successors or assigns. 1022 This document and the information contained herein is provided on 1023 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1024 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1025 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1026 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1027 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1029 9. Acknowledgements 1031 xxxx 1033 10. References 1035 [1] "Requirements for protocol-independent content negotiation" 1036 G. Klyne, Integralis Ltd. 1037 Internet draft: 1038 Work in progress, March 1998. 1040 [2] "Media Feature Tag Registration Procedure" 1041 Koen Holtman, TUE 1042 Andrew Mutz, Hewlett-Packard 1043 Ted Hardie, NASA 1044 Internet draft: 1045 Work in progress, July 1998. 1047 Internet draft 15 December 1998 1048 W3C Composite Capability/Preference Profiles 1050 [3] "A syntax for describing media feature sets" 1051 Graham Klyne, 5GM/Content Technologies 1052 Internet draft: " 1053 Work in progress, September 1998. 1055 [4] "Media Features for Display, Print, and Fax" 1056 Larry Masinter, Xerox PARC 1057 Koen Holtman, TUE 1058 Andrew Mutz, Hewlett-Packard 1059 Dan Wing, Cisco Systems 1060 Internet draft: 1061 Work in progress, September 1998. 1063 [5] "Composite Capability/Preference Profiles (CC/PP): 1064 A user side framework for content negotiation" 1065 Franklin Reynolds, Nokia Research 1066 W3C Note 1067 November 1998 1069 [6] "Resource Description Framework (RDF) Model and Syntax 1070 Specification" 1071 Ora Lassila, Nokia Research Centre 1072 Ralph R Swick, World Wide Web Consortium 1073 W3C working draft: 1074 October 1998 1076 [7] "Resource Description Framework (RDF) Schema Specification" 1077 Dan Brickley, University of Bristol 1078 R. V. Guha, Netscape 1079 Andrew Layman, Microsoft 1080 W3C working draft: 1081 August 1998. 1083 [8] "Extensible Markup Language (XML) 1.0" 1084 Tim Bray, Textuality and Netscape 1085 Jean Paoli, Microsoft 1086 C. M. Sperberg-McQueen, University of Illinois at Chicago 1087 W3C Recommendation: 1088 February 1998. 1090 Internet draft 15 December 1998 1091 W3C Composite Capability/Preference Profiles 1093 11. Author's address 1095 Graham Klyne 1096 Content Technologies Ltd. 5th Generation Messaging Ltd. 1097 Forum 1 5 Watlington Street 1098 Station Road Nettlebed 1099 Theale Henley-on-Thames 1100 Reading, RG7 4RA RG9 5AB 1101 United Kingdom United Kingdom. 1103 Telephone: +44 118 930 1300 +44 1491 641 641 1105 Facsimile: +44 118 930 1301 +44 1491 641 611 1107 E-mail: GK@ACM.ORG