Multimedia in aller Munde. Nach Down- und Rightsizing sowie Client-Server naht das naechste Schlagwort. Vor allem Workstation- Anbieter schmuecken mit audiovisuellen Demonstrationen aller Art ihre Produkte und Prospekte aus, um im derzeit erbittert umkaempften Hard- und Softwaremarkt Positionen zu erringen oder zu verteidigen. Dabei hat sich der Ablauf ganzer Spielfilme in einem Fenster unter Windows oder Motif laengst zur Standardvorfuehrung entwickelt.
Bei Werbeagenturen und in anderen audiovisuellen Branchen hat sich Multimedia mittlerweile durchgesetzt, wenn auch nur in Stand- alone-Anwendungen. Ausgehend vom klassischen Mac sind komplexe Anwendungen aus Text, Sprache und Bild entstanden, die eine neue Aera der Rechnernutzung einleiten.
Die Schwaeche der bisherigen Systeme lag in der lokalen Beschraenkung. Der Austausch der verschiedenen Daten auf elektronischem Wege erwies sich in den meisten Faellen als unpraktikabel. Beruecksichtigt man, dass ein hochwertiges Foto bis zu 18 MB und ein kurzer Videoclip bereits 300 MB Speicherplatz beansprucht, so errechnen sich hieraus selbst im Ethernet noch betraechtliche Uebertragungszeiten. Damit stellt sich die Frage, wie man in Workgroups Multimedia-Informationen effizient austauscht. Sie gewinnt in Weitverkehrsnetzen an Brisanz, da dort noch keine Bandbreiten wie in LANs zur Verfuegung stehen.
Von daher sollte man die oftmals voreilig lancierten Lobpreisungen von Multimedia-Mail mit Vorsicht geniessen. Was geschieht in einem Ethernet-LAN, wenn die Anwender beginnen, in grossem Stil audiovisuelle Informationen, sprich ruhende oder laufende Bilder hoher Qualitaet, per Mail auszutauschen? Selbst ein nicht synchron arbeitendes Mail-System wird innerhalb kuerzester Zeit das Netz verstopfen, da Ethernet sich bekanntlich bereits ab 50 Prozent nomineller Auslastung fast nur noch mit Wiederholungen beschaeftigt. In einem WAN unter X.25 oder ISDN treten zwar keine Kollisionen auf, dafuer bilden sich aber schnell endlose Warteschlangen, so dass es zu exponentiell ansteigenden Wartezeiten kommt. Erschwerend tritt hinzu, dass zu Recht ungeduldige Anwender in ueberlasteten Netzen die Situation durch wiederholte Versendung derselben Nachricht verschaerfen und schliesslich das Netz zum Stillstand bringen.
Andererseits bietet E-Mail gerade fuer nichtsynchrone Anwendungen eine ideale Basis fuer einen effizienten Datenaustausch zwischen Personen oder heterogenen Anwendungen. Das Store-and-forward- Prinzip verzichtet auf simultane Praesenz der Kommunikationspartner, und die Mail-Protokolle stellen die vollstaendige und konsistente Uebertragung aller Daten sicher.
Besonders X.400 bietet eine ideale Ausgangsbasis fuer den Austausch von Multimedia-Nachrichten. Im Gegensatz zu herkoemmlichen Mail- Systemen (Unix-Sendmail etc.) ermoeglicht es die Kombination beliebiger "Body parts" in einer Nachricht. Eine Mail kann zum Beispiel unformatierten ASCII-Text, ein Winword-Dokument, binaere Grafikdateien sowie ausfuehrbare Programme enthalten, wobei die unterschiedlichen Objekte als separate Komponenten behandelt werden. Um die unterschiedlichen Objekte korrekt zu identifizieren und weiterzubearbeiten, bietet es sich an, den einzelnen Nachrichtentypen Kennungen zuzuordnen, zum Beispiel FAX-G3 oder Teletex, um nur zwei herstellerunabhaengige Formate zu nennen.
Damit zeigt sich schon das erste Problem: Wer entscheidet darueber, welche Kennungen zugelassen werden? Sicher kann es nicht nach der Verbreitung im Markt gehen, wie es die Bundespost vor Jahren mit dem 3270-PAD im Datex-P vorexerziert hat. Solche Loesungen pflegen die Marktverhaeltnisse zu bestaetigen und die Maechtigen zu belohnen. Andererseits existieren mit ISO 8632 zwar Standards fuer Grafik, fuer Video- und Audiodaten fehlen sie aber noch. Im eigentlichen Dokumentenbereich deckt ODA/ODIF die Anforderungen ab, erfuellt aber die Multimedia-Anforderungen nicht und hat sich ausserdem noch nicht flaechendeckend durchgesetzt.
Aus diesen Gruenden beschraenken sich verfuegbare Implementationen von X.400-84 im wesentlichen auf die Nachrichtentypen IA5 (International Alphabet 5 = ASCII 7 Bit ohne Umlaute!) sowie "undefined". Letzterer umfasst den "Rest der Welt" und ueberlaesst es dem Absender, die Body parts seiner Nachricht im Anschreiben zu identifizieren. Diese Loesung funktioniert zwar recht und schlecht beim persoenlichen Mail-Austausch, taugt aber nicht zur automatischen Anzeige oder Verarbeitung unterschiedlicher Nachrichtenelemente mit komplexen Anordnungen (zum Beispiel Videoclip im Textfenster mit unterlegter Sprache).
Die 88er-Version von X.400 bietet mit dem Parameter "Externally defined body part" eine Teilloesung an. In diesem Feld kann der Absender einen eindeutigen und allgemein anerkannten Typ eintragen, der sich von jedem Programm einfach auswerten laesst. In den USA vergibt bereits eine zentrale Stelle solche Kennungen an interessierte Bewerber, womit allerdings noch keine internationale Verbreitung gegeben ist. Da diese Stelle noch nicht die Autoritaet des Internet-NIC (Network Information Center fuer die Vergabe weltweit eindeutiger Internet-Adressen) besitzt, ist eine Mehrfachbelegung desselben Codes nicht auszuschliessen. Allerdings ist dieses Problem typisch fuer einen Markt in statu nascendi.
Laufende Vorhaben wie das Berkom-Projekt in Berlin haben sich daher entschieden, vorab einen begrenzten Satz von Codes fuer projektbezogene Zwecke zu definieren, die entweder einen faktischen Standard setzen (TCP/IP laesst gruessen) oder spaeter auszutauschen sind.
Ein weiteres Problem von X.400 hat Marshall Rose in seinem Aufsatz "The Future of OSI: A Modest Prediction" aufgezeigt. Adresse und Inhalt einer Nachricht werden immer zusammen uebertragen, das heisst, es ist nicht moeglich, vor Uebertragung der eigentlichen Nachricht festzustellen, ob der Adressat ueberhaupt existiert oder erreichbar ist. Da es auch kein zentrales X.400- Clearing-Center fuer die Pruefung von Adressen gibt, wird jede Nachricht bis zu der Stelle der falschen Adresskomponente transportiert. Im Fall trivialer Textnachrichten von wenigen hundert oder tausend Zeichen ist dies unerheblich, bei umfangreichen Multimedia-Mails kann es sich jedoch zu einem realen Problem auswachsen.
Was geschieht aber, wenn das "Paket" fuer den Empfaenger zu gross ist, so dass er es physisch nicht annehmen kann? Beim materiellen Transport wird man dieser Gefahr vorbeugen, indem man dem Empfaenger lediglich eine Nachricht ueber den Lagerort der Ware zukommen laesst. Bei der elektronischen Post schlaegt man aehnliche Wege ein.
Wie stellt man also eine reibungslose Kommunikation ueber X.400- Mail sicher und ermoeglicht dem Empfaenger dennoch den moeglichst einfachen Zugriff auf die eigentlichen Daten? Im Berkom-Projekt hat man dieses Problem durch getrennte Wege fuer Benachrichtigung und Daten geloest. Der Absender legt die Multimedia-Informationen auf einem Server ab und sendet dem Empfaenger eine Nachricht mit externen Referenzen auf diese Daten. Dabei enthaelt die E-Mail nicht nur die Ortsangabe, sondern ueber "External type definitions" auch den Typ und Angaben ueber die Reihenfolge der einzelnen Elemente ("Link body part"). Der Empfaenger holt sich diese Daten im Dialog oder automatisch per Programm ab, wobei er fuer Dateitransfer wesentlich geeignetere Protokolle wie XTP (Express Transport Protocol) einsetzen kann.
Damit entschaerft sich auch das Problem unzureichenden lokalen Speicherplatzes, auf das wir oben mit der Analogie des uebergrossen Paketes verwiesen. Aus Effizienz- und Kostengruenden ist es sogar denkbar, die gesamte E-Mail ueber herkoemmliche Kommunikationsmedien wie X.25 oder ISDN zu transportieren, waehrend die Hochgeschwindigkeits-Uebertragung per XTP auf FDDI oder noch schnelleren Medien erfolgt. Dabei ist natuerlich der Mehraufwand fuer zwei unterschiedliche Netze zu beruecksichtigen. Unterstellt man jedoch, dass die grosse Mehrheit der Anwender "normale" Texte im KB-Bereich austauscht und nur wenige grosse Datenmengen effizient uebertragen muessen, so bietet sich eine Trennung des gewoehnlichen Mail-Verkehrs mit hoher Anzahl kleiner Nachrichten von dem "Bulk"- Transfer multimedialer Daten an. Jeder Entwerfer technischer Systeme weiss, dass die "eierlegende Wollmilchsau" fuer alle Anwendungsfaelle letztlich jeden einzelnen unzufrieden stimmt und dass separate, effiziente Loesungen fuer Teilbereiche sich meist schneller durchsetzen. Wenn sie auf einer hoeheren Ebene miteinander gekoppelt sind, ist auch die Gefahr des Auseinanderdriftens zweier Welten gebannt.
Stellt sich abschliessend die Frage, wer denn diese Funktionalitaet benoetigt. Sieht man einmal von der Tatsache ab, dass die meisten neuen Technologien anfangs ueberfluessig erscheinen (wer hat Ende der 70er Jahre Bedarf an PCs gesehen?), so bietet sich unmittelbar die Medienindustrie mit Werbeagenturen, Redaktionen, Druckereien und Marketing-Firmen an. Das gesamte Datenmaterial fuer die Print- Medien laesst sich zwischen den Beteiligten wesentlich effizienter als per Fax oder gelber Post austauschen. Lithos fuer Anzeigen werden nicht mehr als Filme, sondern als Datei versandt, vorausgesetzt, die entsprechende Uebertragungsbandbreite steht zur Verfuegung.
Darueber hinaus wird Multimedia-Mail sicher auch das Konferenzwesen revolutionieren. Besprechungen zwischen raeumlich verteilten Partnern werden zunehmend ueber Multimedia-Kanaele ablaufen, wenn nicht nur die Standfotos der anderen Teilnehmer, sondern auch grafische und bildliche Darstellungen bis hin zum Videoclip moeglich sind. Die eingesparten Reisekosten werden vor allem bei Grossunternehmen schon bald die Abschreibungskosten fuer die Multimedia-Investitionen abdecken. Allerdings wirken die Anschluss- und Uebertragungskosten fuer Breitbandleitungen der Telekom wie Kork in einer alten Spaetlese.
Vor dem breitflaechigen Erfolg steht jedoch immer noch die Akzeptanz durch die Endbenutzer, und sie koennte in den naechsten Jahren das groesste Hindernis auf dem Weg in eine bluehende Multimedia-Landschaft darstellen.