Summary

  • RFC 2016 packaged a high-level Internet activity as a Uniform Resource Agent containing activation data, targets, experience, a script and a response filter, so the activity could be shared, modified and executed again.
  • The portable object remained dependent on a URAgency that mapped its type to an implementation, supplied runtime dependencies, activated local or remote targets and interpreted replies.
  • A stored specification or successful launch was therefore only a record of intended coordination. It did not prove authorization, semantic stability, correct execution, reproducibility or completion.

RFC 2016 begins with a separation that still rewards close reading. A person should be able to describe a need—subscribe to a mailing list, search several services, collect a result—without embedding every protocol and resource choice into the client application. The proposed Uniform Resource Agent, or URA, was the persistent activity description. It could be copied, amended and invoked later. Different implementations could share one virtual structure.

That portability was real, but bounded. The RFC assigned execution to a formal environment called a URAgency. An agency declared which URA types it could handle, translated between an implementation and the common structure, knew how to activate it and satisfied its runtime requirements. The required methods included retrieval and execution. A Pascal binary and an interpreted script could represent the same broad kind of activity while demanding very different machinery. The object recorded the activity; the agency made it operational.

What the object carried

The architecture divided a URA into six parts. A header identified its type. Activation data described values an invoker had to supply. Targets named resources through URLs or URNs. Experience information could retain a previous execution date or URLs already found. An activity script or program supplied conditional steps, sequencing or scheduling. A response filter reformatted a reply or judged its relevance.

Those fields made a task more legible than a monolithic button. They also exposed where meaning could change. An activation template did not establish that the supplied value was authorized. A target could be replaced to use a nearby host, a mirror or a remote URAgency. Experience data could improve a later run, but could also carry stale assumptions. A script could launch subordinate activities. A filter could turn a service's output into the result a user saw.

RFC 2016's mailing-list example says an instance can encapsulate what is needed and identify the subscription result. That is a design promise, not an independent receipt from the list server. Between the request and the claimed result sit target selection, protocol behavior, runtime state and output interpretation.

The agency was the control surface

Remote activation made the distinction sharper. A URAgency itself could be a target; one URA could invoke another; a top-level URA could coordinate subordinate activities. Moving the specification did not remove authority. It distributed decisions across agencies that might use different mappings, interpreters, libraries, credentials, network positions and target substitutions.

The Silk prototype made the dependency visible. The RFC describes Tcl URAs launched through the Silk Desktop Internet Resource Discovery interface. Users could keep activity instances, supply activation values and add Tcl scripts. The sample code hard-coded a service endpoint, submitted an HTTP request and parsed returned HTML with regular expressions. Its comments acknowledged rough edges and weak error reporting.

That sample is valuable precisely because it is not evidence of broad adoption. It shows what execution required in one prototype: a compatible interpreter, a reachable service, assumptions about a human-facing page and enough error handling to distinguish a result from a failure.

Human-readable output was a brittle API

RFC 2016 explicitly warns that a service can change presentation in a way a person barely notices while breaking software that parses its output. The contemporaneous paper by Leslie Daigle and Sandro Mazzucato makes the same point: regular-expression extraction from HTML fails when visual formatting shifts. Their remedies—machine-oriented service entrances or provider-maintained agents—recognize the problem; they do not make old activities self-validating.

A response filter therefore carried interpretive power. It might discard an error page, accept a misleading pattern or label partial output as success. A launch receipt proves only that execution began. A process exit may prove only that one runtime stopped. Reproducing the same URA later may still reach a different target, receive a changed representation or load different dependencies.

RFC 2016 was published in October 1996 as Experimental, in the Legacy stream. Its predecessor draft and the Silk material establish an architectural experiment, not a standards-track victory or a deployment history. There is no need to recruit it into a genealogy of today's AI systems. Its narrower historical contribution is stronger: it made a high-level activity portable while leaving execution, substitution and interpretation somewhere specific.

The resulting question is not whether the object is durable. It is whether the agency can produce a defensible chain from declared need to authorized inputs, resolved targets, runnable dependencies, observed responses and a result whose meaning survives review.

Sources