Home | Go to the previous, next section.
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.
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.
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:
Spezialmitteilungen zerfallen wiederum in verschiedene Kategorien:
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'.
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'.
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.
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:
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.
nicht gelesen.
zurueckgestellt, was bedeutet,
daß er sie zwar gelesen hat, aber erst später entscheiden will, ob
er antwortet.
beantwortet.
gelesen, wurde aber nicht beantwortet.
angekommen.
Gateway das MausNet verlassen.
kopiert.
weitergegeben.
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.
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)
M == (MausNet)
N == (Net)
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.
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.
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.
Von
From - Wer hat diese Nachricht verfasst?
Sender - Wer hat die Nachricht abgeschickt?
Reply-To - An wen sollen die Antworten gehen?
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.
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 inI- undR-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.
Net ein.
Siehe section F :: Followup-To.
T-Zeile angegeben ist, sind persönliche
Antworten an die darin angegebene Adresse zu schicken.
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:
abcd@x.y.z
abcd@x.y.z:2
...
abcd@x.y.z:{N-1}
abcd@x.y.z:N
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:
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:
Home | Go to the previous, next section.