Zusammenfassung

  • RFC 5134 registriert die URN-Namensräume epc und epcglobal, nicht jede darin denkbare Zeichenkette.
  • Allgemeine URI- oder URN-Syntax bestätigt nur die äußere Form.
  • Die normativen Regeln eines EPC-Unterraums und ihre Version müssen gesondert angewendet werden.
  • Eine wohlgeformte Kennung kann regelkonform aussehen und dennoch nie autorisiert zugeteilt worden sein.
  • Im SGTIN-Beispiel sind führende Nullen signifikant; numerische Normalisierung kann den Namen austauschen.
  • Verifizierte Errata stellen klar, dass der namensraumspezifische Teil groß-/kleinschreibungsabhängig ist.
  • Persistenz schützt gegen administrative Wiedervergabe, nicht gegen Kopie, Verlust oder falschen physischen Träger.
  • Eine RFID-Lesung belegt eine begrenzte Beobachtung von Bits, nicht die Echtheit der Ware.
  • ONS/DDDS wählt für bestimmte epc-Unterräume Dienste aus, ohne den benannten Gegenstand zu prüfen.
  • epcglobal verlangt keinerlei Auflösung; ein fehlender Endpunkt ist dort kein Gültigkeitsfehler.
  • Signierte Metadaten und EPCIS-Ereignisse bleiben Aussagen mit eigener Autorität, Zeit und Reichweite.
  • Entscheidungen brauchen getrennte Belege für Form, Zuteilung, Beobachtung, Authentizität und physischen Ausgang.

Der Parser beantwortete nur die erste Frage

Der allgemeine Parser prüfte zulässige Zeichen, Trennzeichen und den URN-Rahmen. Das Ergebnis war korrekt: Die Zeichenkette konnte als URN verarbeitet werden. Der Importeur verwandelte diese schmale Aussage jedoch in „gültiger EPC“ und übersprang zwei weitere Instanzen.

Die zweite Instanz ist der konkrete Unterraum. RFC 5134 zeigt zwar eine ABNF für SGTIN, bezeichnet sie aber als nicht normatives Beispiel und verweist für die verbindliche Struktur auf den Tag Data Standard. Der GS1-Archivbestand macht zudem sichtbar, dass diese Regeln Versionen haben. Ein Prüfer muss deshalb sagen, welchen Unterraum und welchen Stand er angewendet hat.

Die dritte Instanz ist die Zuteilung. Selbst eine regelkonforme Kombination kann aus einem Präfix, einer Produktreferenz oder einer Seriennummer bestehen, die von der zuständigen Stelle nicht vergeben wurde. Form und Verwaltungsakt sind nicht dasselbe. Ein System, das beides in einem grünen Feld verdichtet, macht eine unbekannte Zuteilung unsichtbar.

Vier Zustände statt valid=true

Eine brauchbare Datenstruktur trennt mindestens allgemeine Syntax, Unterraumsyntax, Zuteilungsnachweis und Trägerauthentizität. Für jede Stufe hält sie Regelversion, Prüfergebnis, Beleg, Zeitpunkt und verantwortliche Stelle fest. Dann lässt sich eine formal korrekte, aber unzugeteilte Kennung präzise zurückweisen, ohne die syntaktische Beobachtung zu leugnen.

Auch nach gültiger Zuteilung bleibt die physische Frage offen. Dieselbe sichtbare Bitfolge kann kopiert, auf einen falschen Tag geschrieben oder von einem Reader außerhalb der gedachten Zone empfangen werden. Der Verwaltungsnachweis sagt, wer den Namen vergeben durfte. Er sagt nicht, welcher konkrete Träger gerade vorliegt.

Diese Trennung ist für Migrationen ebenso wichtig. „Nach heutigem TDS gültig“ und „nach der beim Commissioning geltenden Fassung gültig“ können verschiedene Fragen sein. Eine Regeländerung darf die historische Zuteilung nicht heimlich umschreiben, und ein Altbestand darf nicht die künftige Syntax definieren.

Führende Nullen sind keine Dekoration

Das SGTIN-Beispiel in RFC 5134 gliedert Firmenpräfix, Produktreferenz und Serienkomponente. Führende Nullen in aufgefüllten Komponenten sind ausdrücklich signifikant. Wer Felder als Zahlen speichert und später wieder formatiert, kann daher eine andere Identität erzeugen, obwohl der arithmetische Wert gleich erscheint.

