Summary

  • RFC 2361 let Internet applications name codecs already registered in Microsoft's WAVE and AVI databases through audio/vnd.wave;codec=... and video/vnd.avi;codec=...; IANA republished those values rather than assigning them.
  • A valid registry label established an identifier, not a decoder, a match between header and body, a safe parser, a current vendor contact or a successful render.

The browser receives a media object with a precise label: video/vnd.avi;codec=CVID. The registry recognises the four letters. The application has a component called a Cinepak decoder. Three green facts appear to align. Then playback fails.

Nothing about that sequence makes the registry wrong. The label may have been copied incorrectly. The container may carry another stream. The installed component may support a different variant, bit depth or calling convention. It may reject a damaged header, exhaust memory, crash inside a parser or decode frames that the application never presents. A name can be exact while the operation it seems to promise never happens.

RFC 2361 entered this gap in June 1998. Internet applications were beginning to fetch, describe and stream large bodies of multimedia that had not been invented for Internet protocols. RealNetworks and QuickTime were visible parts of the period, but enormous WAVE and AVI collections already depended on registries maintained by Microsoft. An Internet application needed a portable way to say which registered codec a traditional file claimed to use.

The RFC's solution was economical. It did not relocate the codec definitions into an IETF registry. It placed references to the existing namespaces in MIME's vendor tree. An audio object could be labelled audio/vnd.wave with a required codec parameter containing a WAVE Format ID. A video object could be labelled video/vnd.avi with a required codec parameter containing an AVI Codec ID. The subtype named the external registry; the parameter selected a value inside it.

That design joined two authorities without pretending they were one. The Microsoft registries had assigned the WAVE numbers and FourCC values. MIME supplied a syntax in which an Internet message or protocol could carry them. RFC publication made the translation rule public. The current IANA page states the division with unusual clarity: its registration procedure is “IANA does not assign. Republication of values.”

The audio translation contained a small but consequential convention. WAVE Format IDs were hexadecimal registration numbers. Their digits were reproduced in the parameter without a 0x prefix. The MP3 entry numbered 0x0055 therefore became audio/vnd.wave;codec=55. That string did not mean decimal 55. A system that parsed the parameter as a decimal quantity and converted it anew could point at the wrong registry entry while appearing numerically careful.

AVI used a different identity. Its Codec ID was a FourCC: a 32-bit, case-sensitive sequence of four ASCII characters. CVID, cvid and any normalised version were not interchangeable merely because a user interface displayed them similarly. The registry even contained examples where upper- and lower-case spellings were separately noted. Case, length and raw octets belonged to the identifier, not to presentation typography.

RFC 2361 also described how both families could enter software that used GUIDs. A WAVE number was zero-extended into the first field of a fixed GUID template. A FourCC occupied the same 32 bits. The RFC's H260 example became 30363248 because a DWORD's byte ordering made the ASCII sequence appear reversed in hexadecimal. The calculation was deterministic. It let two representations resolve to the same registered identity.

It did not add meaning. A GUID derived from an external codec ID did not become a new, independently assigned specification. It did not prove that the decoder binary on a machine implemented the intended bitstream. It did not say who had installed that binary, whether it was trustworthy or whether it could safely process the object now arriving from a network.

The age of the registries sharpened that distinction. RFC 2361 called them historic databases. Their purpose had been to prevent identifier collisions and publish registered information in a common form. Unless an original registrant reported an acquisition, new address, new telephone number or another status change, contact information generally remained as first submitted. The appendices were authoritative for values registered as of January 1998, not for the contemporary solvency, ownership or reachability of every company named beside them.

This is a durable property of registries: identity can survive stewardship. A code may remain useful long after the original vendor disappears. That stability is valuable precisely because it does not depend on a telephone number remaining live. But an operator cannot reverse the implication. A persistent entry does not prove that a maintained decoder, licensing path, security contact or support organisation still exists.

Nor did registry publication validate the object itself. A media type parameter is sender-supplied metadata. The receiver must still parse enough of the container to see what streams and identifiers the bytes actually contain. The header may be missing, mistaken or hostile. The body may be truncated or polyglot. A correct registry lookup proves only that the supplied token has a defined referent in the consulted snapshot.

Later work on the plural codecs parameter for bucket media types made the same evidence boundary explicit in another context. RFC 6381 requires an accurate declaration, yet says the body is definitive when parameter and media elements conflict. It also recognises that listing a codec does not settle whether every track is needed or whether a receiver can render a useful subset. RFC 6381 does not update RFC 2361 or replace its singular vendor-tree syntax. It shows that the distinction between declaration and inspected content survived well beyond WAVE and AVI.

Capability was a separate decision again. An application could use the label to reject an object early, choose a transcoding service or select a candidate component. It still needed the decoder's precise supported format, version and resource envelope. “Installed” did not mean “selected”; “selected” did not mean “initialised”; “initialised” did not mean “decoded”; and decoded samples did not prove presentation to the intended user.

Transport added no shortcut. RTSP could describe and control a session, RTP could carry time-sensitive media, and HTTP could retrieve an object. A WAVE or AVI codec name helped those systems refer to traditional content. It was not itself an RTP payload format, successful RTSP setup, complete transfer or timing receipt. Naming what might decode the content and observing that the content arrived were different records.

Security was the RFC's shortest and most important refusal. The document said it merely registered formats and did nothing to address their security considerations. Each format had to be investigated separately. A registry hit could not serve as a permission to fetch a decoder, load a privileged plugin or feed untrusted bytes into a native parser.

The operational chain therefore begins with the exact received media type and raw parameter. It records which registry snapshot resolved the token, whether case and hexadecimal rules were preserved, and whether the container agreed. It then records the decoder implementation and provenance, sandbox and resource policy, decode attempt, emitted streams, presentation result and downstream delivery. Every step may succeed while the next remains unknown.

RFC 2361's achievement was not multimedia compatibility by declaration. It was a bounded federation mechanism. Internet software could refer to a mature external namespace without IANA claiming to have created its values and without the RFC pretending to specify the codecs behind them. The label crossed the boundary. Authority, implementation and outcome stayed where the evidence placed them.