Summary

  • RFC 3368 gave go: two different jobs: address a particular CNRP service, or hand a common-name query to services selected by the client.
  • A server-specific id= link could point to a record while omitting the human name a reader believed it represented. Syntax, registration and resolution were separate evidence.

In August 2002, RFC 3368 proposed a link for a problem that ordinary web addresses did not solve neatly: people remembered names, while networks moved resources through identifiers and services. The go: scheme did not make the name itself authoritative. It defined how a client should carry a CNRP query toward a service.

The distinction sits in the characters after the colon. go://cnrp.example?Ada%20Lovelace names a particular server and gives it a query. go:Ada%20Lovelace leaves the server out; the RFC intended that form for one or more CNRP services already configured by the client. The same visible name could therefore enter different service sets on different machines. The link did not contain a universal directory of resolvers.

RFC 3368 also gave a server-only URI a different meaning: it identified a CNRP service, not a particular lookup. A client could ask that service for its capabilities with the protocol's servicequery. An empty server meant the local host; absent other transport knowledge, the specified default was HTTP on port 1096. These defaults helped a client begin a conversation. They did not establish that a server was reachable, trustworthy, or still operating.

The scheme's compactness was deliberate. CNRP requests had an XML representation, but embedding a complex query would make a URI unwieldy. RFC 3368 defined a smaller syntax for a common name and attribute/value pairs. It required UTF-8 encoding and percent escapes for characters outside the grammar; its example encoded ü as UTF-8 bytes. The RFC's short forms were examples, while the ABNF was the authoritative syntax.

The more consequential edge case was go://cnrp.example?id=5432345. That URI pointed to a particular record at a particular server without carrying the common name. RFC 3368's security section called out the mismatch: someone could think a link referred to the resource currently mapped to “BMW,” although the name “BMW” was not in the URI. A machine-readable identifier can be stable and still be opaque to the person asked to trust it.

RFC 3367, the companion protocol, placed service-provider discovery and selection, registration, ownership and uniqueness outside its initial scope. RFC 3368's client-configured service set therefore remained a local choice, not a global answer about who spoke for a name. Later, the IANA URI Scheme Registry listed go as Permanent with RFC 3368 as its reference. That record proves registration status, not browser support, active services, traffic or adoption.

This is the useful historical boundary: a link may identify a service, a query, or a record, but those are not interchangeable objects. Heng Lu's “Reality Layers” and “Running-Code Primacy” are disclosed editorial lenses for keeping syntax, registered design and observed operation apart; they are not protocol requirements or evidence that go: was deployed.

Sources