Der erste Beleg ist eine verlustfreie Erfassung: ursprüngliche Darstellung, Eingabebytes oder -nachricht, Dekodierung, Parserfassung, erkannter Unterraum und Ausgabedarstellung. Ein Rundlauf muss die Identität nach den Regeln des Namensraums erhalten. Die Vorliebe einer Datenbank für Integer ist keine Canonicalization-Regel.

Beim Umgang mit Groß- und Kleinschreibung gilt dieselbe Disziplin. Der ursprüngliche Text von RFC 5134 formulierte zu weit. Die verifizierten Errata 1325 und 1328 beschränken die Abhängigkeit auf den namensraumspezifischen Teil. Schema und NID folgen den allgemeinen URN-Vergleichsregeln. Vollständiges Kleinschreiben kann verschiedene Namen verschmelzen; vollständiger Bytevergleich kann bloße Schreibvarianten des Rahmens verdoppeln.

Zwei Namensräume, zwei Gegenstandsklassen

Unter epc können physische Objekte oder körperliche Einheiten benannt werden. epcglobal dient logischen und softwarebezogenen Konstrukten, darunter Schema-Namensräume. Dass beide als URN erscheinen, begründet keine einheitliche Betriebssemantik.

Für epcglobal ist kein Auflösungsmechanismus vorgeschrieben oder bereitgestellt. Ein Schema-Name kann dauerhaft sinnvoll sein, ohne auf eine abrufbare Datei zu zeigen. Wer jede URN wie eine URL überwacht, meldet eine Spezifikationskonformität als Ausfall.

Umgekehrt beweist ein erreichbarer Dienst bei einem physischen EPC nicht, dass das Objekt vorhanden ist. Eine kopierte Kennung erzeugt dieselbe Anfrage; ein alter Cache kann glaubwürdige Daten liefern; eine manipulierte Delegation kann eine perfekte Produktseite zeigen. Erreichbarkeit ist eine Eigenschaft des Kommunikationswegs, keine Eigenschaft des Körpers.

Persistenz schützt eine begrenzte Invariante

Die Registrierung und Unterdelegation sollen eindeutige, dauerhafte Namen ermöglichen und eine spätere Wiedervergabe vermeiden. Das hält Referenzen trotz organisatorischer oder technischer Änderungen stabil. Es ist ein starkes Versprechen, aber kein lückenloses Eigentumsregister.

Ein Gegenstand kann seinen Besitzer oder Ort wechseln, beschädigt oder vernichtet werden, während sein Name unverändert bleibt. Ein Tag kann getrennt werden. Eine Kopie kann dieselbe Darstellung senden. Die Persistenz des Namens überlebt all diese Ereignisse gerade deshalb, weil sie sie nicht kontrolliert.

Führung scheitert, wenn sie die stärkste Eigenschaft einer Verwaltungsschicht zum Beweis aller anderen Schichten macht. Eine korrekte Zuteilung kann neben einer falschen Beobachtung bestehen. Das System muss beide Tatsachen halten können, statt eine davon an ein einziges Statusfeld anzupassen.

Beobachtung ist noch keine Authentisierung

Ein RFID-Reader kann belastbar festhalten, dass er zu einer Zeit, mit bestimmter Firmware, Antenne, Leistung und Filterung eine Antwort mit einer EPC-Darstellung gesehen hat. Dazu gehören Geräteidentität, Erfassungs- und Eingangszeit sowie die Entscheidung über Duplikate. Dieser Beleg ist operativ wertvoll.

Er authentisiert aber nicht automatisch den Träger. Taucht derselbe Wert an unvereinbaren Orten auf, kommen Kopie, Zonenüberschneidung, Nachrichtenverzug, falsche Kodierung, Uhrenfehler oder ein missverstandener Transport infrage. Der eindeutige Name entscheidet nicht, welche Erklärung stimmt.

Für Trägerauthentizität braucht es risikogerechte Zusatzbelege: kryptografische Fähigkeiten, geschützte Herstellungsdaten, kontrolliertes Commissioning, Manipulationsschutz oder Inspektion. Welche Kombination genügt, ist eine Geschäfts- und Sicherheitsentscheidung. Die Funkbeobachtung darf nicht nachträglich mehr behaupten, als ihre Messung hergab.

Dienstfindung ist keine Wirklichkeitsprüfung

