Zusammenfassung

  • RFC 1865 ersetzte die Übertragungskomponenten zwischen vorhandenen EDI-Systemen durch Internet-Mail. Die als sicher bezeichnete direkte SMTP-Zustellung endete am Partnersystem und ließ das bilaterale Handelsabkommen bestehen.
  • RFC 1767 verpackte X12-, EDIFACT- und EDI-consent-Objekte in MIME, ohne deren Syntax oder Semantik zu ändern und ohne selbst Sicherheit bereitzustellen.
  • RFC 3335 und RFC 4130 verbanden Message-ID, MIC, Signatur und MDN. Eine signierte Bestätigung konnte dennoch einen Verarbeitungsfehler melden; die Gültigkeit der Transaktion blieb Sache der Partner.

Angekommen war zunächst nur die Bestellung als Nachricht

Ein Lieferant sendet eine elektronische Bestellung. Der empfangende SMTP-Server antwortet positiv und speichert die Daten. Noch ist offen, ob der richtige Partner erkannt wurde, die Signatur gilt, die Nachricht kein Duplikat ist, der EDI-Übersetzer sie versteht und Preis sowie Termin akzeptabel sind.

Der RFC 1865 erschien im Januar 1996 als Informational FAQ für eine EDI-Gemeinschaft, die das Internet kennenlernte. Er wollte Geschäftsprogramme und EDI-Übersetzer nicht ersetzen. Internetmodule sollten den Kommunikationsabschnitt übernehmen.

Bei einer dedizierten SMTP-Verbindung, so der Text, gelange die Information direkt zum Partnersystem und die Zustellung sei gesichert. Bei Store-and-forward hänge die Integrität von den Zwischensystemen ab. Diese Abgrenzung beschreibt einen Übertragungsweg. Sie belegt weder erfolgreiche Verarbeitung noch Zustimmung zu einer geschäftlichen Verpflichtung.

Standardisierte Geschäftsdaten waren noch kein Geschäftsergebnis

RFC 1865 definierte EDI als Anwendung-zu-Anwendung-Kommunikation standardisierter Geschäftsinformation. Elektronischer Handel war weiter gefasst und konnte menschliche Kommunikation, Geldtransfer und gemeinsam genutzte Informationsbestände einschließen. Die EDI-Nachricht war daher ein Baustein, nicht der gesamte Abschluss.

Auch bilaterale Trading-Partner-Abkommen blieben erhalten. Internetadressen konnten proprietäre Postfachnamen ersetzen, doch Identität, Fristen, Duplikatregeln, Wirkung und Rechtsbehelf mussten weiter vereinbart werden. RFC 1767 erlaubte EDI-consent ausdrücklich nur aufgrund einer bilateralen Vereinbarung.

Offener Transport bedeutete somit nicht offene Vertretungsmacht. Ein Value-added Network konnte als zwingender Mittler an Bedeutung verlieren; niemand erhielt dadurch automatisch das Recht, ein Unternehmen zu binden.

MIME ersetzte den mittleren Abschnitt

RFC 1767 definierte MIME-Typen für EDI-X12, EDIFACT und EDI-consent. Auf der Sendeseite führte der Weg vom Geschäftsprogramm über den EDI-Übersetzer und MIME zur Maileinlieferung und zu SMTP. Beim Empfänger musste die Verpackung entfernt und der Inhalt übersetzt werden, bevor die Geschäftsanwendung ihn verarbeitete.

Der RFC änderte weder die EDI-Syntax noch ihre Semantik und brachte allein keine Sicherheitsfunktion. MIME sagte, welcher Objekttyp transportiert werden sollte. Es bestätigte nicht Inhalt, Ursprung, Unverändertheit, Berechtigung oder Annahme.

Gerade erfolgreiche Interoperabilität lädt zu einer Übertreibung ein: Wenn zwei bisher getrennte Systeme ein Objekt austauschen können, wirkt der gesamte Vorgang gelöst. Die Prozessfolge des RFC bewahrt die noch ausstehenden Arbeiten vor und nach dem Transport.

Der stärkste Beleg durfte negativ sein

RFC 3335 beschrieb Signatur, Verschlüsselung und signierte MDN. Die ursprüngliche Message-ID ordnete Antwort und Sendung einander zu. Der zurückgegebene MIC stand für den empfangenen Inhalt. Die Empfängersignatur machte die Aussage unter Schlüssel- und Zertifikatsregeln zurechenbar. Der Sender musste die Bestätigung anschließend prüfen.

Selbst die Nichtabstreitbarkeit des Empfangs wurde als rechtliches Ereignis erst nach dieser Prüfung beschrieben. Eine gültige Signatur beweist nicht automatisch die geschäftliche Vollmacht des Schlüsselinhabers.

RFC 4130 machte die Grenze besonders deutlich: War eine signierte Bestätigung vereinbart, sollte sie auch bei fehlgeschlagener Inhaltsverarbeitung zurückkommen. Die Disposition trug den Fehler. Der Beleg war gerade deshalb nützlich, weil er einen negativen Zustand sicher festhalten konnte.

Blieb eine erforderliche signierte Bestätigung aus, mussten die Partner die Gültigkeit der Transaktion klären; wahrscheinlich galt sie nicht als gültig. Der Transport unterstützte Beweisanforderungen, definierte Nichtabstreitbarkeit aber nicht selbst, weil diese eine geschäftliche oder rechtliche Anforderung war.

Angezeigt war nicht verstanden

RFC 3798 erlaubte dem Empfänger, eine MDN-Anforderung zu ignorieren. Außerdem garantierte displayed weder Lesen noch Verstehen. Diese Zurückhaltung ist auch für automatisierte Abläufe entscheidend.

SMTP-Annahme ist keine Anwendungsverarbeitung. MDN ist keine erfolgreiche EDI-Übersetzung. Signatur ist keine Handelsvollmacht. Funktionale Bestätigung ist nicht zwingend Vertragsannahme. Jeder Übergang verlangt einen eigenen Akteur und einen nachvollziehbaren Beleg.

Eine ehrliche Akte hält deshalb das genaue Ausgangsobjekt, die Mailannahme oder -zustellung, korrelierte MDN und MIC, Übersetzungsergebnis, Anwendungsbestätigung und autorisierte Geschäftsentscheidung getrennt. Die Zahl der Dokumente darf variieren; die Zuständigkeiten dürfen es nicht unbemerkt.

Verteilter Transport, vereinbarte Verantwortung

RFC 1865 nannte verteilte Verzeichnisse, kooperatives Routing und Adressauflösung sowie redundante Provider und Mailserver. EDI-Aktivität sollte keinen zentralen Internetkoordinator benötigen. Das machte die Transportfunktion austauschbarer.

Die Partner bestimmten weiterhin Adressen, Zertifikate, Empfangsfristen, Wiederholungen, Aufbewahrung und Streitlösung. Dezentralisiert wurde der Weg, nicht die Haftung.

Die offiziellen Quellen belegen keine benannte Installation, angenommene Bestellung, Zahlung oder Gerichtsentscheidung. Sie belegen eine engere Entwicklung: MIME transportierte, Signaturen und MICs verbesserten die Beweisführung, und die kommerzielle Entscheidung blieb außerhalb des Mailservers.

Quellen