RFC 2938

Identifying Composite Media Features

📅 published September 2000, from ietf

Identifying Composite Media Features 💖

okay bestie, this one is RFC 2938 and it's giving "how to write a tiny nickname for a huge feature set" 🎀 It's a Standards Track doc from the Network Working Group (so it's meant to be implemented, not just vibed about). It was written in September 2000 by G. Klyne (Content Technologies) and L. Masinter (AT&T). It updates RFC 2533, and its header doesn't list anything it obsoletes. So it's basically a patch-note for 2533 that says "hey, here's a shorter way to reference big feature sets" ✨

Status of this Memo

this doc is an Internet standards track protocol for the Internet community, and it's asking everyone for discussion and suggestions for improvements 🦋 for the current standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1). distribution of this memo is unlimited 🌈

Copyright (C) The Internet Society (2000). All Rights Reserved. 💜

Abstract

so in RFC 2533, there's an expression format for describing media feature capabilities as a combo of simple media feature tags 🧚

this doc describes an abbreviated format for a composite media feature set, based on a hash of the feature expression that describes that composite. so instead of writing the whole thing out, you get a short hashed reference 💅

Table of Contents 🌸

1.    Introduction ................................................2
1.1   Organization of this document ...............................2
1.2   Terminology and document conventions ........................2
2.    Motivation and goals ........................................3
3.    Composite feature representation ............................4
3.1   Feature set hashed reference format .........................5
3.1.1 Hash value calculation ......................................6
3.1.2 Base-32 value representation ................................7
3.2   Resolving feature set identifiers ...........................8
3.2.1 Query protocol ..............................................8
3.2.2 Inline feature set details ..................................9
4.    Examples ...................................................10
5.    Internationalization Considerations ........................12
6.    Security Considerations ....................................13
7.    Acknowledgements ...........................................13
8.    References .................................................13
9.    Authors' Addresses .........................................15
10.   Appendix A: The birthday paradox ...........................16
11.   Full Copyright Statement ...................................18

1. Introduction ✨

okay so in "A Syntax for Describing Media Feature Sets" [1], there's an expression format for describing media feature capabilities as a combo of simple media feature tags [2] 🎀

this doc proposes an abbreviated format for a composite media feature set, based on a hash of the feature expression describing that composite. it's literally giving "compress the big thing" 💖

this memo extends and builds on the expression syntax from RFC 2533 [1], and it assumes you already know how feature set expressions are interpreted there 🫶

1.1 Organization of this document

section 2 is the background and goals for feature set references 🌸

section 3 gives the syntax for feature set references and explains how they relate to feature set expressions 🦋

1.2 Terminology and document conventions

this section defines some terms and other doc conventions that have specific meanings in this memo. the terms are in alphabetical order, bc we love a tidy list 💅

dereference : the act of replacing a feature set reference with its corresponding feature set expression. also called "resolution".

feature set : some set of media features described by a media feature assertion, as described in "A Syntax for Describing Media Feature Sets" [1]. (see that memo for a more formal definition of this term.)

feature set expression : a string that describes some feature set, formulated according to the rules in "A Syntax for Describing Media feature sets" [1] (and possibly extended by other specifications).

feature set reference : a brief construct that references some feature set. (see also: "dereference".)

feature set tag : a name that conforms to the syntax of a feature tag [2] that is used to denote a feature set rather than a single feature.

resolution : (see "dereference").

this spec uses the syntax notation and conventions from RFC 2234, "Augmented BNF for Syntax Specifications: ABNF" [3] 🧚

NOTE: Comments like this provide additional nonessential information about the rationale behind this document. Such information is not needed for building a conformant implementation, but may help those who wish to understand the design in greater depth. 🙈

2. Motivation and goals 🌈

the range of media feature capabilities a message handling system can have is honestly huge, and the matching feature set expression [1] can get to a significant size 😭

so a requirement came up: let recurring feature sets be identified by a single reference value, which can be combined with other elements in a feature set expression. the expectation is that there will be mechanisms that let the recipient of such a reference discover the feature set expression it stands for, but any such mechanism is beyond the scope of this spec 🔥

so the goals for this proposal are:

  • to provide an abbreviated form for referencing an arbitrary feature set expression.
  • the meaning of a feature set reference (i.e., the corresponding feature set expression) should be independent of any particular mechanism that may be used to dereference it.
  • to be able to verify whether a given feature set expression corresponds to some feature set reference without having to perform an explicit dereferencing operation (i.e., without incurring additional network traffic). 🦋
  • for protocol processors that conform to RFC 2533 [1] to be able to sensibly handle a feature set reference without explicit knowledge of its meaning (i.e., the introduction of feature set references should not break existing feature expression processors). that is, the applicable interpretation and processing rules of RFC 2533 [1] apply equally to expressions containing feature set references. 💜
NOTE: This proposal does not attempt to address the "override" or "default" problem. (Where a feature set may be referenced and selectively modified.) 💀

some situations where an abbreviated form might be used:

  • a media feature expression that contains a repeated sub-expression. if the sub-expression is quite large, space can be saved by writing it out once, then using the abbreviated form to reference it. 🍓
  • a capability that is common to a range of devices, such as a given class of fax machine where a large number of feature tags are involved, but only a small number of common feature sets. if the recipient understands, or can discover, that some abbreviation stands for a given feature set, then feature expression size can be reduced by using the abbreviation. ✨

if feature set abbreviations are used this way, they may be interpretable by a simple table lookup rather than full feature expression parsing. (making this useful in practice will depend on crafting the feature subsets appropriately.) 👑

examples of this usage are in section 4 of this memo 🎀

this memo does not specify how a program that receives a feature set abbreviation should discover the corresponding feature set expression: see section 3.2. 🌸

3. Composite feature representation 🦋

this spec hinges on two central ideas:

  • the use of auxiliary predicates (introduced in RFC 2533 [1]) to form the basis of a feature set identifier, and
  • the use of a token based on a hash function computed over the referenced feature set expression. 💅

a key reason to use a hash function to generate an identifier is to define a global name space without needing a central naming authority. new feature set tags can be introduced by any party following the appropriate rules of formulation, without reference to any centralized authority. no gatekeepers, just vibes 🌈

local resolution services may be needed to map feature set tags to their corresponding feature set expressions, but they are not able to vary the meaning of any given tag. if a resolution service fails to return the correct expression, the calling application can detect that, and it should reject any incorrect value supplied. 🫶

NOTE: where a feature set reference is used, its meaning is defined by substitution of the referenced feature expression into the referencing expression. When all references have been thus replaced, the result is interpreted as a normal feature expression. In particular, if a referenced feature expression contains some feature tag that is also constrained by the referencing expression, the constraints are interpreted per RFC 2533 [1], without regard for their origin. E.g., (using some notation introduced below): (& (pix-x=100) (pix-y<=300) (h.SBB5REAOMHC09CP2GM4V07PQP0) ) where (h.SBB5REAOMHC09CP2GM4V07PQP0) resolves to: (& (pix-x<=200) (pix-y<=150) ) yields a result equivalent to: (& (pix-x=100) (pix-y<=150) ) 🧚

3.1 Feature set hashed reference format 🔥

this spec introduces a special form of auxiliary predicate name with the following syntax:

fname       = "h." 1*BASE32DIGIT
BASE32DIGIT = DIGIT
            / "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H"
            / "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P"
            / "Q" / "R" / "S" / "T" / "U" / "V"

the sequence of base-32 digits represents the value of a hash function calculated over the corresponding feature set expression (see the following sections). note that the above syntax allows upper- or lower-case letters for base-32 digits (per RFC 2234 [3]). the way you spell it is valid, periodt 💖

so, within a feature set expression, a hashed feature set reference would look like this:

(h.123456789abcdefghijklmnopq)

3.1.1 Hash value calculation 🧮

okay so the hash is made with the MD5 algorithm [6] running over the text of the feature set expression you're referencing, but only after it's been cleaned up a bit first 🫧 the expression has to follow the filter syntax from RFC 2533 [1], which looks like this:

filter = "(" filtercomp ")" *( ";" parameter )

here are the steps for making a hash value, bestie 💅

  1. Whitespace normalization 🫧: all spaces, CR, LF, TAB, and any other layout control characters hiding in the feature expression string get removed (or just ignored for the hash math), except the ones inside quoted strings.
  2. Case normalization 🔠: every lower case letter in the feature expression gets turned into upper case, except the ones inside quoted strings. So unquoted characters with US-ASCII values 97 to 122 (decimal) become the matching characters in the range 65 to 90.
  3. Hash computation 🔐: the MD5 algorithm, described in RFC 1321 [6], gets run on the normalized feature expression string. It's treated as a sequence of octets holding US-ASCII character codes (see also section 5 for more on that).

The result from step 3 is a 128-bit (16 octet) value. That gets converted into a base-32 representation, and boom, that's your feature set reference ✨

NOTE: under some circumstances, removing ALL whitespace might leave you with an invalid feature expression string. This should be fine, since it only happens for hash calculation purposes, and significantly different feature expressions are expected to differ in ways other than their whitespace 🙈
NOTE: case normalization is considered appropriate because feature tag and token matching is case insensitive 🎀

3.1.2 Base-32 value representation 🔡

RFC 1321 [6] explains how to calculate an MD5 hash value, which is a sequence of 16 octets. That value then has to be coded as a base-32 value, which is a sequence of base-32 digit characters 🌸

Each character in a base-32 value stands for 5 bits of the underlying octet sequence, one after another. So each group of 8 characters stands for 5 octets (40 bits) ✨ Here's the picture:

                 1          2          3
      01234567 89012345 67890123 45678901 23456789
     +--------+--------+--------+--------+--------+
     |< 1 >< 2| >< 3 ><|.4 >< 5.|>< 6 ><.|7 >< 8 >|
     +--------+--------+--------+--------+--------+
                                             <===> 8th character
                                       <====> 7th character
                                  <===> 6th character
                            <====> 5th character
                      <====> 4th character
                 <===> 3rd character
           <====> 2nd character
      <===> 1st character

The value (the sequence of bits) that each base-32 digit character represents is listed in this table 📋

       "0"  0       "A"  10     "K"  20      "U"  30
       "1"  1       "B"  11     "L"  21      "V"  31
       "2"  2       "C"  12     "M"  22
       "3"  3       "D"  13     "N"  23
       "4"  4       "E"  14     "O"  24
       "5"  5       "F"  15     "P"  25
       "6"  6       "G"  16     "Q"  26
       "7"  7       "H"  17     "R"  27
       "8"  8       "I"  18     "S"  28
       "9"  9       "J"  19     "T"  29

When you're encoding a base-32 value, every full group of 5 octets becomes 8 characters from the table above. If a group of less than 5 octets is left over, it gets encoded with as many extra characters as it needs: 1, 2, 3, or 4 octets become 2, 4, 5, or 7 characters respectively. Any spare bits in the base-32 digit characters are set to zero 🫶

Decoding goes the other way around. Each full group of 8 characters decodes into 5 octets, and a final group of 2, 4, 5, or 7 characters decodes into 1, 2, 3, or 4 octets respectively. Any spare bits in that final group of characters get thrown away 🗑️

So for a 128-bit (16 octet) MD5 hash value, the first 15 octets come out as 24 base-32 digit characters, and the final octet is coded with two characters. Ta-da 🎀

NOTE: Base64 representation (per MIME [4]) would be more compact (21 rather than 26 characters for the MD5 128-bit hash value), but an auxiliary predicate name is defined (by [1]) to have the same syntax as a feature tag, and the feature tag matching rules (per [2]) state that feature tag matching is case insensitive 🙃
Base36 representation was considered (i.e., using all letters "A"-"Z") but was not used because this would require extended precision multiplication and division operations to encode and decode the hash values 😭

3.2 Resolving feature set identifiers 🗺️

This memo doesn't force any particular mechanism for dereferencing a feature set identifier. It's expected that specific dereferencing mechanisms will be specified for any application or protocol that uses them 💜

The next sections describe some ways that feature set dereferencing information can be put into a feature set expression. These are based on auxiliary predicate definitions inside a "where" clause [1] ✨

When a hashed feature set reference is used, conformance to the hashing rules takes precedence over any other determination of the feature expression. Any expression, however it was obtained, may not be substituted for the hash-based reference unless it yields the correct hash value. No swapping in lookalikes, bestie 🚫

3.2.1 Query protocol 📨

A protocol that handles request/response type queries (e.g., HTTP, LDAP, etc.) might be set up to provide a resolution service 🧚

So a query to a server associated with the capabilities can be performed on the feature set identifier. The response that comes back would be a CONNEG expression; e.g.,

      (h.SBB5REAOMHC09CP2GM4V07PQP0)
      where
      (h.SBB5REAOMHC09CP2GM4V07PQP0) :- (& (pix-x<=200) (pix-y<=150) )
      end

or just:

      (& (pix-x<=200) (pix-y<=150) )

That result then gets combined with the original expression, so you end up with a result that doesn't include the hash based predicate anymore 🦋

This process might get even better by using URN resolution mechanisms (e.g., DNS NAPTR [10]) to discover the resolution protocol and server 👑

3.2.2 Inline feature set details 📦

In this case, a reference gets resolved by including its definition inline in an expression ✨

The feature set expression tied to a reference value can be written directly in a "where" clause, using the auxiliary predicate definition syntax [1]. Like this:

      (& (dpi=100) (h.SBB5REAOMHC09CP2GM4V07PQP0) )
      where
      (h.SBB5REAOMHC09CP2GM4V07PQP0) :- (& (pix-x<=200) (pix-y<=150) )
      end

This form might be used on request (where the request mechanism is defined by the invoking application protocol), or when the originator believes the recipient may not understand the reference 🥺

It is an error if the inline feature expression does not yield the hash value contained in the auxiliary predicate name 🚨

NOTE: viewed in isolation, this format doesn't have any obvious value, because the (h.xxx) form of auxiliary predicate could be replaced by any arbitrary name 🤷‍♀️

It's anticipated that this form might be used as a follow-up response in a sequence along the lines of:

          A> Capabilities are:
            (& (dpi=100) (h.SBB5REAOMHC09CP2GM4V07PQP0) )
          B> Do not understand:
            (h.SBB5REAOMHC09CP2GM4V07PQP0)

          A> Capabilities are:
            (& (dpi=100) (h.SBB5REAOMHC09CP2GM4V07PQP0) )
            where
              (h.SBB5REAOMHC09CP2GM4V07PQP0) :- (& (pix-x<=200)
                (pix-y<=150) )
            end

4. Examples ✨

okay so here are some examples of feature set expressions that use feature set references 🧚💖

(& (dpi=100) (h.SBB5REAOMHC09CP2GM4V07PQP0) )

(& (dpi=100) (h.SBB5REAOMHC09CP2GM4V07PQP0) )
where
(h.SBB5REAOMHC09CP2GM4V07PQP0) :-
  (& (pix-x<=200) (pix-y<=150) )
end

(h.QGEOPMCF02P09QC016CEPU22FO)
where
(h.QGEOPMCF02P09QC016CEPU22FO) :-
 (| (& (ua-media=continuous) (dpi=200) (dpi-xyratio=200/100)
       (color=Binary) (paper-size=B4) (image-coding=MH) )
    (& (ua-media=continuous) (dpi=200) (dpi-xyratio=200/100)
       (color=Binary) (paper-size=B4) (image-coding=MR) )
    (& (ua-media=stationery) (dpi=300) (dpi-xyratio=1)
       (color=Binary) (paper-size=A4) (image-coding=JBIG) )
    (& (ua-media=transparency) (dpi=300) (dpi-xyratio=1)

       (color=Binary) (paper-size=A4) (image-coding=JBIG) ) )
end

These examples come from Internet fax work, and they show how a feature-hash can be used to express features people use all the time 📠🌸 A form of Internet fax system that is expected to be quite common is a so-called "simple mode" system. Its capabilities are described by the following feature expression:

(& (image-file-structure=TIFF-minimal)
  (MRC-mode=0)
  (color=Binary)
  (image-coding=MH) (MRC-mode=0)
  (| (& (dpi=204) (dpi-xyratio=[204/98,204/196]) )
     (& (dpi=200) (dpi-xyratio=[200/100,1]) ) )
  (size-x<=2150/254)
  (paper-size=A4)
  (ua-media=stationery) )

This might be expressed by the hash-based feature set identifier:

(h.MSB955PVIRT1QOHET9AJT5JM3O)

The next example describes the capabilities of a full-color Internet fax system 🌈 Notice that a bunch of feature values are shared between (color=grey) and (color=full), which is a total vibe for pulling them out later:

(& (image-file-structure=TIFF)
   (MRC-mode=0)
   (| (& (color=Binary)
         (image-coding=[MH,MR,MMR])
         (| (& (dpi=204) (dpi-xyratio=[204/98,204/196]) )
            (& (dpi=200) (dpi-xyratio=[200/100,1]) )
            (& (dpi=300) (dpi-xyratio=1) ) ) )
      (& (color=grey)
         (image-coding=JPEG)
         (image-coding-constraint=JPEG-T4E)
         (color-levels<=256)
         (color-space=CIELAB)
         (color-illuminant=D50)
         (CIELAB-L-min>=0)
         (CIELAB-L-max<=100)
         (dpi=[100,200,300]) (dpi-xyratio=1) )
      (& (color=full)
         (image-coding=JPEG)
         (image-coding-constraint=JPEG-T4E)
         (color-subsampling=["1:1:1","4:1:1"])
         (color-levels<=16777216)
         (color-space=CIELAB)
         (color-illuminant=D50)
         (CIELAB-L-min>=0)
         (CIELAB-L-max<=100)
         (CIELAB-a-min>=-85)
         (CIELAB-a-max<=85)
         (CIELAB-b-min>=-75)
         (CIELAB-b-max<=125)
         (dpi=[100,200,300]) (dpi-xyratio=1) ) )
   (size-x<=2150/254)
   (paper-size=[letter,A4,B4]) )
   (ua-media=stationery) )

