idnits 2.17.1 draft-ietf-conneg-feature-syntax-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 27 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. ** There are 27 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** 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 172: '... "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 (September 1998) is 9348 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC2119' on line 174 == Unused Reference: '4' is defined on line 1259, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1275, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1293, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** 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' -- Possible downref: Non-RFC (?) normative reference: ref. '13' Summary: 15 errors (**), 0 flaws (~~), 6 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF media feature registration WG Graham Klyne 3 INTERNET-DRAFT Content Technologies/5GM 4 Category: Work-in-progress September 1998 5 Expires: March 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: 31 This document specifies an Internet standards track protocol for 32 the Internet community, and requests discussion and suggestions for 33 improvements. Please refer to the current edition of the "Internet 34 Official Protocol Standards" (STD 1) for the standardization state 35 and status of this protocol. Distribution of this memo is 36 unlimited.]] 38 Copyright Notice 40 Copyright (C) The Internet Society 1998. All Rights Reserved. 42 Abstract 44 A number of Internet application protocols have a need to provide 45 content negotiation for the resources with which they interact [1]. 46 A framework for such negotiation is described in [2]. Part of this 47 framework is a way to describe the range of media features which 48 can be handled by the sender, recipient or document transmission 49 format of a message. A format for a vocabulary of individual media 50 features and procedures for registering media features are 51 presented in [3]. 53 RFC nnnn A syntax for describing media feature sets 54 September 1998 56 This document introduces and describes a syntax that can be used to 57 define feature sets which are formed from combinations and 58 relations involving individual media features. Such feature sets 59 are used to describe the media feature handling capabilities of 60 message senders, recipients and file formats. 62 This document also outlines an algorithm for feature set matching. 64 Table of contents 66 1. Introduction.............................................3 67 1.1 Structure of this document ...........................4 68 1.2 Document terminology and conventions .................4 69 1.3 Discussion of this document ..........................4 70 1.4 Amendment history ....................................5 71 1.5 Unfinished business ..................................6 72 2. Content feature terminology and definitions..............6 73 3. Media feature combinations and capabilities..............6 74 3.1 Media features .......................................6 75 3.2 Media feature collections and sets ...................7 76 3.3 Media feature set descriptions .......................7 77 3.4 Media feature combination scenario ...................8 78 3.4.1 Data resource options............................8 79 3.4.2 Recipient capabilities...........................8 80 3.4.3 Combined options.................................9 81 3.5 Feature set predicates ...............................9 82 4. Feature set representation...............................10 83 4.1 Textual representation of predicates .................11 84 4.2 Named and auxiliary predicates .......................12 85 4.2.1 Defining a named predicate.......................12 86 4.2.2 Invoking named predicates........................13 87 4.2.3 Auxiliary predicates in a filter.................13 88 4.3 Feature set definition examples ......................14 89 4.3.1 Single predicate.................................14 90 4.3.2 Predicate with auxiliary predicate...............14 91 5. Processing feature set descriptions......................15 92 5.1 Matching feature sets ................................15 93 5.1.1 Feature set matching strategy....................17 94 5.1.2 Formulating the goal predicate...................17 95 5.1.3 Replace set expressions..........................18 96 5.1.4 Replace comparisons and logical negations........18 97 5.1.5 Conversion to canonical form.....................20 98 5.1.6 Grouping of feature predicates...................20 99 5.1.7 Merge single-feature constraints.................21 100 5.1.7.1 Rules for simplifying ordered values 21 101 5.1.7.2 Rules for simplifying unordered values 22 102 5.2 Effect of named predicates ...........................22 103 5.3 Unit designations ....................................22 104 5.4 Unknown feature value data types .....................24 106 RFC nnnn A syntax for describing media feature sets 107 September 1998 109 5.5 Worked example .......................................24 110 5.6 Algorithm source code ................................24 111 6. Security considerations..................................24 112 7. Copyright................................................25 113 8. Acknowledgements.........................................26 114 9. References...............................................26 115 10. Author's address........................................28 117 1. Introduction 119 A number of Internet application protocols have a need to provide 120 content negotiation for the resources with which they interact [1]. 121 A framework for such negotiation is described in [2]. A part of 122 this framework is a way to describe the range of media features 123 which can be handled by the sender, recipient or document 124 transmission format of a message. 126 Descriptions of media feature capabilities need to be based upon 127 some underlying vocabulary of individual media features. A format 128 for such a vocabulary and procedures for registering media features 129 within this vocabulary are presented in [3]. 131 This document defines a syntax that can be used to describe feature 132 sets which are formed from combinations and relations involving 133 individual media features. Such feature sets are used to describe 134 the media handling capabilities of message senders, recipients and 135 file formats. 137 This document also outlines an algorithm for feature set matching. 139 The feature set syntax is built upon the principle of using feature 140 set predicates as "mathematical relations" which define constraints 141 on feature handling capabilities. This allows that the same form 142 of feature set expression can be used to describe sender, receiver 143 and file format capabilities. This has been loosely modelled on 144 the way that relational databases use Boolean expresions to 145 describe a set of result values, and a syntax that is based upon 146 LDAP search filters. 148 RFC nnnn A syntax for describing media feature sets 149 September 1998 151 1.1 Structure of this document 153 The main part of this memo addresses the following main areas: 155 Section 2 introduces and references some terms which are used with 156 special meaning. 158 Section 3 introduces the concept of describing media handling 159 capabilities as combinations of possible media features, and the 160 idea of using Boolean expressions to express such combinations. 162 Section 4 contains a description of a syntax for describing feature 163 sets based on the previously-introduced idea of Boolean expressions 164 used to describe media feature combinations. 166 Section 5 discusses some feature set description processing issues, 167 including a description of an algorithm for feature set matching. 169 1.2 Document terminology and conventions 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in [RFC2119]. 175 NOTE: Comments like this provide additional nonessential 176 information about the rationale behind this document. 177 Such information is not needed for building a conformant 178 implementation, but may help those who wish to understand 179 the design in greater depth. 181 1.3 Discussion of this document 183 Discussion of this document should take place on the content 184 negotiation and media feature registration mailing list hosted by 185 the Internet Mail Consortium (IMC): 187 Please send comments regarding this document to: 189 ietf-medfree@imc.org 191 To subscribe to this list, send a message with the body 'subscribe' 192 to "ietf-medfree-request@imc.org". 194 To see what has gone on before you subscribed, please see the 195 mailing list archive at: 197 http://www.imc.org/ietf-medfree/ 199 RFC nnnn A syntax for describing media feature sets 200 September 1998 202 1.4 Amendment history 204 00a 28-Sep-1998 This memo created to contain a description of the 205 syntax-related features from a previous.draft "An 206 algebra for describing media feature sets". 207 Theoretical background material is replaced by a 208 more practically oriented introduction to the 209 concepts, and references to ASN.1 representation 210 have been removed. 212 Revision history of "An algebra for describing media feature sets": 214 00a 11-Mar-1998 Document initially created. 216 01a 05-May-1998 Mainly-editorial revision of sections describing 217 the feature types and algebra. Added section on 218 indicating preferences. Added section describing 219 feature predicate syntax. Added to security 220 considerations (based on fax negotiation scenarios 221 draft). 223 01b 25-Jun-1998 New Internet draft boilerplate in 'status' 224 preface. Review and rationalization of sections 225 on feature combinations. Added numeric 226 expressions, named predicates and auxiliary 227 predicates as options in the syntax. Added 228 examples of text string predicate representation. 230 02a 08-Jul-1998 Added chapter on protocol processing 231 considerations, and in particular outlined an 232 algorithm for feature set matching. Added 233 restrictions to the form of arithmetic expression 234 to allow deterministic feature set matching. 236 03a 27-Jul-1998 Simplified feature set handling by removing 237 options for expressions on the RHS of feature 238 comparison expressions. Syntax elements have been 239 added as placeholders for possible future 240 extensions in this area; examples have been 241 adjusted accordingly, and the feature set matching 242 algorithm greatly simplified. Add simple unit 243 designations. 245 RFC nnnn A syntax for describing media feature sets 246 September 1998 248 1.5 Unfinished business 250 . Discuss determination of qvalues in the feature set matching 251 algorithm. 253 . Use of unknown data types for feature values (section 5.3) 255 . Add worked example and source code for feature matching 256 implementation. 258 2. Content feature terminology and definitions 260 Feature Collection 261 is a collection of different media features and 262 associated values. This might be viewed as describing a 263 specific rendering of a specific instance of a document 264 or resource by a specific recipient. 266 Feature Set 267 is a set of zero, one or more feature collections. 269 Feature set predicate 270 A function of an arbitrary feature collection value which 271 returns a Boolean result. A TRUE result is taken to mean 272 that the corresponding feature collection belongs to some 273 set of media feature handling capabilities defined by 274 this predicate. 276 Other terms used in this draft are defined in [2]. 278 3. Media feature combinations and capabilities 280 3.1 Media features 282 This memo assumes that individual media feature values are simple 283 atomic values: 285 . Boolean values. 287 . Enumerated values. 289 . Text string values (treated as atomic entities, like enumerated 290 value tokens). 292 . Numeric values (Integer or rational). 294 RFC nnnn A syntax for describing media feature sets 295 September 1998 297 These values all have the property that they can be compared for 298 equality ('='), and that numeric and ordered enumeration values can 299 be compared for less-than and greater-than relationship ('<=', 300 '>='). These basic comparison operations are used as the primitive 301 building blocks for more comprehensive capability expressions. 303 3.2 Media feature collections and sets 305 Any single media feature value can be thought of as just one 306 component of a feature collection that describes some instance of a 307 resource (e.g. a printed document, a displayed image, etc.). Such 308 a feature collection consists of a number of media feature tags 309 (each per [3]) and associated feature values. 311 A feature set is a set containing a number of feature collections. 312 Thus, a feature set can describe a number of different data 313 resource instances. These can correspond to different treatments 314 of a single data resource (e.g. different resolutions used for 315 printing a given document), a number of different data resources 316 subjected to a common treatment (e.g. the range of different images 317 that can be rendered on a given display), or some combination of 318 these (see examples below). 320 Thus, a description of a feature set can describe the capabilities 321 of a data resource or some entity that processes or renders a data 322 resource. 324 3.3 Media feature set descriptions 326 A feature set may be unbounded. For example, in principle, there 327 is no limit on the number of different documents that may be output 328 using a given printer. But for practical use, a feature set 329 description must be finite. 331 The general approach to describing feature sets is to start from 332 the assumption that anything is possible; i.e. the feature set 333 contains all possible document instances (feature collections). 334 Then constraints are applied that progressively remove document 335 instances from this set; e.g. for a monochrome printer, all 336 document instances that use colour are removed, or for a document 337 that must be rendered at some minimum resolution, all document 338 instances with lesser resolutions are removed from the set. The 339 mechanism used to remove document instances from the set is the 340 mathematical idea of a "relation"; i.e. a Boolean function (a 341 "predicate") that takes a feature collection parameter and returns 342 a Boolean value that is TRUE if the feature collection describes an 343 acceptable document instance, or FALSE if it describes one that is 344 excluded. 346 RFC nnnn A syntax for describing media feature sets 347 September 1998 349 P(C) 350 P(C) = TRUE <- : -> P(C) = FALSE 351 : 352 +----------:----------+ This box represents some 353 | : | set of feature collections (C) 354 | Included : Excluded | that is constrained by the 355 | : | predicate P. 356 +----------:----------+ 357 : 359 The result of applying a series of such constraints is a smaller 360 set of feature collections that represent some media handling 361 capability. Where the individual constraints are represented by 362 predicates that each describe some media handling capability, the 363 combined effect of these constraints is some subset of the 364 individual constraint capabilities that can be represented by a 365 predicate that is the logical-AND of the individual constraint 366 predicates. 368 3.4 Media feature combination scenario 370 3.4.1 Data resource options 372 The following expression uses the syntax introduced later to 373 describe a data resource that can be displayed either: 375 (a) as a 750x500 pixel image using 15 colours, or 377 (b) at 150dpi on an A4 page. 379 (| (& (pix-x=750) (pix-y=500) (color=15) ) 380 (& (dpi>=150) (papersize=iso-A4) ) ) 382 3.4.2 Recipient capabilities 384 The following expression describes a receiving system that has: 386 (a) a screen capable of displaying 640*480 pixels and 16 million 387 colours (24 bits per pixel), 800*600 pixels and 64 thousand 388 colours (16 bits per pixel) or 1024*768 pixels and 256 colours 389 (8 bits per pixel), or 391 (b) a printer capable of rendering 300dpi on A4 paper. 393 Note that this expression says noting about the colour or grey- 394 scale capabilities of the printer. In the scheme presented here, 395 it is presumed to be unconstrained in this respect (or, more 396 realistically, any such constraints are handled out-of-band by 397 anyone sending to this recipient). 399 RFC nnnn A syntax for describing media feature sets 400 September 1998 402 (| (& (| (& (pix-x<=640) (pix-y<=480) (color<=16777216) ) 403 (& (pix-x<=800) (pix-y<=600) (color<=65535) ) 404 (& (pix-x<=1024) (pix-y<=768) (color<=256) ) ) 405 (media=screen) ) 406 (& (dpi=300) 407 (media=stationery) (papersize=iso-A4) ) ) 409 3.4.3 Combined options 411 The following example describes the range of document 412 representations available when the resource described in the first 413 example above is sent to the recipient described in the second 414 example. This is the result of combining their capability feature 415 sets: 417 (| (& (pix-x=750) (pix-y=500) (color=15) ) 418 (& (dpi=300) (media=stationery) (papersize=iso-A4) ) ) 420 The feature set described by this expression is the intersection of 421 the sets described by the previous two capability expressions. 423 3.5 Feature set predicates 425 There are many ways of representing a predicate. The ideas in this 426 memo were inspired by the programming language Prolog [5], and its 427 use of predicates to describe sets of objects. 429 For the purpose of media feature description in networked 430 application protocols, the format used for LDAP search filters 431 [7,8] has been adopted, because it is a good match for the 432 requirements of capability identification, and has a very simple 433 structure that is easy to parse and process. 435 Observe that a feature collection is similar to a directory entry, 436 in that it consists of a collection of named values. Further, the 437 semantics of the mechanism for selecting feature collections from a 438 feature set is in many respects similar to selection of directory 439 entries from a directory. 441 A feature set predicate used to describe media handling 442 capabilities is implicitly applied to some feature collection. 443 Within the predicate, members of the feature collection are 444 identified by their feature tags, and are compared with known 445 feature values. (Compare with the way an LDAP search filter is 446 applied to a directory entry, whose members are identified by 447 attribute type names, and compared with known attribute values.) 449 RFC nnnn A syntax for describing media feature sets 450 September 1998 452 Differences between directory selection (per [7]) and feature set 453 selection are: 455 . Directory selection provides substring-, approximate- and 456 extensible- matching for attribute values. Directory selection 457 may also be based on the presence of an attribute without regard 458 to its value. 460 . Directory selection provides for matching rules that test for the 461 presence or absence of a named attribute type. 463 . Directory selection provides for matching rules which are 464 dependent upon the declared data type of an attribute value. 466 . Feature selection provides for the association of a quality value 467 with a feature predicate as a way of ranking the selected value 468 collections. 470 The idea of substring matching does not seem to be relevant to 471 feature set selection, and is excluded from these proposals. 473 Testing for the presence of a feature may be useful in some 474 circumstances, but does not sit comfortably within the semantic 475 framework. Feature sets are described by implied universal 476 quantification over predicates, and the absence of reference to a 477 given feature means the set is not constrained by that feature. 478 Against this, it is difficult to define what might be meant by 479 "presence" of a feature, so the "test for presence" option is not 480 included in these proposals. An effect similar to testing for the 481 presence of a feature can be achieved by a Boolean-valued feature. 483 The idea of extensible matching and matching rules dependent upon 484 data types are facets of a problem not addressed by this memo, but 485 which do not necessarily affect the feature selection syntax. An 486 aspect which might have a bearing on the syntax would be a 487 requirement to specify a matching rule explicitly as part of a 488 selection expression. 490 4. Feature set representation 492 The foregoing sections have described a framework for defining 493 feature sets with predicates applied to feature collections. This 494 section presents a concrete representation for feature set 495 predicates. 497 RFC nnnn A syntax for describing media feature sets 498 September 1998 500 4.1 Textual representation of predicates 502 The text representation of a feature set is based on RFC 2254 "The 503 String Representation of LDAP Search Filters" [8], excluding those 504 elements not relevant to feature set selection (discussed above), 505 and adding elements specific to feature set selection (e.g. options 506 to associate quality values with predicates). 508 The format of a feature predicate is defined by the production for 509 "filter" in the following, using the syntax notation and core rules 510 of [10]: 512 filter = "(" filtercomp *( ";" parameter ) )" 513 parameter = "q" "=" qvalue 514 / ext-param "=" ext-value 515 qvalue = ( "0" [ "." 0*3DIGIT ] ) 516 / ( "1" [ "." 0*3("0") ] ) 517 ext-param = ALPHA *( ALPHA / DIGIT / "-" ) 518 ext-value = 519 filtercomp = and / or / not / item 520 and = "&" filterlist 521 or = "|" filterlist 522 not = "!" filter 523 filterlist = 1*filter 524 item = simple / set / ext-pred 525 set = attr "=" "[" setentry *( "," setentry ) "]" 526 setentry = value "/" range 527 range = value ".." value 528 simple = attr filtertype value 529 filtertype = equal / greater / less 530 equal = "=" 531 greater = ">=" 532 less = "<=" 533 attr = ftag 534 value = fvalue 535 ftag = 536 fvalue = number / token / string 537 number = integer / rational 538 integer = 1*DIGIT 539 rational = 1*DIGIT "." 1*DIGIT 540 token = ALPHA *( ALPHA / DIGIT / "-" ) 541 string = DQUOTE *(%x20-21 / %x23-7E) DQUOTE 542 ; quoted string of SP and VCHAR without DQUOTE 543 ext-pred = 545 (Subject to constraints imposed by the protocol that carries a 546 feature predicate, whitespace characters may appear between any 547 pair of syntax elements or literals that appear on the right hand 548 side of these productions.) 550 RFC nnnn A syntax for describing media feature sets 551 September 1998 553 As described, the syntax permits parameters (including quality 554 values) to be attached to any "filter" value in the predicate (not 555 just top-level values). Only top-level quality values are 556 recognized. If no explicit quality value is given, a value of 557 '1.0' is applied. 559 NOTE 561 The flexible approach to quality values and other 562 parameter values in this syntax has been adopted for two 563 reasons: (a) to make it easy to combine separately 564 constructed feature predicates, and (b) to provide an 565 extensible tagging mechanism for possible future use (for 566 example, to incorporate a conceivable requirement to 567 explicitly specify a matching rule). 569 4.2 Named and auxiliary predicates 571 Named and auxiliary predicates can serve two purposes: 573 (a) making complex predicates easier to write and understand, and 575 (b) providing a possible basis for naming and registering feature 576 sets. 578 [[[TODO: Decide how to treat named predicates. Support 579 for named predicates in the capability syntax has not 580 (currently) been made a requirement. However, its 581 inclusion as an option may be useful for publication 582 purposes, even if not used in actual protocol 583 elements.]]] 585 4.2.1 Defining a named predicate 587 A named predicate definition has the following form: 589 named-pred = "(" fname *pname ")" ":-" filter 590 fname = ftag ; Feature predicate name 591 pname = token ; Formal parameter name 593 'fname' is the name of the predicate. 595 'pname' is the name of a formal parameter which may appear in the 596 predicate body, and which is replaced by some supplied value when 597 the predicate is invoked. 599 RFC nnnn A syntax for describing media feature sets 600 September 1998 602 'filter' is the predicate body. It may contain references to the 603 formal parameters, and may also contain references to feature tags 604 and other values defined in the environment in which the predicate 605 is invoked. References to formal parameters may appear anywhere 606 where a reference to a feature tag ('ftag') is permitted by the 607 syntax for 'filter'. 609 The only specific mechanism defined by this memo for introducing a 610 named predicate into a feature set definition is the "auxiliary 611 predicate" described later. Specific negotiating protocols or 612 other memos may define other mechanisms. 614 NOTE 616 There has been some suggestion of creating a registry for 617 feature sets as well as individual feature values. Such 618 a registry might be used to introduce named predicates 619 corresponding to these feature sets into the environment 620 of a capability assertion. Further discussion of this 621 idea is beyond the scope of this memo. 623 4.2.2 Invoking named predicates 625 Assuming a named predicate has been introduced into the environment 626 of some other predicate, it can be invoked by a filter 'ext-pred' 627 of the form: 629 ext-pred = fname *param 630 param = expr 632 The number of parameters must match the definition of the named 633 predicate that is invoked. 635 4.2.3 Auxiliary predicates in a filter 637 A auxiliary predicate is attached to a filter definition by the 638 following extension to the "filter" syntax: 640 filter =/ "(" filtercomp *( ";" parameter ) ")" 641 "where" 1*( named-pred ) "end" 643 The named predicates introduced by "named-pred" are visible from 644 the body of the "filtercomp" of the filter to which they are 645 attached, but are not visible from each other. They all have 646 access to the same environment as "filter", plus their own formal 647 parameters. (Normal scoping rules apply: a formal parameter with 648 the same name as a value in the environment of "filter" effectively 649 hides the environment value from the body of the predicate to which 650 it applies.) 652 RFC nnnn A syntax for describing media feature sets 653 September 1998 655 NOTE 657 Recursive predicates are not permitted. The scoping 658 rules should ensure this. 660 4.3 Feature set definition examples 662 The following sub-sections give examples of feature predicates that 663 describes a number of image size and resolution combinations. 665 4.3.1 Single predicate 667 (| (& (Pix-x=1024) 668 (Pix-y=768) 669 (| (& (Res-x=150) (Res-y=150) ) 670 (& (Res-x=150) (Res-y=300) ) 671 (& (Res-x=300) (Res-y=300) ) 672 (& (Res-x=300) (Res-y=600) ) 673 (& (Res-x=600) (Res-y=600) ) ) 674 (& (Pix-x=800) 675 (Pix-y=600) 676 (| (& (Res-x=150) (Res-y=150) ) 677 (& (Res-x=150) (Res-y=300) ) 678 (& (Res-x=300) (Res-y=300) ) 679 (& (Res-x=300) (Res-y=600) ) 680 (& (Res-x=600) (Res-y=600) ) ) ;q=0.9 681 (& (Pix-x=640) 682 (Pix-y=480) 683 (| (& (Res-x=150) (Res-y=150) ) 684 (& (Res-x=150) (Res-y=300) ) 685 (& (Res-x=300) (Res-y=300) ) 686 (& (Res-x=300) (Res-y=600) ) 687 (& (Res-x=600) (Res-y=600) ) ) ;q=0.8 689 4.3.2 Predicate with auxiliary predicate 691 (| (& (Pix-x=1024) (Pix-y=768) (Res Res-x Res-y) ) 692 (& (Pix-x=800) (Pix-y=600) (Res Res-x Res-y) );q=0.9 693 (& (Pix-x=640) (Pix-y=480) (Res Res-x Res-y) );q=0.8 ) 694 where 695 (Res Res-x Res-y) :- 696 (| (& (Res-x=150) (Res-y=150) ) 697 (& (Res-x=150) (Res-y=300) ) 698 (& (Res-x=300) (Res-y=300) ) 699 (& (Res-x=300) (Res-y=600) ) 700 (& (Res-x=600) (Res-y=600) ) ) 701 end 703 RFC nnnn A syntax for describing media feature sets 704 September 1998 706 Note that the formal parameters of "Res", "Res-x" and "Res-y", 707 prevent the body of the named predicate from referencing similarly- 708 named feature values. 710 5. Processing feature set descriptions 712 This section addresses some issues that may arise when using 713 feature set predicates as part of some content negotiation or file 714 selection protocol. 716 5.1 Matching feature sets 718 Matching a feature set to some given feature collection is 719 esentially very straightforward: the feature set predicate is 720 simply evaluated for the given feature collection, and the result 721 (TRUE or FALSE) indicates whether the feature collection matches 722 the capabilities, and the associated quality value can be used for 723 selecting among alternative feature collections. 725 Matching a feature set to some other feature set is less 726 straightforward. Here, the problem is to determine whether or not 727 there is at least one feature collection that matches both feature 728 sets (e.g. is there an overlap between the feature capabilities of 729 a given file format and the feature capabilities of a given 730 recipient?) 732 This feature set matching is accomplished by logical manipulation 733 of the predicate expressions as described in the following 734 sections. 736 For this procedure to work reliably, the predicates must be reduced 737 to a canonical form. One such form is "clausal form", and 738 procedures for converting general expressions in predicate calculus 739 are given in [5] (section 10.2), [11] (section 2.13), [12] (chapter 740 4) and [13] (section 5.3.2). 742 "Clausal form" for a predicate is similar to "conjunctive normal 743 form" for a proposition, which consists of a conjunction (logical 744 ANDs) of disjunctions (logical ORs). A related form that is better 745 suited to feature set matching is "disjunctive normal form", which 746 consists of a logical disjunction (OR) of conjunctions (ANDs). In 747 this form, it is sufficient to show that at least one of the 748 disjunctions can be satisfied by some feature collection. 750 RFC nnnn A syntax for describing media feature sets 751 September 1998 753 A syntax for disjunctive normal form is: 755 filter = orlist 756 orlist = "(" "|" andlist ")" / term 757 andlist = "(" "&" termlist ")" / term 758 termlist = 1*term 759 term = "(" "!" simple ")" / simple 761 where "simple" is as described previously in section 6.1. Thus, 762 the canonicalized form has at most three levels: an outermost 763 "(|...)" disjunction of "(&...)" conjunctions of possibly negated 764 feature value tests. 766 NOTE (a theoretical diversion): 768 Is this consideration of "clausal form" really required? 769 After all, the feature predicates are just Boolean 770 expressions, aren't they? 772 Well, no. A feature predicate is a Boolean expression 773 containing primitive feature value tests (comparisons), 774 represented by 'item' in the feature predicate syntax. 775 If these tests could all be assumed to be independently 776 TRUE or FALSE, then each could be regarded as an atomic 777 proposition, and the whole predicate could be dealt with 778 according to the (relatively simple) rules of 779 Propositional Calculus. 781 But, in general, the same feature tag may appear in more 782 than one predicate 'item', so the tests cannot be 783 regarded as independent. Indeed, interdependence is 784 needed in any meaningful application of feature set 785 matching, and it is important to capture these 786 dependencies (e.g. does the set of resolutions that a 787 sender can supply overlap the set of resolutions that a 788 recipient can handle?). Thus, we have to deal with 789 elements of the Predicate Calculus, with its additional 790 rules for algebraic manipulation. 792 This section aims to show that these additional rules are 793 more unfamiliar than complicated. In practice, the way 794 that feature predicates are constructed and used actually 795 avoids some of the complexity of dealing with fully- 796 generalized Predicate Calculus. 798 RFC nnnn A syntax for describing media feature sets 799 September 1998 801 5.1.1 Feature set matching strategy 803 The overall strategy for matching feature sets, expanded in the 804 following sections, is: 806 1. Formulate the feature set match hypothesis. 808 2. Replace "set" expressions with equivalent comparisons. 810 3. Eliminate logical negations, and express all feature comparisons 811 in terms of just four comparison operators 813 4. Reduce the hypothesis to canonical disjunctive normal form (a 814 disjunction of conjunctions). 816 5. For each of the conjunctions, attempt to show that it can be 817 satisfied by some feature collection. Any that cannot be 818 satisfied are discarded. 820 5.1 Separate the feature value tests into independent groups, 821 such that each group contains tests involving just one 822 feature value. That is: no group contains a predicate 823 involving any feature tag that also appears in a predicate 824 in some other group. 826 5.2 For each group, merge the various constraints to a minimum 827 form. This process either yields a reduced expression for 828 the allowable range of feature values, or an indication that 829 no value can satisfy the constraints (in which case the 830 corresponding conjucntion can never be satisfied). 832 6. If the remaining disjunction is non-empty, then the constraints 833 are shown to be satisfiable. Further, it can be used as a 834 statement of the resulting feature set for possible further 835 matching operations. 837 5.1.2 Formulating the goal predicate 839 A formal statement of the problem we need to solve can be given as: 840 given two feature set predicates, '(P x)' and '(Q x)', where 'x' is 841 some feature collection, we wish to establish the truth or 842 otherwise of the proposition: 844 EXISTS(x) : (P x) AND (Q x) 846 i.e. does there exist a feature collection 'x' that satisfies both 847 predicates, 'P' and 'Q'? 849 RFC nnnn A syntax for describing media feature sets 850 September 1998 852 Then, if feature sets to be matched are described by predicates 'P' 853 and 'Q', the problem is to determine if there is any feature set 854 satisfying the goal predicate: 856 (& P Q) 858 i.e. to determine whether the set thus described is non-empty. 860 5.1.3 Replace set expressions 862 Replace all "set" instances in the goal predicate with equivalent 863 "simple" forms: 865 T = [ E1, E2, ... En ] --> (| (T=[E1]) (T=[E2]) ... (T=[En]) ) 866 (T=[R1..R2]) --> (& (T>=R1) (T<=R2) ) 867 (T=[E]) --> (T=E) 869 5.1.4 Replace comparisons and logical negations 871 The predicates are derived from the syntax described previously, 872 and contain primitive value testing functions '=', '<=', '>='. The 873 primitive tests have a number of well known properties that are 874 exploited to reach a useful conclusion; e.g. 876 (A = B) & (B = C) => (A = C) 877 (A <= B) & (B <= C) => (A <= C) 879 These rules form a core body of logic statements against which the 880 goal predicate can be evaluated. The form in which these 881 statements are expressed is important to realizing an effective 882 predicate matching algorithm (i.e. one that doesn't loop or fail to 883 find a valid result). The first step in formulating these rules is 884 to simplify the framework of primitive predicates. 886 The primitive predicates from which feature set definitions are 887 constructed are '=', '<=' and '>='. Observe that, given any pair 888 of feature values, the relationship between them must be exactly 889 one of the following: 891 (LT a b): 'a' is less than 'b'. 892 (EQ a b): 'a' is equal to 'b'. 893 (GT a b): 'a' is greater than 'b'. 894 (NE a b): 'a' is not equal and not related to 'b'. 896 (The final case arises when two values are compared for which no 897 ordering relationship is defined, and the values are not equal; 898 e.g. two unequal string values.) 900 RFC nnnn A syntax for describing media feature sets 901 September 1998 903 These four cases can be captured by a pair of primitive predicates: 905 (LE a b): 'a' is less than or equal to 'b'. 906 (GE a b): 'a' is greater than or equal to 'b'. 908 The four cases described above are prepresented by the following 909 combinations of primitive predicate values: 911 (LE a b) (GE a b) | relationship 912 ---------------------------------- 913 TRUE FALSE | (LT a b) 914 TRUE TRUE | (EQ a b) 915 FALSE TRUE | (GT a b) 916 FALSE FALSE | (NE a b) 918 Thus, the original 3 primitive tests can be translated to 919 combinations of just LE and GE, reducing the number of additional 920 relationships that must be subsequently captured: 922 (a <= b) --> (LE a b) 923 (a >= b) --> (GE a b) 924 (a = b) --> (& (LE a b) (GE a b) ) 926 Further, logical negations of the original 3 primitive tests can be 927 eliminated by the introduction of 'not-greater' and 'not-less' 928 primitives 930 (NG a b) == (! (GE a b) ) 931 (NL a b) == (! (LE a b) ) 933 using the following transformation rules: 935 (! (a = b) ) --> (| (NL a b) (NG a b) ) 936 (! (a <= b) ) --> (NL a b) 937 (! (a >= b) ) --> (NG a b) 939 Thus, we have rules to transform all comparisons and logical 940 negations into combinations of just 4 relational operators. 942 RFC nnnn A syntax for describing media feature sets 943 September 1998 945 5.1.5 Conversion to canonical form 947 Expand bracketed disjunctions, and flatten bracketed conjunctions 948 and disjunctions: 950 (& (| A1 A2 ... Am ) B1 B2 ... Bn ) 951 --> (| (& A1 B1 B2 ... Bn ) 952 (& A2 B1 B2 ... Bn ) 953 : 954 (& Am B1 B2 ... Bn ) ) 955 (& (& A1 A2 ... Am ) B1 B2 ... Bn ) 956 --> (& A1 A2 ... Am B1 B2 ... Bn ) 957 (| (| A1 A2 ... Am ) B1 B2 ... Bn ) 958 --> (| A1 A2 ... Am B1 B2 ... Bn ) 960 The result is a "disjunctive normal form", a disjunction of 961 conjunctions: 963 (| (& S11 S12 ... ) 964 (& S21 S22 ... ) 965 : 966 (& Sm1 Sm2 ... Smn ) ) 968 where the "Sij" elements are simple feature comparison forms 969 constructed during the step at section 7.1.4. Each term within the 970 top-level "(|...)" construct represents a single possible feature 971 set that satisfies the goal. Note that the order of entries within 972 the top-level '(|...)', and within each '(&...)', is immaterial. 974 From here on, each conjunction '(&...)' is processed separately. 975 Only one of these needs to be satisfiable for the original goal to 976 be satisfiable. 978 (A textbook conversion to clausal form [5,11] uses slightly 979 different rules to yield a "conjunctive normal form".) 981 5.1.6 Grouping of feature predicates 983 NOTE: remember that from here on, each conjunction is 984 treated separately. 986 Each simple feature predicate contains a "left-hand" feature tag 987 and a "right-hand" feature value with which it is compared. 989 To arrange these into independent groups, simple predicates are 990 grouped according to their left hand feature tag ('f'). 992 RFC nnnn A syntax for describing media feature sets 993 September 1998 995 5.1.7 Merge single-feature constraints 997 Within each group, apply the predicate simplification rules given 998 below to eliminate redundant single-feature constraints. All 999 single-feature predicates are reduced to an equality or range 1000 constraint on that feature, possibly combined with a number of non- 1001 equality statements. 1003 If the constraints on any feature are found to be contradictory 1004 (i.e. resolved to FALSE according to the applied rules), the 1005 current conjunction is removed from the feature set description. 1006 Otherwise, the resulting description is a minimal form of the 1007 particular conjunction of the feature set definition. 1009 5.1.7.1 Rules for simplifying ordered values 1011 These rules are applicable where there is an ordering relationship 1012 between the given values 'a' and 'b': 1014 (LE f a) (LE f b) --> (LE f a), a<=b 1015 (LE f b), otherwise 1016 (LE f a) (GE f b) --> FALSE, a FALSE, a<=b 1018 (LE f a) (NG f b) --> (LE f a), a (GE f a), a>=b 1022 (GE f b), otherwise 1023 (GE f a) (NL f b) --> (GE f a) a>b 1024 (NL f b), otherwise 1025 (GE f a) (NG f b) --> FALSE, a>=b 1027 (NL f a) (NL f b) --> (NL f a), a>=b 1028 (NL f b), otherwise 1029 (NL f a) (NG f b) --> FALSE, a>=b 1031 (NG f a) (NG f b) --> (NG f a), a<=b 1032 (NG f b), otherwise 1034 RFC nnnn A syntax for describing media feature sets 1035 September 1998 1037 5.1.7.2 Rules for simplifying unordered values 1039 These rules are applicable where there is no ordering relationship 1040 applicable to the given values 'a' and 'b': 1042 (LE f a) (LE f b) --> (LE f a), a=b 1043 FALSE, otherwise 1044 (LE f a) (GE f b) --> FALSE, a!=b 1045 (LE f a) (NL f b) --> (LE f a) a!=b 1046 FALSE, otherwise 1047 (LE f a) (NG f b) --> (LE f a), a!=b 1048 FALSE, otherwise 1050 (GE f a) (GE f b) --> (GE f a), a=b 1051 FALSE, otherwise 1052 (GE f a) (NL f b) --> (GE f a) a!=b 1053 FALSE, otherwise 1054 (GE f a) (NG f b) --> (GE f a) a!=b 1055 FALSE, otherwise 1057 (NL f a) (NL f b) --> (NL f a), a=b 1058 (NL f a) (NG f b) --> (NL f a), a=b 1060 (NG f a) (NG f b) --> (NG f a), a=b 1062 [[[TODO: model the above system to confirm that it is complete and 1063 does indeed work properly in all cases.]]] 1065 5.2 Effect of named predicates 1067 The preceding procedures can be extended to deal with named 1068 predicates simply by instantiating (i.e. substituting) the 1069 predicates wherever they are invoked, before performing the 1070 conversion to disjunctive normal form. In the absence of recursive 1071 predicates, this procedure is guaranteed to terminate. 1073 When substituting the body of a precdicate at its point of 1074 invocation, instances of formal parameters within the predicate 1075 body must be replaced by the corresponding actual parameter from 1076 the point of invocation. 1078 5.3 Unit designations 1080 In some exceptional cases, there may be differing conventions for 1081 the units of measurement of a given feature. For example, 1082 resolution is commonly expressed as dots per inch (dpi) or dots per 1083 centimetre (dpcm) in different applications (e.g. printing vs 1084 faxing). 1086 RFC nnnn A syntax for describing media feature sets 1087 September 1998 1089 In such cases, a unit designator may be appended to a feature value 1090 according to the conventions indicated below (see also [3]). These 1091 considerations apply only to features with numeric values. 1093 Every feature tag has a standard unit of measurement. Any 1094 expression of a feature value that uses this unit is given without 1095 a unit designation -- this is the normal case. When the feature 1096 value is expressed in some other unit, a unit designator is 1097 appended to the numeric feature value. 1099 The registration of a feature tag indicates the standard unit of 1100 measurement for a feature, and also any alternate units and 1101 corresponding unit designators that may be used, according to [3]. 1103 Thus, if the standard unit of measure for resolution is 'dpcm', 1104 then the feature predicate '(res=200)' would be used to indicate a 1105 resolution of 200 dots-per-centimetre, and '(res=72dpi)' might be 1106 used to indicate 72 dots-per-inch. 1108 Unit designators are accommodated by the following extension to the 1109 feature predicate syntax: 1111 fvalue /= number *WSP token 1113 When performing feature set matching, feature comparisons with and 1114 without unit designators, or feature comparisons with different 1115 unit designators, are treated as if they were different features. 1116 Thus, the feature predicate '(res=200)' would not, in general, fail 1117 to match with the predicate '(res=200dpi)'. 1119 NOTE: 1121 A protocol processor with specific knowledge of the 1122 feature and units concerned might recognize the 1123 relationship between the feature predicates in the above 1124 example, and fail to match these predicates. 1126 This appears to be a natural behaviour in this simple 1127 example, but can cause additional complexity in more 1128 general cases. Accordingly, this is not considered to be 1129 required or normal behaviour. It is presumed that in 1130 general, the application concerned will ensure consistent 1131 feature processing by adopting a consistent unit for any 1132 given feature. 1134 RFC nnnn A syntax for describing media feature sets 1135 September 1998 1137 5.4 Unknown feature value data types 1139 [[Discuss issues of specific features which may have feature- 1140 specific comparison rules, as opposed to generic Booleans, 1141 enumerations, strings and numbers which use comparison rules 1142 independent of the feature concerned.]] 1144 [[[TODO]]] 1146 5.5 Worked example 1148 [[[TODO]]] 1150 5.6 Algorithm source code 1152 [[[TODO]]] 1154 6. Security considerations 1156 Some security considerations for content negotiation are raised in 1157 [1,2,3]. 1159 The following are primary security concerns for capability 1160 identification mechanisms: 1162 . Unintentional disclosure of private information through the 1163 announcement of capabilities or user preferences. 1165 . Disruption to system operation caused by accidental or malicious 1166 provision of incorrect capability information. 1168 . Use of a capability identification mechanism might be used to 1169 probe a network (e.g. by identifying specific hosts used, and 1170 exploiting their known weaknesses). 1172 RFC nnnn A syntax for describing media feature sets 1173 September 1998 1175 The most contentious security concerns are raised by mechanisms 1176 which automatically send capability identification data in response 1177 to a query from some unknown system. Use of directory services 1178 (based on LDAP [7], etc.) seem to be less problematic because 1179 proper authentication mechanisms are available. 1181 Mechanisms which provide capability information when sending a 1182 message are less contentious, presumably because some intention can 1183 be inferred that person whose details are disclosed wishes to 1184 communicate with the recipient of those details. This does not, 1185 however, solve problems of spoofed supply of incorrect capability 1186 information. 1188 The use of format converting gateways may prove problematic because 1189 such systems would tend to defeat any message integrity and 1190 authenticity checking mechanisms that are employed. 1192 7. Copyright 1194 Copyright (C) The Internet Society 1998. All Rights Reserved. 1196 This document and translations of it may be copied and furnished to 1197 others, and derivative works that comment on or otherwise explain 1198 it or assist in its implementation may be prepared, copied, 1199 published and distributed, in whole or in part, without restriction 1200 of any kind, provided that the above copyright notice and this 1201 paragraph are included on all such copies and derivative works. 1202 However, this document itself may not be modified in any way, such 1203 as by removing the copyright notice or references to the Internet 1204 Society or other Internet organizations, except as needed for the 1205 purpose of developing Internet standards in which case the 1206 procedures for copyrights defined in the Internet Standards process 1207 must be followed, or as required to translate it into languages 1208 other than English. 1210 The limited permissions granted above are perpetual and will not be 1211 revoked by the Internet Society or its successors or assigns. 1213 This document and the information contained herein is provided on 1214 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1215 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1216 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1217 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1218 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1220 RFC nnnn A syntax for describing media feature sets 1221 September 1998 1223 8. Acknowledgements 1225 My thanks to Larry Masinter for demonstrating to me the breadth of 1226 the media feature issue, and encouraging me to air my early ideas. 1228 Early discussions of ideas on the IETF-HTTP and IETF-FAX discussion 1229 lists led to useful inputs also from Koen Holtman, Ted Hardie and 1230 Dan Wing. 1232 The debate later moved to the IETF conneg WG mailing list, where Al 1233 Gilman was particularly helpful in helping me to refine the feature 1234 set algebra. Ideas for dealing with preferences and specific units 1235 were suggested by Larry Masinter. 1237 This work was supported by Content Technologies Ltd and 5th 1238 Generation Messaging Ltd. 1240 9. References 1242 [1] "Scenarios for the Delivery of Negotiated Content" 1243 T. Hardie, NASA Network Information Center 1244 Internet draft: 1245 Work in progress, November 1997. 1247 [2] "Requirements for protocol-independent content negotiation" 1248 G. Klyne, Integralis Ltd. 1249 Internet draft: 1250 Work in progress, March 1998. 1252 [3] "Media Feature Tag Registration Procedure" 1253 Koen Holtman, TUE 1254 Andrew Mutz, Hewlett-Packard 1255 Ted Hardie, NASA 1256 Internet draft: 1257 Work in progress, July 1998. 1259 [4] "Notes on data structuring" 1260 C. A. R. Hoare, 1261 in "Structured Programming" 1262 Academic Press, APIC Studies in Data Processing No. 8 1263 ISBN 0-12-200550-3 / 0-12-200556-2 1264 1972. 1266 [5] "Programming in Prolog" (2nd edition) 1267 W. F. Clocksin and C. S. Mellish, 1268 Springer Verlag 1269 ISBN 3-540-15011-0 / 0-387-15011-0 1270 1984. 1272 RFC nnnn A syntax for describing media feature sets 1273 September 1998 1275 [6] "Media Features for Display, Print, and Fax" 1276 Larry Masinter, Xerox PARC 1277 Koen Holtman, TUE 1278 Andrew Mutz, Hewlett-Packard 1279 Dan Wing, Cisco Systems 1280 Internet draft: 1281 Work in progress, January 1998. 1283 [7] RFC 2251, "Lightweight Directory Access Protocol (v3)" 1284 M. Wahl, Critical Angle Inc. 1285 T. Howes, Netscape Communications Corp. 1286 S. Kille, Isode Limited 1287 December 1997. 1289 [8] RFC 2254, "The String Representation of LDAP Search Filters" 1290 T. Howes, Netscape Communications Corp. 1291 December 1997. 1293 [9] RFC 2068, "Hyptertext Transfer Protocol -- HTTP/1.1" 1294 R. Fielding, UC Irvine 1295 J. Gettys, 1296 J. Mogul, DEC 1297 H. Frytyk, 1298 T. Berners-Lee, MIT/LCS 1299 January 1997. 1301 [10] RFC 2234, "Augmented BNF for Syntax Specifications: ABNF" 1302 D. Crocker (editor), Internet Mail Consortium 1303 P. Overell, Demon Internet Ltd. 1304 November 1997. 1306 [11] "Logic, Algebra and Databases" 1307 Peter Gray 1308 Ellis Horwood Series: Computers and their Applications 1309 ISBN 0-85312-709-3/0-85312-803-3 (Ellis Horwood Ltd) 1310 ISBN 0-470-20103-7/0-470-20259-9 (Halstead Press) 1311 1984. 1313 [12] "Elementary Logics: A procedural Perspective 1314 Dov Gabbay 1315 Prentice Hall, Series in computer science 1316 ISBN 0-13-726365-1 1317 1998. 1319 [13] "Logic and its Applications" 1320 Edmund Burk and Eric Foxley 1321 Prentice Hall, Series in computer science 1322 ISBN 0-13-030263-5 1323 1996. 1325 RFC nnnn A syntax for describing media feature sets 1326 September 1998 1328 10. Author's address 1330 Graham Klyne 1331 Content Technologies Ltd. 5th Generation Messaging Ltd. 1332 Forum 1 5 Watlington Street 1333 Station Road Nettlebed 1334 Theale Henley-on-Thames 1335 Reading, RG7 4RA RG9 5AB 1336 United Kingdom United Kingdom. 1338 Telephone: +44 118 930 1300 +44 1491 641 641 1340 Facsimile: +44 118 930 1301 +44 1491 641 611 1342 E-mail: GK@ACM.ORG