Summary

  • RFC 2169 specified THTTP, a small convention for carrying URN resolution service requests and responses over HTTP 1.0 or 1.1.
  • A resolver response can describe a location or return a resource, but the HTTP exchange alone does not establish who assigned the name, who is authoritative, whether access is permitted, or whether retrieval succeeded.

The temptation around persistent identifiers is to treat a route to an answer as proof that the answer is entitled to speak. RFC 2169 is useful precisely because it did not make that leap. It was published as an Experimental RFC in June 1997, under the title A Trivial Convention for using HTTP in URN Resolution, and is now Historic. The document called the protocol THTTP: a way to encode a resolution service request in an HTTP URI and let an existing web server return an ordinary HTTP response.

That design solved a deployment problem. A server operator could add a CGI handler or another HTTP extension rather than deploy a wholly new protocol. The request named both a resolution service and a URN. RFC 2169 discussed services such as N2L, which asks for a URL, and N2R, which asks for the named resource. HTTP status codes, content negotiation and cache rules remained HTTP's ordinary machinery.

None of that turns the server into the namespace's authority. RFC 2141 separated URN syntax and lexical equivalence from functional equivalence. A string can be normalized before resolution; whether two names identify the same thing remains governed by the namespace. RFC 2169 itself required equivalent URNs to yield identical results, but it did not designate a universal resolver, certify a database, or make a Location header a title deed.

The distinction matters because the same visible transaction can be mistaken for several different claims. Sending a valid request shows that a client reached a selected HTTP endpoint. A 200 response shows that endpoint chose to answer in that manner at that time. A redirect may supply a location. An N2R response may supply bytes. Each observation is bounded. It does not demonstrate that the namespace assigned the URN, that the endpoint is current, that returned bytes are intact, that the client has a durable right to use them, or that another resolver would agree.

Later URN work made the institutional boundary clearer. RFC 3406 described namespace assignment as a managed process and namespace space as managed; it also said that global resolution needs its own registration path. The current IANA URN Namespaces registry, maintained under RFC 8141 procedures, records registered namespaces. That registry is evidence about namespace administration, not an instruction that any particular 1997 HTTP resolver is alive or authoritative.

RFC 2169 therefore belongs to Internet history as a lesson in composability. The protocol convention was deliberately small enough to be replaced. It gave HTTP a role at the edge of resolution without asking HTTP to adjudicate all the claims that people later attach to identifiers.

Sources and evidence limits

The factual basis is RFC 2169's THTTP grammar and service discussion; RFC 2141's syntax and equivalence boundary; RFC 1737's functional requirements; RFC 3401 and RFC 3406's later resolution and namespace framework; RFC 8141 and the current IANA registry. These standards and registries do not prove which historical THTTP servers ran, how widely they were deployed, or whether a response from a contemporary endpoint is authoritative for a particular URN.