The Part of the Form That Stayed in the Office

The HTML Working Group's charter carried an instruction worth pausing on: describe existing features before developing new ones. By the time RFC 1866 appeared in November 1995, forms had been shipping in Mosaic for more than two years. Servers were already receiving submissions. The group's assignment was largely to write down what browsers were already doing.

What browsers were doing was sending name/value pairs to a URI. Fields had names, a destination received them, and GET or POST carried them there. The spec is not silent on consequences: it separates GET, for operations with "no lasting observable effect," from POST, for things like modifying a database. But consequence there is a property of the request, a question of whether it can be repeated or cached without harm. It says nothing about what the submission means to anyone at either end of the wire.

One absence makes the translation visible. RFC 1866 had no element tying a field to the words displayed beside it. NAME was a transmission key, sent to the server. NCSA's documentation said so plainly: a "symbolic name," not a displayed one. The words a person read in order to know what to type were ordinary page text sitting nearby. The machine-readable identifier and the human-readable meaning were separate objects, related only by their position on the screen. A reader bridges that gap without noticing the effort. A software agent working from the rendered page, the raw markup, or the structured description that browsers expose to screen readers has to rebuild the bridge from whatever later conventions and surrounding context happen to be available.

I went looking through the surviving public record from 1994 and 1995 — the charter, the drafts, the mailing list threads, the companion file-upload RFC — for any discussion of who was submitting, on whose authority, and carrying what liability. The threads are long on syntax, transport, character encoding, field validation, password entry. On institutional standing there is nothing. Not a rejected proposal; simply outside the problem as the group understood it, which was a transport mechanism, under a charter that told them to document practice. Everything that made a paper form function sat outside the paper: the office you walked into, the clerk who looked at your identification, the regulations printed on the reverse, your own sense of what signing committed you to. That context traveled alongside the form and was never in it. Because it was never written into the markup, it cannot be recovered from the markup by anything — a person, a server, or a model.

Agents now work this same machinery at very large volume. They locate fields, supply values, and trigger submission with a precision the Mosaic team would have found startling. What they parse is the skeleton the spec preserved. Whether the submission binds anyone, whether the party filling it in has standing to act, whether the step can be walked back, who absorbs the cost if the values are wrong: none of that was encoded at any layer, so none of it arrives with the form.

The choices made in 1995 were sensible for the problem in front of the group. But the layer that paper forms carried around them still has to live somewhere, and thirty years on, it mostly doesn't.