Summary

  • RFC 3937 registered urn:iptc and centralized assignment under IPTC, with distinct branches for approved standards, drafts and working documents.
  • IPTC committed to persistence and accessibility, yet the RFC said a URL resolver would be developed later and specified no separate validation mechanism. A durable name did not itself create access.

The registry came first

In October 2004, RFC 3937 asked for the formal Namespace Identifier iptc. The International Press Telecommunications Council needed stable names for DTDs, XML schemas, XML namespaces, stylesheets, PDFs, office documents and other materials used by the news industry. Files could move. Web locations could change. An identifier intended to survive those changes could not simply be another current URL.

The RFC Editor record classifies the memo as Informational. Its errata record is the surface for checking later corrections. The IANA URN Namespaces registry currently lists iptc with RFC 3937. Those facts establish a registered namespace and its documentary authority. They do not establish that every descendant string was assigned, that every resource remained available, or that a resolver was operating in 2004.

That separation was already part of URN architecture. RFC 1737 described functional requirements for persistent names. RFC 2141 specified URN syntax. RFC 2276 treated resolution as an architectural problem, while RFC 3401 described the Dynamic Delegation Discovery System used by some resolution applications. RFC 3406 supplied the namespace-definition mechanism that RFC 3937 followed. Syntax, registration and resolution were adjacent layers, not synonyms.

One owner controlled uniqueness

RFC 3937 divided the Namespace Specific String into three top-level branches. std held resources specifying or explaining an approved IPTC standard. std-draft held analogous resources before formal approval. workdoc held documents related to IPTC's work but not directly to an approved standard.

The hierarchy encoded control. The IPTC Managing Director would enforce uniqueness, and assignment was limited to the namespace owner and its authorities. IANA registered iptc; it did not approve every urn:iptc:... beneath it. A syntactically well-formed string was therefore not sufficient evidence that IPTC had assigned it.

This was a centralized institutional ledger. Its strength was collision control: one authority could prevent two resources receiving the same name. Its dependency was equally clear. Uniqueness and provenance relied on the continuity, records and procedures of IPTC. The namespace registration did not cryptographically bind a descendant URN to an assignment event.

RFC 3085 had already created a URN namespace for NewsML resources. RFC 3937 explained that IPTC needed a broader hierarchy for standards beyond NewsML and for documents used outside its membership. The new namespace expanded scope. It did not, by itself, prove that every older NewsML name migrated or that one registry replaced every earlier identifier.

current was stable as a name and movable as a target

The std and std-draft branches included a standard name and standard version. For an explicit version, the path could identify a particular edition and, optionally, a particular resource version. But RFC 3937 also allowed the value current to point to resources for the current version of a standard.

That word exposes two kinds of persistence. The string containing current can remain unchanged while the version it denotes changes. It is a persistent alias, not an immutable edition. A consumer requiring reproducibility needs the explicit version. A consumer wanting the latest approved material may prefer the moving alias. Both names can be legitimate, but they answer different questions.

The examples made this hierarchy concrete: a NewsML DTD, a draft NITF XML schema, a SportsML XML namespace, supporting guidelines and a working document. RFC 3937 warned that the examples were representative and might not refer to actual resources. Copying an example into a database is not evidence that an assignment exists.

A later IPTC Core XMP Schema specification carried an explicit urn:iptc:std:... document URN. That is primary evidence of at least one concrete later use. It is not a census of the namespace, a resolver test or proof of uninterrupted access since publication. An IPTC namespace document shows a current web representation for another IPTC namespace surface; current reachability cannot be projected backward into a continuous history.

Persistence was a commitment; resolution was future work

RFC 3937 said IPTC was committed to maintaining the accessibility and persistence of all resources identified by IPTC URNs. It then stated that IPTC would develop an appropriate mechanism mapping all assigned URNs to URLs for web resolution. Under validation, it said no mechanism was specified; the future resolver would also show whether a URN was valid.

The future tense is the center of the history. The organization registered the authority and promised stewardship before the access mechanism was present in the specification. That ordering is not necessarily a defect. A namespace can be assigned before a resolver is deployed, and a persistent name can be useful inside documents and systems that already know how to interpret it. But the claims must remain bounded.

The URN identifies. A resolver maps. A URL locates. A server supplies a representation. A validation process answers whether the assigning authority actually issued the name. Failure at one stage does not erase every other stage. A valid URN can be temporarily unresolvable. A resolver can return a dead URL. A reachable URL can serve the wrong version. A well-formed but unassigned string can pass a syntax parser.

RFC 8141 later updated general URN syntax and semantics. It helps explain the modern framework, but it cannot serve as evidence that RFC 3937's promised resolver existed in 2004 or that later operational behavior was continuous.

The essays by Heng Lu on minimum initial specification and later voluntary adoption and running-code primacy provide an editorial discipline for this record. Publication, assignment, implementation, deployment and use are separate events. RFC 3937 established a durable naming commitment and governance surface. Only resolver logs, registry exports, archive checks and resource retrievals could prove the later stages.

The sharpest lesson is not that URNs failed because a resolver was deferred. It is that persistence never belonged to a string alone. It depended on an institution preserving assignments, an operational service maintaining mappings, repositories retaining versions and clients asking whether they wanted a fixed edition or whatever current meant that day. The name could promise continuity. Fulfilling it required systems the registration did not yet contain.