idnits 2.17.1 draft-ietf-conneg-feature-hash-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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? 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], [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 == 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 (8 April 1999) is 9142 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) ** Obsolete normative reference: RFC 2234 (ref. '3') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2396 (ref. '5') (Obsoleted by RFC 3986) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF conneg working group Graham Klyne, editor 2 Internet draft 5GM/Content Technologies 3 Category: Work-in-progress Larry Masinter 4 Xerox Corporation 5 8 April 1999 6 Expires: October 1999 8 Identifying composite media features 9 11 Status of this memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC 2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society 1999. All Rights Reserved. 37 Abstract 39 In "A syntax for describing media feature sets" [1], an expression 40 format is presented for describing media feature capabilities as a 41 combination of simple media feature tags [2]. 43 This document proposes an abbreviated format for a composite media 44 feature set, based upon a hash of the feature expression describing 45 that composite or the URI of a resource containing the feature 46 expression. 48 Internet Draft Identifying composite media features 50 Table of contents 52 1. Introduction ............................................2 53 1.1 Organization of this document 2 54 1.2 Terminology and document conventions 3 55 1.3 Discussion of this document 3 56 2. Motivation and goals ....................................4 57 3. Composite feature representation ........................5 58 3.1 Feature set hashed reference format 5 59 3.1.1 Hash value calculation 6 60 3.2 Feature set URI reference format 7 61 3.3 Resolving feature set references 7 62 3.3.1 URI reference 8 63 3.3.2 Inline feature set details 9 64 3.4 The birthday problem 9 65 4. Examples ................................................11 66 5. Internationalization considerations .....................11 67 6. Security considerations .................................11 68 7. Full copyright statement ................................12 69 8. Acknowledgements ........................................12 70 9. References ..............................................12 71 10. Authors' addresses .....................................14 72 Appendix A: Revision history ...............................14 74 1. Introduction 76 In "A syntax for describing media feature sets" [1], an expression 77 format is presented for describing media feature capabilities as a 78 combination of simple media feature tags [2]. 80 This document proposes an abbreviated format for a composite media 81 feature set, based upon a hash of the feature expression describing 82 that composite. 84 1.1 Organization of this document 86 Section 2 sets out somne of the background and goals for feature 87 set references. 89 Section 3 preents a syntax for feature set references, and 90 describes how they are related to feature set expressions. 92 Section 4 discusses how feature set references are used in conction 93 with feature set matching. 95 Internet Draft Identifying composite media features 97 1.2 Terminology and document conventions 99 This section defines a number of terms and other document 100 conventions, which are used with specific meaning in this memo. 101 The terms are listed in alphabetical order. 103 dereference 104 the act of replacing a feature set reference with its 105 corresponding feature set expression. Also called 106 "resolution". 108 feature set 109 some set of media features described by a media feature 110 assertion, as described in "A syntax for describing media 111 feature sets" [1]. (See that memo for a more formal 112 definition of this term.) 114 feature set expression 115 a string that describes some feature set, formulated 116 according to the rules in "A syntax for describing media 117 feature sets" [1] (and possibly extended by other 118 specifications). 120 feature set reference 121 a brief construct that references some feature set. 122 (See also: "dereference".) 124 feature set tag 125 a name that conforms to the syntax of a feature tag [1] 126 that is used to denote a feature set rather than a single 127 feature. 129 resolution 130 (See "dereference"). 132 This specification uses syntax notation and conventions described 133 in RFC2234 "Augmented BNF for Syntax Specifications: ABNF" [3]. 135 NOTE: Comments like this provide additional nonessential 136 information about the rationale behind this document. 137 Such information is not needed for building a conformant 138 implementation, but may help those who wish to understand 139 the design in greater depth. 141 1.3 Discussion of this document 143 Discussion of this document should take place on the content 144 negotiation and media feature registration mailing list hosted by 145 the Internet Mail Consortium (IMC). 147 Internet Draft Identifying composite media features 148 Please send comments regarding this document to: 150 ietf-medfree@imc.org 152 To subscribe to this list, send a message with the body 'subscribe' 153 to "ietf-medfree-request@imc.org". 155 To see what has gone on before you subscribed, please see the 156 mailing list archive at: 158 http://www.imc.org/ietf-medfree/ 160 2. Motivation and goals 162 The range of media feature capabilities of a message handling 163 system can be quite extensive, and the corresponding feature set 164 expression [1] can reach a significant size. 166 A requirement has been identified to allow recurring feature sets 167 to be identified by a single reference value, which can be combined 168 with other elements in a feature set expression. It is anticipated 169 that mechanisms will be provided that allow the recipient of such a 170 feature set reference to discover the corresponding feature set 171 expression. 173 Thus, the goals for this proposal are: 175 o to provide an abbreviated form for referencing an arbitrary 176 feature set expression. 178 o the meaning of (i.e. the corresponding feature set expression) a 179 feature set reference should be independent of any particular 180 mechanism that may be used to dereference it. 182 o to be able to verify whether a given feature set expression 183 corresponds to some feature set reference without having to 184 perform an explicit dereferencing operation (i.e. without 185 incurring additional network traffic). 187 o for protocol processors that conform to [1] to be able to 188 sensibly handle a feature set reference without explicit 189 knowledge of its meaning (i.e. the introduction of feature set 190 references should not break existing feature expression 191 processors). 193 o to allow, but not require, some indication of how to dereference 194 a feature set reference to be included in a feature set 195 expression. 197 Internet Draft Identifying composite media features 198 NOTE: This proposal does not attempt to address the 199 "override" or "default" problem. (Also called 200 "delegation", where a feature set may be referenced and 201 selectively modified.) 203 3. Composite feature representation 205 This specification hinges on three central ideas: 207 o the use of auxiliary predicates (introduced in [1]) to form the 208 basis of a feature set reference, and 210 o the use of a token based on a hash function computed over the 211 referenced feature set expression. 213 o the use of an expression containing a URI to indicate a mechanism 214 and service for resolution of a feature set tag. 216 A key reason to use a hash function to generate an identifier is to 217 define a global name space without requiring a central naming 218 authority. New feature set tags can be introduced by any party 219 following the appropriate rules of formulation, without reference 220 to any centralized authority. 222 Local resolution services may be needed to map feature set tags to 223 their corresponding feature set expressions, but these are not able 224 to vary the meaning of any given tag. Failure of a resolution 225 service to return the correct expression is detectable by a calling 226 application, which should reject any incorrect value supplied. 228 This memo also suggests that an expression containing a URI in the 229 format '' may be used to suggest a mechanism and location of a 230 service to perform feature set resolution. 232 3.1 Feature set hashed reference format 234 This specification introduces a special form of auxililiary 235 predicate name with the following syntax: 237 fname = "h." 1*HEXDIG 239 The sequence of hexadecimal digits is the value of a hash function 240 calculated over the corresponding feature set expression (see next 241 section), represented as a hexadecimal number. 243 Internet Draft Identifying composite media features 244 Thus, within a feature set expression, a feature set reference 245 would have the following form: 247 (h.123456789abcdef0123456789abcdef0) 249 NOTE: Base64 representation (per MIME [4]) would be more 250 compact (21 rather than 32 characters for the MD5 128-bit 251 hash value), but an auxiliary predicate name is defined 252 (by [1]) to have the same syntax as a feature tag, and 253 the feature tag matching rules (per [2]) state that 254 feature tag matching is case insensitive. 256 3.1.1 Hash value calculation 258 The hash value is calculated using the MD5 algorithm [6] over the 259 text of the referenced feature set expression subjected to certain 260 normalizations. The feature expression must conform to the syntax 261 given in "A syntax for describing media feature sets" [1] for 262 'filter': 264 filter = "(" filtercomp ")" *( ";" parameter ) 266 The steps for calculating a hash value are: 268 1. Whitespace normalization: all spaces, CR, LF, TAB and any other 269 layout control characters that may be embedded in the feature 270 expression string are removed (or ignored for the purpose of hash 271 value computation). 273 2. Case normalization: all lower case letters in the feature 274 expression, other than those contained within quoted strings, are 275 converted to upper case. That is, unquoted characters with 276 values 97 to 122 (decimal) are changed to corresponding 277 characters in the range 65 to 90. 279 3. Hash computation: the MD5 algorithm [6] is applied to the 280 normalized feature expression string. 282 The result obtained in step 3 is a 128-bit number that is converted 283 to a hexadecimal representation to form the feature set reference. 285 NOTE: under some circumstances, removal of ALL 286 whitespace may result in an invalid feature expression 287 string. This should not be a problem as significantly 288 different feature expressions are expected to differ in 289 ways other than their whitespace. 291 NOTE: case normalization is deemed appropriate since 292 feature tag and token matching is case insensitive. 294 Internet Draft Identifying composite media features 296 3.2 Feature set URI reference format 298 This section introduces a new form of feature set predicate by 299 extending the feature set syntax [1] as follows: 301 filter =/ "<" URI ">" *( ";" parameter ) 303 where 'URI' is described by "Uniform Resource Identifiers (URI): 304 Generic Syntax" [5]. 306 The meaning of this construct is defined to be the meaning of the 307 expression in which '' is replaced by a copy of the resource 308 indicated by 'URI'. The indicated resource is required to be a 309 text value containing a valid feature set expression, NOT itself 310 containing a '' reference. 312 If a '' reference is used within a feature expression that 313 defines a hash reference, then the hash value is calculated over 314 the expression obtained after the resource has been subsituted. 316 Thus, the following are examples of feature set expressions using 317 URI references: 319 321 (& (dpi=100) ) 323 This specification does not indicate: 325 o any specific URI schemes to be supported, 327 o any meaning if the resource cannot be accessed, of if the value 328 obtained does not correspond to some recognized format. 330 These details must be indicated by the specification of any 331 application or protocol that relies upon this interpretation of an 332 auxiliary feature predicate. 334 If the URI uses characters other than a designated subset of US- 335 ASCII then those additional characters should be represented by a 336 sequence of US-ASCII characters allowed by RFC 2396 [5]. 338 3.3 Resolving feature set references 340 This memo does not mandate any particular mechanism for 341 defeferencing a feature set reference. It is expected that 342 specific dereferencing mechanisms will be specified for any 343 application or protocol that uses them. 345 Internet Draft Identifying composite media features 346 The following sections describe some ways that feature set 347 dereferencing information may be incorporated into a feature set 348 expression. Both of these mechanisms are based on auxiliary 349 predicate definitions within a "where" clause [1]. 351 When a hash-based feature set reference is used, conformance to the 352 hashing rules takes precedence over any other determination of the 353 feature expression. Any expression, however obtained, may not be 354 substituted for the hash-based reference unless it yields the 355 correct hash value. 357 3.3.1 URI reference 359 The two formats for feature set references described above may be 360 combined by defining the meaning of a hash-based reference to be a 361 URI-based reference. For example: 363 (& (dpi=100) (h.1234567890) ) 364 where 365 (h.1234567890) :- 366 end 368 This indicates that the meaning of the hash-based form is contained 369 in the resource whose URI is given. In this case, an HTTP resource 370 retrieval is suggested. 372 The hash value used is calculated over the feature set expression 373 obtained by defererencing the URI form expression. 375 NOTE: How a calling application processes the URI is not 376 specified here. For URIs that are URLs, one reasonable 377 approach would be to use the URL scheme protocol to 378 access the corresponding feature set expression. But 379 other mechanisms might be used; e.g. protocols developed 380 by the IETF resource capability (RESCAP) working group 381 [8]. In any case, any mechanism used must be specified 382 by an application that uses URI references in this way. 384 When a hash-based feature set reference is resolved using a URI 385 value, the retrieving program should use the feature expression 386 thus obtained only if it hashes to the correct value. 388 Internet Draft Identifying composite media features 390 3.3.2 Inline feature set details 392 The feature set expression associated with a reference value may be 393 specified directly in a "where" clause, using the auxiliary 394 predicate definition syntax [1]; e.g. 396 (& (dpi=100) (h.1234567890) ) 397 where 398 (h.1234567890) :- (& (pix-x<=200) (pix-y<=150) ) 399 end 401 This form might be used on request (where the request mechanism is 402 defined by the invoking application protocol), or when the 403 originator believes the recipient may not understand the reference. 405 NOTE: viewed in isolation, this format does not have any 406 obvious value, in that the (h.xxx) form of auxiliary 407 predicate could be replaced by any arbitrary name. 409 It is anticipated that this form might be used as a 410 follow-up response in a sequence along the lines of: 411 A> Capabilities are: 412 (& (dpi=100) (h.1234567890) ) 413 B> Do not understand: 414 (h.1234567890) 415 A> Capabilities are: 416 (& (dpi=100) (h.1234567890) ) 417 where 418 (h.1234567890) :- (& (pix-x<=200) (pix-y<=150) ) 419 end 421 It is an error if the inline feature expression does not yield the 422 hash value contained in auxiliary predicate name. 424 3.4 The birthday problem 426 NOTE: this entire section is commentary, and does not 427 affect the feature set reference specification in any 428 way. 430 The use of a hash value to represent an arbitrary feature set is 431 based on a presumption that no two distinct feature sets will yield 432 the same hash value. 434 There is clearly a small but distinct possibility that two 435 different feature sets will indeed yield the same hash value. 437 We assume that the hash function distributes hash values for 438 feature sets with even very small differences randomly and evenly 439 through the range of 2^128 (approximately 3*10^38) possible values. 441 Internet Draft Identifying composite media features 442 This is a fundamental property of a good digest algorithm like MD5. 443 Thus, the chance that any two distinct feature set expressions 444 yield the same hash is less than 1 in 10^38. This is negligible 445 when compared with, say, the probability that a receiving system 446 will fail having received data conforming to a negotiated feature 447 set. 449 But when the number of distinct feature sets in circulation 450 increases, the probability of clashing hash values increases 451 surprisingly. This is illustrated by the "birthday paradox": 452 given a random collection of just 23 people, there is a greater 453 than even chance that there exists some pair with the same birthay. 454 This topic is discussed further in sections 7.4 and 7.5 of Bruce 455 Schneier's "Applied Cryptography" [7]. 457 Number of feature Probability of two 458 sets in use sets with the same 459 hash value 460 1 0 461 2 3E-39 462 10 1E-37 463 1E3 1E-33 464 1E6 1E-27 465 1E9 1E-21 466 1E12 1E-15 467 1E15 1E-9 468 1E18 1E-3 470 The above probability computations are approximate, being 471 performed using logarithms of a Gamma function 472 approximation by Lanczos [10]. The probability formula 473 is 'P=1-(m!/((m-n)! m^n))', where 'm' is the total number 474 of possible hash values (2^128) and 'n' is the number of 475 feature sets in use. 477 If original feature set expressions are generated manually, or only 478 in response to some manually constrained process, the total number 479 of feature sets in circulation is likely to remain very small in 480 relation to the total number of possible hash values. 482 The outcome of all this is: assuming that the feature sets are 483 manually generated, even taking account of the birthday paradox 484 effect, the probability of incorrectly identifying a feature set 485 using a hash value is still negligibly small when compared with 486 other possible failure modes. 488 Internet Draft Identifying composite media features 490 4. Examples 492 The following are some examples of feature set expressions 493 containing feature set references: 495 (& (dpi=100) (h.1234567890abcdef1234567890abcdef) ) 497 (& (dpi=100) 498 ) 500 (& (dpi=100) (h.1234567890abcdef1234567890abcdef) ) 501 where 502 (h.1234567890abcdef1234567890abcdef) :- 503 504 end 506 5. Internationalization considerations 508 Feature set expressions and URI strings are currently defined to 509 consist of only characters from the US-ASCII repertoire [1,5]; 510 under these circumstances this specification is not impacted by 511 internationalization considerations (other than any already 512 applicable to URIs [5]). 514 But, if future revisions of the feature set syntax permit non-US- 515 ASCII characters (e.g. within quoted strings), then some canonical 516 representation must be defined for the purposes of calculating hash 517 values. One choice might be to use a UTF-8 equivalent 518 representation as the basis for calculating the feature set hash. 519 Another choice might be to leave this as an application protocol 520 issue (but this could lead to non-interoperable feature sets 521 between different protocols). 523 Another conceivable issue is that of up-casing the feature 524 expression in preparation for computing a hash value. This does 525 not apply to the content of strings so is not likely to be an 526 issue. But if changes are made that do permit non-US-ASCII 527 characters in feature tags or token strings, consideration must be 528 given to properly defining how case conversion is to be performed. 530 6. Security considerations 532 For the most part, security considerations are the same as those 533 that apply for capability identification in general [1,2,9]. 535 A possible added consideration is that use of a specific feature 536 set tag may reveal more information about a system than is 537 necessary for a transaction at hand. 539 Internet Draft Identifying composite media features 541 7. Full copyright statement 543 Copyright (C) The Internet Society 1999. All Rights Reserved. 545 This document and translations of it may be copied and furnished to 546 others, and derivative works that comment on or otherwise explain 547 it or assist in its implementation may be prepared, copied, 548 published and distributed, in whole or in part, without restriction 549 of any kind, provided that the above copyright notice and this 550 paragraph are included on all such copies and derivative works. 551 However, this document itself may not be modified in any way, such 552 as by removing the copyright notice or references to the Internet 553 Society or other Internet organizations, except as needed for the 554 purpose of developing Internet standards in which case the 555 procedures for copyrights defined in the Internet Standards process 556 must be followed, or as required to translate it into languages 557 other than English. 559 The limited permissions granted above are perpetual and will not be 560 revoked by the Internet Society or its successors or assigns. 562 This document and the information contained herein is provided on 563 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 564 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 565 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 566 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 567 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 569 8. Acknowledgements 571 Much of the initial work for URI references to feature sets was 572 provided by Bill Newman. Some of the ideas here have been improved 573 by early discussions with Martin Duerst, Al Gilman and Ted Hardie. 575 9. References 577 [1] RFC 2533, "A syntax for describing media feature sets" 578 Graham Klyne, 5GM/Content Technologies 579 March 1999. 581 [2] RFC 2506, "Media Feature Tag Registration Procedure" 582 Koen Holtman, TUE 583 Andrew Mutz, Hewlett-Packard 584 Ted Hardie, Equinix 585 March 1999. 587 Internet Draft Identifying composite media features 589 [3] RFC 2234, "Augmented BNF for Syntax Specifications: ABNF" 590 D. Crocker (editor), Internet Mail Consortium 591 P. Overell, Demon Internet Ltd. 592 November 1997. 594 [4] RFC 2045, "Multipurpose Internet Mail Extensions (MIME) 595 Part 1: Format of Internet message bodies" 596 N. Freed, Innosoft 597 N. Borenstein, First Virtual 598 November 1996. 600 [5] RFC 2396, "Uniform Resource Identifiers (URI): Generic Syntax", 601 Tim Berners-Lee, World Wide Web Consortium/MIT 602 Roy T. Fielding, University of California, Irvine 603 Larry Masinter, Xerox PARC 604 August 1998. 606 [6] RFC 1321, "The MD5 Message-Digest Algorithm", 607 R. Rivest, MIT Laboratory for Computer Science and RSA Data 608 Security, Inc., 609 April 1992. 611 [7] "Applied Cryptography" 612 Bruce Schneier 613 John Wiley and Sons, 1996 (second edition) 614 ISBN 0-471-12845-7 (cloth) 615 ISBN 0-471-11709-9 (paper) 617 [8] Resource capability protocol 618 IETF RESCAP, work in progress 619 (No details published as of March 1999.) 621 [9] "Protocol-independent content negotiation framework" 622 Graham Klyne, 5GM/Content Technologies 623 Internet draft: 624 Work in progress, March 1999. 626 [10] "Numerical Recipes" 627 William H Press, Brian P Flannery, Saul A Teukolski and William T 628 Vetterling 629 Cambridge University Press (1986) 630 ISBN 0 521 30811 9 631 (The Gamma function approximation is presented in chapter 6 on 632 "Special Functions". There have been several later editions of 633 this book published, so the chapter reference may change.) 635 Internet Draft Identifying composite media features 637 10. Authors' addresses 639 Graham Klyne 640 5th Generation Messaging Ltd. Content Technologies Ltd. 641 5 Watlington Street Forum 1, Station Road 642 Nettlebed Theale 643 Henley-on-Thames, RG9 5AB Reading, RG7 4RA 644 United Kingdom United Kingdom. 645 Telephone: +44 1491 641 641 +44 118 930 1300 646 Facsimile: +44 1491 641 611 +44 118 930 1301 647 E-mail: GK@ACM.ORG 649 Larry Masinter 650 Xerox Corporation 651 3333 Coyote Hill Road 652 Palo Alto, CA 94304 653 Facsimile: +1 650 812 4333 654 EMail: masinter@parc.xerox.com 655 http://www.parc.xerox.com/masinter 657 Appendix A: Revision history 659 [[[RFC editor: please remove this section on publication]]] 661 00a 10-Feb-1999 Initial draft. 663 01a 16-Feb-1999 Added pointers to mailing list for discussion. 665 01b 25-Mar-1999 Name all authors. Add some terms to the glossary. 666 Expand on meaning of URI tag used as auxiliary 667 predicate name. Update references. Rework 668 section 3 to deal more evenly with both hash and 669 URI based feature set references. State absolute 670 requirement for hash-based references to be 671 resolved to expressions that yield the correct 672 hash value. 674 01c 06-Apr-1999 Define form of URI reference using new '<...>' 675 syntax, and adjust other text accordingly. 677 01d 06-Apr-1999 Editorial revisions. Include values in table of 678 probabilities for hash value clashes. Remove 679 discussion of algebraic simplification of hash 680 references. Correct syntax of some examples.