Summary

  • RFC 3043 proposed urn:pin as a persistent namespace for identifying people and organizations across applications.
  • Its identifiers were opaque outside Network Solutions’ internal resolver, and the document treated that company’s resolvers as authoritative. Global syntax did not make resolution authority equally portable.

The question was not simply how to give a person a durable label. It was how a label could remain useful when email addresses, surnames, employers, service providers, and even the systems that first assigned it changed. Network Solutions’ January 2001 proposal, RFC 3043, framed this as a problem for directory services and electronic commerce: separate two records even when their descriptive data overlap, and keep referring to the same person or organization over time.

The proposed answer was the Personal Internet Name, or PIN, expressed as a Uniform Resource Name under the pin namespace. The RFC’s examples look like compact tokens—urn:pin:bs4321234—rather than names that expose a person’s surname or organization. The namespace’s “name specific string” (NSS) was declared flat and alphanumeric. More importantly, the document said its internal structure could not be known outside Network Solutions’ resolver and must not be inferred or relied upon externally. The opacity was a design boundary, not an invitation to reverse-engineer the string.

That separation offered a real benefit. Applications could carry a stable reference without embedding a mutable email address or depending on one directory’s local record key. In the RFC’s intended model, identifiers were not reassigned, and the association with the named person or organization was described as permanent through name changes, corporate restructuring, death, or dissolution. RFC 3043 also invoked standardized URN resolution as a way for other applications to reference PINs in an open, non-proprietary fashion.

Yet the registration template drew a second boundary around who could say what a PIN meant. Network Solutions assigned identifiers through a proprietary registration system. It described uniqueness as a guarantee of that system; the then-current algorithm began from the last assigned number and advanced by a positive integer, while leaving room for a future change. The RFC named Network Solutions’ own URN resolvers as the means of resolution. It warned that resolution through another provider would be error-prone and not authoritative.

This is the portability paradox. The token could be copied into an application outside the original directory, but an external application could not independently infer its structure or claim an authoritative binding merely by parsing it. Portability of reference and portability of authority were different properties. The format crossed organizational boundaries more easily than the power to certify the person or organization behind it.

The distinction is not unique to pin. A namespace can make references globally distinguishable while leaving assignment, correction, resolution, and disputes dependent on a steward. That may be a reasonable trade: opacity protects internal flexibility, a single assigner can coordinate uniqueness, and one resolver offers a clear point of authority. But those choices place continuity risk somewhere specific. If identity claims must outlive the service or organization that resolves them, the namespace needs an explicit answer for resolver succession, record export, contested identity, and verification when the designated resolver is unavailable. RFC 3043’s text describes assignment and resolution; it does not establish that those continuity mechanisms existed.

The status of the document also needs precision. The IETF Datatracker today labels RFC 3043 a Legacy, Informational RFC with no formal standing in the IETF standards process. Separately, IANA’s current URN namespace registry still lists pin in its formal namespace table with RFC 3043 as the reference. These are different records answering different questions: the RFC’s standards-stream standing is not the same as whether the namespace appears in IANA’s registry. Neither entry, by itself, proves current service operation or present-day use.

The historical lesson is narrower than “central resolvers are bad.” Stable identifiers solve one failure mode—references that break when descriptions or locations change. They do not automatically solve another: dependence on the institution that assigns or authoritatively resolves them. RFC 3043 made that division unusually visible in its own template. A persistent name can travel farther than its trust anchor. Any system promising both durability and openness has to specify not only how names are formed, but who can verify their binding, how authority can move, and what survives when the original resolver does not.