Summary

  • RFC 2122 defined a URL for an interactive multimedia service, not a data object: a VEMMI client normally opened a continuous TCP session, by default on port 575.
  • The URL could select a service and carry labeled parameters, but it could not contain a username or password; browser support, authentication and receipt of VEMMI_Open remained later, separately observable stages.
  • application/vemmi covered a distinct object-transport role, and operative objects could be executable programs. Download, user approval, execution and safe outcome were therefore different records.

A service address, not an object address

Published as a Proposed Standard in March 1997, RFC 2122 defined the vemmi scheme for the Enhanced Man-Machine Interface for Videotex and Multimedia/Hypermedia Information Retrieval Services. The name belonged to an era in which the Web was becoming a common point of entry while online systems still carried their own clients, state machines and interaction models.

The RFC makes its key distinction unusually plain: the URL does not designate a data object. It designates a VEMMI multimedia service. A normal VEMMI arrangement kept one TCP/IP link between client and server for the user’s session and used that link to manage multimedia objects and report user actions. The URL’s job was to describe where and how to begin that service.

Its general form was vemmi://<host>:<port>/<vemmiservice>;<attribute>=<value>. The port and service were optional. With no port, the client used 575; the RFC also allowed a client to ignore a supplied non-default port as a security policy. Parameters followed the service as labeled attribute-value pairs rather than unlabeled positions. They could carry context or request particular processing.

That syntax was expressive, but it was not evidence that anything had happened. A host string did not prove resolution. Port 575 did not prove a listener. A service name did not prove that the server offered it. A parameter did not prove that the server accepted or acted on it. The URL recorded a proposed launch instruction.

The click began a staged dialogue

The expected client-server exchange shows why a link could not be treated as a completed transaction. After connecting, the server could request service:, username: and password:. The client might take the service from the URL, use a configured identity value, or prompt the user. Only later did the terminal leave its ordinary videotex or telnet-compatible “standard” mode, when it received the VEMMI_Open command.

RFC 2122 deliberately excluded username and password from the URL. Service selection and labeled data could travel with the link; identity was left to a later dialogue. The RFC’s examples included a successful-looking 200 OK and a 401 Unauthorized, but those were examples of status syntax, not reports from a measured deployment.

The evidence chain therefore had several receipts: the hyperlink was selected; a handler was found; the client started; the host resolved; a TCP connection opened; the service prompt and response matched; identity was challenged and accepted; VEMMI_Open arrived; the session operated; an intended result occurred. Each receipt belonged to one transition. None inherited the authority of the next.

An unfamiliar scheme could fail before the service

The RFC anticipated that VEMMI support might be built into a browser or provided by associated software or a plug-in. It also described two failure behaviours when support was absent. One browser might reject an unknown scheme immediately. Another might mistake the text for a relative URL, send a malformed request to the HTTP server that supplied the page and receive a not-found response.

This is an important historical limit. The presence of a clickable vemmi:// string in HTML did not establish that the reader’s software knew what to do with it. Even successful scheme parsing established only dispatch capability. It said nothing about the helper’s version, local configuration, network reachability or remote service.

The RFC proposed usability workarounds: offer a separate client download, let the server recognize the mistaken relative request, or inspect HTTP Accept for application/vemmi. These were proposed mechanisms. They were not measurements of browser coverage, and this article makes no claim about how widely any of them were implemented.

Object transport was a separate role

RFC 2122 also registered application/vemmi. That media type allowed VEMMI objects to move through HTTP, email or other transports; an HTTP request could fetch an object without establishing the continuous VEMMI session. A media-typed file might even contain a VEMMI URL for a browser that could not add a new scheme.

The two mechanisms touched the same environment but did different jobs. The vemmi URL named and launched a service path. application/vemmi labeled an object for transport and decoding. Accepting the media type might suggest that a decoder was installed, but it did not prove that a live VEMMI service existed or that a session would authenticate and open.

IANA still lists vemmi as a permanent URI scheme, application/vemmi as a media type and VEMMI on port 575. Those are current registry facts. They preserve namespace assignments, not a pulse: they do not demonstrate software maintenance, active listeners, traffic, interoperability or adoption.

Executable objects created another consent boundary

The most consequential boundary came after transport. VEMMI metacode objects could contain command sequences, while operative objects were executable programs intended to run on the client platform. The RFC strongly recommended disabling automatic execution for potentially unsafe objects or, at minimum, requiring user approval first.

That recommendation separated receipt from authority. A media type could identify the package. A session could deliver it. A decoder could parse it. None of those acts granted permission to execute. Approval itself still did not prove that the binary matched the platform, behaved safely or produced the intended outcome.

The RFC also called its username/password mechanism insecure and retained for backward compatibility. That statement belongs to the 1997 specification; it should not be repackaged as modern security guidance. Its durable value is architectural: identity, transport and code execution must have distinct controls.

The historical lesson is a ledger of transitions

RFC 1738 had already made URL interpretation scheme-specific and allowed access methods beyond simple retrieval. RFC 2122 is a precise historical specimen of that flexibility. The Web page could serve as rendezvous, yet the real work moved into a separate stateful runtime.

Lu Heng’s Running-Code Primacy supplies a useful reading discipline: a document or registry entry should not borrow the authority of running implementation. Minimum Initial Specification likewise separates a shared initial rule from the local decision to adopt and operate it. Applied here, the registered scheme proves that a name and syntax were standardized; it does not prove that any particular user crossed the later gates.

The right historical record is not “the link worked.” It is a sequence: named, parsed, dispatched, connected, selected, challenged, authenticated, opened, delivered, approved, executed, observed. RFC 2122 matters because it exposed those layers in a single click—and because nearly every operational mistake begins by erasing them.

Sources