Go to the previous, next section.

Einführung in das MausTauschformat

Das MausTauschformat ist das Standarddatenaustauschformat des MausNet.

Überblick

Das MausTauschformat ist das Standarddatenaustauschformat im MausNet. Es ist, im Gegensatz zum Beispiel zu Zconnect, rein textorientiert, und in der Lage, Nachrichten, Kommandos und Informationstexte zu transportieren. Es wird im MausNet für den Datenaustausch zwischen Benutzern und Boxen, Fremdboxen und MAUSboxen, und Gateways und Boxen verwendet.

Im Folgenden wird das Grundprinzip anhand des Tauschs für Benutzer erklärt:

Beim Datentransfer sendet der Benutzer ein Infile zur Box, und erhält von ihr dafür ein Outfile. Für weitere Informationen siehe section Das Nachrichtenpaket zur Box.

Beide Datenpakete bestehen aus Blöcken. Jeder Block enthält eine Nachricht, einen Informationstext oder spezielle Daten oder Kommandos. Siehe section Übersicht über die verschiedenen Blocktypen, um genauere Informationen ueber Blöcke zu bekommen.

Die Blöcke selbst bestehen aus Zeilen, deren Anfangszeichen angibt, was diese Zeile enthält. Die Zeilen sind unter section Die einzelnen Zeilen beschrieben.

Nicht nur einfache Nachrichten werden dabei uebertragen, sondern auch Informationstexte, Kommandos und Statusnachrichten. Für weitere Informationen siehe section Informationen über Box und Netz, section MausTauschKommandos und section Der Bearbeitungsstatus.

Das Nachrichtenpaket zur Box

Das infile ist das Nachrichtenpaket, das zur Box geschickt wird. Es enthält die vom Absender geschriebenen Nachrichten sowie Kommandos für die Box.

Die Box erwartet eine Datei `infile.txt' oder zukünftig auch `anbox'. Der Dateiname ist einzuhalten, auch wenn die MAUS zur Zeit alles Mögliche schluckt. Die Quark tut dies nicht und besteht auf den beiden genannten Formen. Das Einhalten der Namen ist spätestens dann wichtig, wenn die Programmteilunterstützung für den Tausch kommt.

Diese Datei darf mit einem Packer komprimiert worden sein, den auch die Box anbietet, in diesem Fall muß das Archiv die passende Endung für den Packer haben. Wird es entpackt, muß eine Datei `infile.txt' oder `anbox' erzeugt werden.

Ob und wie das Infile eingepackt wurde bestimmt, ob und wie das Outfile eingepackt wird.

Offene Frage: Ist anbox - so schön es theoretisch auch ist, wirklich notwendig?

Das outfile ist das Nachrichtenpaket, das von der Box zum Benutzer geschickt wird. Es enthält die Nachrichten für den Benutzer, Infofiles und diverse Informationen für das Frontend.

Die Box erzeugt eine Datei `outfile.txt', wenn sie eine Datei `infile.txt' vom Benutzer bekam, und eine Datei `vonbox', wenn sie ein `anbox' bekam.

Diese Datei wird mit demselben Packer eingepackt, mit dem das Infile eingepackt war, oder nicht eingepackt, wenn ein unkomprimiertes Nachrichtenpaket vom Benutzer kam.

Die verschiedenen Nachrichtenarten

Man kann die verschiedenen Nachrichtenarten ganz grob in zwei Klassen teilen, nämlich echte Mitteilungen und Spezialmitteilungen. In dieser Anleitung werden als Nachricht von Menschen geschriebene, über die Box versendete öffentliche und private Nachrichten bezeichnet.

Nachrichten zerfallen in zwei Kategorien:

* persoenliche Nachrichten
Dies sind fuer die Oeffentlichkeit nicht lesbare Nachrichten von an einen oder mehrere Empfaenger, vergleichbar mit Briefen. Haeufig werden sie `PM', `Netmail' (Begriff aus dem Fido), oder `Mail' genannt.
* oeffentliche Nachrichten
sind im Gegensatz dazu für die Öffentlichkeit sichtbare Nachrichten, die in Gruppen verteilt werden. Alternative Bezeichnugnen dafür sind `AM' und `OM', `echomail' (Fido) oder `News'. Öffentliche Nachrichten können in eine oder auch in mehrere Gruppen gehen, siehe section Crosspostings.