Now pull out the common capabilities and you get:

(& (image-file-structure=TIFF)
   (MRC-mode=0)
   (| (& (color=Binary)
         (image-coding=[MH,MR,MMR])
         (| (& (dpi=204) (dpi-xyratio=[204/98,204/196]) )
            (& (dpi=200) (dpi-xyratio=[200/100,1]) )
            (& (dpi=300) (dpi-xyratio=1) ) ) )
      (& (color=grey)
         (color-levels<=256)
         (h.QVSEM8V2LMJ8VOR7V682J7079O) )
      (& (color=full)
         (color-subsampling=["1:1:1","4:1:1"])
         (color-levels<=16777216)
         (CIELAB-a-min>=-85)
         (CIELAB-a-max<=85)
         (CIELAB-b-min>=-75)
         (CIELAB-b-max<=125)
         (h.QVSEM8V2LMJ8VOR7V682J7079O) ) )
   (size-x<=2150/254)
   (paper-size=[letter,A4,B4]) )
   (ua-media=stationery) )
where
(h.QVSEM8V2LMJ8VOR7V682J7079O) :-
   (& (image-coding=JPEG)
      (image-coding-constraint=JPEG-T4E)
      (color-space=CIELAB)
      (color-illuminant=D50)
      (CIELAB-L-min>=0)
      (CIELAB-L-max<=100)
      (dpi=[100,200,300]) (dpi-xyratio=1) )