Für bestimmte epc-Unterräume beschreibt RFC 5134 den Object Naming Service als Anwendung des Dynamic Delegation Discovery System. DDDS-Regeln und NAPTR-Einträge führen von einer Eingabe zu Dienstkandidaten. Der überprüfbare Satz lautet: Diese Regeln wählten zu diesem Zeitpunkt dieses Ziel.

Ein Auflösungsbeleg enthält exakte Eingabe, Äquivalenzform, angeforderten Dienst, Delegationskette, Kandidaten, Ziel, DNSSEC- oder andere Schutzlage, Cachealter, Antwortautorität und Cliententscheidung. Ein erfolgreicher Pfad sagt weder, dass die Daten aktuell sind, noch dass sie die einzelne Ware autorisiert beschreiben.

Fehler sind zu differenzieren: kein Dienst definiert, Delegation unvollständig, Validierung gescheitert, Zeitüberschreitung oder Anfrage falsch geformt. Bei epcglobal ist fehlende Auflösung überhaupt kein Fehler des Namens. Eine einzige Kategorie „not found“ vermischt Vertrag und Betriebszustand.

Metadaten benötigen eine eigene Vertrauenskette

Der Sicherheitsabschnitt von RFC 5134 benennt den Anreiz, Metadaten zu wertvollen Dingen wie Kosten oder Größe zu fälschen. Digitale Signaturen, sichere Auflösung und Vertrauensbeziehungen werden deshalb als grundlegend bezeichnet. Eine JSON-Antwort erbt nicht allein durch den Transport Autorität.

Festzuhalten sind Unterzeichner, abgedeckte Felder, gebundene Kennungsdarstellung, Gültigkeitszeitraum, Vertrauensanker und Entscheidung des Empfängers. Eine signierte Klassenbeschreibung kann korrekt sein, ohne die serialisierte Einheit zu authentisieren. Ein integer Datensatz kann veraltet sein.

Selbst perfekte Metadaten können von einem kopierten Tag referenziert werden. Die Signatur bindet eine Aussage an einen Verantwortlichen. Die Verbindung zwischen Silizium, Verpackung und Inhalt braucht einen anderen Beleg. Kryptografische Integrität und physische Echtheit dürfen nicht denselben Schalter teilen.

EPCIS erhält Ereignisaussagen

Die aktuelle GS1-Architektur trennt die Kennung von Sichtbarkeitsereignissen. EPCIS teilt Aussagen darüber, was, wo, wann, warum und wie beobachtet oder bearbeitet wurde. Das Ereignis hat eine Quelle und einen Kontext; es ist keine kontinuierliche Weltbeobachtung.

Ein belastbarer Datensatz hält Ereignis- und Erfassungszeit, Lesepunkt, Geschäftsort, Prozessschritt, Zustand, Quellsystem und verantwortliche Partei fest. Korrekturen, späte Eingänge und Duplikate bleiben nachvollziehbar. Ein Ortsfeld ist eine Prozessbehauptung, nicht der Ort selbst.

Eine Verwahrkette entsteht aus solchen begrenzten Ereignissen, Übergabebelegen und erforderlichen Sachprüfungen. Lücken bleiben sichtbar. Dass dieselbe Serienkennung vor und nach einer Lücke auftaucht, erlaubt keine automatische Erzählung darüber, was dazwischen physisch geschah.

Eine Belegleiter für Entscheidungen

Die Leiter beginnt mit Namespace-Registrierung, Syntax, lexikalischer Treue und Zuteilung. Es folgen Beobachtung, Trägerauthentizität, Dienstfindung, autorisierte Metadaten, Geschäftsereignis und physischer Ausgang. Jede Stufe besitzt einen eigenen Produzenten und kann ausfallen, ohne frühere Stufen zu zerstören.

So kann eine korrekt zugeteilte Kennung keinen Dienst haben. Ein Dienst kann alte Daten liefern. Signierte Daten können zu einer Kopie passen. Ein echter Tag kann durch eine Ereignislücke reisen. Eine vollständige digitale Spur kann vor der tatsächlichen Übergabe enden. Das Modell muss diese Kombinationen ausdrücken können.

Für den Importfall lautet die Konsequenz: Die syntaktische Annahme wird gespeichert, die fehlende Zuteilung aber blockiert die Behauptung autorisierter Identität. Das ist genauer als vollständiges Verwerfen und sicherer als unbedingte Freigabe.

Quellen