Spezialmitteilungen zerfallen wiederum in verschiedene Kategorien:

* Infofiles
Informationen für den Benutzer und die Frontends.
* Kopfblock HEAD
Steuerinformationen, meist zu Beginn des Outfiles. Siehe section Kopfblock im Outfile für weitere Informationen.
* Kommandoblock CMD
Kommandos von Benutzer und Frontend zur Box.
* Logblock LOG
Rückmeldungen der Box auf Kommandos und Nachrichten des Users.
* Umbennenungsblock REN
Liste der Gruppenumbenennungen
* Konfigurationsfile CNF
.CNF von Fremdboxen.

Adressformen

Folgende Formen von Adressen können auftreten:

Username@MausNetBox
So werden Nachrichten an Benutzer im MausNet adressiert. Username darf Leerzeichen enthalten, rund um das @ sind Leerzeichen erlaubt. MausNetBox ist ein Kürzel einer Box im MausNet. Beispiel: `Reiner Luser @ ME', oder `Reiner Luser@ME'.

Username@site.subdomain.domain
Die im InterNet übliche Schreibweise für Adressen. Auch hier sind rund um das @ Leerzeichen erlaubt. Schwieriger wird es beim Usernamen. Für Ziele im MausNet darf er Leerzeichen enthalten, für manche Adressen außerhalb auch, aber bei der überwiegenden Mehrzahl nicht. Außerdem sind Benutzernamen außerhalb des MausNets häufig casesensitiv. Beispiele: `Reiner Luser @ ME.maus.de' oder `loginname @ irgendwo.de'.

