Summary

  • RFC 3650’s global namespace was federated: a unique naming authority plus a unique local name made a Handle unique within the system, while local namespaces could retain their names and value bindings.
  • The Global Handle Registry primarily supplied naming-authority and service information for finding a “home” Handle service; Local Handle Services normally resolved handles beneath those authorities.

A global name did not mean one global store

The architectural question in RFC 3650 was not simply how to spell a persistent identifier. It was how separate naming and administrative domains could share a namespace without requiring one operator to own every resource record. The document’s answer was a split between names, authority and service discovery.

A Handle combines a naming authority—also called its prefix—with a local name or suffix. The naming authority is unique in the Handle System, and the local name must be unique under it. Together they produce a globally unique Handle within that system. An existing local namespace could join by acquiring an authority while keeping its local names and value bindings. “Global,” then, described the shared uniqueness context, not a single administrative database. RFC 3650

The service architecture followed that distinction. RFC 3650 placed the Global Handle Registry (GHR) at the top and Local Handle Services (LHSs) below it. An authority’s Handle carried service information: sites and server interfaces that told a client how to reach the authority’s home service. A client first queried the GHR for that information, then contacted the responsible service for the requested Handle. The registry acted as a directory for service responsibility; it was not, by definition, the only place where all local values had to be stored. RFC 3650 · RFC 3651

That distinction also explains why “local” did not mean one nearby machine. The RFC used the term for namespace and administrative responsibility. A Local Handle Service could have multiple sites across the Internet, and each site could contain several servers. The design allowed replicated service sites, but that is an architectural option, not evidence that a particular deployment had any measured availability or fault tolerance.

Registration hierarchy was not a chain of command

Naming authorities could be arranged as a tree. A parent had to be registered before it could register a child, but the RFC explicitly separated this registration order from administrative power: parent and child namespaces could be served by different services and might share no administration privileges. The visual hierarchy did not itself establish who could change a child’s Handles, resolve disputes, or guarantee continued operation. RFC 3650

Nor was the GHR an absolute exception-free directory. RFC 3650 says it can manage any Handle namespace, and RFC 3651 allows it to manage and provide resolution or administration for non-naming-authority Handles. The useful claim is narrower: the GHR’s distinctive role was managing naming-authority Handles and their service information, while local services normally carried responsibility for the namespaces assigned to them. RFC 3651

The value behind a Handle could change while the Handle stayed the same, allowing a resource’s location or associated information to be updated without changing its identifier. But RFC 3650 does not turn persistence into a syntactic guarantee: it says persistence depends on administrative care. A stable string cannot compel an institution to maintain its records, preserve a resolver, or keep a destination available. RFC 3650

Related to identifiers, not interchangeable with them

The RFC appeared beside familiar Internet naming systems but did not erase their distinctions. DNS organizes names and resolution around its own delegated zone architecture. URN work specifies requirements and namespace mechanisms for names intended to identify resources independently of location; separate resolution architecture asks how a resolver finds services. A Handle can be used in applications that need persistent names or resolution, but it is not automatically a URN, and a Handle response does not establish that the resource is reachable. RFC 1034 · RFC 1737 · RFC 2276 · RFC 3406 · RFC 8141

Its publication status matters too. RFC 3650 is Informational, not an Internet Standard. The IESG note says IETF and IRTF groups had discussed the system but had not reached IETF consensus on the described architecture or its place in the IETF identifier architecture. That note is neither an endorsement nor a rejection; it marks the boundary between a published architectural proposal and IETF consensus. RFC 3650

The historical contribution was therefore a particular distribution of functions: a root registry mapped authorities to services, while independently administered services could hold and resolve local namespaces. Its promise depended on the records, operators and service paths behind that map continuing to work. The RFC specified how the boundaries could fit together; it did not prove universal resolution, permanence, adoption at scale or successful access to any named resource.

Sources: RFC 3650; RFC 3651; RFC 3652; RFC 1737; RFC 2276; RFC 3406; RFC 8141; RFC 3986; RFC 1034.