idnits 2.17.1 draft-ietf-conneg-W3C-ccpp-00.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-00', 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 22 longer pages, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 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. 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 (20 October 1998) is 9313 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) -- Missing reference section? '2' on line 1024 looks like a reference -- Missing reference section? '3' on line 1031 looks like a reference -- Missing reference section? '4' on line 1036 looks like a reference -- Missing reference section? '5' on line 1044 looks like a reference -- Missing reference section? '6' on line 1055 looks like a reference -- Missing reference section? '1' on line 1019 looks like a reference -- Missing reference section? 'A' on line 316 looks like a reference -- Missing reference section? 'S' on line 328 looks like a reference -- Missing reference section? 'R' on line 333 looks like a reference -- Missing reference section? 'U' on line 334 looks like a reference -- Missing reference section? 'XML' on line 813 looks like a reference -- Missing reference section? '7' on line 1062 looks like a reference -- Missing reference section? '8' on line 1069 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 3 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 20 October 1998 5 Expires: April 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 20 October 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 .............9 64 3.4.1 Assumed values construct.........................9 65 3.4.2 End of chain indicator...........................9 66 3.4.3 Extended form of conjunction.....................10 67 3.5 Additional reduction rules ...........................10 68 3.6 Extended canonicalization rules ......................11 69 3.7 Examples .............................................11 70 3.7.1 The "font" problem...............................12 71 3.7.2 Resolution dependent font........................13 72 3.7.3 Combining default values.........................14 73 4. XML representation of capability descriptions............15 74 5. Mapping between RDF and media features...................16 75 6. Conclusions..............................................20 76 x. Security considerations..................................20 77 x. Full copyright statement.................................20 78 x. Acknowledgements.........................................21 79 x. References...............................................21 80 x. Author's address.........................................22 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 20 October 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 Internet draft 20 October 1998 142 W3C Composite Capability/Preference Profiles 144 2. Tag-independent content negotiation 146 One can imagine two extremes of content negotiation procedure: 148 o One in which the decisions about whether the features in a data 149 data resource match some set of capabilities are made in full 150 knowledge of the exact meaning of every feature and capability. 152 o The other, in which the matching decision is made without any 153 knowledge of the particular features concerned. 155 A practical procedure is likely to lie somewhere between these 156 extremes. The purpose of this section is to argue that a procedure 157 that minimizes the required knowledge of particular feature tags is 158 likely to be more useful than one which depends heavily upon such 159 knowledge. 161 This approach is described here as "tag-independent negotiation": 162 negotiation that can proceed without specific knowledge of the tags 163 used to describe various media features of the participating 164 entities. 166 2.1 WWW resource transfer scenario 168 Consider a WWW transaction scenario that involves content 169 negotiation: 171 Resource-1 ->- +--------+ +--------+ ->- Plugin-1 172 \ | Origin | | | / 173 Resource-2 ->----| Server |--<--->--| Client |---->- Plugin-2 174 / | | | | \ 175 Resource-3 ->- +--------+ +--------+ ->- Plugin-3 177 In this scenario, the active negotiation takes place between the 178 origin server and the receiving client. 180 The resources available to the origin server are possibly passive 181 data files, with no opportunity for interaction between data 182 resource and server. 184 The plugins available to the browser may well be dispatched as 185 separate programs, with limited opportunity for ongoing interaction 186 between the plugin and the client. Also, there may be a high 187 overhead associated with activating a plugin, so it is not 188 desirable to activate one or more plugins simply to determine 189 whether a data resource is acceptable to that plugin. 191 Internet draft 20 October 1998 192 W3C Composite Capability/Preference Profiles 194 2.2 Conclusions 196 In an environment like WWW where new and changed features are 197 deployed on a regular basis, it is clearly not desirable that 198 detailed knowledge be hard-coded into either the origin server or 199 the client software. This would rather defeat the idea of 200 extending functionality through plugins and data resource 201 abstractions. 203 Thus, to avoid early obsolesence of servers and clients, we seek a 204 negotiation framwork that permits a data resource to describe 205 itself to the origin server, a plugin to describe itself to a 206 browser, and allows the server and browser to conduct negotiations 207 without any further knowledge. 209 There are doubtless some cases where the degree of negotiating 210 flexibility indicated here is not essential: "Internet appliances" 211 and other dedicated devices spring to mind. But even for such 212 devices, it can be argued that the flexibility of tag-independent 213 negotiation will simplify configuration of such devices. 215 2.3 Consequences 217 Some consequences of the conclusion just outlined are: 219 o The capability description should be able to describe 220 dependencies between content features in such a way that they can 221 be handled by the negotiation protocol. 223 o The vocabulary used to describe content features should avoid 224 having multiple ways to describe the same capabilities. 226 3. Assumed feature values 228 The W3C CC/PP [5] work embodies a concept that is not currently 229 supported in the IETF 'conneg' framework [3]; namely the 230 construction of a set of capability and preference values from a 231 number of separate sources (e.g. hardware platform defaults, 232 software platform defaults, user preferences). Also, there is a 233 desire to have a compact way to represent a small number of 234 differences from some baseline set of capabilities. What is not 235 covered by this work, that the IETF 'conneg' work can supply, is a 236 framework for actually combining the various information sources. 238 Also, there is an identified capability gap in the IETF 'conneg' 239 work: the ability to indicate that some particular feature must be 240 supplied by a communicating counterparty. This has been 241 charactirized as the "font problem": how can a sender require that 242 some particular font is supported by a recipient? Currently the 244 Internet draft 20 October 1998 245 W3C Composite Capability/Preference Profiles 247 'conneg' framework operates to effectively ignore a request for an 248 unknown font, or other unrecognized feature. 250 3.1 Unifying "required" and "default" values 252 The two situations we wish to describe are: 254 (A) "required" values: given two feature set descriptions, the 255 feature set match is to fail if one of them does not define a 256 value for a feature tag tested by the other. This is 257 exemplified by the "fonts" problem: if a data resource uses 258 some font indicated by the feature tag "Font-obscure", and the 259 receiver does not explicitly declare an ability to deal with 260 that font, then we should assume that the feature sets do not 261 match. As currently defined, the 'conneg' algebraic framework 262 [3] would allow a feature set match in the absence of an 263 explicit denial of such support. 265 (B) "override" and "default" values: given two feature set 266 descriptions that contain different constraints involving some 267 feature tag, the constraint from one of the feature sets is to 268 override the constraint in the other. This is exemplified by 269 the scenario outlined in the W3 CC/PP draft [5], in which a 270 hardware manufacturer may supply a default profile for a 271 device which can then be overridden by local user preferences. 273 A mechanism that can address both of these requirements is one 274 which allows a feature set description to indicate "assumed" values 275 for a given feature. 277 Case (A): 278 A data resource requires a given font to be available, and its 279 feature set description provides "assumed" values for the font 280 availability that are used only if the recipient does not 281 itself reference that feature. Thus, if the data resource 282 indicates: 283 (Font-obscure=TRUE) 284 Assume: (Font-obscure=FALSE) 285 and the recipient does not supply a constraint for 'Font- 286 obscure', then the assumed value is used to force a feature 287 set match failure. 289 Case (B): 290 A hardware platform capability description consists entirely 291 of assumed feature values. When combined with user 292 preferences, these provide values for those features that are 293 not mentioned in the user preferences. 295 The ideas here can be extended to deal with combinations of more 296 than two feature sets. 298 Internet draft 20 October 1998 299 W3C Composite Capability/Preference Profiles 301 The assumed value idea breaks a number of assumptions of the 302 current 'conneg' algebraic model [3], which is based pretty much on 303 simplified predicate algebra. The sections that follow reconcile 304 this idea with the existing framework. 306 3.2 Message transmission model 308 The following discussion is based on a message transmission model 309 that assumes multiple feature set constraints. The following 310 example is from [1], section 3.1: 312 The life of a data resource may be viewed as: 313 (C) (T) (F) 314 [A]-->--[S]-->--[R]-->--[U] 315 where: 316 [A] = author of document 317 (C) = original document content 318 [S] = message sending system 319 (T) = transmitted data file (representation of (C)) 320 [R] = receiving system 321 (F) = formatted (rendered) document data (presentation of (C)) 322 [U] = user or consumer of a document 324 Here, it is [S] and [R] who exchange negotiation metadata to 325 decide the form of (T), so these elements are the focus of our 326 attention. 328 Negotiation metadata provided by [S] would take account of 329 available document content (C) (e.g. availability of resource 330 variants) as well as its own possible ability to offer that 331 content in variety of formats. 333 Negotiation metadata provided by [R] would similarly take account 334 of the needs and preferences of its user [U] as well as its own 335 capabilities to process and render received data. 337 This example suggests a generic framework within which negotiation 338 is conducted: a chain of entities, each of which may impose some 339 constraint(s) on the message features that can usefully be 340 transferred: 342 [.]-->--[E1]-->--[E2]-->-- ... -->--[En]-->--[.] 344 '[.]' are used here indicate specific begin and end points of the 345 chain, and '[Ei]' are entities that may impose feaure constraints. 346 If the feature constraint predicate associated with '[Ei]' is 347 'FCi', then the composite feature constraint for the entire chain 348 is the conjunction of the individual constraints: 350 (& FC1 FC2 ... FCn ) 352 Internet draft 20 October 1998 353 W3C Composite Capability/Preference Profiles 355 using the notation of [3]. 357 3.3. Problem summary 359 The 'conneg' algebraic framework depends on combining feature sets 360 by set intersection (i.e. a logical AND of the predicates that 361 describe feature sets). 363 For the purposes of this discussion, all feature set expressions 364 are reduced to disjunctive normal form: thus, every feature set is 365 described as a disjunction (union) of one or more subsets, each of 366 which is described by a conjunction of atomic feature comaprisons; 367 e.g. 369 (| (& (size=s1) (resolution=r1) (color=c1) ) 370 (& (size=s2) (resolution=r2) (grey=g2) ) ) 372 This is without loss of generality: the combining framework 373 description [3] shows how more complex expressions can be reduced 374 to this canonical form. 376 Now consider the following observations: 378 (1) all atomic feature comparisons have the form '(ftag relop 379 fvalue)', where 'ftag' is a feature tag that uniquely 380 identifies a feature, 'relop' is a comparison operator and 381 'fvalue' is a particular value associated with the feature 382 tag. 384 (2) The conjunction operator is symmetric: 386 (& A B) == (& B A) 388 (3) The conjunction operator is associative: 390 (& A (& B C) ) == (& (& A B) C) 392 This property is important because it means that the feature 393 sets are not required to be combined in any specific order. 394 This point is raised in the CC/PP memo [5], and this is a 395 property that should be preserved. 397 (4) The assumed value mechanism outlined above is inherrently 398 anti-symmetric. One of the feature sets used takes precedence 399 over the other: 401 (Assume: A B) != (Assume: B A) 403 (5) The assumed value mechanism, by its very nature, is sensitive 404 to the particular feature tags used. 406 Internet draft 20 October 1998 407 W3C Composite Capability/Preference Profiles 409 (6) Assumed values should be used only when an explicit constraint 410 for a feature tag cannot be found. For example, if a data 411 resource has the requirement: 413 (Font-obscure=TRUE) 415 and also indicates an assumed value: 417 Assume: (Font-obscure=FALSE) 419 The assumed value must be ignored if the recipient asserts: 421 (Font-obscure=TRUE) 423 This requirement is captured without imposing an order of 424 evaluation on the feature set matching process (because such 425 imposition is considered to make the entire process more 426 complex and error-prone). 428 (7) A feature set constraint must be reduced to the predicate form 429 currently defined by the 'conneg' framework [3] (i.e. all 430 default values must be eliminated) before a feature collection 431 (i.e. some specific feature values) can be tested with it. 433 3.4 Proposed extension to 'conneg' framework 435 Two extensions to the 'conneg' algebraic framework are proposed: 437 (a) a "assumed values" construct 439 (b) an "end-of-chain" indicator 441 and revision of the conjunction '(&...)' and other processing rules 442 to take account of these new constructs. 444 3.4.1 Assumed values construct 446 This is expressed as: 448 (+ FC ) 450 where 'FC' is a list of one or more feature constraint expressions. 451 For an expression in the canonical disjunctive normal form, each is 452 an atomic feature value constraint (i.e. contains a single feature 453 comparison). 455 3.4.2 End of chain indicator 457 This is expressed as: 459 Internet draft 20 October 1998 460 W3C Composite Capability/Preference Profiles 462 (.) 464 3.4.3 Extended form of conjunction 466 The canonical form of a conjunction is extended to allow: 468 (& ... (+ FL) FC (+ FR) ... ) 470 That is, it contains separate, optional assumed value constructs to 471 the left- and right- of any expression in the conjunction. 472 Referring to the message transmission chain model, these correspond 473 to assumed values that are applied "upstream" and "downstream" 474 along the chain. For example, when feature sets along a chain are 475 combined: 477 (& FC1 (& (+ FL2) FC2 (+FR2) ) FC3 ) 479 the 'FL2' assumed values applied to 'FC1', and values 'FR2' are 480 applied to 'FC3'. 482 Assumed value constructs can appear anywhere in a conjunction, and 483 the additional rules below indicate how to process these into the 484 canonical form. 486 The '(.)' construct can appear at the left or right hand end of a 487 conjunction: 489 (& (.) FC (.) ) 491 It may not appear anywhere else in a conjunction. Additional 492 processing rules (below) show how these can be used to eliminate 493 assumed value constructs from a conjunction, thus reducing it to a 494 simple predicate form. 496 3.5 Additional reduction rules 498 The aim of these rules is to allow assumed values to propagate 499 along the message transfer chain until either (a) it is determined 500 they are redundant, or (b) the assumed values are used as actual 501 feature constraints which can be evaluated in the normal way. 503 The following rules assume that all feature constraints are atomic; 504 i.e. they refer to a single feature tag. The next section contains 505 rules for canonicalization of complex predicates to a form with 506 just atomic feature constraints. 508 Note that if there are any assumed value constructs present in a 509 conjunction, re-ordering of the component constraints is allowed 510 only according to reordering rule below. 512 Internet draft 20 October 1998 513 W3C Composite Capability/Preference Profiles 515 (a) Re-ordering of assumed value constraints: 516 (& ... (+FC1) FC2 ... ) ---> (& ... FC2 (+FC1) ... ) 517 (& ... FC1 (+FC2) ... ) ---> (& ... (+FC2) FC1 ... ) 518 (& ... (+FC1) (+FC2) ... ) ---> (& ... (+FC2) (+FC1) ... ) 519 ONLY IF: FC1 and FC2 reference different feature tags. 521 (b) Assumed value elimination: 522 (& ... FC1 (+FC2) FC3 ... ) ---> (& ... FC1 FC3 ... ) 523 ONLY IF: FC1, FC2 and FC3 reference the same feature tag, 525 Two extended forms of this rule allow multiple assumed values 526 to be eliminated: 527 (& ... FC1 ... (+FC2) FC3 ... ) ---> (& ... FC1 FC3 ... ) 528 (& ... FC1 (+FC2) ... FC3 ... ) ---> (& ... FC1 FC3 ... ) 529 ONLY IF: FC1, FC2 and FC3 reference the same feature tag, 531 (c) Default resolution: 532 (& (.) (+FC1) ... ) ---> (& FC1 ... ) 533 (& ... (+FC1) (.) ) ---> (& ... FC1 ) 535 3.6 Extended canonicalization rules 537 The above reduction rules assume a canonical form of predicate 538 expressions. The canonicalization rules described for the 'conneg' 539 framework [3] must be extended to handle assumed value constructs. 541 The main goal of these additional rules is to push assumed values 542 "down" in the expression so that they are contained within all 543 disjunctions and conjunctions, and themselves contain only atomic 544 feature constraints. 546 (a) Separate default constructs: 547 (+ FC1 FC2 ... ) ---> (+FC1) (+FC2) ... 548 Following repeated application of this rule, all default 549 constructs contain just one feature predicate expression 550 (conjunction, disjunction or atomic). 552 (b) Move assumed value into conjunction: 553 (+ (& FC1 FC2 ... ) ) ---> (& (+FC1) (+FC2) ... ) 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 Internet draft 20 October 1998 567 W3C Composite Capability/Preference Profiles 569 3.7.1 The "font" problem 571 Sender/data resource description: 573 (& (Font-1=TRUE) (Font-2=TRUE) 574 (+ (Font-1=FALSE) (Font-2=FALSE) ) ) 576 Recipient description: 578 (& (Font-1=TRUE) (Font-3=TRUE) ) 580 Combine these to obtain the full transmission path description 581 (recall that feature sets are matched by combining them with 582 '(&...)', and left is upstream in the transmission path): 584 (& (.) 585 (& (Font-1=TRUE) (Font-2=TRUE) // Sender.. 586 (+ (Font-1=FALSE) (Font-2=FALSE) ) ) 587 (& (Font-1=TRUE) (Font-3=TRUE) ) // Receiver.. 588 (.) ) 590 What follows is a sequence of rewriting rule applications that show 591 how this expression is processed to eliminate the (+...) constructs 592 and, in the process, the receiver's lack of support for 'Font-2' 593 causes the feature set match to fail. 595 --> [expand (+...)] 597 (& (.) 598 (& (Font-1=TRUE) (Font-2=TRUE) 599 (+ (Font-1=FALSE) ) (+ (Font-2=FALSE) ) ) 600 (& (Font-1-TRUE) (Font-2=TRUE) (Font-4=TRUE) ) 601 (.) ) 603 --> [flatten (&...(&...)...)] 605 (& (.) 606 (Font-1=TRUE) (Font-2=TRUE) 607 (+ (Font-1=FALSE) ) (+ (Font-2=FALSE) ) 608 (Font-1-TRUE) (Font-2=TRUE) (Font-4=TRUE) ) 609 (.) ) 611 --> [collect features, being careful to preserve ordering of 612 constraints with the same feature tag]: 614 (& (.) 615 (Font-1=TRUE) (+ (Font-1=FALSE) ) (Font-1=TRUE) 616 (Font-2=TRUE) (+ (Font-2=FALSE) ) 617 (Font-3=TRUE) ) 618 (& (.) 620 Internet draft 20 October 1998 621 W3C Composite Capability/Preference Profiles 623 --> [eliminate un-needed default] 625 (& (.) 626 (Font-1=TRUE) (Font-1=TRUE) 627 (Font-2=TRUE) (+ (Font-2=FALSE) ) 628 (Font-3=TRUE) ) 629 (& (.) 631 --> [Resolve non-eliminated default: move to end, then use (+...) 632 (.) rewriting rule] 634 (& (.) 635 (Font-1=TRUE) (Font-1=TRUE) 636 (Font-2=TRUE) (Font-2=FALSE) 637 (Font-3=TRUE) ) 638 (& (.) 640 --> [Combine (&...) with same tag: 642 (& (.) 643 (Font-1=TRUE) 644 (FALSE) 645 (Font-3=TRUE) 646 (.) ) 648 Which leaves a conjunction containing FALSE, indicating that there 649 is no feature set matching all the capability constraints. 651 Note that the receiver's (Font-3=TRUE) was not eliminated because 652 it did not use the (+...) mechanism to say, in effect, that the 653 sender must use it. 655 3.7.2 Resolution dependent font 657 A slightly more complex example might be: 659 Sender/data resource description: 661 (| (& (dpi>=100) (Font-simple=TRUE) (+ (Font-simple=FALSE) ) ) 662 (& (dpi>=300) (Font-fancy=TRUE) (+ (Font-fancy=FALSE) ) ) ) 664 This would match the recipient capalities: 665 (& (dpi=100) (Font-simple=TRUE) ) 666 or 667 (& (dpi=300) (Font-simple=TRUE) (Font-fancy=TRUE) ) 669 But it would not match the recipient capability: 670 (& (dpi=100) (Font-fancy=TRUE) ) 672 Internet draft 20 October 1998 673 W3C Composite Capability/Preference Profiles 675 3.7.3 Combining default values 677 Finally, note there is a possibility to use nested '(& ... (.) )' 678 constructs for defaults which are restricted to a particular entity 679 in the transmission chain, for example (which is the type of 680 scenario discussed in the CC/PP draft): 682 (& 683 (& (+ ) 684 (.) ) ... ) 686 Using the "indirect references" example from the CC/PP memo [5], we 687 could construct a framework like this: 689 (& (& (Hardware-defaults) (+ (Hardware-defaults) ) 690 (Hardware-platform) (.) ) 691 (& (Software-defaults) (+ (Software-defaults) ) 692 (Software-platform) (.) ) 693 (EpocEmail) 694 (EpocCalendar) 695 (UserPreferences) 696 (.) ) 698 where 700 (Hardware-defaults) :- 701 (& (Vendor="Nokia") 702 (Model="2160") 703 (Type="PDA") 704 (ScreenSize="800x600x24") 705 (CPU="PPC") 706 (Keyboard="Yes") 707 (Speaker="Yes") 708 (Memory="16Mb) ) 710 (Hardware-platform) :- 711 (Memory="32Mb") 713 (Software-defaults) :- 714 (& (OS="EPOC1.0") 715 (HTMLVersion="4.0") 716 (JavaScriptVersion="4.0") 717 (WAPVersion="1.0") 718 (WMLScriptVersion="1.0") ) 720 (Software-platform) :- 721 (& (Sound="Off") 722 (Images="Off") ) 724 Internet draft 20 October 1998 725 W3C Composite Capability/Preference Profiles 727 (EpocEmail) :- 728 (& (Version="EpocEmail1.0") 729 (HTMLVersion="4.0") ) 731 (EpocCalendar) :- 732 (& (Version="EpocCalendar1.0") 733 (HTMLVersion="4.0") ) 735 end 737 The repetition of '(Hardware-defaults)' and '(Software-defaults)' 738 is needed to force application of the default value through 739 reduction rule 2.5(b), "Assumed value elimination". This is, 740 however, a little clumsy and suggests introduction of a new 741 construct and reduction rule. 743 The new construct, a default end of chain indicator, is expressed 744 as: 746 (*) 748 and its purpose is to force elimination of any unused default 749 value, using the following rule 751 Default value elimination: 752 (& (*) ... (+FC1) FC2 ... ) ---> (& (*) ... FC2 ... ) 753 ONLY IF: FC1 and FC2 reference the same feature tag. 755 Thus, the above feature set expression could be re-written as: 757 (& (& (*) (+ (Hardware-defaults) ) (Hardware-platform) (.) ) 758 (& (*) (+ (Software-defaults) ) (Software-platform) (.) ) 759 (EpocEmail) 760 (EpocCalendar) 761 (UserPreferences) 762 (.) ) 764 where 766 (etc.) 768 Internet draft 20 October 1998 769 W3C Composite Capability/Preference Profiles 771 4. XML representation of capability descriptions 773 The 'conneg' feature set description framework is well-suited to 774 being expressed in XML. The previously given example: 776 (| (& (dpi>=100) (Font-simple=TRUE) (+ (Font-simple=FALSE) ) ) 777 (& (dpi>=300) (Font-fancy=TRUE) (+ (Font-fancy=FALSE) ) ) ) 779 might be represented (in conjunction with an appropriate XML tag 780 definitions) using something like the following XML: 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 799 [[[I am not expert in XML, and the above is almost certainly 800 flawed. But I do believe that it is possble to use XML broadly in 801 this way, and would welcome further comment from any XML 802 cognoscenti.]]] 804 5. Mapping between RDF and media features 806 The following extract is from the RDF Model and Syntax 807 specification: 809 "This document introduces a model for representing RDF metadata 810 as well as a syntax for encoding and transporting this metadata 811 in a manner that maximizes the interoperability of independently 812 developed web servers and clients. The syntax presented here 813 uses the Extensible Markup Language [XML]: one of the goals of 814 RDF is to make it possible to specify semantics for data based on 815 XML in a standardized, interoperable manner. [...] It is also 816 important to understand that this XML syntax is only one possible 817 syntax for RDF, and that alternate ways to represent the same RDF 818 data model may emerge." 820 Internet draft 20 October 1998 821 W3C Composite Capability/Preference Profiles 823 It is interesting to note that the 'conneg' feature expression 824 framework shares with the RDF framework this clear intent to 825 separate the data model from its representative syntax. 827 In this section, the RDF data model is explored and related to the 828 'conneg' feature registration namespace. The RDF data model is 829 very rich compared with that used by 'conneg', so should easily be 830 capable of representing the concepts used. 832 IETF 'conneg' deals with the following value-sets: 834 Feature-tag ::= Token 835 Feature-value ::= Integer 836 | Rational 837 | Boolean 838 | Token 839 | String 840 Feature-collection ::= FINITE MAP Feature-tag TO Feature-value 841 Feature-set ::= SET OF Feature-collection 843 Further, a "Feature-set" is described by a collection of feature 844 value assertions: 846 Feature-assertion ::= ( "&", SEQUENCE OF Feature-assertion ) 847 | ( "|", SEQUENCE OF Feature-assertion ) 848 | ( "!", Feature-assertion ) 849 | Atomic-assertion 850 Atomic-assertion ::= ( Relation, Feature-tag, Feature-value ) 851 Relation ::= "EQ" | "NE" | "GE" | "LE" 853 A "Feature-collection" can be represented directly as an RDF 854 resource, where each feature tag/value pair is an RDF property name 855 and string value. 857 A "Feature-set" does not have such an obvious RDF representation. 858 However, the characterization of RDF as having "predicates" that 859 associate some "object value" with a "resource" suggests a 860 representation. Atomic feature value assertions are also 861 predicates that relate a feature tag with a value. 863 Thus, to fit the RDF model, we can model a feature as an RDF 864 "resource", with a tag and one or more value assertions. The 865 following example models a simple description of a VGA display, 866 which using 'conneg' notation would be: 868 (& (pix-x<=640) (pix-y<=480) (color<=256) ) 870 Internet draft 20 October 1998 871 W3C Composite Capability/Preference Profiles 873 This display might be described by the following RDF: 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 894 In this example, the multiple feature values within a "Feature- 895 assertion" are taken to be implicitly ANDed together. Other 896 representations are possible. All 'conneg'-related tags are 897 assumed to be defined in a 'conneg' namespace. 899 Internet draft 20 October 1998 900 W3C Composite Capability/Preference Profiles 902 To take a slightly more complex 'conneg' example: 904 (| (& (pix-x<=800) (pix-y<=600) (color<=256) ) 905 (& (pix-x<=640) (pix-y<=480) (color<=65536) ) ) 907 This might be represented as: 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 942 943 944 945 946 947 948 950 Internet draft 20 October 1998 951 W3C Composite Capability/Preference Profiles 953 [[[I am not expert in RDF, but already I can see ways in which the 954 above might to improved. At this stage, the key ideas I wish to 955 test are: (a) that feature collections can be modelled directly as 956 RDL resource descriptions, (b) that feature sets must me modelled 957 as resources in their own right, and (c) that atomic value 958 assertions should use the RDF "predicate" to indicate the kind of 959 constraint that is being applied.]]] 961 6. Conclusions 963 One of the goals of these proposals is to allow the 'conneg' work 964 to integrate seamlessly with ongoing work that is being undertaken 965 by W3C. 967 I have suggested some constructs and handling rules that I believe 968 capture the required concepts embodied in the W3C work, and provide 969 a way to manipulate them consistently within the 'conneg' framework 970 already proposed. 972 [[[Ideally, the extensions to the conneg algebraic framework should 973 be subjected to some mathematical analysis to show that application 974 of the rules can never yield contradictory results, and that the 975 behaviour is consistent with the concept of assumed values that it 976 tries to capture.]]] 978 x. Security considerations 980 xxxx 982 x. Full copyright statement 984 Copyright (C) The Internet Society 1998. All Rights Reserved. 986 This document and translations of it may be copied and furnished to 987 others, and derivative works that comment on or otherwise explain 988 it or assist in its implementation may be prepared, copied, 989 published and distributed, in whole or in part, without restriction 990 of any kind, provided that the above copyright notice and this 991 paragraph are included on all such copies and derivative works. 992 However, this document itself may not be modified in any way, such 993 as by removing the copyright notice or references to the Internet 994 Society or other Internet organizations, except as needed for the 995 purpose of developing Internet standards in which case the 996 procedures for copyrights defined in the Internet Standards process 997 must be followed, or as required to translate it into languages 998 other than English. 1000 Internet draft 20 October 1998 1001 W3C Composite Capability/Preference Profiles 1003 The limited permissions granted above are perpetual and will not be 1004 revoked by the Internet Society or its successors or assigns. 1006 This document and the information contained herein is provided on 1007 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1008 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1009 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1010 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1011 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1013 x. Acknowledgements 1015 xxxx 1017 x. References 1019 [1] "Requirements for protocol-independent content negotiation" 1020 G. Klyne, Integralis Ltd. 1021 Internet draft: 1022 Work in progress, March 1998. 1024 [2] "Media Feature Tag Registration Procedure" 1025 Koen Holtman, TUE 1026 Andrew Mutz, Hewlett-Packard 1027 Ted Hardie, NASA 1028 Internet draft: 1029 Work in progress, July 1998. 1031 [3] "A syntax for describing media feature sets" 1032 Graham Klyne, 5GM/Content Technologies 1033 Internet draft: " 1034 Work in progress, September 1998. 1036 [4] "Media Features for Display, Print, and Fax" 1037 Larry Masinter, Xerox PARC 1038 Koen Holtman, TUE 1039 Andrew Mutz, Hewlett-Packard 1040 Dan Wing, Cisco Systems 1041 Internet draft: 1042 Work in progress, September 1998. 1044 [5] "Composite Capability/Preference Profiles (CC/PP): 1045 A user side framework for content negotiation" 1046 Franklin Reynolds, Nokia Research 1047 W3C working draft: unpublished, but submitted to IETF content 1048 negotiation mailing list. Available at: 1049 1050 October 1998 (?) 1052 Internet draft 20 October 1998 1053 W3C Composite Capability/Preference Profiles 1055 [6] "Resource Description Framework (RDF) Model and Syntax 1056 Specification" 1057 Ora Lassila, Nokia Research Centre 1058 Ralph R Swick, World Wide Web Consortium 1059 W3C working draft: 1060 October 1998 1062 [7] "Resource Description Framework (RDF) Schema Specification" 1063 Dan Brickley, University of Bristol 1064 R. V. Guha, Netscape 1065 Andrew Layman, Microsoft 1066 W3C working draft: 1067 August 1998. 1069 [8] "Extensible Markup Language (XML) 1.0" 1070 Tim Bray, Textuality and Netscape 1071 Jean Paoli, Microsoft 1072 C. M. Sperberg-McQueen, University of Illinois at Chicago 1073 W3C Recommendation: 1074 February 1998. 1076 x. Author's address 1078 Graham Klyne 1079 Content Technologies Ltd. 5th Generation Messaging Ltd. 1080 Forum 1 5 Watlington Street 1081 Station Road Nettlebed 1082 Theale Henley-on-Thames 1083 Reading, RG7 4RA RG9 5AB 1084 United Kingdom United Kingdom. 1086 Telephone: +44 118 930 1300 +44 1491 641 641 1088 Facsimile: +44 118 930 1301 +44 1491 641 611 1090 E-mail: GK@ACM.ORG