Zusammenfassung

  • Content-Duration: 33 ermöglichte einem Mailclient, die vom Absender angegebene Dauer von 33 Sekunden anzuzeigen, ohne das Medium zu öffnen. Der Wert war leicht abrufbar, aber keine unabhängige Messung.
  • RFC 2424 hielt fest, dass sich die exakte Dauer erst durch Öffnen und Abspielen des Inhalts feststellen lässt. Die Nutzung beim Empfang bleibt der jeweiligen Implementierung überlassen; auch die exakte Datengröße weist das Feld nicht nach.

Die Nachricht war noch nicht abgespielt. Die Zahl stand trotzdem bereits darin: Content-Duration: 33. Auf einem kleinen Bildschirm konnte der Client anzeigen, wie lang ein Sprachclip offenbar war, bevor jemand den Anhang öffnete. Dafür musste er das Audio nicht erst decodieren. Der Komfort war real. Ebenso real blieb der Abstand zwischen dem Headerwert und einer Beobachtung des Mediums.

Dieses klar umrissene Problem behandelte RFC 2424, das im September 1998 auf dem Standards Track erschien. Es definierte ein MIME-Headerfeld für zeitveränderliche Inhalte, typischerweise Audio oder Video. Die Syntax ist bewusst knapp: Auf Content-Duration: folgen ein bis zehn Dezimalziffern. Der Wert steht für Sekunden, ohne Einheitenkennzeichnung. Im RFC-Beispiel entsprechen 33 genau 33 Sekunden.

Warum die Angabe in einen eigenen Header schreiben? Manche Medienformate enthalten ihre Dauer bereits; bei anderen lässt sie sich genau aus der Datenlänge berechnen. In beiden Fällen muss man den Inhalt verarbeiten oder seine Codierung verstehen. Ein MIME-Header bietet einen billigeren Zugriff: Das Zeitmaß lässt sich aus der äußeren Nachrichtenstruktur auslesen, ohne das Medium anzufassen. In einer eingeschränkten Sprachmail-Umgebung konnte so selbst ein einfacher MIME- oder Nicht-MIME-Desktop die Dauer anzeigen, bevor er das Audio öffnete.

Die einfache Form macht auch die Zuständigkeit sichtbar. RFC 2424 bezeichnet den Wert als vom Absender bestimmt. Er sollte exakt sein, doch unmittelbar darauf folgt die Einschränkung: Ohne Öffnen und Abspielen des Inhalts lässt sich die genaue Dauer nicht kennen. Wenn Genauigkeit erforderlich ist, soll diese zweite Methode verwendet werden. Das Feld ist also kein Messdienst. Es ist eine vom Absender gelieferte, leicht zugängliche Erklärung; überprüfen lässt sie sich erst durch Beobachtung des Mediums.

Eine einheitliche Benutzeroberfläche schrieb die Norm nicht vor. Sie nennt mögliche Anzeigeorte – etwa die Kopfzeilen im Posteingang oder den geöffneten Audioanhang – und überlässt die tatsächliche Nutzung beim Empfang der lokalen Implementierung. Standardisiert wurden das Feld und seine Bedeutung, nicht die Pflicht, es in jedem Client anzuzeigen, und auch nicht seine Hervorhebung. Ebenso wenig beweist es, dass ein bestimmter Client das Medium korrekt decodiert hat. Ein standardisierter Hinweis kann weiter reisen als eine einzelne Oberflächenentscheidung, vereinheitlicht diese aber nicht.

Voice Profile for Internet Mail gab dem Feld einen konkreten Rahmen. Für audio/32KADPCM konnte eine einfache Desktop-Umgebung die Dauer einer Sprachnachricht anzeigen, bevor sie das Audio öffnete. Daraus folgt jedoch nicht, wer gesprochen hat, wann der Clip aufgenommen wurde, ob jemand die Nachricht öffnete oder sie bis zum Ende anhörte. Das sind andere Tatsachen, die gegebenenfalls auf anderem Weg übertragen oder beobachtet werden müssen.

Die späteren Dokumente zeigen sowohl Kontinuität als auch einen größeren Anwendungsrahmen. RFC 3803 ersetzte RFC 2424 im Jahr 2004 und hielt fest, dass nur redaktionelle und formale Änderungen vorgenommen wurden. Syntax und Unterscheidung zwischen Absenderwert und durch Abspielen feststellbarer Genauigkeit blieben bestehen. 2005 nahm RFC 4021 Content-Duration als MIME-Headerfeld auf dem Standards Track in das Register auf: Es bezeichnet die Dauer des Inhalts eines Nachrichtenteils in Sekunden. Der Registereintrag erleichtert das Auffinden, macht aus der Erklärung aber keinen verifizierten Messwert.

Ein Informationsdokument zum Verhalten von Clients, RFC 4024, formulierte die Darstellungsfrage genauer. Textgröße lässt sich in Kilobyte angeben, Sprachdauer in Sekunden und Faxumfang in Seiten. Für Sprachnachrichten bevorzugt das Dokument die Content-Duration des Haupt-Audioteils, erlaubt einem Client aber auch, mehrere Audioteile zusammenzurechnen. Bei gemischten Inhalten soll sich die angezeigte „Größe“ nach dem primären Inhalt richten. Das sind Empfehlungen zur Oberfläche, keine Garantie, dass der Wert gemessen oder das Audio abgespielt wurde.

RFC 2424 weist außerdem darauf hin, dass eine aus dem Medium herausgelöste Eigenschaft anders sichtbar wird. In bestimmten Umgebungen kann es ein Sicherheitsproblem sein, die Dauer ausdrücklich im Header anzugeben. Und das Feld darf nicht als Nachweis der exakten Datengröße dienen; dafür müssen die Daten selbst untersucht werden. Sekunden und Bytes beantworten verschiedene Fragen. Die vom Absender genannte Dauer ersetzt keine Bytezählung – so wenig wie die Bytezahl beweist, wie lange ein bestimmter Decoder einen Clip abspielen wird.

Die historische Lehre ist nüchtern und dauerhaft: Ein Standard kann eine Aussage leicht übertragbar und sichtbar machen, ohne die Überprüfung der beschriebenen Eigenschaft ebenso günstig zu machen. RFC 2424 benennt beide Seiten: die vom Absender gelieferte Zeitangabe für den schnellen Zugriff und das Öffnen samt Abspielen, das für Genauigkeit nötig ist. Ein Client kann die erste anzeigen, bevor die zweite stattfindet. Weder Feld noch Anzeige beweisen, dass die Dauer der Wiedergabe entsprach, die Nachricht unversehrt ankam oder jemand sie hörte. Im Header stehen 33 Sekunden. Bis der Inhalt geprüft wird, reicht der Beleg nicht weiter.