idnits 2.17.1 draft-ietf-conneg-feature-syntax-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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. == The page length should not exceed 58 lines per page, but there was 30 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([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 176: '... "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 (October 1998) is 9324 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) == Unused Reference: '6' is defined on line 1400, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Downref: Normative reference to an Experimental RFC: RFC 2295 (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2251 (ref. '7') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2254 (ref. '8') (Obsoleted by RFC 4510, RFC 4515) ** Obsolete normative reference: RFC 2068 (ref. '9') (Obsoleted by RFC 2616) ** Obsolete normative reference: RFC 2234 (ref. '10') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' Summary: 16 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF media feature registration WG Graham Klyne 3 Request for comments: nnnn Content Technologies/5GM 4 Category: Work-in-progress October 1998 5 Expires: April 1999 7 A syntax for describing media feature sets 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 [[INTENDED STATUS: This document specifies an Internet standards 31 track protocol for the Internet community, and requests discussion 32 and suggestions for improvements. Please refer to the current 33 edition of the "Internet Official Protocol Standards" (STD 1) for 34 the standardization state and status of this protocol. 35 Distribution of this memo is unlimited.]] 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 RFC nnnn A syntax for describing media feature sets 52 October 1998 54 This document introduces and describes a syntax that can be used to 55 define feature sets which are formed from combinations and 56 relations involving individual media features. Such feature sets 57 are used to describe the media feature handling capabilities of 58 message senders, recipients and file formats. 60 An algorithm for feature set matching is also described here. 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 1.4 Amendment history ....................................5 69 1.5 Unfinished business ..................................6 70 2. Content feature terminology and definitions..............6 71 3. Media feature combinations and capabilities..............7 72 3.1 Media features .......................................7 73 3.2 Media feature collections and sets ...................7 74 3.3 Media feature set descriptions .......................7 75 3.4 Media feature combination scenario ...................8 76 3.4.1 Data resource options............................8 77 3.4.2 Recipient capabilities...........................9 78 3.4.3 Combined options.................................9 79 3.5 Feature set predicates ...............................9 80 3.5.1 Comparison with directory search filters.........10 81 3.6 Describing preferences ...............................11 82 3.7 Combining preferences ................................12 83 4. Feature set representation...............................12 84 4.1 Textual representation of predicates .................12 85 4.2 Notational conveniences ..............................14 86 4.3 Feature set definition example .......................14 87 5. Matching feature sets....................................15 88 5.1 Feature set matching strategy ........................17 89 5.2 Formulating the goal predicate .......................17 90 5.3 Replace set expressions ..............................18 91 5.4 Replace comparisons and logical negations ............18 92 5.5 Conversion to canonical form .........................20 93 5.6 Grouping of feature predicates .......................20 94 5.7 Merge single-feature constraints .....................21 95 5.7.1 Rules for simplifying ordered values.............21 96 5.7.2 Rules for simplifying unordered values...........22 97 6. Other features and issues................................22 98 6.1 Named and auxiliary predicates .......................22 99 6.1.1 Defining a named predicate.......................22 100 6.1.2 Invoking named predicates........................23 101 6.1.3 Auxiliary predicates in a filter.................23 102 6.1.4 Feature matching with named predicates...........24 104 RFC nnnn A syntax for describing media feature sets 105 October 1998 107 6.1.4 Example..........................................24 108 6.2 Unit designations ....................................24 109 6.3 Unknown feature value data types .....................25 110 7. Worked example...........................................26 111 8. Algorithm source code....................................26 112 9. Security considerations..................................26 113 10. Full copyright statement................................27 114 11. Acknowledgements........................................28 115 12. References..............................................28 116 13. Author's address........................................30 118 1. Introduction 120 A number of Internet application protocols have a need to provide 121 content negotiation for the resources with which they interact [1]. 122 A framework for such negotiation is described in [2]. A part of 123 this framework is a way to describe the range of media features 124 which can be handled by the sender, recipient or document 125 transmission format of a message. 127 Descriptions of media feature capabilities need to be based upon 128 some underlying vocabulary of individual media features. A format 129 for such a vocabulary and procedures for registering media features 130 within this vocabulary are presented in [3]. 132 This document defines a syntax that can be used to describe feature 133 sets which are formed from combinations and relations involving 134 individual media features. Such feature sets are used to describe 135 the media handling capabilities of message senders, recipients and 136 file formats. 138 An algorithm for feature set matching is also described here. 140 The feature set syntax is built upon the principle of using feature 141 set predicates as "mathematical relations" which define constraints 142 on feature handling capabilities. This allows that the same form 143 of feature set expression can be used to describe sender, receiver 144 and file format capabilities. This has been loosely modelled on 145 the way that relational databases use Boolean expresions to 146 describe a set of result values, and a syntax that is based upon 147 LDAP search filters. 149 RFC nnnn A syntax for describing media feature sets 150 October 1998 152 1.1 Structure of this document 154 The main part of this memo addresses the following main areas: 156 Section 2 introduces and references some terms which are used with 157 special meaning. 159 Section 3 introduces the concept of describing media handling 160 capabilities as combinations of possible media features, and the 161 idea of using Boolean expressions to express such combinations. 163 Section 4 contains a description of a syntax for describing feature 164 sets based on the previously-introduced idea of Boolean expressions 165 used to describe media feature combinations. 167 Section 5 describes an algorithm for feature set matching. 169 Section 6 discusses some additional media feature description and 170 processing issues that may be viewed as extensions to the core 171 framework. 173 1.2 Document terminology and conventions 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in RFC 2119. 179 NOTE: Comments like this provide additional nonessential 180 information about the rationale behind this document. 181 Such information is not needed for building a conformant 182 implementation, but may help those who wish to understand 183 the design in greater depth. 185 1.3 Discussion of this document 187 Discussion of this document should take place on the content 188 negotiation and media feature registration mailing list hosted by 189 the Internet Mail Consortium (IMC): 191 Please send comments regarding this document to: 193 ietf-medfree@imc.org 195 To subscribe to this list, send a message with the body 'subscribe' 196 to "ietf-medfree-request@imc.org". 198 To see what has gone on before you subscribed, please see the 199 mailing list archive at: 201 http://www.imc.org/ietf-medfree/ 203 RFC nnnn A syntax for describing media feature sets 204 October 1998 206 1.4 Amendment history 208 00a 28-Sep-1998 This memo created to contain a description of the 209 syntax-related features from a previous.draft "An 210 algebra for describing media feature sets". 211 Theoretical background material is replaced by a 212 more practically oriented introduction to the 213 concepts, and references to ASN.1 representation 214 have been removed. 216 00b 16-Oct-1998 Reinstated discussion of preferences and q-values 217 that was lost in the previous edit. Corrected 218 error in placement of "parameter" in formal 219 syntax. Added description of set construct in 220 syntax section. 222 01a 22-Oct-1998 Added references to previous TCN work. Move 223 discussion of named predicates and value units to 224 separate section, and other restructuring. Added 225 text dealing with handling of unknown data types. 227 Revision history of "An algebra for describing media feature sets": 229 00a 11-Mar-1998 Document initially created. 231 01a 05-May-1998 Mainly-editorial revision of sections describing 232 the feature types and algebra. Added section on 233 indicating preferences. Added section describing 234 feature predicate syntax. Added to security 235 considerations (based on fax negotiation scenarios 236 draft). 238 01b 25-Jun-1998 New Internet draft boilerplate in 'status' 239 preface. Review and rationalization of sections 240 on feature combinations. Added numeric 241 expressions, named predicates and auxiliary 242 predicates as options in the syntax. Added 243 examples of text string predicate representation. 245 02a 08-Jul-1998 Added chapter on protocol processing 246 considerations, and in particular outlined an 247 algorithm for feature set matching. Added 248 restrictions to the form of arithmetic expression 249 to allow deterministic feature set matching. 251 RFC nnnn A syntax for describing media feature sets 252 October 1998 254 03a 27-Jul-1998 Simplified feature set handling by removing 255 options for expressions on the RHS of feature 256 comparison expressions. Syntax elements have been 257 added as placeholders for possible future 258 extensions in this area; examples have been 259 adjusted accordingly, and the feature set matching 260 algorithm greatly simplified. Add simple unit 261 designations. 263 1.5 Unfinished business 265 o Add worked example and source code for feature matching 266 implementation. 268 2. Content feature terminology and definitions 270 Feature Collection 271 is a collection of different media features and 272 associated values. This might be viewed as describing a 273 specific rendering of a specific instance of a document 274 or resource by a specific recipient. 276 Feature Set 277 is a set of zero, one or more feature collections. 279 NOTE: this term is used slightly differently by earlier 280 work on Transparent Content Negotiation in HTTP [4]. 282 Feature set predicate 283 A function of an arbitrary feature collection value which 284 returns a Boolean result. A TRUE result is taken to mean 285 that the corresponding feature collection belongs to some 286 set of media feature handling capabilities defined by 287 this predicate. 289 Other terms used in this draft are defined in [2]. 291 RFC nnnn A syntax for describing media feature sets 292 October 1998 294 3. Media feature combinations and capabilities 296 3.1 Media features 298 This memo assumes that individual media feature values are simple 299 atomic values: 301 o Boolean values. 303 o Enumerated values. 305 o Text string values (treated as atomic entities, like enumerated 306 value tokens). 308 o Numeric values (Integer or rational). 310 These values all have the property that they can be compared for 311 equality ('='), and that numeric and ordered enumeration values can 312 be compared for less-than and greater-than relationship ('<=', 313 '>='). These basic comparison operations are used as the primitive 314 building blocks for more comprehensive capability expressions. 316 3.2 Media feature collections and sets 318 Any single media feature value can be thought of as just one 319 component of a feature collection that describes some instance of a 320 resource (e.g. a printed document, a displayed image, etc.). Such 321 a feature collection consists of a number of media feature tags 322 (each per [3]) and associated feature values. 324 A feature set is a set containing a number of feature collections. 325 Thus, a feature set can describe a number of different data 326 resource instances. These can correspond to different treatments 327 of a single data resource (e.g. different resolutions used for 328 printing a given document), a number of different data resources 329 subjected to a common treatment (e.g. the range of different images 330 that can be rendered on a given display), or some combination of 331 these (see examples below). 333 Thus, a description of a feature set can describe the capabilities 334 of a data resource or some entity that processes or renders a data 335 resource. 337 3.3 Media feature set descriptions 339 A feature set may be unbounded. For example, in principle, there 340 is no limit on the number of different documents that may be output 341 using a given printer. But to be practically useful, a feature set 342 description must be finite. 344 RFC nnnn A syntax for describing media feature sets 345 October 1998 347 The general approach to describing feature sets is to start from 348 the assumption that anything is possible; i.e. the feature set 349 contains all possible document instances (feature collections). 350 Then constraints are applied that progressively remove document 351 instances from this set; e.g. for a monochrome printer, all 352 document instances that use colour are removed, or for a document 353 that must be rendered at some minimum resolution, all document 354 instances with lesser resolutions are removed from the set. The 355 mechanism used to remove document instances from the set is the 356 mathematical idea of a "relation"; i.e. a Boolean function (a 357 "predicate") that takes a feature collection parameter and returns 358 a Boolean value that is TRUE if the feature collection describes an 359 acceptable document instance, or FALSE if it describes one that is 360 excluded. 362 P(C) 363 P(C) = TRUE <- : -> P(C) = FALSE 364 : 365 +----------:----------+ This box represents some 366 | : | set of feature collections (C) 367 | Included : Excluded | that is constrained by the 368 | : | predicate P. 369 +----------:----------+ 370 : 372 The result of applying a series of such constraints is a smaller 373 set of feature collections that represent some media handling 374 capability. Where the individual constraints are represented by 375 predicates that each describe some media handling capability, the 376 combined effect of these constraints is some subset of the 377 individual constraint capabilities that can be represented by a 378 predicate that is the logical-AND of the individual constraint 379 predicates. 381 3.4 Media feature combination scenario 383 This section develops some exaple scenarios, introducing the 384 notation that is defined formally in the next section. 386 3.4.1 Data resource options 388 The following expression describes a data resource that can be 389 displayed either: 390 (a) as a 750x500 pixel image using 15 colours, or 391 (b) at 150dpi on an A4 page. 393 (| (& (pix-x=750) (pix-y=500) (color=15) ) 394 (& (dpi>=150) (papersize=iso-A4) ) ) 396 RFC nnnn A syntax for describing media feature sets 397 October 1998 399 3.4.2 Recipient capabilities 401 The following expression describes a receiving system that has: 402 (a) a screen capable of displaying 640*480 pixels and 16 million 403 colours (24 bits per pixel), 800*600 pixels and 64 thousand 404 colours (16 bits per pixel) or 1024*768 pixels and 256 colours 405 (8 bits per pixel), or 406 (b) a printer capable of rendering 300dpi on A4 paper. 408 (| (& (| (& (pix-x<=640) (pix-y<=480) (color<=16777216) ) 409 (& (pix-x<=800) (pix-y<=600) (color<=65535) ) 410 (& (pix-x<=1024) (pix-y<=768) (color<=256) ) ) 411 (media=screen) ) 412 (& (dpi=300) 413 (media=stationery) (papersize=iso-A4) ) ) 415 Note that this expression says noting about the colour or grey- 416 scale capabilities of the printer. In the scheme presented here, 417 it is presumed to be unconstrained in this respect (or, more 418 realistically, any such constraints are handled out-of-band by 419 anyone sending to this recipient). 421 3.4.3 Combined options 423 The following example describes the range of document 424 representations available when the resource described in the first 425 example above is sent to the recipient described in the second 426 example. This is the result of combining their capability feature 427 sets: 429 (| (& (pix-x=750) (pix-y=500) (color=15) ) 430 (& (dpi=300) (media=stationery) (papersize=iso-A4) ) ) 432 The feature set described by this expression is the intersection of 433 the sets described by the previous two capability expressions. 435 3.5 Feature set predicates 437 There are many ways of representing a predicate. The ideas in this 438 memo were inspired by the programming language Prolog [5], and its 439 use of predicates to describe sets of objects. 441 For the purpose of media feature description in networked 442 application protocols, the format used for LDAP search filters 443 [7,8] has been adopted, because it is a good match for the 444 requirements of capability identification, and has a very simple 445 structure that is easy to parse and process. 447 RFC nnnn A syntax for describing media feature sets 448 October 1998 450 3.5.1 Comparison with directory search filters 452 Observe that a feature collection is similar to a directory entry, 453 in that it consists of a collection of named values. Further, the 454 semantics of the mechanism for selecting feature collections from a 455 feature set is in many respects similar to selection of directory 456 entries from a directory. 458 A feature set predicate used to describe media handling 459 capabilities is implicitly applied to some feature collection. 460 Within the predicate, members of the feature collection are 461 identified by their feature tags, and are compared with known 462 feature values. (Compare with the way an LDAP search filter is 463 applied to a directory entry, whose members are identified by 464 attribute type names, and compared with known attribute values.) 466 For example, in: 468 (& (dpi>=150) (papersize=iso-A4) ) 470 the tokens 'dpi' and 'papersize' are feature tags, and '150' and 471 'iso-A4' are feature values. (In a corresponding LDAP search 472 filter, they would directory entry attribute types and attribute 473 values.) 475 Differences between directory selection (per [7]) and feature set 476 selection are: 478 o Directory selection provides substring-, approximate- and 479 extensible- matching for attribute values. Directory selection 480 may also be based on the presence of an attribute without regard 481 to its value. 483 o Directory selection provides for matching rules that test for the 484 presence or absence of a named attribute type. 486 o Directory selection provides for matching rules which are 487 dependent upon the declared data type of an attribute value. 489 o Feature selection provides for the association of a quality value 490 with a feature predicate as a way of ranking the selected value 491 collections. 493 The idea of substring matching does not seem to be relevant to 494 feature set selection, and is excluded from these proposals. 496 Testing for the presence of a feature may be useful in some 497 circumstances, but does not sit comfortably within the semantic 498 framework. Feature sets are described by implied universal 499 quantification over predicates, and the absence of reference to a 501 RFC nnnn A syntax for describing media feature sets 502 October 1998 504 given feature means the set is not constrained by that feature. 505 Against this, it is difficult to define what might be meant by 506 "presence" of a feature, so the "test for presence" option is not 507 included in these proposals. An effect similar to testing for the 508 presence of a feature can be achieved by a Boolean-valued feature. 510 The idea of extensible matching and matching rules dependent upon 511 data types are facets of a problem not addressed by this memo, but 512 which do not necessarily affect the feature selection syntax. An 513 aspect that might bear on the syntax would be specification of an 514 explicit matching rule as part of a selection expression. 516 3.6 Describing preferences 518 A convenient way to describe preferences is by numeric "quality 519 values", as used in HTTP "Accept" headers, etc. (see RFC 2068 [9], 520 section 3.9). 522 It has been suggested that numeric quality values are potentially 523 misleading if used as more than just a way of ranking options. 524 Attempts to perform arithmetic on quality values do seem to 525 degenerate into meaningless juggling of numbers. 527 Numeric quality values in the range 0 to 1 (as defined by RFC 2068 528 [9], section 3.9) are used to rank feature sets according to 529 preference. Higher values are preferred over lower values, and 530 equal values are presumed to be equally preferred. Beyond this, 531 the actual number used has no significance defined by this memo, 532 and arithmetic operations using them are likely to produce 533 unpredictable results unless suitably defined for the context where 534 they are used. 536 In the absence of any explicitly applied quality value, a value of 537 "1" is assumed, suggesting an "ideal" option that is equally or 538 more preferred than any other. 540 Using the notation defined later, a quality value may be attached 541 to any feature set predicate sub-expression: 543 (| (& (pix-x=750) (pix-y=500) (color=15) );q=0.8 544 (& (dpi>=150) (papersize=iso-A4) ) ;q=0.7 ) 546 The next section explains that quality values attached to sub- 547 expressions are not always useful. 549 RFC nnnn A syntax for describing media feature sets 550 October 1998 552 3.7 Combining preferences 554 The general problem of describing and combining preferences among 555 feature sets is very much more complex than simply describing 556 allowable feature sets. For example, given two feature sets: 557 (& (a1);q=0.8 (b1);q=0.7 ) 558 (& (a2);q=0.5 (b2);q=0.9 ) 560 where: 561 feature a1 is preferred over a2 562 feature b2 is preferred over b1 564 Which of these feature sets is preferred? In the absence of 565 additional information or assumptions, there is no generally 566 satisfactory answer to this. 568 The proposed resolution of this issue is simply to say that no 569 rules are provided for combining preference information. Applied 570 to the above example, any preference information about (a1) in 571 relation to (a2), or (b1) in relation to (b2) is not presumed to 572 convey information about preference of (& (a1) (b1) ) in relation 573 to (& (a2) (b2) ). 575 In practical terms, this restricts the application of preference 576 information to top-level predicate clauses. A top-level clause 577 completely defines an allowable feature set; clauses combined by 578 logical-AND operators cannot be top-level clauses (see canonical 579 format for feature set predicates, described later). 581 NOTE: This memo does not apply specific meaning to 582 quality values or rules for combining them. Application 583 of such meanings and rules is not prohibited, but is seen 584 as an area for future research and experimentation. 586 4. Feature set representation 588 The foregoing sections have described a framework for defining 589 feature sets with predicates applied to feature collections. This 590 section presents a concrete representation for feature set 591 predicates. 593 4.1 Textual representation of predicates 595 The text representation of a feature set is based on RFC 2254 "The 596 String Representation of LDAP Search Filters" [8], excluding those 597 elements not relevant to feature set selection (discussed above), 598 and adding elements specific to feature set selection (e.g. options 599 to associate quality values with predicates). 601 RFC nnnn A syntax for describing media feature sets 602 October 1998 604 The format of a feature predicate is defined by the production for 605 "filter" in the following, using the syntax notation and core rules 606 of [10]: 608 filter = "(" filtercomp ")" *( ";" parameter ) 609 parameter = "q" "=" qvalue 610 / ext-param "=" ext-value 611 qvalue = ( "0" [ "." 0*3DIGIT ] ) 612 / ( "1" [ "." 0*3("0") ] ) 613 ext-param = ALPHA *( ALPHA / DIGIT / "-" ) 614 ext-value = 615 filtercomp = and / or / not / item 616 and = "&" filterlist 617 or = "|" filterlist 618 not = "!" filter 619 filterlist = 1*filter 620 item = simple / set / ext-pred 621 set = attr "=" "[" setentry *( "," setentry ) "]" 622 setentry = value "/" range 623 range = value ".." value 624 simple = attr filtertype value 625 filtertype = equal / greater / less 626 equal = "=" 627 greater = ">=" 628 less = "<=" 629 attr = ftag 630 value = fvalue 631 ftag = 632 fvalue = number / token / string 633 number = integer / rational 634 integer = 1*DIGIT 635 rational = 1*DIGIT "." 1*DIGIT 636 token = ALPHA *( ALPHA / DIGIT / "-" ) 637 string = DQUOTE *(%x20-21 / %x23-7E) DQUOTE 638 ; quoted string of SP and VCHAR without DQUOTE 639 ext-pred = 641 (Subject to constraints imposed by the protocol that carries a 642 feature predicate, whitespace characters may appear between any 643 pair of syntax elements or literals that appear on the right hand 644 side of these productions.) 646 As described, the syntax permits parameters (including quality 647 values) to be attached to any "filter" value in the predicate (not 648 just top-level values). Only top-level quality values are 649 recognized. If no explicit quality value is given, a value of 650 '1.0' is applied. 652 RFC nnnn A syntax for describing media feature sets 653 October 1998 655 NOTE: The flexible approach to quality values and other 656 parameter values in this syntax has been adopted for two 657 reasons: (a) to make it easy to combine separately 658 constructed feature predicates, and (b) to provide an 659 extensible tagging mechanism for possible future use (for 660 example, to incorporate a conceivable requirement to 661 explicitly specify a matching rule). 663 4.2 Notational conveniences 665 A "set" item is simply a shorthand notation for some common 666 situations that can be expressed using "simple" item constructs. 667 Occurrences of "set" items can eliminated by applying the following 668 identities: 670 T = [ E1, E2, ... En ] --> (| (T=[E1]) (T=[E2]) ... (T=[En]) ) 671 (T=[R1..R2]) --> (& (T>=R1) (T<=R2) ) 672 (T=[E]) --> (T=E) 674 Examples: 676 The expression: 677 ( paper-size=[A4,B4] ) 678 can be used to express a capability to print documents on either A4 679 or B4 sized paper. 681 The expression: 682 ( width=[4..8.5] ) 683 might be used to express a capability to print documents that are 684 anywhere between 4 and 8.5 inches wide. 686 The set construct is designed so that enumerated values and ranges 687 can be combined in a single expression, e.g.: 688 ( width=[3,4,6..8.5] ) 690 4.3 Feature set definition example 692 The following is an example of a feature predicate that describes a 693 number of image size and resolution combinations. 695 (| (& (Pix-x=1024) 696 (Pix-y=768) 697 (| (& (Res-x=150) (Res-y=150) ) 698 (& (Res-x=150) (Res-y=300) ) 699 (& (Res-x=300) (Res-y=300) ) 700 (& (Res-x=300) (Res-y=600) ) 701 (& (Res-x=600) (Res-y=600) ) ) 703 RFC nnnn A syntax for describing media feature sets 704 October 1998 706 (& (Pix-x=800) 707 (Pix-y=600) 708 (| (& (Res-x=150) (Res-y=150) ) 709 (& (Res-x=150) (Res-y=300) ) 710 (& (Res-x=300) (Res-y=300) ) 711 (& (Res-x=300) (Res-y=600) ) 712 (& (Res-x=600) (Res-y=600) ) ) ;q=0.9 713 (& (Pix-x=640) 714 (Pix-y=480) 715 (| (& (Res-x=150) (Res-y=150) ) 716 (& (Res-x=150) (Res-y=300) ) 717 (& (Res-x=300) (Res-y=300) ) 718 (& (Res-x=300) (Res-y=600) ) 719 (& (Res-x=600) (Res-y=600) ) ) ;q=0.8 721 5. Matching feature sets 723 This section presents a procedure for combining feature sets to 724 determine the common feature collections to which they refer, if 725 there are any. Making a selection from the possible feature 726 collections (based on q-values or otherwise) is not covered here. 728 Matching a feature set to some given feature collection is 729 esentially very straightforward: the feature set predicate is 730 simply evaluated for the given feature collection, and the result 731 (TRUE or FALSE) indicates whether the feature collection matches 732 the capabilities, and the associated quality value can be used for 733 selecting among alternative feature collections. 735 Matching a feature set to some other feature set is less 736 straightforward. Here, the problem is to determine whether or not 737 there is at least one feature collection that matches both feature 738 sets (e.g. is there an overlap between the feature capabilities of 739 a given file format and the feature capabilities of a given 740 recipient?) 742 This feature set matching is accomplished by logical manipulation 743 of the predicate expressions as described in the following 744 sections. 746 For this procedure to work reliably, the predicates must be reduced 747 to a canonical form. The canonical form used here is "disjunctive 748 normal form". A syntax for disjunctive normal form is: 750 filter = orlist 751 orlist = "(" "|" andlist ")" / term 752 andlist = "(" "&" termlist ")" / term 753 termlist = 1*term 754 term = "(" "!" simple ")" / simple 756 RFC nnnn A syntax for describing media feature sets 757 October 1998 759 where "simple" is as described previously in section 4.1. Thus, 760 the canonicalized form has at most three levels: an outermost 761 "(|...)" disjunction of "(&...)" conjunctions of possibly negated 762 feature value tests. 764 NOTE 766 The usual canonical form for predicate expressions is 767 "clausal form". Procedures for converting general 768 predicate expressions are given in [5] (section 10.2), 769 [11] (section 2.13) and [12] (section 5.3.2). 771 "Clausal form" for a predicate is similar to "conjunctive 772 normal form" for a proposition, being a conjunction 773 (logical AND) of disjunctions (logical ORs). The related 774 form used here, better suited to feature set matching, is 775 "disjunctive normal form", which is a logical disjunction 776 (OR) of conjunctions (ANDs). In this form, the aim of 777 feature set matching is to show that at least one of the 778 disjunctions can be satisfied by some feature collection. 780 Is this consideration of canonical forms really required? 781 After all, the feature predicates are just Boolean 782 expressions, aren't they? Well, no: a feature predicate 783 is a Boolean expression containing primitive feature 784 value tests (comparisons), represented by 'item' in the 785 feature predicate syntax. If these tests could all be 786 assumed to be independently TRUE or FALSE, then each 787 could be regarded as an atomic proposition, and the whole 788 predicate could be dealt with according to the 789 (relatively simple) rules of Propositional Calculus. 791 But, in general, the same feature tag may appear in more 792 than one predicate 'item', so the tests cannot be 793 regarded as independent. Indeed, interdependence is 794 needed in any meaningful application of feature set 795 matching, and it is important to capture these 796 dependencies (e.g. does the set of resolutions that a 797 sender can supply overlap the set of resolutions that a 798 recipient can handle?). Thus, we have to deal with 799 elements of the Predicate Calculus, with some additional 800 rules for algebraic manipulation. 802 A description of both the Propositional and Predicate 803 calculi can be found in [12]. 805 We aim to show that these additional rules are more 806 unfamiliar than complicated. The construction and use of 807 feature predicates actually avoids some of the complexity 808 of dealing with fully-generalized Predicate Calculus. 810 RFC nnnn A syntax for describing media feature sets 811 October 1998 813 5.1 Feature set matching strategy 815 The overall strategy for matching feature sets, expanded in the 816 following sections, is: 818 1. Formulate the feature set match hypothesis. 820 2. Replace "set" expressions with equivalent comparisons. 822 3. Eliminate logical negations, and express all feature comparisons 823 in terms of just four comparison operators 825 4. Reduce the hypothesis to canonical disjunctive normal form (a 826 disjunction of conjunctions). 828 5. For each of the conjunctions, attempt to show that it can be 829 satisfied by some feature collection. Any that cannot be 830 satisfied are discarded. 832 5.1 Separate the feature value tests into independent feature 833 groups, such that each group contains tests involving just 834 one feature tag. Thus, no predicate in a feature group 835 contains a feature tag that also appears in some other 836 group. 838 5.2 For each feature group, merge the various constraints to a 839 minimum form. This process either yields a reduced 840 expression for the allowable range of feature values, or an 841 indication that no value can satisfy the constraints (in 842 which case the corresponding conjucntion can never be 843 satisfied). 845 6. If the remaining disjunction is non-empty, then the constraints 846 are shown to be satisfiable. Further, it can be used as a 847 statement of the resulting feature set for possible further 848 matching operations. 850 5.2 Formulating the goal predicate 852 A formal statement of the problem we need to solve can be given as: 853 given two feature set predicates, '(P x)' and '(Q x)', where 'x' is 854 some feature collection, we wish to establish the truth or 855 otherwise of the proposition: 857 EXISTS(x) : (P x) AND (Q x) 859 i.e. does there exist a feature collection 'x' that satisfies both 860 predicates, 'P' and 'Q'? 862 RFC nnnn A syntax for describing media feature sets 863 October 1998 865 Then, if feature sets to be matched are described by predicates 'P' 866 and 'Q', the problem is to determine if there is any feature set 867 satisfying the goal predicate: 869 (& P Q) 871 i.e. to determine whether the set thus described is non-empty. 873 5.3 Replace set expressions 875 Replace all "set" instances in the goal predicate with equivalent 876 "simple" forms: 878 T = [ E1, E2, ... En ] --> (| (T=[E1]) (T=[E2]) ... (T=[En]) ) 879 (T=[R1..R2]) --> (& (T>=R1) (T<=R2) ) 880 (T=[E]) --> (T=E) 882 5.4 Replace comparisons and logical negations 884 The predicates are derived from the syntax described previously, 885 and contain primitive value testing functions '=', '<=', '>='. The 886 primitive tests have a number of well known properties that are 887 exploited to reach a useful conclusion; e.g. 889 (A = B) & (B = C) => (A = C) 890 (A <= B) & (B <= C) => (A <= C) 892 These rules form a core body of logic statements against which the 893 goal predicate can be evaluated. The form in which these 894 statements are expressed is important to realizing an effective 895 predicate matching algorithm (i.e. one that doesn't loop or fail to 896 find a valid result). The first step in formulating these rules is 897 to simplify the framework of primitive predicates. 899 The primitive predicates from which feature set definitions are 900 constructed are '=', '<=' and '>='. Observe that, given any pair 901 of feature values, the relationship between them must be exactly 902 one of the following: 904 (LT a b): 'a' is less than 'b'. 905 (EQ a b): 'a' is equal to 'b'. 906 (GT a b): 'a' is greater than 'b'. 907 (NE a b): 'a' is not equal and not related to 'b'. 909 (The final case arises when two values are compared for which no 910 ordering relationship is defined, and the values are not equal; 911 e.g. two unequal string values.) 913 RFC nnnn A syntax for describing media feature sets 914 October 1998 916 These four cases can be captured by a pair of primitive predicates: 918 (LE a b): 'a' is less than or equal to 'b'. 919 (GE a b): 'a' is greater than or equal to 'b'. 921 The four cases described above are prepresented by the following 922 combinations of primitive predicate values: 924 (LE a b) (GE a b) | relationship 925 ---------------------------------- 926 TRUE FALSE | (LT a b) 927 TRUE TRUE | (EQ a b) 928 FALSE TRUE | (GT a b) 929 FALSE FALSE | (NE a b) 931 Thus, the original 3 primitive tests can be translated to 932 combinations of just LE and GE, reducing the number of additional 933 relationships that must be subsequently captured: 935 (a <= b) --> (LE a b) 936 (a >= b) --> (GE a b) 937 (a = b) --> (& (LE a b) (GE a b) ) 939 Further, logical negations of the original 3 primitive tests can be 940 eliminated by the introduction of 'not-greater' and 'not-less' 941 primitives 943 (NG a b) == (! (GE a b) ) 944 (NL a b) == (! (LE a b) ) 946 using the following transformation rules: 948 (! (a = b) ) --> (| (NL a b) (NG a b) ) 949 (! (a <= b) ) --> (NL a b) 950 (! (a >= b) ) --> (NG a b) 952 Thus, we have rules to transform all comparisons and logical 953 negations into combinations of just 4 relational operators. 955 RFC nnnn A syntax for describing media feature sets 956 October 1998 958 5.5 Conversion to canonical form 960 NOTE: Logical negations have been eliminated in the 961 previous step. 963 Expand bracketed disjunctions, and flatten bracketed conjunctions 964 and disjunctions: 966 (& (| A1 A2 ... Am ) B1 B2 ... Bn ) 967 --> (| (& A1 B1 B2 ... Bn ) 968 (& A2 B1 B2 ... Bn ) 969 : 970 (& Am B1 B2 ... Bn ) ) 971 (& (& A1 A2 ... Am ) B1 B2 ... Bn ) 972 --> (& A1 A2 ... Am B1 B2 ... Bn ) 973 (| (| A1 A2 ... Am ) B1 B2 ... Bn ) 974 --> (| A1 A2 ... Am B1 B2 ... Bn ) 976 The result is a "disjunctive normal form", a disjunction of 977 conjunctions: 979 (| (& S11 S12 ... ) 980 (& S21 S22 ... ) 981 : 982 (& Sm1 Sm2 ... Smn ) ) 984 where the "Sij" elements are simple feature comparison forms 985 constructed during the step at section 7.1.4. Each term within the 986 top-level "(|...)" construct represents a single possible feature 987 set that satisfies the goal. Note that the order of entries within 988 the top-level '(|...)', and within each '(&...)', is immaterial. 990 From here on, each conjunction '(&...)' is processed separately. 991 Only one of these needs to be satisfiable for the original goal to 992 be satisfiable. 994 (A textbook conversion to clausal form [5,11] uses slightly 995 different rules to yield a "conjunctive normal form".) 997 5.6 Grouping of feature predicates 999 NOTE: remember that from here on, each conjunction is 1000 treated separately. 1002 Each simple feature predicate contains a "left-hand" feature tag 1003 and a "right-hand" feature value with which it is compared. 1005 To arrange these into independent groups, simple predicates are 1006 grouped according to their left hand feature tag ('f'). 1008 RFC nnnn A syntax for describing media feature sets 1009 October 1998 1011 5.7 Merge single-feature constraints 1013 Within each group, apply the predicate simplification rules given 1014 below to eliminate redundant single-feature constraints. All 1015 single-feature predicates are reduced to an equality or range 1016 constraint on that feature, possibly combined with a number of non- 1017 equality statements. 1019 If the constraints on any feature are found to be contradictory 1020 (i.e. resolved to FALSE according to the applied rules), the 1021 current conjunction is removed from the feature set description. 1022 Otherwise, the resulting description is a minimal form of the 1023 particular conjunction of the feature set definition. 1025 5.7.1 Rules for simplifying ordered values 1027 These rules are applicable where there is an ordering relationship 1028 between the given values 'a' and 'b': 1030 (LE f a) (LE f b) --> (LE f a), a<=b 1031 (LE f b), otherwise 1032 (LE f a) (GE f b) --> FALSE, a FALSE, a<=b 1034 (LE f a) (NG f b) --> (LE f a), a (GE f a), a>=b 1038 (GE f b), otherwise 1039 (GE f a) (NL f b) --> (GE f a) a>b 1040 (NL f b), otherwise 1041 (GE f a) (NG f b) --> FALSE, a>=b 1043 (NL f a) (NL f b) --> (NL f a), a>=b 1044 (NL f b), otherwise 1045 (NL f a) (NG f b) --> FALSE, a>=b 1047 (NG f a) (NG f b) --> (NG f a), a<=b 1048 (NG f b), otherwise 1050 RFC nnnn A syntax for describing media feature sets 1051 October 1998 1053 5.7.2 Rules for simplifying unordered values 1055 These rules are applicable where there is no ordering relationship 1056 applicable to the given values 'a' and 'b': 1058 (LE f a) (LE f b) --> (LE f a), a=b 1059 FALSE, otherwise 1060 (LE f a) (GE f b) --> FALSE, a!=b 1061 (LE f a) (NL f b) --> (LE f a) a!=b 1062 FALSE, otherwise 1063 (LE f a) (NG f b) --> (LE f a), a!=b 1064 FALSE, otherwise 1066 (GE f a) (GE f b) --> (GE f a), a=b 1067 FALSE, otherwise 1068 (GE f a) (NL f b) --> (GE f a) a!=b 1069 FALSE, otherwise 1070 (GE f a) (NG f b) --> (GE f a) a!=b 1071 FALSE, otherwise 1073 (NL f a) (NL f b) --> (NL f a), a=b 1074 (NL f a) (NG f b) --> (NL f a), a=b 1076 (NG f a) (NG f b) --> (NG f a), a=b 1078 6. Other features and issues 1080 6.1 Named and auxiliary predicates 1082 Named and auxiliary predicates can serve two purposes: 1084 (a) making complex predicates easier to write and understand, and 1086 (b) providing a possible basis for naming and registering feature 1087 sets. 1089 6.1.1 Defining a named predicate 1091 A named predicate definition has the following form: 1093 named-pred = "(" fname *pname ")" ":-" filter 1094 fname = ftag ; Feature predicate name 1095 pname = token ; Formal parameter name 1097 'fname' is the name of the predicate. 1099 'pname' is the name of a formal parameter which may appear in the 1100 predicate body, and which is replaced by some supplied value when 1101 the predicate is invoked. 1103 RFC nnnn A syntax for describing media feature sets 1104 October 1998 1106 'filter' is the predicate body. It may contain references to the 1107 formal parameters, and may also contain references to feature tags 1108 and other values defined in the environment in which the predicate 1109 is invoked. References to formal parameters may appear anywhere 1110 where a reference to a feature tag ('ftag') is permitted by the 1111 syntax for 'filter'. 1113 The only specific mechanism defined by this memo for introducing a 1114 named predicate into a feature set definition is the "auxiliary 1115 predicate" described later. Specific negotiating protocols or 1116 other specifications may define other mechanisms. 1118 NOTE: There has been some suggestion of creating a 1119 registry for feature sets as well as individual feature 1120 values. Such a registry might be used to introduce named 1121 predicates corresponding to these feature sets into the 1122 environment of a capability assertion. Further 1123 discussion of this idea is beyond the scope of this memo. 1125 6.1.2 Invoking named predicates 1127 Assuming a named predicate has been introduced into the environment 1128 of some other predicate, it can be invoked by a filter 'ext-pred' 1129 of the form: 1131 ext-pred = fname *param 1132 param = expr 1134 The number of parameters must match the definition of the named 1135 predicate that is invoked. 1137 6.1.3 Auxiliary predicates in a filter 1139 A auxiliary predicate is attached to a filter definition by the 1140 following extension to the "filter" syntax: 1142 filter =/ "(" filtercomp *( ";" parameter ) ")" 1143 "where" 1*( named-pred ) "end" 1145 The named predicates introduced by "named-pred" are visible from 1146 the body of the "filtercomp" of the filter to which they are 1147 attached, but are not visible from each other. They all have 1148 access to the same environment as "filter", plus their own formal 1149 parameters. (Normal scoping rules apply: a formal parameter with 1150 the same name as a value in the environment of "filter" effectively 1151 hides the environment value from the body of the predicate to which 1152 it applies.) 1154 NOTE: Recursive predicates are not permitted. The 1155 scoping rules should ensure this. 1157 RFC nnnn A syntax for describing media feature sets 1158 October 1998 1160 6.1.4 Feature matching with named predicates 1162 The preceding procedures can be extended to deal with named 1163 predicates simply by instantiating (i.e. substituting) the 1164 predicates wherever they are invoked, before performing the 1165 conversion to disjunctive normal form. In the absence of recursive 1166 predicates, this procedure is guaranteed to terminate. 1168 When substituting the body of a precdicate at its point of 1169 invocation, instances of formal parameters within the predicate 1170 body must be replaced by the corresponding actual parameter from 1171 the point of invocation. 1173 6.1.4 Example 1175 This example restates that given in section 4.3 using an auxiliary 1176 predicate named 'Res': 1178 (| (& (Pix-x=1024) (Pix-y=768) (Res Res-x Res-y) ) 1179 (& (Pix-x=800) (Pix-y=600) (Res Res-x Res-y) );q=0.9 1180 (& (Pix-x=640) (Pix-y=480) (Res Res-x Res-y) );q=0.8 ) 1181 where 1182 (Res Res-x Res-y) :- 1183 (| (& (Res-x=150) (Res-y=150) ) 1184 (& (Res-x=150) (Res-y=300) ) 1185 (& (Res-x=300) (Res-y=300) ) 1186 (& (Res-x=300) (Res-y=600) ) 1187 (& (Res-x=600) (Res-y=600) ) ) 1188 end 1190 Note that the formal parameters of "Res", "Res-x" and "Res-y", 1191 prevent the body of the named predicate from referencing similarly- 1192 named feature values. 1194 6.2 Unit designations 1196 In some exceptional cases, there may be differing conventions for 1197 the units of measurement of a given feature. For example, 1198 resolution is commonly expressed as dots per inch (dpi) or dots per 1199 centimetre (dpcm) in different applications (e.g. printing vs 1200 faxing). 1202 In such cases, a unit designator may be appended to a feature value 1203 according to the conventions indicated below (see also [3]). These 1204 considerations apply only to features with numeric values. 1206 RFC nnnn A syntax for describing media feature sets 1207 October 1998 1209 Every feature tag has a standard unit of measurement. Any 1210 expression of a feature value that uses this unit is given without 1211 a unit designation -- this is the normal case. When the feature 1212 value is expressed in some other unit, a unit designator is 1213 appended to the numeric feature value. 1215 The registration of a feature tag indicates the standard unit of 1216 measurement for a feature, and also any alternate units and 1217 corresponding unit designators that may be used, according to [3]. 1219 Thus, if the standard unit of measure for resolution is 'dpcm', 1220 then the feature predicate '(res=200)' would be used to indicate a 1221 resolution of 200 dots-per-centimetre, and '(res=72dpi)' might be 1222 used to indicate 72 dots-per-inch. 1224 Unit designators are accommodated by the following extension to the 1225 feature predicate syntax: 1227 fvalue =/ number *WSP token 1229 When performing feature set matching, feature comparisons with and 1230 without unit designators, or feature comparisons with different 1231 unit designators, are treated as if they were different features. 1232 Thus, the feature predicate '(res=200)' would not, in general, fail 1233 to match with the predicate '(res=200dpi)'. 1235 NOTE: 1237 A protocol processor with specific knowledge of the 1238 feature and units concerned might recognize the 1239 relationship between the feature predicates in the above 1240 example, and fail to match these predicates. 1242 This appears to be a natural behaviour in this simple 1243 example, but can cause additional complexity in more 1244 general cases. Accordingly, this is not considered to be 1245 required or normal behaviour. It is presumed that an 1246 application concerned will ensure consistent feature 1247 processing by adopting a consistent unit for any given 1248 feature. 1250 6.3 Unknown feature value data types 1252 This memo has dealt with feature values that have well-understood 1253 comparison properties: numbers, with equality, less-than, greater- 1254 than relationships, and other values with equality relationships 1255 only. 1257 RFC nnnn A syntax for describing media feature sets 1258 October 1998 1260 Some feature values may have comparison operations that are not 1261 covered by this framework. For example, strings containing multi- 1262 part version numbers: "x.y.z". Such feature comparisons are not 1263 covered by this memo. 1265 Specific applications may recognize and process feature tags that 1266 are associated with such values. Future work may define ways to 1267 introduce new feature value data types in a way that allows them to 1268 be used by applications that do not contain built-in knowledge of 1269 their properties. 1271 7. Worked example 1273 [[[TODO]]] 1275 8. Algorithm source code 1277 [[[TODO]]] 1279 9. Security considerations 1281 Some security considerations for content negotiation are raised in 1282 [1,2,3]. 1284 The following are primary security concerns for capability 1285 identification mechanisms: 1287 . Unintentional disclosure of private information through the 1288 announcement of capabilities or user preferences. 1290 . Disruption to system operation caused by accidental or malicious 1291 provision of incorrect capability information. 1293 . Use of a capability identification mechanism might be used to 1294 probe a network (e.g. by identifying specific hosts used, and 1295 exploiting their known weaknesses). 1297 RFC nnnn A syntax for describing media feature sets 1298 October 1998 1300 The most contentious security concerns are raised by mechanisms 1301 which automatically send capability identification data in response 1302 to a query from some unknown system. Use of directory services 1303 (based on LDAP [7], etc.) seem to be less problematic because 1304 proper authentication mechanisms are available. 1306 Mechanisms which provide capability information when sending a 1307 message are less contentious, presumably because some intention can 1308 be inferred that person whose details are disclosed wishes to 1309 communicate with the recipient of those details. This does not, 1310 however, solve problems of spoofed supply of incorrect capability 1311 information. 1313 The use of format converting gateways may prove problematic because 1314 such systems would tend to defeat any message integrity and 1315 authenticity checking mechanisms that are employed. 1317 10. Full copyright statement 1319 Copyright (C) The Internet Society 1998. All Rights Reserved. 1321 This document and translations of it may be copied and furnished to 1322 others, and derivative works that comment on or otherwise explain 1323 it or assist in its implementation may be prepared, copied, 1324 published and distributed, in whole or in part, without restriction 1325 of any kind, provided that the above copyright notice and this 1326 paragraph are included on all such copies and derivative works. 1327 However, this document itself may not be modified in any way, such 1328 as by removing the copyright notice or references to the Internet 1329 Society or other Internet organizations, except as needed for the 1330 purpose of developing Internet standards in which case the 1331 procedures for copyrights defined in the Internet Standards process 1332 must be followed, or as required to translate it into languages 1333 other than English. 1335 The limited permissions granted above are perpetual and will not be 1336 revoked by the Internet Society or its successors or assigns. 1338 This document and the information contained herein is provided on 1339 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1340 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1341 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1342 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1343 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1345 RFC nnnn A syntax for describing media feature sets 1346 October 1998 1348 11. Acknowledgements 1350 Thanks are due to Larry Masinter for demonstrating the breadth of 1351 the media feature issue, and encouraging the development of some 1352 early thoughts. 1354 Many of the ideas presented derive from the "Transparent Content 1355 Negotiation in HTTP" work of Koen Holtman and Andy Mutz [4]. 1357 Early discussions of ideas with the IETF HTTP and FAX working 1358 groups led to further useful inputs from Koen Holtman, Ted Hardie 1359 and Dan Wing. The debate later moved to the IETF conneg working 1360 group, where Al Gilman was particularly helpful in helping to 1361 refine the feature set algebra. Ideas for dealing with preferences 1362 and specific units were suggested by Larry Masinter. 1364 This work was supported by Content Technologies Ltd and 5th 1365 Generation Messaging Ltd. 1367 12. References 1369 [1] "Scenarios for the Delivery of Negotiated Content" 1370 T. Hardie, NASA Network Information Center 1371 Internet draft: 1372 Work in progress, November 1997. 1374 [2] "Requirements for protocol-independent content negotiation" 1375 G. Klyne, Integralis Ltd. 1376 Internet draft: 1377 Work in progress, March 1998. 1379 [3] "Media Feature Tag Registration Procedure" 1380 Koen Holtman, TUE 1381 Andrew Mutz, Hewlett-Packard 1382 Ted Hardie, NASA 1383 Internet draft: 1384 Work in progress, July 1998. 1386 [4] RFC 2295, "Transparent Content Negotiation in HTTP" 1387 Koen Holtman, TUE 1388 Andrew Mutz, Hewlett Packard 1389 March 1998. 1391 [5] "Programming in Prolog" (2nd edition) 1392 W. F. Clocksin and C. S. Mellish, 1393 Springer Verlag 1394 ISBN 3-540-15011-0 / 0-387-15011-0 1395 1984. 1397 RFC nnnn A syntax for describing media feature sets 1398 October 1998 1400 [6] "Media Features for Display, Print, and Fax" 1401 Larry Masinter, Xerox PARC 1402 Koen Holtman, TUE 1403 Andrew Mutz, Hewlett-Packard 1404 Dan Wing, Cisco Systems 1405 Internet draft: 1406 Work in progress, January 1998. 1408 [7] RFC 2251, "Lightweight Directory Access Protocol (v3)" 1409 M. Wahl, Critical Angle Inc. 1410 T. Howes, Netscape Communications Corp. 1411 S. Kille, Isode Limited 1412 December 1997. 1414 [8] RFC 2254, "The String Representation of LDAP Search Filters" 1415 T. Howes, Netscape Communications Corp. 1416 December 1997. 1418 [9] RFC 2068, "Hyptertext Transfer Protocol -- HTTP/1.1" 1419 R. Fielding, UC Irvine 1420 J. Gettys, 1421 J. Mogul, DEC 1422 H. Frytyk, 1423 T. Berners-Lee, MIT/LCS 1424 January 1997. 1426 [10] RFC 2234, "Augmented BNF for Syntax Specifications: ABNF" 1427 D. Crocker (editor), Internet Mail Consortium 1428 P. Overell, Demon Internet Ltd. 1429 November 1997. 1431 [11] "Logic, Algebra and Databases" 1432 Peter Gray 1433 Ellis Horwood Series: Computers and their Applications 1434 ISBN 0-85312-709-3/0-85312-803-3 (Ellis Horwood Ltd) 1435 ISBN 0-470-20103-7/0-470-20259-9 (Halstead Press) 1436 1984. 1438 [12] "Logic and its Applications" 1439 Edmund Burk and Eric Foxley 1440 Prentice Hall, Series in computer science 1441 ISBN 0-13-030263-5 1442 1996. 1444 RFC nnnn A syntax for describing media feature sets 1445 October 1998 1447 13. Author's address 1449 Graham Klyne 1450 Content Technologies Ltd. 5th Generation Messaging Ltd. 1451 Forum 1 5 Watlington Street 1452 Station Road Nettlebed 1453 Theale Henley-on-Thames 1454 Reading, RG7 4RA RG9 5AB 1455 United Kingdom United Kingdom. 1457 Telephone: +44 118 930 1300 +44 1491 641 641 1459 Facsimile: +44 118 930 1301 +44 1491 641 611 1461 E-mail: GK@ACM.ORG