end

5. Internationalization Considerations 🌍

Right now, feature set expressions and URI strings are only allowed to use characters from the US-ASCII repertoire [1,5]. Under those conditions this spec isn't affected by internationalization stuff, other than whatever already applies to URIs [5] 💅

BUT if future versions of the feature set syntax let in non-US-ASCII characters (like inside quoted strings, for example), then there has to be a canonical representation for calculating hash values 👀 One option would be to use a UTF-8 equivalent representation as the basis for the feature set hash. Another option would be to leave it up to the application protocol. That one could lead to feature sets that don't interoperate between different protocols, though, so ngl it's a bit risky 😬

Another thing to think about is up-casing the feature expression before computing a hash value. This doesn't apply to the content of strings, so it's not likely to be an issue. But if changes are made that allow non-US-ASCII characters in feature tags or token strings, then case conversion has to be properly defined, no exceptions 🫶

6. Security Considerations 🔐

For the most part, the security considerations are the same as the ones that apply to capability identification in general [1,2,9] ✨

There's one possible extra consideration, though, and it's kind of a big deal 😳 Using a specific feature set identifier may reveal more information about a system than is necessary for the transaction at hand. Yikes! Think of it like handing someone your whole diary when they only asked for the time 📖💀

Be careful about what your identifiers give away. A feature set identifier can leak more about a system than the transaction actually needs, and that's a privacy and security risk you don't want to ignore 🚨

