Zusammenfassung

  • RFC 3937 registrierte urn:iptc und gliederte den Namensraum in std, std-draft und workdoc; die Hierarchie kodierte den jeweiligen institutionellen Status.
  • IPTC sagte dauerhaften Zugang zu, doch ein URL-Resolver sollte erst entwickelt werden. Auch die Prüfung, ob ein Name tatsächlich vergeben war, blieb diesem künftigen Dienst überlassen.

Drei Zweige waren drei Aussagen

Wer in RFC 3937 nur einen neuen Präfix liest, übersieht die wichtigste Konstruktion. std war für Ressourcen bestimmt, die einen verabschiedeten IPTC-Standard festlegten oder erläuterten. std-draft nahm entsprechende Materialien vor der formellen Verabschiedung auf. workdoc bezeichnete Dokumente aus der Arbeit des IPTC, die nicht unmittelbar zu einem verabschiedeten Standard gehörten.

Der Name transportierte damit eine Governance-Aussage. Ein Entwurf war nicht bloß eine ältere Datei eines Standards, und ein Arbeitsdokument war nicht automatisch ein Standardentwurf. Der IPTC Managing Director sollte die Eindeutigkeit sichern; nur der Namensrauminhaber und seine Bevollmächtigten durften Namen vergeben. Die korrekte Zeichenfolge reichte nicht aus. Gültigkeit verlangte einen nachvollziehbaren Vergabeakt.

Der RFC-Editor-Eintrag führt das Memo als Informational. Im Errata-Verzeichnis lassen sich spätere Korrekturen prüfen. IANA listet iptc im Register der URN Namespaces. Diese Quellen belegen die Registrierung der Wurzel und die maßgebliche Beschreibung. Sie sind weder das vollständige Vergabebuch aller untergeordneten Namen noch Betriebsnachweise eines Resolvers.

Registrierung war nur eine Schicht

Die URN-Architektur hatte diese Beweise schon zuvor getrennt. RFC 1737 formulierte funktionale Anforderungen an beständige Namen. RFC 2141 beschrieb ihre Syntax. RFC 2276 behandelte Auflösung als Architekturproblem, während RFC 3401 das Dynamic Delegation Discovery System für bestimmte Auflösungsanwendungen erläuterte. RFC 3406 lieferte das Verfahren zur Definition eines formalen Namensraums, dem RFC 3937 folgte. Syntax, globale Registrierung, lokale Vergabe und operative Auflösung waren benachbart, aber nicht identisch.

IANA registrierte iptc; sie billigte nicht jeden String darunter. Das zentralisierte Modell konnte Kollisionen vermeiden, schuf aber eine dauerhafte Abhängigkeit von den Unterlagen und Nachfolgeregeln des IPTC. Ging das Vergabebuch verloren, ließ sich aus dem Namen allein nicht rekonstruieren, ob die Organisation ihn wirklich ausgegeben hatte.

RFC 3085 hatte bereits einen URN-Namensraum für NewsML-Ressourcen eingerichtet. RFC 3937 begründete den größeren Rahmen mit weiteren IPTC-Standards, öffentlich nutzbaren Dokumenten, DTDs, XML-Schemata, Stylesheets, PDF- und Office-Dateien. Der breitere Geltungsbereich bewies jedoch weder eine vollständige Migration der NewsML-Namen noch die Ablösung aller früheren Kennungen.

Die Beispiele für NewsML-DTD, NITF-Entwurfsschema, SportsML-XML-Namensraum, Leitfäden und Arbeitsdokumente waren ausdrücklich nur repräsentativ und mussten keine realen Ressourcen bezeichnen. Aus einem im RFC gedruckten Beispiel wurde kein Eintrag im Vergaberegister.

Status konnte wechseln, der Name aber auch absichtlich beweglich sein

In std und std-draft konnte ein expliziter Versionswert eine bestimmte Ausgabe bezeichnen. Daneben erlaubte RFC 3937 current. Ein Name mit diesem Wert konnte als Zeichenfolge unverändert bleiben, während sein Ziel mit der jeweils aktuellen Standardversion wechselte. Für Reproduzierbarkeit war eine feste Version nötig; für den laufenden Zugriff auf das Neueste war der bewegliche Alias nützlich.

Diese Semantik durfte nicht mit dem Übergang von std-draft nach std verwechselt werden. Ein verabschiedeter Standard brauchte einen anderen Governance-Zustand; ein current-Alias innerhalb eines Zweigs beantwortete die Frage nach der gegenwärtigen Version. Wer nur URLs oder Dateinamen speicherte, konnte beide Veränderungen unsichtbar machen.

Eine spätere Spezifikation des IPTC Core XMP Schema trägt einen konkreten Dokument-URN aus der Familie urn:iptc:std:.... Das belegt eine spätere reale Nutzung, aber keinen vollständigen Bestand und keinen ununterbrochenen Resolverbetrieb. Das heutige IPTC-Dokument zu einem externen Namensraum ist gegenwärtig im Web erreichbar; daraus folgt nicht, dass jede frühere Repräsentation dauerhaft erreichbar war.

Die Betriebszusage stand im Futur

IPTC verpflichtete sich laut RFC 3937, Zugänglichkeit und Beständigkeit aller durch seine URNs identifizierten Ressourcen zu erhalten. Zugleich kündigte es an, einen geeigneten Mechanismus zu entwickeln, der alle vergebenen URNs für die Webauflösung auf URLs abbildet. Unter Validierung wurde kein eigenes Verfahren beschrieben; auch die Aussage, ob ein URN gültig sei, sollte der künftige Resolver liefern.

Damit war 2004 die Governance festgeschrieben, nicht der vollständige Dienst nachgewiesen. Der URN identifiziert, der Resolver bildet ab, die URL lokalisiert, der Server liefert eine Repräsentation, und die Validierung prüft den autorisierten Vergabeakt. Ein gültiger Name kann vorübergehend unauflösbar sein. Ein Resolver kann eine tote URL liefern. Eine erreichbare URL kann die falsche Version enthalten. Ein wohlgeformter, aber erfundener Name kann den Parser passieren.

RFC 8141 aktualisierte später allgemeine URN-Syntax und -Semantik. Er erklärt den späteren Rahmen, aber nicht den Betriebszustand des IPTC-Dienstes im Jahr 2004. Heng Lus Überlegungen zur minimalen Anfangsspezifikation und späteren freiwilligen Übernahme sowie zum Vorrang laufenden Codes verlangen genau diese Trennung: Veröffentlichung, Vergabe, Implementierung, Einsatz und Nutzung brauchen eigene Belege.

Die historische Leistung von RFC 3937 lag in einem belastbaren Ordnungs- und Verantwortungsmodell. Die Beständigkeit selbst entstand erst, wenn Institution, Resolver, Archiv und Hosting ihre verschiedenen Pflichten fortlaufend erfüllten. Die drei Zweige konnten den Status benennen; sie konnten ihn nicht ohne Betriebsbelege garantieren.