Go to the previous, next section.

Übersicht über die verschiedenen Blocktypen

Die verschiedenen Blocktypen (gleich Mitteilungsarten) werden anhand der Zeilenkombination und der Message-ID unterschieden. Sie unterscheiden sich je nach Absender etwas.

Legende: Zeichenerklärung
Spezial-Format: Format der Spezialmitteilungen
Status-Format: Format der Statusmitteilungen
Oeffentliche-Format: Format der öffentlichen Nachrichten
Persoenliche-Format: Format der persönlichen Nachrichten

Legende

Im Folgenden werden verschiedene Kürzel verwendet. Die meisten von ihnen sind Anfangsbuchstaben der Zeilen, aber in einigen Fällen ist eine genauere Unterscheidung notwendig:

# Eine #-Zeile mit einem @, also einer echten Message-ID darin.
#e Eine #-Zeile ohne @, aber mit einer Zahl darin.
#a Eine #-Zeile ohne @ oder Ziffern darin, die nur Buchstaben enthält.

Format der Spezialmitteilungen

Spezialnachrichten erkennt man daran, daß ihre Message-ID in der #-Zeile nur aus Buchstaben besteht.

Zur Zeit kommen in Spezialnachrichten nur #- und :-Zeilen. Es gibt aber (nach Ansicht des Autors) Gründe, weitere Headerzeilen zuzulassen:

* V: Für Boximplementationen kann es sinnvoll sein, einen Absender anzugeben, der zum Beispiel der Ansprechpartner für diese Infofile ist.
* E: Das Änderungsdatum von Infofiles kann interessant sein.
* W: Nicht ganz so interessant ist der Betreff, bzw. der Titel eines Infofiles, denn man kann ihn auch aus dem ITI entnehmen.

Das Format der Spezialnachrichten ist für alle gleich, wenn man davon absieht, daß Benutzer auch zukünftig keine V-Zeilen angeben dürfen.

Format der Statusmitteilungen

