rfc-2938

Identifying Composite Media Features

G. Klyne, L. Masinter
date2000-09 streamIETF areaapp wgconneg statusPROPOSED STANDARD pages18 canonicalhttps://www.rfc-editor.org/rfc/rfc2938 doi10.17487/RFC2938 errataview
This document describes an abbreviated format for a composite media feature set, based upon a hash of the feature expression describing that composite. [STANDARDS-TRACK]

updates

Extracted elements (15)

design-rationale §3

A hash function is used to generate feature set identifiers to define a global name space without requiring a central naming authority. Any party can introduce new feature set tags by following the formulation rules, without reference to any centralized authority.

registry

design-rationale §3.1.2

Base-32 was chosen over Base-64 because auxiliary predicate names have the same syntax as feature tags, and feature tag matching is case insensitive, making case-sensitive Base-64 unsuitable. Base-36 (using all letters A-Z) was considered but rejected because it would require extended precision multiplication and division to encode/decode hash values.

design-rationale §10

The birthday paradox analysis shows that assuming manually generated feature sets, the probability of two distinct feature sets yielding the same MD5 hash is negligibly small (less than 1 in 10^38 for any pair). Even with 1 billion feature sets in circulation, the collision probability remains only 1 in 10^21.

crypto, security

design-rationale §3

The meaning of a feature set reference is defined by substitution of the referenced feature expression into the referencing expression, and is independent of any particular dereferencing mechanism. This ensures that failure of a resolution service to return the correct expression is detectable by a calling application.

interoperability-note §2

Protocol processors conforming to RFC 2533 can handle feature set references without explicit knowledge of their meaning, because the applicable interpretation and processing rules of RFC 2533 apply equally to expressions containing feature set references. This ensures backward compatibility.

interoperability-note §3

When a referenced feature expression contains a feature tag also constrained by the referencing expression, the constraints are interpreted per RFC 2533 without regard for their origin, effectively taking the intersection of constraints from both expressions.

normative-requirement §5 MUST

If future revisions of the feature set syntax permit non-US-ASCII characters, a canonical representation must be defined for calculating hash values, with UTF-8 suggested as one option. Currently, feature set expressions consist only of US-ASCII characters.

normative-requirement §3.2.2 MUST

It is an error if an inline feature expression provided in a 'where' clause does not yield the hash value contained in the auxiliary predicate name.

normative-requirement §3.2 MUST NOT

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 obtained by other means may not be substituted for the hash-based reference unless it yields the correct hash value.

security

protocol-element §3.1

A feature set hashed reference takes the form 'h.' followed by one or more BASE32DIGIT characters, where BASE32DIGIT includes digits 0-9 and letters A-V (upper or lower case). This auxiliary predicate name syntax is used within feature set expressions to reference a composite feature set.

protocol-element §3.2.2

Feature set details can be resolved inline by including the feature set expression directly in a 'where' clause using RFC 2533's auxiliary predicate definition syntax. This form may be used when the originator believes the recipient may not understand the reference.

protocol-element §3.2.1

Feature set identifiers can be resolved via a query protocol (e.g., HTTP, LDAP) that returns the corresponding feature set expression, possibly enhanced using URN resolution mechanisms such as DNS NAPTR to discover the resolution protocol and server.

dns

protocol-element §3.1.1

Hash value calculation involves three normalization steps: (1) remove all whitespace outside quoted strings, (2) convert all unquoted lowercase letters to uppercase, (3) apply MD5 to the normalized US-ASCII string. The feature expression must conform to RFC 2533's 'filter' syntax.

crypto

security-consideration §6

Use of a specific feature set identifier may reveal more information about a system than is necessary for the transaction at hand, since a known hash value may allow a recipient to infer detailed capability information about the sender.

security, privacy

wire-format §3.1.2

The hash value is a 128-bit MD5 digest encoded as base-32 digits, where each character represents 5 bits. A 128-bit MD5 value encodes to 26 base-32 characters (first 15 octets as 24 characters, final octet as 2 characters).

crypto