Zusammenfassung

  • RFC 2122 definierte eine URL für einen interaktiven Multimediadienst, nicht für ein Datenobjekt; der VEMMI-Client hielt gewöhnlich eine TCP-Sitzung auf Port 575 offen.
  • Dienst und benannte Parameter konnten in der URL stehen, Benutzername und Passwort nicht. Browser-Unterstützung, Authentisierung und VEMMI_Open waren spätere Schritte.
  • application/vemmi diente dem getrennten Objekttransport. Operative Objekte konnten Programme sein; Empfang, Freigabe, Ausführung und sicheres Ergebnis brauchten eigene Nachweise.

Die Adresse eines Dienstes

RFC 2122 erschien im März 1997 als Proposed Standard. VEMMI stand für eine erweiterte Mensch-Maschine-Schnittstelle für Videotex- und Multimedia-Dienste. Der entscheidende Satz des Dokuments lautet sinngemäß: Diese URL bezeichnet kein Datenobjekt, sondern einen interaktiven Multimediadienst.

vemmi://<host>:<port>/<vemmiservice>;<attribute>=<value> konnte Rechner, Port, Dienst und benannte Parameter enthalten. Ohne Port galt 575; ein Client durfte einen abweichenden URL-Port aus Sicherheitsgründen ignorieren. Das beschrieb eine Startabsicht. Es bewies weder DNS-Auflösung noch Listener, angebotenen Dienst oder angenommene Parameter.

Typischerweise blieb eine TCP/IP-Verbindung während der ganzen Sitzung bestehen. Über sie verwaltete VEMMI Objekte und meldete Aktionen zurück. Das Web war Treffpunkt, nicht Laufzeitumgebung.

Nach dem Klick begann erst der Dialog

Der Server konnte service:, username: und password: abfragen. Der Client antwortete aus URL, Konfiguration oder nach Rückfrage beim Nutzer. Bis VEMMI_Open eintraf, blieb das Terminal im Standardmodus für Videotex oder Telnet.

Benutzername und Passwort durften nicht in der URL stehen. Dienstwahl und Identität waren bewusst getrennt. Auch die Beispiele 200 OK und 401 Unauthorized waren Protokollbeispiele, keine Messdaten. Link, Handlerstart, TCP-Verbindung, akzeptierte Identität und geöffnete Sitzung waren fünf verschiedene Belege.

Ein unbekanntes Schema scheiterte früher

Unterstützung konnte eingebaut oder über Zusatzsoftware registriert sein. Ohne sie meldete ein Browser entweder einen unbekannten Scheme-Fehler oder behandelte den Text als relative URL und fragte den HTTP-Server der Seite nach einem nicht vorhandenen Pfad. Ein vemmi://-Link im HTML bewies somit nicht einmal einen lokalen Handler.

Das RFC schlug Client-Download, serverseitige Erkennung der Fehlanfrage oder Accept: application/vemmi als Hinweis vor. Es maß keine Verbreitung dieser Verfahren. Spezifikation und tatsächliche Unterstützung bleiben getrennt.

Objekttransport war eine andere Funktion

application/vemmi erlaubte den Versand von Objekten per HTTP, E-Mail oder anderem Transport, ohne die dauerhafte Sitzung zu öffnen. Der Medientyp konnte sogar eine Textdatei mit einer zu startenden URL tragen. Scheme und Medientyp gehörten zur gleichen Umgebung, hatten aber verschiedene Aufgaben.

IANA führt vemmi weiterhin als permanentes URI-Scheme, application/vemmi als Medientyp und Port 575. Das sind Namensraumbelege, keine Betriebsdaten. Sie beweisen weder gepflegte Software noch aktive Dienste, Verkehr, Interoperabilität oder Verbreitung.

Ausführung verlangte eine eigene Zustimmung

Metacode-Objekte konnten Befehlsfolgen enthalten; operative Objekte konnten ausführbare Programme für den Client sein. RFC 2122 empfahl dringend, automatische Ausführung abzuschalten oder vorher die Zustimmung des Nutzers einzuholen.

Transport war damit keine Autorisierung. Typbestimmung, Download, Dekodierung, Freigabe, Ausführung und Ergebnis waren getrennte Kontrollpunkte. Auch das Passwortverfahren nannte das RFC unsicher und nur aus Kompatibilitätsgründen vorhanden — eine historische Feststellung, keine heutige Empfehlung.

RFC 1738 hatte Schemes unterschiedliche Zugriffsmethoden erlaubt. RFC 2122 zeigt einen konkreten Grenzfall: Eine Webseite übergab an eine zustandsbehaftete Laufzeit. Running-Code Primacy liefert die passende Leseregel: Dokument und Registereintrag erhalten nicht die Beweiskraft laufender Implementierung.

Die präzise Chronik lautet daher: benannt, erkannt, übergeben, verbunden, ausgewählt, authentisiert, geöffnet, geliefert, freigegeben, ausgeführt, beobachtet. „Der Link funktionierte“ löscht genau diese Grenzen.

Quellen