Statusnachrichten erkennt man am einfachsten daran, daß sie eine Message-ID (#@-Zeile), die einen @ enthält und eine B-Zeile haben, aber keine :-Zeile, also keinen Nachrichtentext.

Das Format der Statusnachrichten ist je nach Transportweg sehr unterschiedlich:

MAUS -> alle anderen

#
Die ID der Nachricht, auf die sich diese Statusmitteilung bezieht
B
Der neue Status und der Zeitpunkt, zu dem die Statusänderung eingetreten ist.
E
Die Eingabezeit der in der #-Zeile referenzierten Nachricht.
Benutzer -> Box

#
Die ID der Nachricht, auf die sich diese Statusmitteilung bezieht
B
Der neue Status, ohne Datum dahinter.
E
Der Zeitpunkt, zu dem die Statusänderung eingetreten ist. Falls diese Zeile nicht angegeben ist, wird der Zeitpunkt des Tauschs verwendet.
K
Beim Kopieren/Weiterleiten von Nachrichten muß hier der neue Empfänger angegeben werden.
>
Nach der K-Zeile kann eine >-Zeile angegeben werden, in die ein Kommentar für den Empfänger eingetragen wird.

Der Benutzer darf die Statusänderungen X, Z, G, K und W schicken.
Fremdbox -> MAUS

#
Die ID der Nachricht, auf die sich diese Statusmitteilung bezieht.
B
Der neue Status, ohne Datum dahinter.
E (Zwang)
Der Zeitpunkt, zu dem die Statusänderung eingetreten ist.

Eine Fremdbox darf die Statusnachrichten X, Z und G zur MAUS schicken.
Gateway -> MAUS

#
Die ID der Nachricht, auf die sich diese Statusmitteilung bezieht
B
Der neue Status. Vermutlich ohne Datum (Kais Doku sagt dazu nichts)
E (???)
Der Zeitpunkt, zu dem die Statusänderung eingetreten ist. Dürfen Gateways diese Zeile mitschicken?

Ein Gateway darf die Statusänderungen X, Z, G und Y zur MAUS schicken.

Die Unterschiede im Datenformat sind unlogisch. Daher sollte man darüber nachdenken, das Mitschicken des Änderungsdatums in der B-Zeile für alle Seiten zu erlauben und die E-Zeile, falls ein Datum in der B-Zeile angegeben worden ist, als Eingabezeit der referenzierten Nachricht zu verstehen. Auf diese Art wäre ein fließender Übergang zwischen alten und neuem Format gewährleistet.

Das Konzept der Statusnachrichten basiert daraus, daß die Nachricht, für die der Status verschickt wird, in Empfänger- und Absenderbox noch vorhanden ist. Daher sind Statusmeldungen nach Datenbankcrashs oder einigen Wochen Urlaub nicht mehr zustellbar. Sie sind auch problematisch zu implementieren in Boxen, die - aus welchen Gründen auch immer - die Nachrichten nach Versand - in welche Richtung auch immer - nicht länger aufbewahren. Daher sollte die Angabe des Empfängers der Statusmeldung zumindest erlaubt werden.

Format der Öffentlichen Nachrichten

Öffentliche Nachrichten erkennt man daran, daß ihre Message-ID einen @ enthält und sie eine G-Zeile haben - jedenfalls sehen so die von einer Box versandten Nachrichten aus. Es gibt aber eine Reihe Spezialfälle, die eine einfache Unterscheidung in bestimmten Fällen unmöglich machen.

Öffentliche Nachrichten haben nie B-Zeilen.

MAUS -> alle anderen (auch Fremdboxen an alle anderen außer MAUS)

- immer
# W E G
- nie
B K
- möglicherweise
prinzipiell alle weiteren und beliebige neue Zeilen
- Bemerkungen
: ist optional, es kann vorkommen daß MAUS leere Nachrichten verschickt (wenn der User kein Zahler ist und die Gruppe nur für Zahler frei ist).
V ist optional wegen anonymen Gruppen
Benutzer -> MAUS

- immer
#e :
- möglicherweise
G - E R D W
- Bemerkungen
G ist optional, wenn es nicht angebenen wird, kann sich die Box die Zielgruppe möglicherweise aus der kommentierten Nachricht entnehmen (wenn diese noch vorhanden ist, selbstverständlich). Daher muß, wenn keine G-Zeile angegeben ist, eine --Zeile mit Bezug auf eine öffentliche Nachricht angegeben werden. Es ist möglich, bei Kommentaren beide Zeilen anzugeben, Frontends sollten diese Möglichkeit nutzen.
W war in Kais Doku als optional bei Kommentaren gekennzeichnet, MAUS übernimmt den Betreff der kommentierten Nachricht, falls keiner angegeben ist. Quark lehnt solche Nachrichten ab.
D sollte angegeben werden, auch wenn MAUS diese Angabe aus der kommentierten Nachricht übernimmt (Quark tut dies nicht).
Generell sollten Frontends möglichst viele Daten mitschicken und sich nicht darauf verlassen, daß die kommentierte Nachricht noch in der Box vorhanden ist.
Gateway -> MAUS

- immer
#e V E :
- möglicherweise
G - W I R O N D
- nie
A B K >
- Bemerkungen
Alle Anmerkungen zu Frontends -> MAUS gelten auch hier.
Fremdbox -> MAUS

- immer
# V E :
- möglicherweise
G - W R D
- nie
A B K > I O N
- Bemerkungen
Die Anmerkungen zu Frontends -> MAUS gelten auch hier.
Fremdboxen dürfen keine I-Zeilen und keine Nachrichten mit Absender oder Message-ID außerhalb ihrer eigenen Box mitschicken.
Gateway -> Quark

- immer
# V E G W :
- möglicherweise
- I O N Y D
- nie
A B K R >
- Bemerkungen
Falls keine Message-ID mit @, sondern eine temporäre ID in der #-Zeile angegeben ist, muß eine echte ID in der I-Zeile angegeben sein, die die Quark dann in die #-Zeile einsetzt. Ins #LOG wird die temporäre ID eingetragen, der Dupecheck wird über die ID in der I-Zeile gemacht. Einziger Sinn der temporären IDs ist, daß das Gateway in der #-Zeile einen Schlüssel (Filenamen ?) angeben kann, über den es direkt auf die Nachricht zugreifen kann.

Format der persönlichen Nachrichten

MAUS -> alle anderen

- immer
# V A W E B > :
- möglicherweise
- I R O N
- nie
G K D
Benutzer -> Box

- immer
#e :
- möglicherweise
A - W K > E R
- nie
V B G K I O N D Y
- Bemerkungen
A ist optional, wenn es nicht angebenen wird, kann sich die Box den Empfänger möglicherweise aus der kommentierten Nachricht entnehmen (wenn diese noch vorhanden ist, selbstverständlich). Daher muß, wenn keine A-Zeile angegeben ist, eine --Zeile mit Bezug auf eine persönliche Nachricht angegeben werden. Es ist möglich, bei Kommentaren beide Zeilen anzugeben, Frontends sollten diese Möglichkeit nutzen.

Genau eine >-Zeile kann auf eine K-Zeile folgen, insgesamt dürfen bis zu 10 K-Zeilen (und damit auch 10 >-Zeilen) kommen.
W war in Kais Doku als optional bei Kommentaren gekennzeichnet, MAUS übernimmt den Betreff der kommentierten Nachricht, falls keiner angegeben ist. Quark lehnt solche Nachrichten ab.
Generell sollten Frontends möglichst viele Daten mitschicken und sich nicht darauf verlassen, daß die kommentierte Nachricht noch in der Box vorhanden ist.
Gateway -> MAUS

- immer
#e V E :
- möglicherweise
A - W K > I R O N
- nie
B G D
- Bemerkungen
Die Anmerkungen unter Benutzer -> MAUS gelten auch hier.
Fremdbox -> MAUS

- immer
# V E :
- möglicherweise
A - W K R
- nie
B G D I O N
- Bemerkungen
K ist in Kais Doku als erlaubt angegeben, aber Sinn ergibt das eigentlich nicht.
Ansonsten gelten die schon bei den Benutzern angegebenen Hinweise.
Gateway -> Quark

- immer
# V E A :
- möglicherweise
- W K I R O N p Y
- nie
B D G
- Bemerkungen
Falls keine Message-ID mit @, sondern eine temporäre ID in der #-Zeile angegeben ist, muß eine echte ID in der I-Zeile angegeben sein, die die Quark dann in die #-Zeile einsetzt. Ins #LOG wird die temporäre ID eingetragen, der Dupecheck wird über die ID in der I-Zeile gemacht. Einziger Sinn der temporären IDs ist, daß das Gateway in der #-Zeile einen Schlüssel (Filenamen ?) angeben kann, über den es direkt auf die Nachricht zugreifen kann.

Go to the previous, next section.