Username @ FidoTechnikNet <Fidoadresse>
Die im MausNet übliche Adressierungsform für Netze mit Fidotechnik. Beispiel: `Reiner Wahn @ Fido 444:555/666.777'

Zeitdarstellung im MausTausch

Datum und Uhrzeit werden, wenn sie maschinenlesbar sein sollen, im Format YYYYMMDDHHMM angegeben. Da Zeitzoneninformationen fehlen, ist immer von der in Deutschland, Oesterreich und der Schweiz gueltigen Zeitzone MEZ oder MEZ Sommerzeit auszugehen.

Gateways sind für das korrekte Umwandeln der Zeit verantwortlich.

Implementationen sollten damit rechnen, daß das Format um Sekunden ergänzt werden wird, es wäre dann YYYYMMDDHHMMSS.

Message-IDs

Damit alle Nachrichten eindeutig identifiziert werden können, bekommt jede Nachricht eine Message-ID. Diese sollte eindeutig sein, denn vielerorts wird der Dupecheck anhand der Message-ID durchgeführt, und außerdem funktioniert die Kommentarverkettung über die Message-ID.

Die Message-ID darf auch nicht verändert werden, denn dann funktioniert der Dupecheck nicht mehr, und es entstehen Dupes. Wird dies nicht schleunigst abgestellt, besteht die Gefahr der Erzeugung von Ringdupes (Dupes, von denen neue Dupes erzeugt werden). Ein wunderbares Beispiel dafür bietet die Gruppe GATEWAYS alias de.comm.gateways mindestens zwei mal im Jahr.

Die zur Zeit von MAUS in den # und --Zeilen transportierte ID ist leider nicht eindeutig, sondern wiederholt sich nach einiger Zeit. Boximplementationen müssen zur Zeit folgendes Format einhalten, wenn sie Nachrichten an die MAUS schicken:

* Annnnn@box
für öffentliche Nachrichten.
* Pnnnnn@box
für persönliche Nachrichten.
nnnnn ist eine Zahl im Bereich von 0 bis 65535.

box ist das Kürzel einer Box im MausNet.

Frontends und Gateways sollten damit rechnen, ganz anders geformte IDs zu bekommen, so verwendet die Quark II heute schon lange IDs, die sie erst auf dem Weg zur MAUS umsetzt in kurze.

Ein unangenehmer Nebeneffekt ist, daß beim Import fremder Nachrichten ins MausNet nicht die IDs übernommen werden können. Damit wäre eine Kommentarverkettung unmöglich, wenn nicht die echten IDs aus Fremdnetzen in den I- und R-Zeilen transportiert werden würden.

Weitere unangenehme Folgen der Unfähigkeit der jetzigen MAUS, mit langen IDs zu arbeiten, können fehlerhafte Verkettungen (im Frontend und in der box) und Message-ID-Dupes (im Sinne von "unterschiedlichen Nachrichten mit gleicher ID") sein.

Seit MAUS 7.94 erzeugt MAUS die langen IDs auch für Nachrichten aus dem MausNet, um die Situation zu entschärfen. Frontends sollten diese langen IDs nach Möglichkeit nutzen.

Für die MAUS 9 ist geplant, die Message-IDs fremder Netze zu übernehmen. Das bedeutet, daß sich das Format der IDs grundlegend ändern wird. So ist es empfehlenswert, sich heute schon darauf einzurichten, und keine Annahmen über den Aufbau von IDs zu machen.

Garantiert ist nur, daß irgendwo in der Mitte ein @ zu finden ist. Der Teil dahinter ist caseinsensitiv, der vordere Teil leider nicht.

Apropos caseinsensitiv: Quark und MAUS (seit Version 7.94) behandeln die Message-ID casesensitiv im lokalen Teil, und danach caseinsensitiv. Vorherige Versionen verglichen die ID generell caseinsensitiv.

Die Quark verwendet heute schon IDs, die nicht so aufgebaut sind wie die der MAUS, jedenfalls soweit das MausNet nicht betroffen ist. Quark ab Version 2.x verzichtet völlig auf die kurzen IDs und setzt stattdessen die Langen in die #- und minus-Zeilen ein.

Eine besondere Rolle im MausTausch spielen IDs ohne @, die Spezial-IDs. Nachrichten mit diesem IDs sind keine echten Nachrichten, sondern sogenannte Spezialnachrichten von der Box an den Benutzer oder das Frontend, oder umgekehrt. Weitere Informationen darüber unter section Spezialnachrichten.

Der Bearbeitungsstatus

Der Bearbeitungsstatus gibt Auskunft, wo eine persönliche Nachricht angekommen ist und was der Empfänger damit gemacht hat.
N
Die Nachricht wurde noch nicht gelesen.
Z
Der Empfänger hat die Nachricht zurueckgestellt, was bedeutet, daß er sie zwar gelesen hat, aber erst später entscheiden will, ob er antwortet.
B
Sie wurde beantwortet.
G
Die Nachricht wurde gelesen, wurde aber nicht beantwortet.
M
Die Nachricht ist im MausNet und noch nicht in der Zielbox angekommen.
A
Mittlerweile ist die Nachricht durch das MausNet in der Zielbox angekommen.
Y
Die Nachricht hat über ein Gateway das MausNet verlassen.
K
Der Empfänger hat die Nachricht jemand anderem als Kopie geschickt, sie wurde also kopiert.
W
Die Nachricht wurde weitergegeben.
T
Der Empfänger hat die Nachricht über den Tausch erhalten.

Frontends sollten die Statusmeldungen möglichst vollständig unterstützen. Falls der Benutzer aus welchen Gründen auch immer nicht wünscht, daß Statusmeldungen zurückgeliefert werden, sollte das Frontend keine versenden. Falsche Statusmeldungen sind in jedem Fall zu vermeiden.

Die Benutzer von Quarks erhalten keine Statusmeldungen, da die aktuelle Quark keine Statusmeldungen unterstützt. Quark ab Version 2.0 wird die Statusmeldung korrekt handhaben.

Der Verteilungsbereich der Nachricht

Die Distribution gibt an, über welchen Bereich eine Nachricht verteilt werden soll. Die Angabe der Distribution kann im MausTausch auf zwei Arten geschehen: Über eine D-Zeile oder über Textkludges. Erstere Form war vor MAUS 7.94 nur der MAUS erlaubt, seitdem darf sie auch von Fremdboxen, Gates und Benutzern verwendet werden. Nicht jede Boximplementation unterstützt die Textkludges.

Die D-Zeile ist vorzuziehen!

MAUS erkennt caseinsensitiv drei verschiedene Textkludges in der ersten und der letzten Zeile des Textes, und analog dazu drei verschiedene Inhalte der D-Zeile. Die folgende Tabelle zeigt die möglichen Distributionen, dabei wird zuerst der Wert in der D-Zeile, dann der äquivalente Textcludge angegeben:

* L == (lokal)
Die Nachricht soll nicht über die lokale Box hinaus verteilt werden.
* M == (MausNet)
Die Nachricht soll nicht über das MausNet hinaus verbreitet werden.
* N == (Net)
Die Nachricht darf beliebig verteilt werden.

Defaultdistribution ist Net, bzw. bei Kommentaren die Distribution der kommentierten Nachricht. Allerdings sollte man sich darauf nicht verlassen: Ist die kommentierte Nachricht nicht mehr in der Box, so kann natürlich auch ihre Distribution nicht mehr festgestellt werden. Quark 2.x verwendet in keinem Fall die Distribution der kommentierten Nachricht.

Natürlich haben persönliche Nachrichten keine Distribution.

Der Inhalt der Nachricht

MAUS erlaubt zur Zeit nicht Nachrichten von bis zu 16000 Bytes Länge. Dabei werden die Doppelpunkte am Zeilenanfang nicht mitgerechnet, und das Zeilenende nur als ein Zeichen gerechnet. Die Erhöhung dieses Limits (auf 64KB) ist geplant. Bei anderen Boximplementationen gibt es kein Limit. (1).

Die Erweiterung auf 64K ist unter den Tauschprogrammierern schon vor längerer Zeit verabredet worden. Zukünftig dürfte es sich als notwendig oder wünschenswert herausstellen, das Limit noch weiter zu erhöhen.

Textzeilen können nun sehr lang werden, einziges Limit ist die maximale Messagelänge.

MAUS löscht beim Import der Nachricht Leerzeilen am Anfang und Ende sowie größere Mengen Leerzeilen in der Nachricht. Zuvor werden noch Leerzeichen am Ende einer Zeile entfernt. Die Quark tut dieses nicht (2).

Kontrollzeichen außer Newline und Carriage Return werden von MAUS in Fragezeichen (?) umgewandelt. Leider betrifft dies auch das Tab-Zeichen. Andere Boximplementationen haben dieses Mißfeature nicht.

Die Zeilen werden, bevor sie zum Benutzer geschickt werden, noch einer Umlautwandlung (sofern nötig) unterzogen und auch Wunsch auch umgebrochen. Siehe section Umlautwandlung.

Das 16000-Byte-Limit macht es notwendig, daß lange Nachrichten beim Übergang ins MausNet gesplittet werden. Siehe section Standard für das Splitten von Nachrichten.

Umlautwandlung

Dieses Kapitel bietet eine kurze Einführung in die Konzepte der Umlautwandlung im MausNet.

Das MausNet (hier ist zur Abwechslung das Programm gemeint!) transportiert alle Nachrichten in IBM-PC-Zeichensatz (Codepage 437). Beim Transfer der Nachrichten zur MAUS muß daher eine Zeichensatzwandlung durchgeführt werden.

Zur Zeit wandeln MAUS und Quark 1.x nur die Umlaute und das Sz.

Quark II wandelt alle Zeichen aus dem Zeichensatz des Benutzers in den von der Quark benutzten um (und umgekehrt beim Export). Zeichen, die im Zielzeichensatz nicht vorhanden sind, werden unter Beibehaltung ihres Asciiwerts übernommen. Diese Lösung ist besser, aber noch lange nicht perfekt.

Für MAUS 9 ist eine erheblich bessere Methode geplant: MAUS wird intern Kaicode verwenden. Diese Codierung kann nicht nur 256, sondern beliebig viele Zeichen darstellen (siehe unten). Dadurch kann gewährleistet werden, daß alle Zeichen möglichst spät und nur einmal gewandelt werden, so daß Informationsverluste, wie sie bei den beiden oben geschilderten Methoden auftreten, minimal bleiben.

Der sogenannten Kaicode: Als Basis wird iso-8859-1 (latin-1, Amiga) verwendet. Alle Zeichen aus diesem Zeichensatz im Bereich 32 bis 127 und 192 bis 256 werden als ein Ascii-Zeichen transportiert. Alle anderen Zeichen aus dem Zeichensatz und alle Zeichen, die in iso-8859-1 nicht vorhanden sind, werden als Folge von 4 Bytes abgelegt. Dabei wird der Unicode-Wert des Zeichens codiert: Aus dem Unicode-Zeichen mit der Nummer 4321 (hexadezimal) wird 84 93 A2 B1.

Blick ueber den Zaun

Absenderangaben im Usenet

Im Usenet kennt man nicht nur eine Angabe für den Absender, sondern drei:
From - Wer hat diese Nachricht verfasst?
Sender - Wer hat die Nachricht abgeschickt?
Das koennte z.B. der Sekretaer des in der From-Zeile angegebenen sein.
Reply-To - An wen sollen die Antworten gehen?
Default: an den in der From-Zeile Angegebenen.

Multipurpose Internet Mail Extensions

MIME ist der kommende Standard für Mail im Internet. MIME bietet unter anderem Multimedia. Im MausNet werden wahrscheinlich Teile davon übernommen, insbesondere enriched text, der die Möglichkeiten von normalen Texten u.a. um Textattribute und Textformatierung erweitert.

MIME ist in RFC1521 beschrieben, enriched text in RFC1563. Für Gatewayprogrammierer ist auch noch RFC1522 interessant.

Was ein Frontend können sollte

Umgang mit der Kommentarverkettung

Frontends sollten bei der Erzeugung von Kommentaren auf folgende Punkte achten:

* Kommentarverkettung
Frontends, die ihren Benutzern Kommentarverkettung bieten (und andere werden sich im MausNet wohl nicht halten können), sollten dafür die IDs aus I- und R-Zeilen verwenden, wenn die Box diese Zeilen liefert, und die #- und --Zeilen, wenn sie nur diese liefert.

Die Überlegung dahinter: Die langen IDs in I- und R-Zeilen sind eindeutig und daher für das Frontend unproblematischer. Liefert eine Box nicht beide ID-Typen, dann bleibt ohnehin keine andere Wahl, als die #/--Kombination zu verwenden.

Schwierig ist die Situation für multiboxfähige Frontends: MAUS liefert I/R und #/-, Quark II nur #/- (aber mit langen IDs darin), Quark 1.x liefert je nach Versionsnummer entweder keine I/R und/oder keine langen IDs im LOG-Block (!=).

Bei der Erzeugung von Kommentaren müssen Frontends den Inhalt der #-Zeile der kommentieren Nachricht in die --Zeile der neuen Nachricht, und den Inhalt der I-Zeile der kommentierten Nachricht in die R-Zeile der neuen Nachricht einsetzen. Hat die kommentierte Nachricht keine I-Zeile gehabt, ist auch keine R-Zeile zu erzeugen.

* Gruppen- und Empfängerangaben
Gruppen/Empfängerangaben sind bei Kommentaren optional. Auch wenn alle derzeitigen Boximplementationen in der Lage sind, aus der kommentierte Nachricht den Empfänger oder die Gruppe festzustellen, sollten Frontends dennoch diese Angaben mitschicken. Zum einen kann dann die Nachricht auch weitergeleitet werden, wenn die kommentierte Nachricht in der Box nicht (mehr) vorhanden ist, zum anderen könnte der Benutzer das Frontend mit einem Formatkonverter benutzen und an einem System pollen, daß nicht MausTausch benutzt und die fehlenden Angaben nicht toleriert (für den Konverter ist es möglicherweise unmöglich, die Angaben zu erzeugen).

* Betreff und Distribution
Auch Betreff- und Distributionszeilen sind bei Kommentaren an einer MAUS optional, weil MAUS diese Angaben aus der kommentierten Nachricht holt. Quark lehnt Nachrichten ohne Betreff generell ab und setzt als Defaultdistribution Net ein.

* Followup-To
Enthält die kommentierte Nachricht eine (oder mehrere) F-Zeilen, so sollte das Frontend die angegebenen Gruppen als Default-Zielgruppen für den Kommentar anbieten. Tips:

Siehe section F :: Followup-To.

* Reply-To
Falls eine T-Zeile angegeben ist, sind persönliche Antworten an die darin angegebene Adresse zu schicken.

Crosspostings

Crosspostings sind Nachrichten, die (mit einer ID) in mehrere Gruppen gehen. Crosspostings sind resourcenschonender als das Versenden mehrerer Nachrichten (geeignete Implementation vorausgesetzt).

Crosspostings sind in anderen Netzen üblich, MAUS beherrscht sie allerdings noch nicht. Quark ab 1.93 kann hingegen damit umgehen (und versendet sie auch an die Benutzer, die nicht explizit etwas anderes einstellen).

Ein Crossposting erkennt man daran, daß nicht eine, sondern mehrere Gruppenzeilen kommen. Siehe section G :: Gruppenangabe, für eine Beschreibung der Gruppenzeile. Mehrere ist eine möglicherweise große Zahl.

Hinweise:

Standard für das Splitten von Nachrichten

Wenn eine Nachricht gesplittet werden muß (was man besser vermeiden sollte), dann müssen den einzelnen Teilen Message-IDs nach folgendem Verfahren gegeben werden:

  1. Die Nachricht wird in N Teile zerlegt.
  2. Die n Teile erhalten folgende N IDs:
    abcd@x.y.z
    abcd@x.y.z:2
    ...
    abcd@x.y.z:{N-1}
    abcd@x.y.z:N
    
  3. N darf dabei auch eine Zahl > 9 sein. Es gilt N > 1, N Element "unsigned int". N als Byte zu deklarieren ist ein Verstoß gegen diesen Standard.
  4. N wird im Dezimalsystem ohne führende Nullen codiert, also z.b.: abcd@x.y.z:12345
  5. Die Teile 2 bis N dürfen untereinander verkettet werden.
  6. Sämtliche Headerzeilen sind in allen Teilen der Nachricht zu duplizieren. Ausnahmen sind ID-Zeile und R/--Zeile.

Ein Programm, das gesplittete Nachrichten wieder zusammensetzen will, kann einen Teil einer gesplitteten Nachricht daran erkennen, daß im Domainpart der ID nach dem letzten Punkt (so einer vorhanden ist - RFC822-Mail zeichnet sich durch unschöne Überraschungen aus) ein Doppelpunkt kommt, dem nur noch Ziffern folgen.

Wenn das zusammensetzende Programm merkt, daß Teile fehlen, ist je nach Typ der Nachricht unterschiedlich zu verfahren:

* News (öffentliche Nachrichten)
Es ist auf den flood-fill-mechanismus des Usenets zu hoffen. Die Nachricht darf keineswegs weitergeleitet werden. Der Implementation steht es allerdings frei, ein paar Tage zu warten, ob der Rest der Nachricht noch eintrifft.
* Mail (persönliche Nachrichten)
Nach einer angemessen (kurzen) Zeit des Warten auf die fehlenden Teile sollte der Rest der Nachricht weitergeleitet werden, möglichst mit einem Hinweis im Text. Das ist eigentlich ein "this should not happen", aber es *kann* passieren wenn aus irgendwelchen Gründen ein Teil einer Mail über einen anderen Weg geroutet wurde. Es ist nicht akzeptabel, daß Mails verschwinden.

Dieselbe Software, die Nachrichten wieder zusammensetzt, muß auch dafür sorgen, daß Kommentarverkettungsinformationen, die sich auf Teile von gesplitteten Nachrichten beziehen, angepaßt werden (durch Entfernen des :N am Ende der Referenz-ID).

Das Verfahren zeichnet aus:

Go to the previous, next section.