idnits 2.17.1 draft-ietf-conneg-feature-syntax-04.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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 40 longer pages, the longest (page 1) being 75 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 ([2], [3], [1]), 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 190: '... "SHOULD", SHOULD NOT", "RECOMMENDED"...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Unrecognized Status in 'Category: Work-in-progress', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (14 December 1998) is 9265 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: '7' is mentioned on line 1852, but not defined == Missing Reference: '8' is mentioned on line 1858, but not defined == Missing Reference: '9' is mentioned on line 1862, but not defined == Missing Reference: '14' is mentioned on line 1900, but not defined == Missing Reference: '10' is mentioned on line 1870, but not defined == Missing Reference: '11' is mentioned on line 1875, but not defined == Missing Reference: '12' is mentioned on line 1882, but not defined == Missing Reference: '13' is mentioned on line 1891, but not defined == Missing Reference: '6' is mentioned on line 1844, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Downref: Normative reference to an Experimental RFC: RFC 2295 (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 10 errors (**), 0 flaws (~~), 12 warnings (==), 6 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 Category: Work-in-progress 14 December 1998 5 Expires: June 1999 7 A syntax for describing media feature sets 8 10 Status of this memo 12 [[INTENDED STATUS: This document specifies an Internet standards 13 track protocol for the Internet community, and requests discussion 14 and suggestions for improvements. Please refer to the current 15 edition of the "Internet Official Protocol Standards" (STD 1) for 16 the standardization state and status of this protocol. 17 Distribution of this memo is unlimited.]] 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its 21 areas, and its working groups. Note that other groups may also 22 distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet- 27 Drafts as reference material or to cite them other than as 28 "work in progress." 30 To view the entire list of current Internet-Drafts, please check 31 the "1id-abstracts.txt" listing contained in the Internet-Drafts 32 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 33 (Northern Europe), ftp.nic.it (Southern Europe), munnari.oz.au 34 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 35 (US West Coast). 37 Copyright Notice 39 Copyright (C) The Internet Society 1998. All Rights Reserved. 41 Abstract 43 A number of Internet application protocols have a need to provide 44 content negotiation for the resources with which they interact [1]. 45 A framework for such negotiation is described in [2], part of which 46 is a way to describe the range of media features which can be 47 handled by the sender, recipient or document transmission format of 48 a message. A format for a vocabulary of individual media features 49 and procedures for feature registration are presented in [3]. 51 This document introduces and describes a syntax that can be used to 52 define feature sets which are formed from combinations and 53 relations involving individual media features. Such feature sets 54 are used to describe the media feature handling capabilities of 55 message senders, recipients and file formats. 57 An algorithm for feature set matching is also described here. 59 RFC nnnn A syntax for describing media feature sets 60 14 December 1998 62 Table of contents 64 1. Introduction.............................................3 65 1.1 Structure of this document ...........................4 66 1.2 Document terminology and conventions .................4 67 1.3 Discussion of this document ..........................4 68 2. Content feature terminology and definitions..............5 69 3. Media feature combinations and capabilities..............5 70 3.1 Media features .......................................5 71 3.2 Media feature collections and sets ...................6 72 3.3 Media feature set descriptions .......................6 73 3.4 Media feature combination scenario ...................7 74 3.4.1 Data resource options............................7 75 3.4.2 Recipient capabilities...........................7 76 3.4.3 Combined options.................................8 77 3.5 Feature set predicates ...............................8 78 3.5.1 Comparison with directory search filters.........8 79 3.6 Describing preferences ...............................9 80 3.7 Combining preferences ................................10 81 4. Feature set representation...............................11 82 4.1 Textual representation of predicates .................11 83 4.2 Interpretation of feature predicate syntax ...........12 84 4.2.1 Filter syntax....................................13 85 4.2.2 Feature comparison...............................13 86 4.2.3 Feature tags.....................................14 87 4.2.4 Feature values...................................14 88 4.2.4.1 Boolean values 14 89 4.2.4.2 Numeric values 14 90 4.2.4.3 Token values 15 91 4.2.4.4 String values 15 92 4.2.5 Notational conveniences..........................15 93 4.3 Feature set definition example .......................16 94 5. Matching feature sets....................................16 95 5.1 Feature set matching strategy ........................18 96 5.2 Formulating the goal predicate .......................19 97 5.3 Replace set expressions ..............................20 98 5.4 Move logical negations inwards .......................20 99 5.5 Replace comparisons and logical negations ............20 100 5.6 Conversion to canonical form .........................22 101 5.7 Grouping of feature predicates .......................22 102 5.8 Merge single-feature constraints .....................23 103 5.8.1 Rules for simplifying ordered values.............23 104 5.8.2 Rules for simplifying unordered values...........24 105 6. Other features and issues................................24 106 6.1 Named and auxiliary predicates .......................24 107 6.1.1 Defining a named predicate.......................24 108 6.1.2 Invoking named predicates........................25 109 6.1.3 Auxiliary predicates in a filter.................25 111 RFC nnnn A syntax for describing media feature sets 112 14 December 1998 114 6.1.4 Feature matching with named predicates...........26 115 6.1.4 Example..........................................26 116 6.2 Unit designations ....................................26 117 6.3 Unknown feature value data types .....................27 118 7. Examples and additional comments.........................28 119 7.1 Worked example .......................................28 120 7.2 A note on feature tag scoping ........................32 121 8. Security considerations..................................34 122 9. Full copyright statement.................................35 123 10. Acknowledgements........................................36 124 11. References..............................................36 125 12. Author's address........................................38 126 Appendix A: Amendment history...............................39 128 1. Introduction 130 A number of Internet application protocols have a need to provide 131 content negotiation for the resources with which they interact [1]. 132 A framework for such negotiation is described in [2]. A part of 133 this framework is a way to describe the range of media features 134 which can be handled by the sender, recipient or document 135 transmission format of a message. 137 Descriptions of media feature capabilities need to be based upon 138 some underlying vocabulary of individual media features. A format 139 for such a vocabulary and procedures for registering media features 140 within this vocabulary are presented in [3]. 142 This document defines a syntax that can be used to describe feature 143 sets which are formed from combinations and relations involving 144 individual media features. Such feature sets are used to describe 145 the media handling capabilities of message senders, recipients and 146 file formats. 148 An algorithm for feature set matching is also described here. 150 The feature set syntax is built upon the principle of using feature 151 set predicates as "mathematical relations" which define constraints 152 on feature handling capabilities. This allows that the same form 153 of feature set expression can be used to describe sender, receiver 154 and file format capabilities. This has been loosely modelled on 155 the way that relational databases use Boolean expresions to 156 describe a set of result values, and a syntax that is based upon 157 LDAP search filters. 159 RFC nnnn A syntax for describing media feature sets 160 14 December 1998 162 1.1 Structure of this document 164 The main part of this memo addresses the following main areas: 166 Section 2 introduces and references some terms which are used with 167 special meaning. 169 Section 3 introduces the concept of describing media handling 170 capabilities as combinations of possible media features, and the 171 idea of using Boolean expressions to express such combinations. 173 Section 4 contains a description of a syntax for describing feature 174 sets based on the previously-introduced idea of Boolean expressions 175 used to describe media feature combinations. 177 Section 5 describes an algorithm for feature set matching. 179 Section 6 discusses some additional media feature description and 180 processing issues that may be viewed as extensions to the core 181 framework. 183 Section 7 contains a worked example of feature set matching, and 184 some additional explanatory comments spurred by issues arising from 185 applying this framework to fascimile transmissions. 187 1.2 Document terminology and conventions 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in RFC 2119. 193 NOTE: Comments like this provide additional nonessential 194 information about the rationale behind this document. 195 Such information is not needed for building a conformant 196 implementation, but may help those who wish to understand 197 the design in greater depth. 199 1.3 Discussion of this document 201 Discussion of this document should take place on the content 202 negotiation and media feature registration mailing list hosted by 203 the Internet Mail Consortium (IMC): 205 Please send comments regarding this document to: 207 ietf-medfree@imc.org 209 To subscribe to this list, send a message with the body 'subscribe' 210 to "ietf-medfree-request@imc.org". 212 RFC nnnn A syntax for describing media feature sets 213 14 December 1998 215 To see what has gone on before you subscribed, please see the 216 mailing list archive at: 218 http://www.imc.org/ietf-medfree/ 220 2. Content feature terminology and definitions 222 Feature Collection 223 is a collection of different media features and 224 associated values. This might be viewed as describing a 225 specific rendering of a specific instance of a document 226 or resource by a specific recipient. 228 Feature Set 229 is a set of zero, one or more feature collections. 231 NOTE: this term is used slightly differently by earlier 232 work on Transparent Content Negotiation in HTTP [4]. 234 Feature set predicate 235 A function of an arbitrary feature collection value which 236 returns a Boolean result. A TRUE result is taken to mean 237 that the corresponding feature collection belongs to some 238 set of media feature handling capabilities defined by 239 this predicate. 241 Other terms used in this draft are defined in [2]. 243 3. Media feature combinations and capabilities 245 3.1 Media features 247 This memo assumes that individual media feature values are simple 248 atomic values: 250 o Boolean values. 252 o Enumerated values. 254 o Text string values (treated as atomic entities, like enumerated 255 value tokens). 257 o Numeric values (Integer or rational). 259 RFC nnnn A syntax for describing media feature sets 260 14 December 1998 262 These values all have the property that they can be compared for 263 equality ('='), and that numeric and ordered enumeration values can 264 be compared for less-than and greater-than relationship ('<=', 265 '>='). These basic comparison operations are used as the primitive 266 building blocks for more comprehensive capability expressions. 268 3.2 Media feature collections and sets 270 Any single media feature value can be thought of as just one 271 component of a feature collection that describes some instance of a 272 resource (e.g. a printed document, a displayed image, etc.). Such 273 a feature collection consists of a number of media feature tags 274 (each per [3]) and associated feature values. 276 A feature set is a set containing a number of feature collections. 277 Thus, a feature set can describe a number of different data 278 resource instances. These can correspond to different treatments 279 of a single data resource (e.g. different resolutions used for 280 printing a given document), a number of different data resources 281 subjected to a common treatment (e.g. the range of different images 282 that can be rendered on a given display), or some combination of 283 these (see examples below). 285 Thus, a description of a feature set can describe the capabilities 286 of a data resource or some entity that processes or renders a data 287 resource. 289 3.3 Media feature set descriptions 291 A feature set may be unbounded. For example, in principle, there 292 is no limit on the number of different documents that may be output 293 using a given printer. But to be practically useful, a feature set 294 description must be finite. 296 The general approach to describing feature sets is to start from 297 the assumption that anything is possible; i.e. the feature set 298 contains all possible document instances (feature collections). 299 Then constraints are applied that progressively remove document 300 instances from this set; e.g. for a monochrome printer, all 301 document instances that use colour are removed, or for a document 302 that must be rendered at some minimum resolution, all document 303 instances with lesser resolutions are removed from the set. The 304 mechanism used to remove document instances from the set is the 305 mathematical idea of a "relation"; i.e. a Boolean function (a 306 "predicate") that takes a feature collection parameter and returns 307 a Boolean value that is TRUE if the feature collection describes an 308 acceptable document instance, or FALSE if it describes one that is 309 excluded. 311 RFC nnnn A syntax for describing media feature sets 312 14 December 1998 314 P(C) 315 P(C) = TRUE <- : -> P(C) = FALSE 316 : 317 +----------:----------+ This box represents some 318 | : | set of feature collections (C) 319 | Included : Excluded | that is constrained by the 320 | : | predicate P. 321 +----------:----------+ 322 : 324 The result of applying a series of such constraints is a smaller 325 set of feature collections that represent some media handling 326 capability. Where the individual constraints are represented by 327 predicates that each describe some media handling capability, the 328 combined effect of these constraints is some subset of the 329 individual constraint capabilities that can be represented by a 330 predicate that is the logical-AND of the individual constraint 331 predicates. 333 3.4 Media feature combination scenario 335 This section develops some example scenarios, introducing the 336 notation that is defined formally in section 4. 338 3.4.1 Data resource options 340 The following expression describes a data resource that can be 341 displayed either: 342 (a) as a 750x500 pixel image using 15 colours, or 343 (b) at 150dpi on an A4 page. 345 (| (& (pix-x=750) (pix-y=500) (color=15) ) 346 (& (dpi>=150) (papersize=iso-A4) ) ) 348 3.4.2 Recipient capabilities 350 The following expression describes a receiving system that has: 351 (a) a screen capable of displaying 640*480 pixels and 16 million 352 colours (24 bits per pixel), 800*600 pixels and 64 thousand 353 colours (16 bits per pixel) or 1024*768 pixels and 256 colours 354 (8 bits per pixel), or 355 (b) a printer capable of rendering 300dpi on A4 paper. 357 (| (& (| (& (pix-x<=640) (pix-y<=480) (color<=16777216) ) 358 (& (pix-x<=800) (pix-y<=600) (color<=65535) ) 359 (& (pix-x<=1024) (pix-y<=768) (color<=256) ) ) 360 (media=screen) ) 361 (& (dpi=300) 362 (media=stationery) (papersize=iso-A4) ) ) 364 RFC nnnn A syntax for describing media feature sets 365 14 December 1998 367 Note that this expression says nothing about the colour or grey- 368 scale capabilities of the printer. In the scheme presented here, 369 it is presumed to be unconstrained in this respect (or, more 370 realistically, any such constraints are handled out-of-band by 371 anyone sending to this recipient). 373 3.4.3 Combined options 375 The following example describes the range of document 376 representations available when the resource described in the first 377 example above is sent to the recipient described in the second 378 example. This is the result of combining their capability feature 379 sets: 381 (| (& (pix-x=750) (pix-y=500) (color=15) ) 382 (& (dpi=300) (media=stationery) (papersize=iso-A4) ) ) 384 The feature set described by this expression is the intersection of 385 the sets described by the previous two capability expressions. 387 3.5 Feature set predicates 389 There are many ways of representing a predicate. The ideas in this 390 memo were inspired by the programming language Prolog [5], and its 391 use of predicates to describe sets of objects. 393 For the purpose of media feature description in networked 394 application protocols, the format used for LDAP search filters 395 [7,8] has been adopted, because it is a good match for the 396 requirements of capability identification, and has a very simple 397 structure that is easy to parse and process. 399 3.5.1 Comparison with directory search filters 401 Observe that a feature collection is similar to a directory entry, 402 in that it consists of a collection of named values. Further, the 403 semantics of the mechanism for selecting feature collections from a 404 feature set is in many respects similar to selection of directory 405 entries from a directory. 407 A feature set predicate used to describe media handling 408 capabilities is implicitly applied to some feature collection. 409 Within the predicate, members of the feature collection are 410 identified by their feature tags, and are compared with known 411 feature values. (Compare with the way an LDAP search filter is 412 applied to a directory entry, whose members are identified by 413 attribute type names, and compared with known attribute values.) 415 RFC nnnn A syntax for describing media feature sets 416 14 December 1998 418 For example, in: 420 (& (dpi>=150) (papersize=iso-A4) ) 422 the tokens 'dpi' and 'papersize' are feature tags, and '150' and 423 'iso-A4' are feature values. (In a corresponding LDAP search 424 filter, they would be directory entry attribute types and attribute 425 values.) 427 Differences between directory selection (per [7]) and feature set 428 selection are: 430 o Directory selection provides substring-, approximate- and 431 extensible- matching for attribute values. Such matching is not 432 provided for feature set selection. 434 o Directory selection may be based on the presence of an attribute 435 without regard to its value. Within the semantic framework 436 described by this document, Boolean-valued feature tests can be 437 used to provide a similar effect. 439 o Directory selection provides for matching rules that test for the 440 presence or absence of a named attribute type. 442 o Directory selection provides for matching rules which are 443 dependent upon the declared data type of an attribute value. 445 o Feature selection provides for the association of a quality value 446 with a feature predicate as a way of ranking the selected value 447 collections. 449 Within the semantic framework described by this document, Boolean- 450 valued feature tests can be used where presence tests would be used 451 in a directory search filter. 453 The idea of extensible matching and matching rules dependent upon 454 data types are facets of a problem not addressed by this memo, but 455 which do not necessarily affect the feature selection syntax. An 456 aspect that might bear on the syntax would be specification of an 457 explicit matching rule as part of a selection expression. 459 3.6 Describing preferences 461 A convenient way to describe preferences is by numeric "quality 462 values". 464 It has been suggested that numeric quality values are potentially 465 misleading if used as more than just a way of ranking options. For 466 the purposes of this memo, ranking of options is sufficient. 468 RFC nnnn A syntax for describing media feature sets 469 14 December 1998 471 Numeric quality values in the range 0 to 1, with up to 3 fractional 472 digits, are used to rank feature sets according to preference. 473 Higher values are preferred over lower values, and equal values are 474 presumed to be equally preferred. Beyond this, the actual number 475 used has no significance defined here. Arithmetic operations on 476 quality values are likely to produce unpredictable results unless 477 appropriate semantics have been defined for the context where such 478 operations are used. 480 In the absence of any explicitly applied quality value, a value of 481 "1" is assumed. 483 Using the notation defined later, a quality value may be attached 484 to any feature set predicate sub-expression: 486 (| (& (pix-x=750) (pix-y=500) (color=15) );q=0.8 487 (& (dpi>=150) (papersize=iso-A4) ) ;q=0.7 ) 489 Section 3.7 below explains that quality values attached to sub- 490 expressions are not always useful. 492 NOTE: the syntax for quality values used here taken from 493 that defined for HTTP 'Accept:' headers in RFC 2068 [9], 494 section 3.9. However, the use of quality values defined 495 here does not go as far as that defined in RFC 2068. 497 3.7 Combining preferences 499 The general problem of describing and combining preferences among 500 feature sets is very much more complex than simply describing 501 allowable feature sets. For example, given two feature sets: 502 (& (a1);q=0.8 (b1);q=0.7 ) 503 (& (a2);q=0.5 (b2);q=0.9 ) 505 where: 506 feature a1 is preferred over a2 507 feature b2 is preferred over b1 509 Which of these feature sets is preferred? In the absence of 510 additional information or assumptions, there is no generally 511 satisfactory answer to this. 513 The proposed resolution of this issue is simply to say that no 514 rules are provided for combining preference information. Applied 515 to the above example, any preference information about (a1) in 516 relation to (a2), or (b1) in relation to (b2) is not presumed to 517 convey information about preference of (& (a1) (b1) ) in relation 518 to (& (a2) (b2) ). 520 RFC nnnn A syntax for describing media feature sets 521 14 December 1998 523 In practical terms, this restricts the application of preference 524 information to top-level predicate clauses. A top-level clause 525 completely defines an allowable feature set; clauses combined by 526 logical-AND operators cannot be top-level clauses (see canonical 527 format for feature set predicates, described later). 529 NOTE: This memo does not apply specific meaning to 530 quality values or rules for combining them. Application 531 of such meanings and rules is not prohibited, but is seen 532 as an area for continuing research and experimentation. 534 An example of a design that uses extended quality value 535 semantics and combining operations is "Transparent 536 Content Negotiation in HTTP" [4]. Other work that also 537 extends quality values is the content negotiation 538 algorithm in the Apache HTTP server [14]. 540 4. Feature set representation 542 The foregoing sections have described a framework for defining 543 feature sets with predicates applied to feature collections. This 544 section presents a concrete representation for feature set 545 predicates. 547 4.1 Textual representation of predicates 549 The text representation of a feature set is based on RFC 2254 "The 550 String Representation of LDAP Search Filters" [8], excluding those 551 elements not relevant to feature set selection (discussed above), 552 and adding elements specific to feature set selection (e.g. options 553 to associate quality values with predicates). 555 The format of a feature predicate is defined by the production for 556 "filter" in the following, using the syntax notation and core rules 557 of [10]: 559 filter = "(" filtercomp ")" *( ";" parameter ) 560 parameter = "q" "=" qvalue 561 / ext-param "=" ext-value 562 qvalue = ( "0" [ "." 0*3DIGIT ] ) 563 / ( "1" [ "." 0*3("0") ] ) 564 ext-param = ALPHA *( ALPHA / DIGIT / "-" ) 565 ext-value = 566 filtercomp = and / or / not / item 567 and = "&" filterlist 568 or = "|" filterlist 569 not = "!" filter 570 filterlist = 1*filter 572 RFC nnnn A syntax for describing media feature sets 573 14 December 1998 575 item = simple / set / ext-pred 576 set = attr "=" "[" setentry *( "," setentry ) "]" 577 setentry = value "/" range 578 range = value ".." value 579 simple = attr filtertype value 580 filtertype = equal / greater / less 581 equal = "=" 582 greater = ">=" 583 less = "<=" 584 attr = ftag 585 value = fvalue 586 ftag = 587 fvalue = Boolean / number / token / string 588 Boolean = "TRUE" / "FALSE" 589 number = integer / rational 590 integer = [ "+" / "-" ] 1*DIGIT 591 rational = [ "+" / "-" ] 1*DIGIT "/" 1*DIGIT 592 token = ALPHA *( ALPHA / DIGIT / "-" ) 593 string = DQUOTE *(%x20-21 / %x23-7E) DQUOTE 594 ; quoted string of SP and VCHAR without DQUOTE 595 ext-pred = 597 (Subject to constraints imposed by the protocol that carries a 598 feature predicate, whitespace characters may appear between any 599 pair of syntax elements or literals that appear on the right hand 600 side of these productions.) 602 As described, the syntax permits parameters (including quality 603 values) to be attached to any "filter" value in the predicate (not 604 just top-level values). Only top-level quality values are 605 recognized. If no explicit quality value is given, a value of 606 '1.0' is applied. 608 NOTE: The flexible approach to quality values and other 609 parameter values in this syntax has been adopted for two 610 reasons: (a) to make it easy to combine separately 611 constructed feature predicates, and (b) to provide an 612 extensible tagging mechanism for possible future use (for 613 example, to incorporate a conceivable requirement to 614 explicitly specify a matching rule). 616 4.2 Interpretation of feature predicate syntax 618 A feature set predicate is described by the syntax production for 619 'filter'. 621 RFC nnnn A syntax for describing media feature sets 622 14 December 1998 624 4.2.1 Filter syntax 626 A 'filter' is defined as either a simple feature comparison 627 ('item', see below) or a composite filter ('and', 'or', 'not'), 628 decorated with optional parameter values (including "q=qvalue"). 630 A composite filter is a logical combination of one or more 'filter' 631 values: 633 (& f1 f2 ... fn ) is the logical-AND of the filter values 'f1', 634 'f2' up to 'fn'. That is, it is satisfied by 635 any feature collection that satisfies all of 636 the predicates represented by those filters. 638 (| f1 f2 ... fn ) is the logical-OR of the filter values 'f1', 639 'f2' up to 'fn'. That is, it is satisfied by 640 any feature collection that satisfies at least 641 one of the predicates represented by those 642 filters. 644 (! f1 ) is the logican negation of the filter value 645 'f1'. That is, it is satusfied by any feature 646 collection that does NOT satisfy the predicate 647 represented by 'f1'. 649 4.2.2 Feature comparison 651 A feature comparison is defined by the 'simple' option of the 652 syntax production for 'item'. There are three basic forms: 654 (ftag=value) compares the feature named 'ftag' (in some 655 feature collection that is being tested) with 656 the supplied 'value', and matches if they are 657 equal. This can be used with any type of 658 feaure value (numeric, Boolean, token or 659 string). 661 (ftag<=value) compares the numeric feature named 'ftag' with 662 the supplied 'value', and matches if the 663 feature is less than or equal to 'value'. 665 (ftag>=value) compares the numeric feature named 'ftag' with 666 the supplied 'value', and matches if the 667 feature is greater than or equal to 'value'. 669 RFC nnnn A syntax for describing media feature sets 670 14 December 1998 672 Less-than and greater-than tests may be performed with feature 673 values that are not numeric but, in general, they amount to 674 equality tests as there is no ordering relation on non-numeric 675 values defined by this specification. Specific applications may 676 define such ordering relations on specific feature tags, but such 677 definitions are beyond the scope of (and not required for 678 conformance to) this specification. 680 4.2.3 Feature tags 682 Feature tags conform to the syntax given in "Media Feature Tag 683 Registration Procedure" [3]. Feature tags used to describe 684 capabilities should be registered using the procedures described in 685 that memo. Unregistered feature tags should be allocated in the 686 "URI tree", as discussed in the media feature registration 687 procedures memo [3]. 689 If an unrecognized feature tag is encountered in the course of 690 feature set predicate processing, it should be still be processed 691 as a legitimate feature tag. The feature set matching rules are 692 designed to allow new feature tags to be introduced without 693 affecting the validity of existing capability assertions. 695 4.2.4 Feature values 697 A feature may have a number, Boolean, token or string value. 699 4.2.4.1 Boolean values 701 A Boolean is simply a token with two predefined values: "TRUE" and 702 "FALSE". (Upper- or lower- case letters may be used in any 703 combination.) 705 4.2.4.2 Numeric values 707 A numeric value is either a decimal integer, optionally preceded by 708 a "+" or "-" sign, or rational number. 710 A rational number is expressed as "n/m", optionally preceded by a 711 "+" or "-" sign. The "n" and "m" are unsigned decimal integers, 712 and the value represented by "n/m" is "n" divided by "m". Thus, 713 the following are all valid representations of the number 1.5: 715 3/2 716 +15/10 717 600/400 719 RFC nnnn A syntax for describing media feature sets 720 14 December 1998 722 Thus, several rational number forms may express the same value. A 723 canonical form of rational number is obtained by finding the 724 highest common factor of "n" and "m", and dividing both "n" and "m" 725 by that value. 727 A simple integer value may be used anywhere in place of a rational 728 number. Thus, we have: 730 +5 is equivalent to +5/1 or +50/10, etc. 731 -2 is equivalent to -2/1 or -4/2, etc. 733 Any sign in a rational number must precede the entire number, so 734 the following are not rational numbers: 736 3/+2, 15/-10 (**NOT VALID**) 738 4.2.4.3 Token values 740 A token value is any sequence of letters, digits and '-' characters 741 that conforms to the syntax for 'token' given above. It is a name 742 that stands for some (unspecified) value. 744 4.2.4.4 String values 746 A string value is any sequence of characters enclosed in double 747 quotes that conform to the syntax for 'string' given above. 749 The semantics of string defined by this memo are the same as those 750 for a token value. But a string allows a far greater variety of 751 internal formats, and specific applications may choose to interpret 752 the content in ways that go beyond those given here. Where such 753 interpretation is possible, the allowed string formats and the 754 corresponding interpretations should be indicated in the media 755 feature registration (per [3]). 757 4.2.5 Notational conveniences 759 The 'set' option of the syntax production for 'item' is simply a 760 shorthand notation for some common situations that can be expressed 761 using 'simple' constructs. Occurrences of 'set' items can 762 eliminated by applying the following identities: 764 T = [ E1, E2, ... En ] --> (| (T=[E1]) (T=[E2]) ... (T=[En]) ) 765 (T=[R1..R2]) --> (& (T>=R1) (T<=R2) ) 766 (T=[E]) --> (T=E) 768 RFC nnnn A syntax for describing media feature sets 769 14 December 1998 771 Examples: 773 The expression: 774 ( paper-size=[A4,B4] ) 775 can be used to express a capability to print documents on either A4 776 or B4 sized paper. 778 The expression: 779 ( width=[4..17/2] ) 780 might be used to express a capability to print documents that are 781 anywhere between 4 and 8.5 inches wide. 783 The set construct is designed so that enumerated values and ranges 784 can be combined in a single expression, e.g.: 785 ( width=[3,4,6..17/2] ) 787 4.3 Feature set definition example 789 The following is an example of a feature predicate that describes a 790 number of image size and resolution combinations, presuming the 791 registration and use of 'Pix-x', 'Pix-y', 'Res-x' and 'Res-y' 792 feature tags: 794 (| (& (Pix-x=1024) 795 (Pix-y=768) 796 (| (& (Res-x=150) (Res-y=150) ) 797 (& (Res-x=150) (Res-y=300) ) 798 (& (Res-x=300) (Res-y=300) ) 799 (& (Res-x=300) (Res-y=600) ) 800 (& (Res-x=600) (Res-y=600) ) ) ) 801 (& (Pix-x=800) 802 (Pix-y=600) 803 (| (& (Res-x=150) (Res-y=150) ) 804 (& (Res-x=150) (Res-y=300) ) 805 (& (Res-x=300) (Res-y=300) ) 806 (& (Res-x=300) (Res-y=600) ) 807 (& (Res-x=600) (Res-y=600) ) ) ) ;q=0.9 808 (& (Pix-x=640) 809 (Pix-y=480) 810 (| (& (Res-x=150) (Res-y=150) ) 811 (& (Res-x=150) (Res-y=300) ) 812 (& (Res-x=300) (Res-y=300) ) 813 (& (Res-x=300) (Res-y=600) ) 814 (& (Res-x=600) (Res-y=600) ) ) ) ;q=0.8 ) 816 RFC nnnn A syntax for describing media feature sets 817 14 December 1998 819 5. Matching feature sets 821 This section presents a procedure for combining feature sets to 822 determine the common feature collections to which they refer, if 823 there are any. Making a selection from the possible feature 824 collections (based on q-values or otherwise) is not covered here. 826 Matching a feature set to some given feature collection is 827 esentially very straightforward: the feature set predicate is 828 simply evaluated for the given feature collection, and the result 829 (TRUE or FALSE) indicates whether the feature collection matches 830 the capabilities, and the associated quality value can be used for 831 selecting among alternative feature collections. 833 Matching a feature set to some other feature set is less 834 straightforward. Here, the problem is to determine whether or not 835 there is at least one feature collection that matches both feature 836 sets (e.g. is there an overlap between the feature capabilities of 837 a given file format and the feature capabilities of a given 838 recipient?) 840 This feature set matching is accomplished by logical manipulation 841 of the predicate expressions as described in the following sub- 842 sections. 844 For this procedure to work reliably, the predicates must be reduced 845 to a canonical form. The canonical form used here is "disjunctive 846 normal form". A syntax for disjunctive normal form is: 848 filter = orlist 849 orlist = "(" "|" andlist ")" / term 850 andlist = "(" "&" termlist ")" / term 851 termlist = 1*term 852 term = "(" "!" simple ")" / simple 854 where "simple" is as described previously in section 4.1. Thus, 855 the canonicalized form has at most three levels: an outermost 856 "(|...)" disjunction of "(&...)" conjunctions of possibly negated 857 feature value tests. 859 NOTE 861 The usual canonical form for predicate expressions is 862 "clausal form". Procedures for converting general 863 predicate expressions are given in [5] (section 10.2), 864 [11] (section 2.13) and [12] (section 5.3.2). 866 "Clausal form" for a predicate is similar to "conjunctive 867 normal form" for a proposition, being a conjunction 868 (logical AND) of disjunctions (logical ORs). The related 870 RFC nnnn A syntax for describing media feature sets 871 14 December 1998 873 form used here, better suited to feature set matching, is 874 "disjunctive normal form", which is a logical disjunction 875 (OR) of conjunctions (ANDs). In this form, the aim of 876 feature set matching is to show that at least one of the 877 disjunctions can be satisfied by some feature collection. 879 Is this consideration of canonical forms really required? 880 After all, the feature predicates are just Boolean 881 expressions, aren't they? Well, no: a feature predicate 882 is a Boolean expression containing primitive feature 883 value tests (comparisons), represented by 'item' in the 884 feature predicate syntax. If these tests could all be 885 assumed to be independently TRUE or FALSE, then each 886 could be regarded as an atomic proposition, and the whole 887 predicate could be dealt with according to the 888 (relatively simple) rules of Propositional Calculus. 890 But, in general, the same feature tag may appear in more 891 than one predicate 'item', so the tests cannot be 892 regarded as independent. Indeed, interdependence is 893 needed in any meaningful application of feature set 894 matching, and it is important to capture these 895 dependencies (e.g. does the set of resolutions that a 896 sender can supply overlap the set of resolutions that a 897 recipient can handle?). Thus, we have to deal with 898 elements of the Predicate Calculus, with some additional 899 rules for algebraic manipulation. 901 A description of both the Propositional and Predicate 902 calculi can be found in [12]. 904 We aim to show that these additional rules are more 905 unfamiliar than complicated. The construction and use of 906 feature predicates actually avoids some of the complexity 907 of dealing with fully-generalized Predicate Calculus. 909 5.1 Feature set matching strategy 911 The overall strategy for matching feature sets, expanded below, is: 913 1. Formulate the feature set match hypothesis. 915 2. Replace "set" expressions with equivalent comparisons. 917 3. Move logical negations "inwards", so that they are all applied 918 directly to feature comparisons. 920 4. Eliminate logical negations, and express all feature comparisons 921 in terms of just four comparison operators 923 RFC nnnn A syntax for describing media feature sets 924 14 December 1998 926 5. Reduce the hypothesis to canonical disjunctive normal form (a 927 disjunction of conjunctions). 929 6. For each of the conjunctions, attempt to show that it can be 930 satisfied by some feature collection. 932 6.1 Separate the feature value tests into independent feature 933 groups, such that each group contains tests involving just 934 one feature tag. Thus, no predicate in a feature group 935 contains a feature tag that also appears in some other 936 group. 938 6.2 For each feature group, merge the various constraints to a 939 minimum form. This process either yields a reduced 940 expression for the allowable range of feature values, or an 941 expression containing the value FALSE, which is an 942 indication that no combination of feature values can satisfy 943 the constraints (in which case the corresponding conjunction 944 can never be satisfied). 946 7. If the remaining disjunction contains at least one satisfiable 947 conjunction, then the constraints are shown to be satisfiable. 949 The final expression obtained by this procedure, if it is non- 950 empty, can be used as a statement of the resulting feature set for 951 possible further matching operations. That is, it can be used as a 952 starting point for combining with additional feature set constraint 953 predicate to determine a feature set that is constrained by the 954 capabilities of several entities in a message transfer path. 956 NOTE: as presented, the feature matching process 957 evaluates (and stores) all conjunctions of the 958 disjunctive normal form before combining feature tag 959 comparisons and eliminating unsatisfiable conjunctions. 960 For low-memory systems an alternative approach is 961 possible, in which each normal form conjunction is 962 enumerated and evaluated in turn, with only those that 963 are satisfiable being retained for further use. 965 5.2 Formulating the goal predicate 967 A formal statement of the problem we need to solve can be given as: 968 given two feature set predicates, '(P x)' and '(Q x)', where 'x' is 969 some feature collection, we wish to establish the truth or 970 otherwise of the proposition: 972 EXISTS(x) : (P x) AND (Q x) 974 i.e. does there exist a feature collection 'x' that satisfies both 975 predicates, 'P' and 'Q'? 977 RFC nnnn A syntax for describing media feature sets 978 14 December 1998 980 Then, if feature sets to be matched are described by predicates 'P' 981 and 'Q', the problem is to determine if there is any feature set 982 satisfying the goal predicate: 984 (& P Q) 986 i.e. to determine whether the set thus described is non-empty. 988 5.3 Replace set expressions 990 Replace all "set" instances in the goal predicate with equivalent 991 "simple" forms: 993 T = [ E1, E2, ... En ] --> (| (T=[E1]) (T=[E2]) ... (T=[En]) ) 994 (T=[R1..R2]) --> (& (T>=R1) (T<=R2) ) 995 (T=[E]) --> (T=E) 997 5.4 Move logical negations inwards 999 The goal of this step is to move all logical negations so that they 1000 are applied directly to feature comparisons. During the following 1001 step, these logical negations are replaced by alternative 1002 comparison operators. 1004 This is achieved by repeated application of the following 1005 transformation rules: 1007 (! (& A1 A2 ... Am ) ) --> (| (! A1 ) (! A2 ) ... (! Am ) ) 1008 (! (| A1 A2 ... Am ) ) --> (& (! A1 ) (! A2 ) ... (! Am ) ) 1009 (! (! A ) ) --> A 1011 The first two rules are extended forms of De Morgan's law, and the 1012 third is elimination of double negatives. 1014 5.5 Replace comparisons and logical negations 1016 The predicates are derived from the syntax described previously, 1017 and contain primitive value testing functions '=', '<=', '>='. The 1018 primitive tests have a number of well known properties that are 1019 exploited to reach a useful conclusion; e.g. 1021 (A = B) & (B = C) => (A = C) 1022 (A <= B) & (B <= C) => (A <= C) 1024 These rules form a core body of logic statements against which the 1025 goal predicate can be evaluated. The form in which these 1026 statements are expressed is important to realizing an effective 1027 predicate matching algorithm (i.e. one that doesn't loop or fail to 1028 find a valid result). The first step in formulating these rules is 1029 to simplify the framework of primitive predicates. 1031 RFC nnnn A syntax for describing media feature sets 1032 14 December 1998 1034 The primitive predicates from which feature set definitions are 1035 constructed are '=', '<=' and '>='. Observe that, given any pair 1036 of feature values, the relationship between them must be exactly 1037 one of the following: 1039 (LT a b): 'a' is less than 'b'. 1040 (EQ a b): 'a' is equal to 'b'. 1041 (GT a b): 'a' is greater than 'b'. 1042 (NE a b): 'a' is not equal to 'b', and is not less than 1043 or greater than 'b'. 1045 (The final case arises when two values are compared for which no 1046 ordering relationship is defined, and the values are not equal; 1047 e.g. two unequal string values.) 1049 These four cases can be captured by a pair of primitive predicates: 1051 (LE a b): 'a' is less than or equal to 'b'. 1052 (GE a b): 'a' is greater than or equal to 'b'. 1054 The four cases described above are prepresented by the following 1055 combinations of primitive predicate values: 1057 (LE a b) (GE a b) | relationship 1058 ---------------------------------- 1059 TRUE FALSE | (LT a b) 1060 TRUE TRUE | (EQ a b) 1061 FALSE TRUE | (GT a b) 1062 FALSE FALSE | (NE a b) 1064 Thus, the original 3 primitive tests can be translated to 1065 combinations of just LE and GE, reducing the number of additional 1066 relationships that must be subsequently captured: 1068 (a <= b) --> (LE a b) 1069 (a >= b) --> (GE a b) 1070 (a = b) --> (& (LE a b) (GE a b) ) 1072 Further, logical negations of the original 3 primitive tests can be 1073 eliminated by the introduction of 'not-greater' and 'not-less' 1074 primitives 1076 (NG a b) == (! (GE a b) ) 1077 (NL a b) == (! (LE a b) ) 1079 using the following transformation rules: 1081 (! (a = b) ) --> (| (NL a b) (NG a b) ) 1082 (! (a <= b) ) --> (NL a b) 1083 (! (a >= b) ) --> (NG a b) 1085 RFC nnnn A syntax for describing media feature sets 1086 14 December 1998 1088 Thus, we have rules to transform all comparisons and logical 1089 negations into combinations of just 4 relational operators. 1091 5.6 Conversion to canonical form 1093 NOTE: Logical negations have been eliminated in the 1094 previous step. 1096 Expand bracketed disjunctions, and flatten bracketed conjunctions 1097 and disjunctions: 1099 (& (| A1 A2 ... Am ) B1 B2 ... Bn ) 1100 --> (| (& A1 B1 B2 ... Bn ) 1101 (& A2 B1 B2 ... Bn ) 1102 : 1103 (& Am B1 B2 ... Bn ) ) 1104 (& (& A1 A2 ... Am ) B1 B2 ... Bn ) 1105 --> (& A1 A2 ... Am B1 B2 ... Bn ) 1106 (| (| A1 A2 ... Am ) B1 B2 ... Bn ) 1107 --> (| A1 A2 ... Am B1 B2 ... Bn ) 1109 The result is in "disjunctive normal form", a disjunction of 1110 conjunctions: 1112 (| (& S11 S12 ... ) 1113 (& S21 S22 ... ) 1114 : 1115 (& Sm1 Sm2 ... Smn ) ) 1117 where the "Sij" elements are simple feature comparison forms 1118 constructed during the step at section 7.1.4. Each term within the 1119 top-level "(|...)" construct represents a single possible feature 1120 set that satisfies the goal. Note that the order of entries within 1121 the top-level '(|...)', and within each '(&...)', is immaterial. 1123 From here on, each conjunction '(&...)' is processed separately. 1124 Only one of these needs to be satisfiable for the original goal to 1125 be satisfiable. 1127 (A textbook conversion to clausal form [5,11] uses slightly 1128 different rules to yield a "conjunctive normal form".) 1130 5.7 Grouping of feature predicates 1132 NOTE: Remember that from here on, each conjunction is 1133 treated separately. 1135 Each simple feature predicate contains a "left-hand" feature tag 1136 and a "right-hand" feature value with which it is compared. 1138 RFC nnnn A syntax for describing media feature sets 1139 14 December 1998 1141 To arrange these into independent groups, simple predicates are 1142 grouped according to their left hand feature tag ('f'). 1144 5.8 Merge single-feature constraints 1146 Within each group, apply the predicate simplification rules given 1147 below to eliminate redundant single-feature constraints. All 1148 single-feature predicates are reduced to an equality or range 1149 constraint on that feature, possibly combined with a number of non- 1150 equality statements. 1152 If the constraints on any feature are found to be contradictory 1153 (i.e. resolved to FALSE according to the applied rules), the 1154 containing conjunction is not satisfiable and may be discarded. 1155 Otherwise, the resulting description is a minimal form of that 1156 particular conjunction of the feature set definition. 1158 5.8.1 Rules for simplifying ordered values 1160 These rules are applicable where there is an ordering relationship 1161 between the given values 'a' and 'b': 1163 (LE f a) (LE f b) --> (LE f a), a<=b 1164 (LE f b), otherwise 1165 (LE f a) (GE f b) --> FALSE, a FALSE, a<=b 1167 (LE f a) (NG f b) --> (LE f a), a (GE f a), a>=b 1171 (GE f b), otherwise 1172 (GE f a) (NL f b) --> (GE f a) a>b 1173 (NL f b), otherwise 1174 (GE f a) (NG f b) --> FALSE, a>=b 1176 (NL f a) (NL f b) --> (NL f a), a>=b 1177 (NL f b), otherwise 1178 (NL f a) (NG f b) --> FALSE, a>=b 1180 (NG f a) (NG f b) --> (NG f a), a<=b 1181 (NG f b), otherwise 1183 RFC nnnn A syntax for describing media feature sets 1184 14 December 1998 1186 5.8.2 Rules for simplifying unordered values 1188 These rules are applicable where there is no ordering relationship 1189 applicable to the given values 'a' and 'b': 1191 (LE f a) (LE f b) --> (LE f a), a=b 1192 FALSE, otherwise 1193 (LE f a) (GE f b) --> FALSE, a!=b 1194 (LE f a) (NL f b) --> (LE f a) a!=b 1195 FALSE, otherwise 1196 (LE f a) (NG f b) --> (LE f a), a!=b 1197 FALSE, otherwise 1199 (GE f a) (GE f b) --> (GE f a), a=b 1200 FALSE, otherwise 1201 (GE f a) (NL f b) --> (GE f a) a!=b 1202 FALSE, otherwise 1203 (GE f a) (NG f b) --> (GE f a) a!=b 1204 FALSE, otherwise 1206 (NL f a) (NL f b) --> (NL f a), a=b 1207 (NL f a) (NG f b) --> (NL f a), a=b 1209 (NG f a) (NG f b) --> (NG f a), a=b 1211 6. Other features and issues 1213 6.1 Named and auxiliary predicates 1215 Named and auxiliary predicates can serve two purposes: 1217 (a) making complex predicates easier to write and understand, and 1219 (b) providing a possible basis for naming and registering feature 1220 sets. 1222 6.1.1 Defining a named predicate 1224 A named predicate definition has the following form: 1226 named-pred = "(" fname *pname ")" ":-" filter 1227 fname = ftag ; Feature predicate name 1228 pname = token ; Formal parameter name 1230 'fname' is the name of the predicate. 1232 'pname' is the name of a formal parameter which may appear in the 1233 predicate body, and which is replaced by some supplied value when 1234 the predicate is invoked. 1236 RFC nnnn A syntax for describing media feature sets 1237 14 December 1998 1239 'filter' is the predicate body. It may contain references to the 1240 formal parameters, and may also contain references to feature tags 1241 and other values defined in the environment in which the predicate 1242 is invoked. References to formal parameters may appear anywhere 1243 where a reference to a feature tag ('ftag') is permitted by the 1244 syntax for 'filter'. 1246 The only specific mechanism defined by this memo for introducing a 1247 named predicate into a feature set definition is the "auxiliary 1248 predicate" described later. Specific negotiating protocols or 1249 other specifications may define other mechanisms. 1251 NOTE: There has been some suggestion of creating a 1252 registry for feature sets as well as individual feature 1253 values. Such a registry might be used to introduce named 1254 predicates corresponding to these feature sets into the 1255 environment of a capability assertion. Further 1256 discussion of this idea is beyond the scope of this memo. 1258 6.1.2 Invoking named predicates 1260 Assuming a named predicate has been introduced into the environment 1261 of some other predicate, it can be invoked by a filter 'ext-pred' 1262 of the form: 1264 ext-pred = fname *param 1265 param = expr 1267 The number of parameters must match the definition of the named 1268 predicate that is invoked. 1270 6.1.3 Auxiliary predicates in a filter 1272 A auxiliary predicate is attached to a filter definition by the 1273 following extension to the "filter" syntax: 1275 filter =/ "(" filtercomp *( ";" parameter ) ")" 1276 "where" 1*( named-pred ) "end" 1278 The named predicates introduced by "named-pred" are visible from 1279 the body of the "filtercomp" of the filter to which they are 1280 attached, but are not visible from each other. They all have 1281 access to the same environment as "filter", plus their own formal 1282 parameters. (Normal scoping rules apply: a formal parameter with 1283 the same name as a value in the environment of "filter" effectively 1284 hides the environment value from the body of the predicate to which 1285 it applies.) 1287 NOTE: Recursive predicates are not permitted. The 1288 scoping rules should ensure this. 1290 RFC nnnn A syntax for describing media feature sets 1291 14 December 1998 1293 6.1.4 Feature matching with named predicates 1295 The preceding procedures can be extended to deal with named 1296 predicates simply by instantiating (i.e. substituting) the 1297 predicates wherever they are invoked, before performing the 1298 conversion to disjunctive normal form. In the absence of recursive 1299 predicates, this procedure is guaranteed to terminate. 1301 When substituting the body of a precdicate at its point of 1302 invocation, instances of formal parameters within the predicate 1303 body must be replaced by the corresponding actual parameter from 1304 the point of invocation. 1306 6.1.4 Example 1308 This example restates that given in section 4.3 using an auxiliary 1309 predicate named 'Res': 1311 (| (& (Pix-x=1024) (Pix-y=768) (Res Res-x Res-y) ) 1312 (& (Pix-x=800) (Pix-y=600) (Res Res-x Res-y) );q=0.9 1313 (& (Pix-x=640) (Pix-y=480) (Res Res-x Res-y) );q=0.8 ) 1314 where 1315 (Res Res-x Res-y) :- 1316 (| (& (Res-x=150) (Res-y=150) ) 1317 (& (Res-x=150) (Res-y=300) ) 1318 (& (Res-x=300) (Res-y=300) ) 1319 (& (Res-x=300) (Res-y=600) ) 1320 (& (Res-x=600) (Res-y=600) ) ) 1321 end 1323 Note that the formal parameters of "Res", "Res-x" and "Res-y", 1324 prevent the body of the named predicate from referencing similarly- 1325 named feature values. 1327 6.2 Unit designations 1329 In some exceptional cases, there may be differing conventions for 1330 the units of measurement of a given feature. For example, 1331 resolution is commonly expressed as dots per inch (dpi) or dots per 1332 centimetre (dpcm) in different applications (e.g. printing vs 1333 faxing). 1335 In such cases, a unit designator may be appended to a feature value 1336 according to the conventions indicated below (see also [3]). These 1337 considerations apply only to features with numeric values. 1339 RFC nnnn A syntax for describing media feature sets 1340 14 December 1998 1342 Every feature tag has a standard unit of measurement. Any 1343 expression of a feature value that uses this unit is given without 1344 a unit designation -- this is the normal case. When the feature 1345 value is expressed in some other unit, a unit designator is 1346 appended to the numeric feature value. 1348 The registration of a feature tag indicates the standard unit of 1349 measurement for a feature, and also any alternate units and 1350 corresponding unit designators that may be used, according to [3]. 1352 Thus, if the standard unit of measure for resolution is 'dpcm', 1353 then the feature predicate '(res=200)' would be used to indicate a 1354 resolution of 200 dots-per-centimetre, and '(res=72dpi)' might be 1355 used to indicate 72 dots-per-inch. 1357 Unit designators are accommodated by the following extension to the 1358 feature predicate syntax: 1360 fvalue =/ number *WSP token 1362 When performing feature set matching, feature comparisons with and 1363 without unit designators, or feature comparisons with different 1364 unit designators, are treated as if they were different features. 1365 Thus, the feature predicate '(res=200)' would not, in general, fail 1366 to match with the predicate '(res=200dpi)'. 1368 NOTE: 1370 A protocol processor with specific knowledge of the 1371 feature and units concerned might recognize the 1372 relationship between the feature predicates in the above 1373 example, and fail to match these predicates. 1375 This appears to be a natural behaviour in this simple 1376 example, but can cause additional complexity in more 1377 general cases. Accordingly, this is not considered to be 1378 required or normal behaviour. It is presumed that an 1379 application concerned will ensure consistent feature 1380 processing by adopting a consistent unit for any given 1381 feature. 1383 6.3 Unknown feature value data types 1385 This memo has dealt with feature values that have well-understood 1386 comparison properties: numbers, with equality, less-than, greater- 1387 than relationships, and other values with equality relationships 1388 only. 1390 RFC nnnn A syntax for describing media feature sets 1391 14 December 1998 1393 Some feature values may have comparison operations that are not 1394 covered by this framework. For example, strings containing multi- 1395 part version numbers: "x.y.z". Such feature comparisons are not 1396 covered by this memo. 1398 Specific applications may recognize and process feature tags that 1399 are associated with such values. Future work may define ways to 1400 introduce new feature value data types in a way that allows them to 1401 be used by applications that do not contain built-in knowledge of 1402 their properties. 1404 7. Examples and additional comments 1406 7.1 Worked example 1408 This example considers sending a document to a high-end black-and- 1409 white fax system with the following receiver capabilities: 1411 (& (dpi=[200,300]) 1412 (grey=2) (color=0) 1413 (image-coding=[MH,MR]) ) 1415 Turning to the document itself, assume it is available to the 1416 sender in three possible formats, A4 high resolution, B4 low 1417 resolution and A4 high resolution colour, described by: 1419 (& (dpi=300) 1420 (grey=2) 1421 (image-coding=MR) ) 1423 (& (dpi=200) 1424 (grey=2) 1425 (image-coding=[MH,MMR]) ) 1427 (& (dpi=300) (dpi-xyratio=1) 1428 (color<=256) 1429 (image-coding=JPEG) ) 1431 RFC nnnn A syntax for describing media feature sets 1432 14 December 1998 1434 These three image formats can be combined into a composite 1435 capability statement by a logical-OR operation (to describe 1436 format-1 OR format-2 OR format-3): 1438 (| (& (dpi=300) 1439 (grey=2) 1440 (image-coding=MR) ) 1441 (& (dpi=200) 1442 (grey=2) 1443 (image-coding=[MH,MMR]) ) 1444 (& (dpi=300) 1445 (color<=256) 1446 (image-coding=JPEG) ) ) 1448 The composite document description can be matched with the receiver 1449 capability description by combining the capability descriptions 1450 with a logical AND operation: 1452 (& (& (dpi=[200,300]) 1453 (grey=2) (color=0) 1454 (image-coding=[MH,MR]) ) 1455 (| (& (dpi=300) 1456 (grey=2) 1457 (image-coding=MR) ) 1458 (& (dpi=200) 1459 (grey=2) 1460 (image-coding=[MH,MMR]) ) 1461 (& (dpi=300) 1462 (color<=256) 1463 (image-coding=JPEG) ) ) ) 1465 --> Expand value-set notation: 1467 (& (& (| (dpi=200) (dpi=300) ) 1468 (grey=2) (color=0) 1469 (| (image-coding=MH) (image-coding=MR) ) ) 1470 (| (& (dpi=300) 1471 (grey=2) 1472 (image-coding=MR) ) 1473 (& (dpi=200) 1474 (grey=2) 1475 (| (image-coding=MH) (image-coding=MMR) ) ) 1476 (& (dpi=300) 1477 (color<=256) 1478 (image-coding=JPEG) ) ) ) 1480 RFC nnnn A syntax for describing media feature sets 1481 14 December 1998 1483 -->Flatten nested '(&...)': 1485 (& (| (dpi=200) (dpi=300) ) 1486 (grey=2) (color=0) 1487 (| (image-coding=MH) (image-coding=MR) ) 1488 (| (& (dpi=300) 1489 (grey=2) 1490 (image-coding=MR) ) 1491 (& (dpi=200) 1492 (grey=2) 1493 (| (image-coding=MH) (image-coding=MMR) ) ) 1494 (& (dpi=300) 1495 (color<=256) 1496 (image-coding=JPEG) ) ) ) 1498 --> (distribute '(&...)' over inner '(|...)'): 1500 (& (| (dpi=200) (dpi=300) ) 1501 (grey=2) (color=0) 1502 (| (image-coding=MH) (image-coding=MR) ) 1503 (| (& (dpi=300) (grey=2) (image-coding=MR) ) 1504 (& (dpi=200) (grey=2) (image-coding=MH) ) 1505 (& (dpi=200) (grey=2) (image-coding=MMR) ) 1506 (& (dpi=300) (color<=256) (image-coding=JPEG) ) ) ) 1508 --> continue to distribute '(&...)' over '(|...)', and flattening 1509 nested '(&...)' and '(|...)' ...: 1511 (| (& (dpi=200) (grey=2) (color=0) (image-coding=MH) 1512 (| (& (dpi=300) (grey=2) (image-coding=MR) ) 1513 (& (dpi=200) (grey=2) (image-coding=MH) ) 1514 (& (dpi=200) (grey=2) (image-coding=MMR) ) 1515 (& (dpi=300) (color<=256) (image-coding=JPEG) ) ) ) 1516 (& (dpi=200) (grey=2) (color=0) (image-coding=MR) 1517 (| (& (dpi=300) (grey=2) (image-coding=MR) ) 1518 (& (dpi=200) (grey=2) (image-coding=MH) ) 1519 (& (dpi=200) (grey=2) (image-coding=MMR) ) 1520 (& (dpi=300) (color<=256) (image-coding=JPEG) ) ) ) 1521 (& (dpi=300) (grey=2) (color=0) (image-coding=MH) 1522 (| (& (dpi=300) (grey=2) (image-coding=MR) ) 1523 (& (dpi=200) (grey=2) (image-coding=MH) ) 1524 (& (dpi=200) (grey=2) (image-coding=MMR) ) 1525 (& (dpi=300) (color<=256) (image-coding=JPEG) ) ) ) 1526 (& (dpi=300) (grey=2) (color=0) (image-coding=MR) 1527 (| (& (dpi=300) (grey=2) (image-coding=MR) ) 1528 (& (dpi=200) (grey=2) (image-coding=MH) ) 1529 (& (dpi=200) (grey=2) (image-coding=MMR) ) 1530 (& (dpi=300) (color<=256) (image-coding=JPEG) ) ) ) ) 1532 RFC nnnn A syntax for describing media feature sets 1533 14 December 1998 1535 --> ... until normal form is achieved: 1537 (| (& (dpi=200) (grey=2) (color=0) (image-coding=MH) 1538 (dpi=300) (grey=2) (image-coding=MR) ) 1539 (& (dpi=200) (grey=2) (color=0) (image-coding=MR) 1540 (dpi=300) (grey=2) (image-coding=MR) ) 1541 (& (dpi=300) (grey=2) (color=0) (image-coding=MH) 1542 (dpi=300) (grey=2) (image-coding=MR) ) 1543 (& (dpi=300) (grey=2) (color=0) (image-coding=MR) 1544 (dpi=300) (grey=2) (image-coding=MR) ) 1545 (& (dpi=200) (grey=2) (color=0) (image-coding=MH) 1546 (dpi=200) (grey=2) (image-coding=MH) ) 1547 (& (dpi=200) (grey=2) (color=0) (image-coding=MR) 1548 (dpi=200) (grey=2) (image-coding=MH) ) 1549 (& (dpi=300) (grey=2) (color=0) (image-coding=MH) 1550 (dpi=200) (grey=2) (image-coding=MH) ) 1551 (& (dpi=300) (grey=2) (color=0) (image-coding=MR) 1552 (dpi=200) (grey=2) (image-coding=MH) ) 1553 (& (dpi=200) (grey=2) (color=0) (image-coding=MH) 1554 (dpi=200) (grey=2) (image-coding=MMR) ) 1555 (& (dpi=200) (grey=2) (color=0) (image-coding=MR) 1556 (dpi=200) (grey=2) (image-coding=MMR) ) 1557 (& (dpi=300) (grey=2) (color=0) (image-coding=MH) 1558 (dpi=200) (grey=2) (image-coding=MMR) ) 1559 (& (dpi=300) (grey=2) (color=0) (image-coding=MR) 1560 (dpi=200) (grey=2) (image-coding=MMR) ) 1561 (& (dpi=200) (grey=2) (color=0) (image-coding=MH) 1562 (dpi=300) (color<=256) (image-coding=JPEG) ) ) ) 1563 (& (dpi=200) (grey=2) (color=0) (image-coding=MR) 1564 (dpi=300) (color<=256) (image-coding=JPEG) ) ) ) 1565 (& (dpi=300) (grey=2) (color=0) (image-coding=MH) 1566 (dpi=300) (color<=256) (image-coding=JPEG) ) ) ) 1567 (& (dpi=300) (grey=2) (color=0) (image-coding=MR) 1568 (dpi=300) (color<=256) (image-coding=JPEG) ) ) 1570 --> Group terms in each conjunction by feature tag: 1572 (| (& (dpi=200) (dpi=300) (grey=2) (grey=2) (color=0) 1573 (image-coding=MH) (image-coding=MR) ) 1574 (& (dpi=200) (dpi=300) (grey=2) (grey=2) (color=0) 1575 (image-coding=MR) (image-coding=MR) ) 1576 : 1577 (etc.) 1578 : 1579 (& (dpi=300) (dpi=300) (grey=2) (color=0) (color<=256) 1580 (image-coding=MR) (image-coding=JPEG) ) ) 1582 RFC nnnn A syntax for describing media feature sets 1583 14 December 1998 1585 --> Combine feature tag comparisons and eliminate unsatisfiable 1586 conjunctions: 1588 (| (& (dpi=300) (grey=2) (color=0) (image-coding=MR) ) 1589 (& (dpi=200) (grey=2) (color=0) (image-coding=MH) ) ) 1591 Thus, we see that this combination of sender and receiver options 1592 can transfer a bi-level image, either at 300dpi using MR coding, or 1593 at 200dpi using MH coding. 1595 Points to note about the feature matching process: 1597 o The colour document option is eliminated because the receiver 1598 cannot handle either colour (indicated by '(color=0)') or JPEG 1599 coding. 1601 o The high resolution version of the document with '(dpi=300)' must 1602 be sent using '(image-coding=MR)' because this is the only 1603 available coding of the image data that the receiver can use for 1604 high resolution documents. (The available 300dpi document 1605 codings here are MMR and MH, and the receiver capabilities are MH 1606 and MR.) 1608 7.2 A note on feature tag scoping 1610 This section contains some additional commentary on the 1611 interpretation of feture set predicates. It does not extend or 1612 modify what has been described previously. Rather, it attempts to 1613 clarify an area of possible misunderstanding. 1615 The essential fact that needs to be established here is: 1617 Within a given feature collection, each feature tag may 1618 have only one value. 1620 This idea is explained below in the context of using the media 1621 feature framework to describe the characteristics of transmitted 1622 image data. 1624 In this context, we have the requirement that any feature tag value 1625 must apply to the entire image, and cannot have different values 1626 for different parts of an image. This is a consequence of the way 1627 that the framework of feature predicates is used to describe 1628 different possible images, such as the different images that can be 1629 rendered by a given recipient. 1631 RFC nnnn A syntax for describing media feature sets 1632 14 December 1998 1634 This idea is illustrated here using an example of a flawed feature 1635 set description based on the TIFF image format defined for use by 1636 Internet fax [13]: 1638 (& (& (MRC-mode=1) (stripe-size=256) ) 1639 (| (& (image-coding=JBIG-2-LEVEL) (stripe-size=128) ) 1640 (image-coding=[MH,MR,MMR]) ) ) 1642 This example is revealing because the 'stripe-size' attribute is 1643 applied differently to different attributes on an MRC-formatted 1644 data: it can be applied to the MRC format as a whole, and it can 1645 be applied separately to a JBIG image that may appear as part of 1646 the MRC data. 1648 One might imagine that this example describes a stripe size of 256 1649 when applied to the MRC image format, and a separate stripe size of 1650 128 when applied to a JBIG-2-LEVEL coded image within the MRC- 1651 formatted data. But it doesn't work that way: the predicates used 1652 obey the normal laws of Boolean logic, and would be transformed as 1653 follows: 1655 --> [flatten nested (&...)]: 1656 (& (MRC-mode=1) (stripe-size=256) 1657 (| (& (image-coding=JBIG-2-LEVEL) (stripe-size=128) ) 1658 (image-coding=[MH,MR,MMR]) ) ) 1660 --> [Distribute (&...) over (|...)]: 1661 (| (& (MRC-mode=1) (stripe-size=256) 1662 (& (image-coding=JBIG-2-LEVEL) (stripe-size=128) ) ) 1663 (& (MRC-mode=1) (stripe-size=[0..256]) 1664 (image-coding=[MH,MR,MMR]) ) ) 1666 --> [Flatten nested (&...) and group feature tags]: 1667 (| (& (MRC-mode=1) 1668 (stripe-size=256) 1669 (stripe-size=128) 1670 (image-coding=JBIG-2-LEVEL) ) 1671 (& (MRC-mode=1) 1672 (stripe-size=256) 1673 (image-coding=[MH,MR,MMR]) ) ) 1675 Examination of this final expression shows that it requires both 1676 'stripe-size=128' and 'stripe-size=256' within the same 1677 conjunction. This is manifestly false, so the entire conjunction 1678 must be false, reducing the entire predicate expression to: 1680 (& (MRC-mode=1) 1681 (stripe-size=256) 1682 (image-coding=[MH,MR,MMR]) ) ) 1684 RFC nnnn A syntax for describing media feature sets 1685 14 December 1998 1687 This indicates that no MRC formatted data containing a JBIG-2-LEVEL 1688 coded image is permitted within the feature set, which is not what 1689 was intended in this case. 1691 The only way to avoid this in situations when a given 1692 characteristic has different constraints in different parts of a 1693 resource is to use separate feature tags. In this example, 1694 'MRC-stripe-size' and 'JBIG-stripe-size' could be used to capture 1695 the intent: 1697 (& (& (MRC-mode=1) (MRC-stripe-size=256) ) 1698 (| (& (image-coding=JBIG-2-LEVEL) (JBIG-stripe-size=128) ) 1699 (image-coding=[MH,MR,MMR]) ) ) 1701 which would reduce to: 1703 (| (& (MRC-mode=1) 1704 (MRC-stripe-size=256) 1705 (JBIG-stripe-size=128) 1706 (image-coding=JBIG-2-LEVEL) ) 1707 (& (MRC-mode=1) 1708 (MRC-stripe-size=256) 1709 (image-coding=[MH,MR,MMR]) ) ) 1711 The property of the capability description framework explicated 1712 above is captured by the idea of a "feature collection" which (in 1713 this context) describes the feature values that apply to a single 1714 resource. Within a feature collection, each feature tag may have 1715 no more than one value. 1717 The characteristics of an image sender or receiver are described by 1718 a "Feature set", which is formally a set of feature collections. 1719 Here, the feature set predicate is applied to some image feature 1720 collection to determine whether or not it belongs to the set that 1721 can be handled by an image receiver. 1723 8. Security considerations 1725 Some security considerations for content negotiation are raised in 1726 [1,2,3]. 1728 The following are primary security concerns for capability 1729 identification mechanisms: 1731 o Unintentional disclosure of private information through the 1732 announcement of capabilities or user preferences. 1734 o Disruption to system operation caused by accidental or malicious 1735 provision of incorrect capability information. 1737 RFC nnnn A syntax for describing media feature sets 1738 14 December 1998 1740 o Use of a capability identification mechanism might be used to 1741 probe a network (e.g. by identifying specific hosts used, and 1742 exploiting their known weaknesses). 1744 The most contentious security concerns are raised by mechanisms 1745 which automatically send capability identification data in response 1746 to a query from some unknown system. Use of directory services 1747 (based on LDAP [7], etc.) seem to be less problematic because 1748 proper authentication mechanisms are available. 1750 Mechanisms which provide capability information when sending a 1751 message are less contentious, presumably because some intention can 1752 be inferred that person whose details are disclosed wishes to 1753 communicate with the recipient of those details. This does not, 1754 however, solve problems of spoofed supply of incorrect capability 1755 information. 1757 The use of format converting gateways may prove problematic because 1758 such systems would tend to defeat any message integrity and 1759 authenticity checking mechanisms that are employed. 1761 9. Full copyright statement 1763 Copyright (C) The Internet Society 1998. All Rights Reserved. 1765 This document and translations of it may be copied and furnished to 1766 others, and derivative works that comment on or otherwise explain 1767 it or assist in its implementation may be prepared, copied, 1768 published and distributed, in whole or in part, without restriction 1769 of any kind, provided that the above copyright notice and this 1770 paragraph are included on all such copies and derivative works. 1771 However, this document itself may not be modified in any way, such 1772 as by removing the copyright notice or references to the Internet 1773 Society or other Internet organizations, except as needed for the 1774 purpose of developing Internet standards in which case the 1775 procedures for copyrights defined in the Internet Standards process 1776 must be followed, or as required to translate it into languages 1777 other than English. 1779 The limited permissions granted above are perpetual and will not be 1780 revoked by the Internet Society or its successors or assigns. 1782 This document and the information contained herein is provided on 1783 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1784 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1785 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1786 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1787 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1789 RFC nnnn A syntax for describing media feature sets 1790 14 December 1998 1792 10. Acknowledgements 1794 Thanks are due to Larry Masinter for demonstrating the breadth of 1795 the media feature issue, and encouraging the development of some 1796 early thoughts. 1798 Many of the ideas presented derive from the "Transparent Content 1799 Negotiation in HTTP" work of Koen Holtman and Andy Mutz [4]. 1801 Early discussions of ideas with the IETF HTTP and FAX working 1802 groups led to further useful inputs from Koen Holtman, Ted Hardie 1803 and Dan Wing. The debate later moved to the IETF 'conneg' working 1804 group, where Al Gilman and Koen Holtman were particularly helpful 1805 in refining the feature set algebra. Ideas for dealing with 1806 preferences and specific units were suggested by Larry Masinter. 1808 This work was supported by Content Technologies Ltd and 5th 1809 Generation Messaging Ltd. 1811 11. References 1813 [1] "Scenarios for the Delivery of Negotiated Content" 1814 T. Hardie, NASA Network Information Center 1815 Internet draft: 1816 Work in progress, November 1997. 1818 [2] "Requirements for protocol-independent content negotiation" 1819 G. Klyne, Integralis Ltd. 1820 Internet draft: 1821 Work in progress, March 1998. 1823 [3] "Media Feature Tag Registration Procedure" 1824 Koen Holtman, TUE 1825 Andrew Mutz, Hewlett-Packard 1826 Ted Hardie, NASA 1827 Internet draft: 1828 Work in progress, July 1998. 1830 [4] RFC 2295, "Transparent Content Negotiation in HTTP" 1831 Koen Holtman, TUE 1832 Andrew Mutz, Hewlett Packard 1833 March 1998. 1835 [5] "Programming in Prolog" (2nd edition) 1836 W. F. Clocksin and C. S. Mellish, 1837 Springer Verlag 1838 ISBN 3-540-15011-0 / 0-387-15011-0 1839 1984. 1841 RFC nnnn A syntax for describing media feature sets 1842 14 December 1998 1844 [6] "Media Features for Display, Print, and Fax" 1845 Larry Masinter, Xerox PARC 1846 Koen Holtman, TUE 1847 Andrew Mutz, Hewlett-Packard 1848 Dan Wing, Cisco Systems 1849 Internet draft: 1850 Work in progress, January 1998. 1852 [7] RFC 2251, "Lightweight Directory Access Protocol (v3)" 1853 M. Wahl, Critical Angle Inc. 1854 T. Howes, Netscape Communications Corp. 1855 S. Kille, Isode Limited 1856 December 1997. 1858 [8] RFC 2254, "The String Representation of LDAP Search Filters" 1859 T. Howes, Netscape Communications Corp. 1860 December 1997. 1862 [9] RFC 2068, "Hyptertext Transfer Protocol -- HTTP/1.1" 1863 R. Fielding, UC Irvine 1864 J. Gettys, 1865 J. Mogul, DEC 1866 H. Frytyk, 1867 T. Berners-Lee, MIT/LCS 1868 January 1997. 1870 [10] RFC 2234, "Augmented BNF for Syntax Specifications: ABNF" 1871 D. Crocker (editor), Internet Mail Consortium 1872 P. Overell, Demon Internet Ltd. 1873 November 1997. 1875 [11] "Logic, Algebra and Databases" 1876 Peter Gray 1877 Ellis Horwood Series: Computers and their Applications 1878 ISBN 0-85312-709-3/0-85312-803-3 (Ellis Horwood Ltd) 1879 ISBN 0-470-20103-7/0-470-20259-9 (Halstead Press) 1880 1984. 1882 [12] "Logic and its Applications" 1883 Edmund Burk and Eric Foxley 1884 Prentice Hall, Series in computer science 1885 ISBN 0-13-030263-5 1886 1996. 1888 RFC nnnn A syntax for describing media feature sets 1889 14 December 1998 1891 [13] RFC 2301, "File format for Internet fax" 1892 L. McIntyre, 1893 R. Buckley, 1894 D. Venable, Xerox Corporation 1895 S. Zilles, Adobe Systems, Inc. 1896 G. Parsons, Northern Telecom 1897 J. Rafferty, Human Communications 1898 March 1998. 1900 [14] Apache content negotiation algorithm 1901 1903 12. Author's address 1905 Graham Klyne 1906 Content Technologies Ltd. 5th Generation Messaging Ltd. 1907 Forum 1 5 Watlington Street 1908 Station Road Nettlebed 1909 Theale Henley-on-Thames 1910 Reading, RG7 4RA RG9 5AB 1911 United Kingdom United Kingdom. 1913 Telephone: +44 118 930 1300 +44 1491 641 641 1915 Facsimile: +44 118 930 1301 +44 1491 641 611 1917 E-mail: GK@ACM.ORG 1919 RFC nnnn A syntax for describing media feature sets 1920 14 December 1998 1922 Appendix A: Amendment history 1924 00a 28-Sep-1998 This memo created to contain a description of the 1925 syntax-related features from a previous.draft "An 1926 algebra for describing media feature sets". 1927 Theoretical background material is replaced by a 1928 more practically oriented introduction to the 1929 concepts, and references to ASN.1 representation 1930 have been removed. 1932 00b 16-Oct-1998 Reinstated discussion of preferences and q-values 1933 that was lost in the previous edit. Corrected 1934 error in placement of "parameter" in formal 1935 syntax. Added description of set construct in 1936 syntax section. 1938 01a 22-Oct-1998 Added references to previous TCN work. Move 1939 discussion of named predicates and value units to 1940 separate section, and other restructuring. Added 1941 text dealing with handling of unknown data types. 1943 02a 29-Oct-1998 Added feature set processing step to move logical 1944 negations to apply directly to feature 1945 comparisons. Added discussion of (non-)scoping of 1946 features, based on RFC2301 MRC image data example. 1947 Fix syntax for numbers and added explicit syntax 1948 for Boolean values. 1950 03a 10-Nov-1998 Adjusted description of q-value semantics. Added 1951 worked example of feature matching procedure. 1953 03b 13-Nov-1998 Removed placeholder section for sample source 1954 code: it is planned to publish this separately. 1956 03c 16-Nov-1998 Editorial changes to discussion of quality values. 1957 Added new sections describing interpretation of 1958 the feature predicate syntax. 1960 04a 14-Dec-1998 Editorial changes. 1962 RFC nnnn A syntax for describing media feature sets 1963 14 December 1998 1965 Revision history of "An algebra for describing media feature sets": 1967 00a 11-Mar-1998 Document initially created. 1969 01a 05-May-1998 Mainly-editorial revision of sections describing 1970 the feature types and algebra. Added section on 1971 indicating preferences. Added section describing 1972 feature predicate syntax. Added to security 1973 considerations (based on fax negotiation scenarios 1974 draft). 1976 01b 25-Jun-1998 New Internet draft boilerplate in 'status' 1977 preface. Review and rationalization of sections 1978 on feature combinations. Added numeric 1979 expressions, named predicates and auxiliary 1980 predicates as options in the syntax. Added 1981 examples of text string predicate representation. 1983 02a 08-Jul-1998 Added chapter on protocol processing 1984 considerations, and in particular outlined an 1985 algorithm for feature set matching. Added 1986 restrictions to the form of arithmetic expression 1987 to allow deterministic feature set matching. 1989 03a 27-Jul-1998 Simplified feature set handling by removing 1990 options for expressions on the RHS of feature 1991 comparison expressions. Syntax elements have been 1992 added as placeholders for possible future 1993 extensions in this area; examples have been 1994 adjusted accordingly, and the feature set matching 1995 algorithm greatly simplified. Add simple unit 1996 designations.