idnits 2.17.1 draft-ietf-conneg-feature-algebra-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 21 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (5 May 1998) is 9459 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: '0' is mentioned on line 846, 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' -- Possible downref: Non-RFC (?) normative reference: 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) Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 8 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 Ltd. 4 5 May 1998 5 Expires: 5 November 1998 7 An algebra 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 28 (US West Coast). 30 Copyright (C) 1998, The Internet Society 32 Abstract 34 A number of Internet application protocols have a need to provide 35 content negotiation for the resources with which they interact [1]. 36 A framework for such negotiation is described in [2]. Part of this 37 framework is a way to describe the range of media features which 38 can be handled by the sender, recipient or document transmission 39 format of a message. A format for a vocabulary of individual media 40 features and procedures for registering media features are 41 presented in [3]. 43 This document describes an algebra which can be used to define 44 feature sets which are formed from combinations and relations 45 involving individual media features. Such feature sets are used to 46 describe the media feature handling capabilities of message 47 senders, recipients and file formats. 49 An algebra for describing media feature sets 51 Table of contents 53 1. Introduction.............................................2 54 1.1 Structure of this document ...........................3 55 1.2 Discussion of this document ..........................4 56 1.3 Ammendment history ...................................4 57 1.4 Unfinished business ..................................4 58 2. Terminology and definitions..............................4 59 3. Media feature values.....................................5 60 3.1 Complexity of feature algebra ........................5 61 3.2 Sufficiency of simple types ..........................6 62 3.2.1 Unstructured data types..........................6 63 3.2.2 Cartesian product................................6 64 3.2.3 Disciminated union...............................7 65 3.2.4 Array............................................7 66 3.2.5 Powerset.........................................8 67 3.2.6 Sequence.........................................8 68 4. Feature set predicates...................................8 69 4.1 An algebra for data file format selection ............9 70 4.1.1 Describing file format features..................10 71 4.1.1.1 Feature ranges 10 72 4.1.1.2 Feature combinations 11 73 (A) Additional predicates 11 74 (B) Meta-features as groupings of other features 12 75 4.1.2 Content, sender and recipient capabilities.......12 76 4.2 Conclusion and proposal ..............................12 77 5. Indicating preferences...................................13 78 5.1 Combining preferences ................................13 79 5.2 Representing preferences .............................14 80 6. Feature set representation...............................15 81 6.1 Text string representation ...........................16 82 6.2 ASN.1 representation .................................17 83 7. Security considerations..................................18 84 8. Copyright................................................19 85 9. Acknowledgements.........................................19 86 10. References..............................................19 87 11. Author's address........................................21 89 1. Introduction 91 A number of Internet application protocols have a need to provide 92 content negotiation for the resources with which they interact [1]. 93 A framework for such negotiation is described in [2]. A part of 94 this framework is a way to describe the range of media features 95 which can be handled by the sender, recipient or document 96 transmission format of a message. 98 An algebra for describing media feature sets 100 Descriptions of media feature capabilities need to be based upon 101 some underlying vocabulary of individual media features. A format 102 for such a vocabulary and procedures for registering media features 103 are presented in [3]. 105 This document defines an algebra which can be used to describe 106 feature sets which are formed from combinations and relations 107 involving individual media features. Such feature sets are used to 108 describe the media handling capabilities of message senders, 109 recipients and file formats. 111 The feature set algebra is built around the principle of using 112 feature set predicates as mathematical relations which define 113 constraints on feature handling capabilities. The idea is that the 114 same form of feature set expression can be used to describe sender, 115 receiver and file format capabilities. This has been loosely 116 modelled on the way that the Prolog programming language uses Horn 117 Clauses to describe a set of result values. 119 In developing the algebra, axamples are given using notation drawn 120 from the C and Prolog programming languages. A syntax for 121 expressing feature predicates is suggested, based on LDAP search 122 filters. 124 1.1 Structure of this document 126 The main part of this draft addresses the following main areas: 128 Section 2 introduces and references some terms which are used with 129 special meaning. 131 Section 3 discusses constraints on the data types allowed for 132 individual media feature values. 134 Section 4 introduces and describes the algebra used to construct 135 feature set descriptions with expressions containing media 136 features. The first part of this section contains a development of 137 the ideas, and the second part contains the conclusions and 138 proposed algebra. 140 Section 5 introduces and describes extensions to the algebra for 141 indicating preferences between different feature sets. 143 Section 6 contains a description of recommended representations for 144 describing feature sets based on the previously-described algebra. 146 An algebra for describing media feature sets 148 1.2 Discussion of this document 150 Discussion of this document should take place on the content 151 negotiation and media feature reagistration mailing list hosted by 152 the Internet Mail Consortium (IMC): 154 Please send comments regarding this document to: 156 ietf-medfree@imc.org 158 To subscribe to this list, send a message with the body 'subscribe' 159 to "ietf-medfree-request@imc.org". 161 To see what has gone on before you subscribed, please see the 162 mailing list archive at: 164 http://www.imc.org/ietf-medfree/ 166 1.3 Ammendment history 168 00a 11-Mar-1998 169 Document initially created. 171 01a 05-May-1998 172 Mainly-editorial revision of sections describing the 173 feature types and algebra. Added section on indicating 174 preferences. Added section describing feature predicate 175 syntax. Added to security considerations (based on fax 176 negotiation scenarios draft). 178 1.4 Unfinished business 180 . Array values: are they needed? (section 3.2.4) 182 . Use of unknown data types for feature values (section 6) 184 . Is a test for presence of a feature required? (section 6) 186 . Should ASN.1 representation be pursued? If so, should it be 187 aligned with LDAP filter representation? (section 6.2) 189 2. Terminology and definitions 191 Feature Collection 192 is a collection of different media features and 193 associated values. This might be viewed as describing a 194 specific rendering of a specific instance of a document 195 or resource by a specific recipient. 197 An algebra for describing media feature sets 199 Feature Set 200 is a set of zero, one or more feature collections. 202 Feature set predicate 203 A function of an arbitrary feature collection value which 204 returns a Boolean result. A TRUE result is taken to mean 205 that the corresponding feature collection belongs to some 206 set of media feature handling capabilities defined by the 207 predicate. 209 Other terms used in this draft are defined in [2]. 211 3. Media feature values 213 This document assumes that individual media feature values are 214 simple atomic values: 216 . Boolean values 218 . Enumerated values 220 . Numeric values 222 More complex media feature values might be accommodated, but they 223 would (a) be undesirable because they would complicate the algebra, 224 and (b) are not necessary. 226 These statements are justified in the following sub-sections. 228 3.1 Complexity of feature algebra 230 Statement (a) above is justified as follows: predicates constructed 231 as expressions containing media feature values must ultimately 232 resolve to a logical combination of feature value tests. 234 A full range of simple tests for all of the data types listed above 235 can be performed based on just two fundamental operations: equality 236 and less-than. All other meaningful tests can be constructed as 237 predicates incorporating these two basic tests. 239 For example: 240 ( a != b ) iff !( a == b ) 241 ( a <= b ) iff !( b < a ) 242 ( a > b ) iff ( b < a ) 243 ( a >= b ) iff !( a < b ) 245 An algebra for describing media feature sets 247 If additional (composite) data types are introduced, then 248 additional operators must be introduced to test their component 249 parts: the addition of just one further comparison operator 250 increases the number of such operators by 50%. 252 3.2 Sufficiency of simple types 254 To justify statement (b), let us first review the range of 255 composite data types that might reasonably be considered. 257 In 1972, a paper "Notes on data structuring" by C. A. R. Hoare was 258 published in the book "Structured Programming" [4]. This was an 259 early formalization of data types used in programming languages, 260 and its content has formed a sufficient basis for describing the 261 data types in almost every programming language which has been 262 developed. This gives good grounds to believe that the type 263 framework is also sufficient for media features. 265 The data types covered by Hoare's paper are: 267 . Unstructured data types: (integer, real, enumeration, ordered 268 enumeration, subranges). 270 . Cartesian product (e.g. C 'struct'). 272 . Discriminated union (e.g. C 'union'). 274 . Array. 276 . Powerset (e.g. Pascal 'SET OF'). 278 . Sequence (e.g. C string, Pascal 'FILE OF'). 280 To demonstrate sufficiency of simple types for media features we 281 must show that the feature-set defining properties of these 282 composite types can be captured using predicates on the simple 283 simple types described previously. 285 3.2.1 Unstructured data types 287 The unstructured data types noted correspond closely to, and can be 288 represented by the proposed simple value types for media features. 290 3.2.2 Cartesian product 292 A cartesian product value (e.g. resolution=[x,y]) is easily 293 captured as a collection of two or more separately named media 294 features (e.g. x-resolution=x, y-resolution=y). 296 An algebra for describing media feature sets 298 3.2.3 Disciminated union 300 A discriminated union value is an either/or type of choice. For 301 example, a given workstation might be able to display 16K colours 302 at 1024x768 resolution, OR 256 colours at 1280x1024 resolution. 304 These possibilities are captured by a logical-OR of predicates: 305 ( ( x-resolution <= 1024 ) && 306 ( y-resolution <= 768 ) && 307 ( colours <= 16384 ) ) || 308 ( ( x-resolution <= 1280 ) && 309 ( y-resolution <= 1024 ) && 310 ( colours <= 256 ) ) 312 3.2.4 Array 314 An array represents a mapping from one data type to another. For 315 example, the availability of pens in a pen plotter might be 316 represented by an array which maps a pen number to a colour. 318 If the array index which forms the basis for defining a feature set 319 is assumed to be a constant, then each member can be designated by 320 a feature name which incorporates the index value. For example: 321 Pen-1=black, pen-2=red, etc. 323 Another example where an array might describe a media feature is a 324 colour palette: an array is used to associate a colour value (in 325 terms of RGB or some other colour model) with a colour index value. 326 In this case is is possible to envisage a requirement for a 327 particular colour to be loaded in the palette without any knowledge 328 of the index which maps to it. 330 In this case, the colour might be treated as a named Boolean 331 attribute: if TRUE then that colour is deemed to be available in 332 the pallette 334 Feature selection based on a variable array index is more 335 difficult, but it is believed that this is not required for media 336 selection. 338 [[I cannot think of any example of feature selection which involves 339 a variable index into an array. If such a feature is presented, an 340 array type could be added to the set of allowable media feature 341 types, and an array selection operator added to the algebra.]] 343 An algebra for describing media feature sets 345 3.2.5 Powerset 347 A powerset is a collection of zero, one or more values from some 348 base set of values. A colour palette may be viewed as a powerset 349 of colour values, or the fonts available in a printer as a powerset 350 of all available fonts. 352 A powerset is very easily represented by a separate Boolean-valued 353 feature for each member of the base set. The value TRUE indicates 354 that the corresonding value is a member of the powerset value. 356 3.2.6 Sequence 358 A sequence is a list of values from some base set of values, which 359 are accessed sequentially. 361 A sequence can be modelled by an array if one assumes integer index 362 values starting at (say) 1 and incrementing by 1 for each 363 successive element of the sequence. 365 Thus, the considerations described above relating to array values 366 can be considered as also applying (in part) to sequence values. 367 That is, if arrays are deemed to be adequately handled, then 368 sequence values too can be handled. 370 4. Feature set predicates 372 A model for data file selection is proposed, based on relational 373 set definition and subset selection, using elements of the Prolog 374 programming language [5] as a descriptive notation for this 375 purpose. 377 NOTE: The use of Prolog as a syntax for feature 378 description is NOT being proposed; rather, the Prolog- 379 like notation is used to develop the semantics of an 380 algebra. Once the semantics have been developed, they 381 can be mapped to some convenient syntax. 383 For the purposes of developing this algebra, examples are drawn 384 from the media features described in "Media Features for Display, 385 Print, and Fax" [6], which in summary are: 387 pix-x=n (Image size, in pixels) 388 pix-y=m 390 res-x=n (Image resolution, pixels per inch) 391 res-y=m 393 An algebra for describing media feature sets 395 UA-media= screen|stationary|transparency|envelope| 396 continuous-long 397 papersize= na-letter|iso-A4|iso-B4|iso-A3|na-legal 399 color=n (Colour depth in bits) 400 grey=n (Grey scale depth in bits) 402 4.1 An algebra for data file format selection 404 The basic idea proposed here is that a feature capability of the 405 original content, sender, data file format or recipient is 406 represented as a predicate applied to a collection of feature 407 values. Under universal quantification (i.e. selecting all 408 possible values that satisfy it), a predicate indicates a range of 409 possible combinations of feature values). 411 This idea is inherent in Prolog clause notation, which is used in 412 the example below to describe a predicate 413 'acceptable_file_format(File)' which yields a set of possible file 414 transfer formats using other predicates which indicate the file 415 formats available to the sender and feature capabilities of the 416 file format, original content: 418 acceptable_file_format(File) :- 419 sender_available_file_format(File), 420 match_format(File). 422 match_format(File) :- 423 pix_x(File,Px), content_pix_x(Px), recipient_pix_x(Px), 424 pix_y(File,Py), content_pix_x(Py), recipient_pix_y(Py), 425 res_x(File,Rx), content_res_x(Rx), recipient_res_x(Rx), 426 res_y(File,Ry), content_res_y(Ry), recipient_res_y(Ry), 427 colour(File,C), content_colour(C), recipient_colour(C), 428 grey(File,G), content_grey(G), recipient_grey(G), 429 ua_media(File,M), 430 content_ua_media(M), 431 recipient_ua_media(M), 432 papersize(File,P), 433 content_papersize(P), 434 recipient_papersize(P). 436 Essentially, this selects a set of file transfer formats from those 437 available ('sender_available_file_format'), choosing any whose 438 feature capabilities have a non-empty intersection with the feature 439 capabilities of the original content and the recipient. 441 An algebra for describing media feature sets 443 4.1.1 Describing file format features 445 The above framework suggests a file format is described by a set of 446 feature values. As an abstract theory, this works fine but for 447 practical use it has a couple of problems: 449 (a) description of features with a large number of possibilities 451 (b) describing features which are supported in specific 452 combinations 454 A typical case of (a) would be where a feature (e.g. size of image 455 in pixels) can take any value from a range. To present and test 456 each value separately is not a practical proposition, even if it 457 were possible. (A guide here as to what constitutes a practical 458 approach is to make a judgement about the feasibility of writing 459 the corresponding Prolog program.) 461 A typical case of (b) would be where different values for certain 462 features can occur only in combinations (e.g. allowable 463 combinations of resolution and colour depth on a given video 464 display). If the features are treated independently as suggested 465 by the framework above, all possible combinations would be allowed, 466 rather than the specifically allowable combinations. 468 4.1.1.1 Feature ranges 470 The first issue can be addressed by considering the type of value 471 which can represent the allowed features of a data file format. 472 The features of a specific data file are represented as values from 473 an enumeration (e.g. ua_media, papersize), or a numeric values 474 (integer or rational). The description of allowable file format 475 feature needs to represent all the allowable values. 477 The Prolog clauses used above to describe file format features 478 already allow for multiple enumerated values. Each acts as a 479 mathematical relation to select a subset of the set of file values 480 allowed by the preceding predicates. 482 Section 3 of this document describes proposed media feature value 483 types. 485 For numeric feature values, a sequence of two numbers to represent 486 a closed interval is suggested, where either value may be replaced 487 by an empty list to indicate no limiting value. Thus: 489 [m,n] => { x : m <= x <= n } 490 [m,[]] => { x : m <= x } 491 [[],n] => { x : x <= n } 493 An algebra for describing media feature sets 495 The following Prolog could be used to describe such range matching: 497 feature_match(X,[[],[]]). 498 feature_match(X,[L,[]]) :- L <= X. 499 feature_match(X,[[],H]) :- X <= H. 500 feature_match(X,[L,H]) :- L <= X, X <= H. 501 feature_match(X,X). 503 (This example strectches standard Prolog, which does not support 504 non-integer numbers. The final clause allows 'feature_match' to 505 deal with equality matching for the normal enumerated value case.) 507 4.1.1.2 Feature combinations 509 Representing allowed combinations of features is trickier. Two 510 possible approaches might be considered: 512 (a) use additional predicates to impose relationships between 513 features. 515 (b) allow meta-features which are groupings of other features. 517 (A) Additional predicates 519 If x- and y- resolutions were to be constrained to square or semi- 520 square aspect-ratios, the following predicates might be added to 521 the feature set description: 523 ( feature_match(Rx,Ry) ; 524 feature_match(Rx,2*Ry) ; 525 feature_match(2*Rx,Ry) ), 526 feature_match(Rx,[72,600]), 527 feature_match(Ry,[72,600]) 529 (where the last two constraints might be imposed by the 'res_x' and 530 'res_y' predicates). 532 Another example might be: 534 ( ( feature_match(Px,640), feature_match(Py,480) ) ; 535 ( feature_match(Px,600), feature_match(Py,800) ) ; 536 ( feature_match(Px,1024), feature_match(Py,768) ) ) 538 This is based on the predicates 'pix_x(File,Px)', 'pix_y(File,Py)', 539 'res_x(File,Rx)' and 'res_y(File,Ry)' from the initial framework 540 above.) 542 An algebra for describing media feature sets 544 (B) Meta-features as groupings of other features 546 Applying this to the above examples would replace: 548 pix_x(File,Px), 549 pix_y(File,Py), 550 res_x(File,Rx), 551 res_y(File,Ry), 553 with the meta-features 'pix' and 'res': 555 pix(File,[Px,Py]), 556 res(File,[Rx,Ry]) 558 where: 560 pix(File,[640, 480]). 561 pix(File,[800, 600]). 562 pix(File,[1024,768]). 563 res(File,[Rx,Ry]) :- 564 feature_match(Rx,[72,600]), 565 feature_match(Ry,[72,600]), 566 ( feature_match(Rx,Ry) ; 567 feature_match(Rx,2*Ry) ; 568 feature_match(2*Rx,Ry) ). 570 On closer examination, these two options turn out to be pretty much 571 the same thing: a requirement to impose additional constraint 572 predicates on a file feature set. They differ only in where the 573 predicates are applied. 575 This all suggests that file format capabilities can be described by 576 feature set predicates: arbitrary logical expressions using AND, 577 OR, NOT logical combining operators, and media feature value 578 matching. 580 4.1.2 Content, sender and recipient capabilities 582 It has already been suggested that these are represented as 583 predicates on the feature set of a particular data file. 585 Having also shown that these same predicates can represent 586 constraints on feature combinations, we proceed directly to a 587 proposal that everything is represented by predicates. 589 4.2 Conclusion and proposal 591 Data file features, original content features, sender features and 592 recipient features (and user features) can all be represented as 593 predicates. 595 An algebra for describing media feature sets 597 A key insight, which points to this conclusion, is that a 598 collection of feature values can be viewed as describing a specific 599 document rendered by a specific recipient. The capabilities that 600 we wish to describe, be they sender, file format, recipient or 601 other capabilities, are sets of such feature collections, with the 602 potential to ultimately render using any of the feature value 603 collections in the set. 605 This raises a terminology problem, because the term "feature set" 606 has been used to mean a collection of specific feature values and a 607 range of possible feature values. Thus the more restricted 608 definitions of "feature collection" and "feature set" which appear 609 in the terminology section of this document. 611 Original content, data files and recipients (and users) all embody 612 the potential capability to deal with a "feature set". One of the 613 aims of content negotiation is to select an available data file 614 format (availability being circumscribed by the original content 615 and sender capabilities) whose feature set intersection with the 616 recipient feature set is non-empty. (The further issue of 617 preference being deferred for later consideration.) 619 The concept of a mathematical relation as a subset defined by a 620 predicate can be used to define feature sets, using universal 621 quantification (i.e. using the predicate to select from some 622 notional universe of all possible feature collections). 624 Thus, a common framework of predicates can be used to represent the 625 feature capabilities of original content, data file formats, 626 recipients and any other participating entity which may impose 627 constraints on the usable feature sets. 629 Within this framework, it is sufficient to represent individual 630 feature values as enumerated values or numeric ranges. The thesis 631 in section 3 of his document, combined with a study of "Media 632 Features for Display, Print, and Fax" [6], indicate that more 633 complex media feature values can be handled by predicates. 635 5. Indicating preferences 637 5.1 Combining preferences 639 The general problem of describing and combining preferences among 640 feature sets is very much more complex than simply describing 641 allowable feature sets. For example, given two feature sets: 642 {A1,B1} 643 {A2,B2} 645 An algebra for describing media feature sets 647 where: 648 A1 is preferred over A2 649 B2 is preferred over B1 651 which of the feature sets is preferred? In the absence of 652 additional information or assumptions, there is no generally 653 satisfactory answer to this. 655 The proposed resolution of this issue is simply to assert that 656 preference information cannot be combined. Applied to the above 657 example, any preference information about A1 in relation to A2, or 658 B1 in relation to B2 is not presumed to convey any information 659 about preference of {A1,B1} in relation to {A2,B2}. (This approach 660 was selected as being the simplest among those considered, and 661 because there is no clear need for anything more). 663 In practical terms, this restricts the aplication of preference 664 information to top-level predicate clauses. A top-level clause 665 completely defines an allowable feature set; clauses combined by 666 logical-AND operators cannot be top-level clauses. 668 5.2 Representing preferences 670 A convenient way to represent preferences is by numeric "quality 671 values", as used in HTTP "Accept" headers, etc. (see RFC 2068 [9], 672 section 3.9]). 674 It has been suggested that numeric quality values, as used in some 675 HTTP negotiations, are misleading and are really just a way of 676 ranking options. Attempts to perform arithmetic on quality values 677 do seem to degenerate into meaningless juggling of numbers. 679 Numeric quality values in the range 0 to 1 (as defined by RFC 2068 680 [9], section 3.9) are used to rank feature sets according to 681 preference. Higher values are preferred over lower values, and 682 equal values are presumed to be equally preferred. Beyond this, 683 the actual number used has no significance, and should not be used 684 as a basis for any arithmetic operation. 686 In the absence of any explcitly applied quality value, a value of 687 "1" is assumed, suggesting an option which is equally or more 688 preferred than any other. 690 This approach can be represented in the Prolog-based framework of 691 an earlier example as follows: 693 match_format(File,Qvalue) :- 694 match_format(File), 695 Qvalue=1. 697 An algebra for describing media feature sets 699 match_format(File) :- 700 pix(File,[1024,768], 701 res(File,[Rx,Ry]). 703 match_format(File,Q) :- 704 pix(File,[800, 600]), 705 res(File,[Rx,Ry]), 706 Qvalue=0.9. 708 match_format(File,Q) :- 709 pix(File,[640, 480]). 710 res(File,[Rx,Ry]), 711 Qvalue=0.8. 713 res(File,[Rx,Ry]) :- 714 feature_match(Rx,[72,600]), 715 feature_match(Ry,[72,600]), 716 ( feature_match(Rx,Ry) ; 717 feature_match(Rx,2*Ry) ; 718 feature_match(2*Rx,Ry) ). 720 This example applies image preference ranking based solely on the 721 size of the image, provided that the resolution constrains are 722 satisfied. 724 6. Feature set representation 726 The foregoing sections have desribed a framework and semantics for 727 defining feature sets with predicates applied to feature 728 collections. This section proposes some concrete representations 729 for these feature setpredicates. 731 Rather than invent an all-new notation, this proposal adapts a 732 notation already defined for directory access [7,8]. Observe that 733 a feature collection is similar to a directory entry, in that it 734 consists of a collection of named values. Further, the semantics 735 of the mechanism for selecting feature collections from a feature 736 set is in most respects identical to selection of directory entries 737 from a directory. 739 Differences between directory selection (per [7]) and feature set 740 selection described previously are: 742 . Directory selection provides substring-, approximate- and 743 extensible- matching for attribute values. Directory selection 744 may also be based on the presence of an attribute without regard 745 to its value. 747 An algebra for describing media feature sets 749 . Directory selection provides for matching rules which are 750 dependent upon the declared data type of an attribute value. 752 . Feature selection provides for the association of a quality value 753 with a top-level feature predicate as a way of ranking the 754 selected value collections. 756 The idea of substring matching does not seem to be relevant to 757 feature set selection, and is excluded from these proposals. 759 The idea of extensible matching and matching rules dependent upon 760 data types are facets of a problem not addressed by this memo, but 761 which do not necessarily affect the feature selection syntax. An 762 aspect which might have a bearing on the syntax would be a 763 requirement to specify a matching rule explicitly as part of a 764 selection expression. 766 Testing for the presence of a feature may be useful in some 767 circumstances, but does not sit comfortably within the semantic 768 framework. Feature sets are described by universal quantification 769 over predicates, and the absence of reference to a given feature 770 means the set is not constrained by that feature. Against this, it 771 is difficult to define what might be meant by "presence" of a 772 feature, so this option is not included in these proposals. 774 6.1 Text string representation 776 The text representation of a feature set is closely based on RFC 777 2254 "The String Representation of LDAP Search Filters" [8], 778 excluding those elements not relevant to feature set selection 779 (discussed above), and adding options to associate quality values 780 with top-level predicates. 782 The format of a feature predicate is defined by the production for 783 "filter" in the following, using the syntax notation of [10]: 785 filter = "(" filtercomp [ ";" "q=" qvalue ] )" 786 qvalue = ( "0" [ "." 0*3DIGIT ] ) 787 / ( "1" [ "." 0*3("0") ] ) 788 filtercomp = and / or / not / item 789 and = "&" filterlist 790 or = "|" filterlist 791 not = "!" filter 792 filterlist = 1*filter 793 item = simple 795 An algebra for describing media feature sets 797 simple = attr filtertype value 798 filtertype = equal / greater / less 799 equal = "=" 800 approx = "~=" 801 greater = ">=" 802 less = "<=" 803 attr = 804 value = 806 As described, the syntax permits a quality value to be attached to 807 any "filter" value in the predicate (not just top-level values). 808 But it should be noted that values which are enclosed by "not" or 809 "and" constructs are not visible to the enclosing context. 811 If a given feature collection is matched by more than one "filter" 812 in an "or" clause, the highest associated quality value is applied. 814 NOTE 816 The flexible approach to allowable quality values in this 817 syntax has been adopted for two reasons: (a) to make it 818 easy to combine separately constructed feature 819 predicates, and (b) to allow that the mechanism used for 820 quality values might, in future, be generalized to an 821 extensible tagging mechanism (for example, to incorporate 822 a conceivable requirement to explicitly specify a 823 matching rule). 825 6.2 ASN.1 representation 827 Should it be required, the LDAP search filter model provides the 828 basis for an ASN.1 representation of a feature predicate. 830 The following ASN.1 is adapted from RFC 2251 "Lightweight Directory 831 Access Protocol (v3)" [7] (also contained in RFC 2254 "The String 832 Representation of LDAP Search Filters" [8]) to mirror the 833 adaptation of the string representation presented above 835 [[The following ASN.1 fragment does not include provision for 836 quality value (and possibly other parameter values) to be attached 837 to a filter value. Also, if using an ASN.1-derived representation 838 it would seem more appropriate to use an ISO object identifier for 839 the feature tag, and an appropriate ASN.1 type for the feature 840 value. Such changes would remove any semblance of compatibility 841 with LDAP, but that may not matter.]] 843 An algebra for describing media feature sets 845 Filter ::= CHOICE { 846 and [0] SET OF Filter, 847 or [1] SET OF Filter, 848 not [2] Filter, 849 equalityMatch [3] AttributeValueAssertion, 850 greaterOrEqual [5] AttributeValueAssertion, 851 lessOrEqual [6] AttributeValueAssertion 852 } 854 AttributeValueAssertion ::= SEQUENCE { 855 featureTag OCTET STRING, 856 featureValue OCTET STRING 857 } 859 7. Security considerations 861 Some security considerations for content negotiation are raised in 862 [1,2,3]. 864 The following are primary security concerns for capability 865 identification mechanisms: 867 . Unintentional disclosure of private information through the 868 announcement of capabilities or user preferences. 870 . Disruption to system operation caused by accidental or malicious 871 provision of incorrect capability information. 873 . Use of a capability identification mechanism might be used to 874 probe a network (e.g. by identifying specific hosts used, and 875 exploiting their known weaknesses). 877 The most contentious security concerns are raised by mechanisms 878 which automatically send capability identification data in response 879 to a query from some unknown system. Use of directory services 880 (based on LDAP [7], etc.) seem to be less problematic because 881 proper authentication mechanisms are available. 883 Mechanisms which provide capability information when sending a 884 message are less contentious, presumably because some intention can 885 be inferred that person whose details are disclosed wishes to 886 communicate with the recipient of those details. This does not, 887 however, solve problems of spoofed supply of incorrect capability 888 information. 890 The use of format converting gateways may prove problematic because 891 such systems would tend to defeat any message integrity and 892 authenticity checking mechanisms that are employed. 894 An algebra for describing media feature sets 896 8. Copyright 898 Copyright (C) The Internet Society 1998. All Rights Reserved. 900 This document and translations of it may be copied and furnished to 901 others, and derivative works that comment on or otherwise explain 902 it or assist in its implementation may be prepared, copied, 903 published and distributed, in whole or in part, without restriction 904 of any kind, provided that the above copyright notice and this 905 paragraph are included on all such copies and derivative works. 906 However, this document itself may not be modified in any way, such 907 as by removing the copyright notice or references to the Internet 908 Society or other Internet organizations, except as needed for the 909 purpose of developing Internet standards in which case the 910 procedures for copyrights defined in the Internet Standards process 911 must be followed, or as required to translate it into languages 912 other than English. 914 The limited permissions granted above are perpetual and will not be 915 revoked by the Internet Society or its successors or assigns. 917 This document and the information contained herein is provided on 918 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 919 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 920 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 921 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 922 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 924 9. Acknowledgements 926 My thanks to Larry Masinter for demonstrating to me the breadth of 927 the media feature issue, and encouraging me to air my early ideas. 929 Early discussions of ideas on the IETF-HTTP and IETF-FAX discussion 930 lists led to useful inputs also from Koen Holtman, Ted Hardie and 931 Dan Wing. 933 The debate later moved to the IETF conneg WG mailing list, where Al 934 Gilman was particularly helpful in helping me to refine the feature 935 set algebra. Several ideas for indicating preferences were 936 suggested by Larry Masinter. 938 10. References 940 [1] "Scenarios for the Delivery of Negotiated Content" 941 T. Hardie, NASA Network Information Center 942 Internet draft: 943 Work in progress, November 1997. 945 An algebra for describing media feature sets 947 [2] "Requirements for protocol-independent content negotiation" 948 G. Klyne, Integralis Ltd. 949 Internet draft: 950 Work in progress, March 1998. 952 [3] "Content feature tag registration procedures" 953 Koen Holtman, TUE 954 Andrew Mutz, Hewlett-Packard 955 Ted Hardie, NASA 956 Internet draft: 957 Work in progress, November 1997. 959 [4] "Notes on data structuring" 960 C. A. R. Hoare, 961 in "Structured Programming" 962 Academic Press, APIC Studies in Data Processing No. 8 963 ISBN 0-12-200550-3 / 0-12-200556-2 964 1972. 966 [5] "Programming in Prolog" (2nd edition) 967 W. F. Clocksin and C. S. Mellish, 968 Springer Verlag 969 ISBN 3-540-15011-0 / 0-387-15011-0 970 1984. 972 [6] "Media Features for Display, Print, and Fax" 973 Larry Masinter, Xerox PARC 974 Koen Holtman, TUE 975 Andrew Mutz, Hewlett-Packard 976 Dan Wing, Cisco Systems 977 Internet draft: 978 Work in progress, January 1998. 980 [7] RFC 2251, "Lightweight Directory Access Protocol (v3)" 981 M. Wahl, Critical Angle Inc. 982 T. Howes, Netscape Communications Corp. 983 S. Kille, Isode Limited 984 December 1997. 986 [8] RFC 2254, "The String Representation of LDAP Search Filters" 987 T. Howes, Netscape Communications Corp. 988 December 1997. 990 [9] RFC 2068, "Hyptertext Transfer Protocol -- HTTP/1.1" 991 R. Fielding, UC Irvine 992 J. Gettys, 993 J. Mogul, DEC 994 H. Frytyk, 995 T. Berners-Lee, MIT/LCS 996 January 1997. 998 An algebra for describing media feature sets 1000 [10] RFC 2234, "Augmented BNF for Syntax Specifications: ABNF" 1001 D. Crocker (editor), Internet Mail Consortium 1002 P. Overell, Demon Internet Ltd. 1003 November 1997. 1005 11. Author's address 1007 Graham Klyne 1008 Content Technologies Ltd 1009 Forum 1 1010 Station Road 1011 Theale 1012 Reading, RG7 4RA 1013 United Kingdom 1015 Telephone: +44 118 930 1300 1017 Facsimile: +44 118 930 1301 1019 E-mail: GK@ACM.ORG