Summary

  • RFC 3367 standardized a minimal protocol for querying common-name services, describing capabilities, carrying results and referrals, and preserving service and dataset provenance.
  • It deliberately left discovery, provider selection, registration, ownership and uniqueness outside scope. The protocol could make answers interoperable without deciding which service had authority to answer.

In the late 1990s, the browser address field was becoming more than a place to type a URL. People entered company names, book titles and ordinary phrases. Browsers and portals could interpret that input as navigation or search, but their back-end services had no shared way to exchange a focused name query.

RFC 3367 addressed that interface. The Common Name Resolution Protocol, or CNRP, gave clients a common XML request-and-response language for services that associated human phrases with Internet resources. It was published on the standards track in 2002. Its ambition was both narrower and more revealing than a new global naming system.

A common name, in the protocol's terms, was a word or phrase without imposed syntactic structure. It might be a company name, a trade name, a person's name or a book title. Unlike a URI, it did not carry a standardized structure. Unlike a URN, its association with a resource did not have to be unique or persistent.

That difference was not a drafting omission. RFC 3367 expected more than one resolution service to exist and allowed any common name to be used in any service. One service might specialize in organizations, another in books, and a portal might aggregate several. The same phrase could therefore be associated with different records in different datasets.

CNRP standardized what happened after a client had somewhere to ask. A client could request a service description, learn the properties a service understood, send a query and receive a result set. Results could include resource descriptors, status messages and referrals. Service objects described datasets and servers. A proxy aggregating several services could preserve which service and dataset had produced each item.

The common core was deliberately small. All conforming services understood core properties such as the common name, a service-local identifier, a resource URI and a description. Additional properties could describe language, geography or category. Services could publish their schemas so clients did not have to pretend that every provider organized information the same way.

That extensibility carried a precise limit. Query properties could operate as hints. A user might prefer one language or geography, yet a service was not required to interpret every hint in the same way. RFC 3367 called the degree of responsiveness a service differentiator. A correctly encoded query could be accepted even when some properties were ignored, and a partial-success status could disclose that difference.

This was not SQL over the open Internet. A query did not promise that every returned item satisfied every qualifier. It asked a service for results closest to its selection criteria. The protocol standardized the container and some semantics while leaving ranking, coverage and much classification behavior with the service.

The earlier context document, RFC 2972, made the institutional boundary unusually explicit. Service discovery and selection, service administration, name registration, name ownership, and methods for creating or ensuring unique names were outside the initial protocol scope. CNRP could connect a client and provider once that provider had been selected. It did not choose the provider.

The boundary matters because selection is where authority entered. If one browser was configured to ask a commercial directory and another to ask a regional public service, both could send the same conforming request and receive different valid bindings. The protocol could preserve their origins. It could not pronounce one dataset globally authoritative.

RFC 2972 distinguished private namespaces, where an authority controlled assignment, from public namespaces such as personal names, place names or titles, where ambiguity was inherent. It anticipated multiple taxonomies and even acknowledged that free-form category keywords might not guarantee full interoperability across services. Standardizing the query did not standardize the world being queried.

RFC 3368 exposed the same boundary through the go: URI scheme. One form could identify a particular server. Another could express a common-name query without naming a server, to be sent to one or more services configured by the client. The URI carried the question. Client configuration still supplied the answering institutions.

That is a more consequential design than it first appears. A serverless go: URI could be identical on two machines while resolving differently because their service lists differed. A copyable identifier did not necessarily carry a copyable authority choice. Resolution was partly in the string and partly in local configuration.

The transport bootstrap was more concrete. Generic clients and servers had to support HTTP on port 1096 for initial contact. Specialized applications could define another server, port or transport. Once contacted, a service description could advertise alternatives. This solved the mechanical problem of beginning an exchange with a known service; it did not solve how the client came to trust or prefer that service.

Referrals extended the authority graph. A service could return some results and tell the client that another service might have more. The client, rather than the server, could follow the referral. CNRP therefore specified service and dataset references and described loop detection. A client had to remember which service-and-dataset pairs it had visited, not merely which hostname it had contacted.

Partial success was a first-class result. A service could report that unsupported properties were ignored, that only one requested dataset was used, or that a referral server was unavailable. This made incompleteness visible. It did not make every client equally good at presenting the limits to a human.

Security exposed the same dependency one level deeper. RFC 3367 identified man-in-the-middle attacks, spoofed Service objects and denial of service created by another level of indirection. A Service object could be signed, but verification required an authoritative public key. How the client obtained that key was declared out of scope because it depended on the service-discovery problem.

The signature could protect a statement after the trust anchor was chosen. It could not choose the trust anchor. This is the protocol's central historical lesson in compact form: cryptographic validity and institutional authority meet, but they are not the same operation.

The current IANA URI-schemes registry lists go as a Permanent scheme and cites RFC 3368. RFC 3367 remains a Proposed Standard. Those are durable registry and standards facts. They do not measure how many browsers implemented the scheme, how many CNRP services ran, how much traffic they handled or whether anyone relies on them now.

The absence of a deployment census prevents an easy rise-and-fall story. RFC 2972 anticipated integration by portals and browser vendors, but anticipation is not adoption. Likewise, a registered scheme is not a browser capability receipt. Historical accuracy requires keeping proposal, registry custody, implementation, configuration, live service and user outcome apart.

Neighboring URI and URN work helps locate CNRP without collapsing it into those systems. RFC 2396 described generic URI syntax; RFC 3986 later updated that foundation. RFC 2276 and RFC 2483 discussed resolution and resolution services around URNs. RFC 3401 described the later Dynamic Delegation Discovery System family. These documents show a period intensely concerned with translating human or persistent identifiers into actionable resources. They do not prove that one mechanism replaced another in a specific deployment.

Two Lu Heng essays provide the disclosed analytical lens. “Minimum Initial Specification” argues for a small deterministic common layer and local decisions after that point. CNRP is almost a literal case: its interoperable core standardized exchange while leaving selection, ownership and future service behavior outside. “On Reality Layers” prevents a valid protocol response from being mistaken for the user's intended reality. Protocol conformance, service identity, dataset provenance, returned binding and successful destination are distinct layers.

The architecture was honest about plural answers. It preserved service origin instead of hiding aggregation behind a single undifferentiated list. It treated hints as best effort and partial results as reportable states. It placed loop detection on referral traversal. These are not the properties of a design that secretly assumed one universal directory.

But the honesty did not remove power. Whoever configured the service list influenced which datasets could answer, which categories were understood, which referrals were followed and which resources appeared. A neutral wire format can lower integration costs while leaving distribution and selection power elsewhere.

RFC 3367 therefore marks a useful boundary in Internet history. The question could be standardized: here is the phrase, context and result shape. The answerer could not be standardized without making a different governance decision. CNRP stopped at that line and made enough provenance visible for clients to know there was a line.

Sources