7. Acknowledgements 💜

Ideas here got better thanks to early discussions with Martin Duerst, Al Gilman and Ted Hardie 🫶 Maurizio Codogno also gave useful suggestions for improvement 🌸

8. References 📚

  • [1] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.
  • [2] Mutz, A. and T. Hardie, "Media Feature Tag Registration Procedure", RFC 2506, March 1999.
  • [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
  • [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part 1: Format of Internet message bodies", RFC 2045, November 1996.
  • [5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
  • [6] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
  • [7] "Applied Cryptography" Bruce Schneier John Wiley and Sons, 1996 (second edition) ISBN 0-471-12845-7 (cloth) ISBN 0-471-11709-9 (paper)
  • [8] Klyne, G., "Protocol-independent Content Negotiation Framework", RFC 2703, September 1999.
  • [9] "Numerical Recipes" William H Press, Brian P Flannery, Saul A Teukolski and William T Vetterling, Cambridge University Press (1986), ISBN 0 521 30811 9. (The Gamma function approximation is presented in chapter 6 on "Special Functions". There have been several later editions of this book published, so the chapter reference may change.)
  • [10] Daniel, R. and M. Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", RFC 2168, June 1997.
  • [11] Java source code of feature set matching algorithm, with feature set hash computation option. Linked from <http://www.imc.org/ietf-medfree/>

9. Authors' Addresses 🖊️

Graham Klyne
Content Technologies Ltd.
1220 Parkview,
Arlington Business Park
Theale
Reading, RG7 4SA
United Kingdom

Phone: +44 118 930 1300
Fax:   +44 118 930 1301
EMail: GK@ACM.ORG


Larry Masinter
AT&T Labs
75 Willow Road
Menlo Park, CA 94025

Phone: +1-650-463-7059
EMail: LMM@acm.org
http://larry.masinter.net

10. Appendix A: The birthday paradox 🎂

NOTE: this entire section is commentary, and does not affect the feature set reference specification in any way.

The whole idea of using a hash value to stand in for an arbitrary feature set rests on a presumption that no two distinct feature sets will ever produce the same hash value 🤞

There's a small but real possibility that two different feature sets will indeed produce the same hash value 😅

We assume that the 128-bit hash function spreads out hash values for feature sets, even ones with very small differences, randomly and evenly across the range of 2^128 (approximately 3*10^38) possible values. That's a fundamental property of a good digest algorithm like MD5 💖 So the chance that any two distinct feature set expressions yield the same hash is less than 1 in 10^38. That's negligible compared with, say, the probability that a receiving system fails after receiving data that matches a negotiated feature set.

BUT when the number of distinct feature sets in circulation grows, the probability of repeating a hash value increases surprisingly fast 🙈 This is the "birthday paradox": given a random group of just 23 people, there's a greater than even chance that some pair shares a birthday 🎂 This topic is discussed further in sections 7.4 and 7.5 of Bruce Schneier's "Applied Cryptography" [7].

The table below shows the "birthday paradox" probabilities that at least one pair of feature sets has the same hash value, for different numbers of feature sets in use 📊

Number of feature   Probability of two
sets in use         sets with the same
                    hash value
1                   0
2                   3E-39
10                  1E-37
1E3                 1E-33
1E6                 1E-27
1E9                 1E-21
1E12                1E-15
1E15                1E-9
1E18                1E-3

The probability computations above are approximate. They're done using logarithms of a Gamma function approximation by Lanczos [9]. The probability formula is P=1-(m!/((m-n)! m^n)), where m is the total number of possible hash values (2^128) and n is the number of feature sets in use 🧮

If original feature set expressions are generated manually, or only in response to some manually constrained process, the total number of feature sets in circulation is likely to stay very small compared with the total number of possible hash values 🌷

The outcome of all this: if the feature sets are manually generated, then even counting the birthday paradox effect, the chance of incorrectly identifying a feature set using a hash value is still negligibly small compared with other possible failure modes. 🌈✨

okay bestie, the legal bit is next and it's serious, but I'll keep it lowkey fun 🎀

Copyright (C) The Internet Society (2000). All Rights Reserved. 💖

So this document, and any translations of it, can be copied and handed out to other people. You can also make derivative works that comment on or explain it, or help people implement it, and you can prepare, copy, publish, and distribute those, in whole or in part, with no restrictions at all. The one condition is that the copyright notice above and this paragraph have to be on every copy and every derivative work. 🫶

The document itself can't be modified in any way. That means you can't remove the copyright notice or the references to the Internet Society or other Internet organizations. There are two exceptions. The first is when it's needed for developing Internet standards, and then the copyright procedures in the Internet Standards process have to be followed. The second is when it's being translated into a language other than English. 🌸

These permissions are perpetual. The Internet Society, its successors, and its assigns will never revoke them. 🦋

This document and the information in it are provided "AS IS", and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💅

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society. 🙌

📦 where this page comes from