Summary

  • RFC 3367 made language, geography and category available as shared query properties, but called them hints rather than compulsory filters.
  • The protocol aligned the question's structure while leaving matching, ranking and the practical meaning of relevance with each service.

A name was not a unique answer

Common names are ordinary words and phrases, not globally unique identifiers. “Mercury” can name a planet, a company, a person or a product; even within one service, a name can lead to several records. RFC 3367 therefore addressed a limited problem: how a client could query services for records associated with a common name. It did not define how to discover or select services, register a name, establish ownership, or guarantee uniqueness. That boundary matters: CNRP was a query protocol, not a naming authority.

A shared vocabulary, not a shared verdict

The protocol gave clients more than a bare string. Core properties included the common name, language, geography, category and range. A client could first send a ServiceQuery to learn which properties a service supported; a service could also expose additional data types. This made capability negotiation part of the exchange, rather than assuming every database understood the same fields.

But RFC 3367 deliberately stopped short of turning those fields into universal tests. It described them as hints: context and preference supplied by the client. Their order could signal priority, yet the service could ignore them and was expected to attempt a best match. Different properties combine logically with AND; multiple values for one property combine with OR. Still, the response need not satisfy every requested value. “French” and “Paris” could guide a search without excluding all other results.

That distinction makes the protocol's most consequential choice easy to miss. The wire format could be interoperable while its answers remained service-specific. One provider might treat language as decisive; another might regard it as a weak signal. RFC 3367 specified no common weighting formula and no universal tie-breaker.

Encoding did not settle meaning

UTF-8 let clients and services exchange text, while language tags supplied a structured way to identify languages. Neither mechanism settled whether two spellings, scripts, transliterations or names were equivalent. RFC 3367 left common-name matching rules dependent on the service and language. Character encoding can preserve a string; it cannot decide what that string refers to.

The same locality applied to ranking. Within a service, results could be ordered by that service's relevance judgment. Results from separate services could not be merged into one objectively comparable list merely because they spoke CNRP. RFC 3368's companion go: URI scheme could point to a specific service or record, or carry a broader query, but it did not erase this division of responsibility.

Where interoperability ended

RFC 3367 standardized the syntax of preference, the capability conversation and the broad logic for combining fields. It left semantic equivalence and the final ordering to service operators. That is not a defect hidden in the fine print; it is the protocol's design boundary. A common request vocabulary can make systems communicate without making their judgments identical.

Read through Lu Heng's Running-Code Primacy lens, the distinction is useful but bounded: a specification can describe what implementations may exchange, while the behavior users encounter depends on what services actually implement. The RFC documents a design, not evidence of adoption or commercial impact. Its lasting historical interest here is narrower: it made preference portable while keeping relevance local.

Sources