MausTausch-Doku
Das MausTausch-Format beschreibt, wie die Pakete für den Datenaustausch zwischen den verschiedenen Systemen im MausNet aufgebaut sind. (Eine Ausnahme bildet zur Zeit noch die Kommunikation von MAUS-Boxen untereinander, die mittels eines undokumentierten Binärformats stattfindet.)
MausTausch-Doku
Einführung in das MausTausch-Format
Für folgende Übertragungswege werden Pakete im MausTausch-Format gebraucht:
MausTausch-Doku
Einführung in das MausTausch-Format
Die Datenpakete bestehen aus reinem ASCII-Text. Im Textteil von Nachrichtenblöcken sind zum Teil systemspezifische Sonderzeichen erlaubt.
Ein Paket ist in Blöcke unterteilt. Jeder Block enthält eine Nachricht, einen Informationstext oder spezielle Daten oder Kommandos.
Die Blöcke wiederum bestehen aus Zeilen, deren jeweils erstes Zeichen angibt, was diese Zeile enthält.
Von der Transportrichtung der Datenpakete hängt es ab, wie sie bezeichnet werden. Generell gilt: Pakete, die zu einer MausNet-Box geschickt werden, müssen "INFILE.TXT" heißen; Pakete, die von einer MausNet-Box kommen. heißen "OUTFILE.TXT".
Bei der Kommunikation zwischen Benutzer und MausNet-Box dürfen die Pakete vom Benutzer mit einem der Packer komprimiert sein, die die jeweilige Box anbietet. Das Archiv muß ebenfalls "INFILE.xxx" heißen, wobei "xxx" abhängig vom verwendeten Packer ist.
Sofern das Infile gepackt war, komprimiert die Box das Outfile mit dem gleichen Packer und benutzt als Archivnamen "OUTFILE.xxx". "xxx" ist wieder abhängig vom benutzen Packer.
MausTausch-Doku
Einführung in das MausTausch-Format
Die verschiedenen Blöcke, aus denen die Datenpakete bestehen, lassen sich grob in Nachrichten und Spezialmitteilungen trennen. Als "Nachrichten" werden dabei von Benutzern an andere Benutzer versandte Texte bezeichnet. Alles, was technische oder für Maschinen aufbereitete Informationen enthält, wird in Form von "Spezialmitteilungen" übertragen.
Es gibt zwei Arten von Nachrichten:
Spezialmitteilungen gibt es zur Zeit folgende:
| HEAD | Kopfblock im Outfile
|
| REN | Gruppenumbenennungsinformationen
|
| CMD | Kommandos via MausTausch
|
| LOG | Rückmeldungen
|
| OUT | Kommandoausgaben
|
| CNF | MausNet-Konfigurationsfile
|
| UPL | Upload-Block im Infile
|
Wichtig! Unbekannte Blöcke sind generell zu ignorieren.
MausTausch-Doku
Einführung in das MausTausch-Format
Folgende Formen von Adressen können auftreten:
Reiner Luser @ MEoder
Reiner Luser@ME
Reiner Luser @ ME.maus.deoder
loginname @ irgendwo.de
Reiner Wahn @ Fido 444:555/666.777
MausTausch-Doku
Einführung in das MausTausch-Format
Datum und Uhrzeit werden, wenn sie maschinenlesbar sein sollen, im Format 'YYYYMMDDHHMM' angegeben. Da Zeitzoneninformationen fehlen, ist immer von der in Deutschland, Österreich und der Schweiz gültigen Zeitzone MEZ oder MESZ (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'.
Beispiel:
199808061543steht für den 6.8.1998 15:43
MausTausch-Doku
Einführung in das MausTausch-Format
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).
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. (!nl)'nnnnn' ist eine Zahl
im Bereich von 0 bis 65535.
(!nl)'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 in die Kurzform umsetzt.
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 Zukunft 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 vor dem '@' nennt sich "Local-Part", der Teil nach dem '@' ist der "Domain-Part".
Der Local-Part ist muß casesensitiv behandelt werden, der Domain-Part ist 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 Spezialmitteilungen von der Box an den Benutzer oder das Frontend, oder umgekehrt.
MausTausch-Doku
Einführung in das MausTausch-Format
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 zurückgestellt,
was bedeutet, daß er sie zwar gelesen hat, aber erst später
entscheiden will, ob er antwortet.
|
| B | Die Nachricht wurde beantwortet.
|
| G | Die Nachricht wurde gelesen, aber nicht beantwortet.
|
| M | Die Nachricht ist im MausNet aber 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.
Wichtig! Falsche Statusmeldungen sind in jedem Fall zu vermeiden.
MausTausch-Doku
Einführung in das MausTausch-Format
Die Distribution gibt an, über welchen Bereich eine Nachricht verteilt werden soll. Die Angabe der Distribution erfolgt Über die 'D'-Zeile:
| L | Die Nachricht soll nicht über die lokale Box hinaus verteilt
werden.
|
| M | Die Nachricht soll nicht über das MausNet hinaus verbreitet
werden.
|
| N | 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.
Die Quark II verwendet in keinem Fall die Distribution der kommentierten Nachricht.
Natürlich haben persönliche Nachrichten keine Distribution.
MausTausch-Doku
Einführung in das MausTausch-Format
MAUS erlaubt zur Zeit nur Nachrichten von bis zu 16000 Bytes Länge. Dabei werden die Doppelpunkte am Zeilenanfang nicht mitgerechnet, und das Zeilenende nur als ein Zeichen gerechnet. Für die Zukunft ist eine Erhöhung dieses Limits geplant. Bei anderen Boximplementationen gibt es kein Limit.
Textzeilen können sehr lang werden, einziges Limit ist die maximale Messagelänge.
Die MAUS löscht beim Import der Nachricht Leerzeilen am Anfang und Ende sowie größere Mengen (mehr als drei) Leerzeilen in der Nachricht. Die Quark tut dieses nicht.
Kontrollzeichen außer TAB (0x09), LF (0x0A), CR (0x0D), DC4 (0x14) und NAK (0x15) werden von MAUS in Fragezeichen (?) umgewandelt. Auch dies unterläßt die Quark.
Die Zeilen werden, bevor sie zum Benutzer geschickt werden, noch einer Umlautwandlung (sofern nötig) unterzogen und auf Wunsch auch umgebrochen.
Enthält der Header einer Nachricht eine 'M'-Zeile, werden keine der oben angegebenen Veränderungen vorgenommen - auch keine Umlautwandlung.
Das 16000-Byte-Limit macht es notwendig, daß lange Nachrichten beim Übergang von anderen Netzen ins MausNet gesplittet werden.
MausTausch-Doku
Einführung in das MausTausch-Format
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 im IBM-PC-Zeichensatz (Codepage 437). Beim Transfer der Nachrichten zur MAUS muß daher eine Zeichensatzwandlung durchgeführt werden.
Die MAUS bis Version 7.96a und die Quark 1.x wandlen 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 ASCII-Werts übernommen.
Ab der Version 7.96b unterstützt die MAUS die Zeichensatzwandlung nach ITZ. Das Infofile ITZ wurde erstmals am 14.10.1997 von Udo Halfmann @ K2 in TAUSCHBAU vorgeschlagen. Siehe A31567@K2.
MausTausch-Doku
Einführung in das MausTausch-Format
Umlautwandlung
Während bislang nur die Umlaute und das scharfe S konvertiert wurden, wird bei der Zeichensatzwandlung nach ITZ alles übersetzt, was im Zielzeichensatz vorhanden ist. Genaugenommen gibt es bei der Umwandlung eines Zeichens drei Möglichkeiten:
Nachrichten werden in Zukunft also in der vom Absender gelieferten Form bis zur Empfänger-MAUS transportiert, die dann eine Wandlung direkt vom Sender- in den Empfängerzeichensatz vornimmt. Bei gleichen Systemen auf beiden Seiten ergibt sich so auch bei exotischen Zeichen kein Verlust mehr. Außerdem kann der Empfänger auch ganz auf die Zeichensatzwandlung verzichten, wenn er möchte (Kommando TC).
MausTausch-Doku
Einführung in das MausTausch-Format
Umlautwandlung
Gruppe: TAUSCHBAU
ID: A31567@K2
Wg.: Vorschlag für Infofile ITZ
Von: Udo Halfmann @ K2 (Di, 14.10.97 02:29)
MId: 199710140229.a31567@k2.maus.de
Hierzu gibt es 2 Kommentare
Hi.
Ich würde gerne ein neues Infofile vorschlagen. Es soll
maschienenlesbar sein, von Zeichensätzen handeln, und als Namen
schlage ich ITZ vor.
Motivation
==========
Die Motivation für das ITZ ist folgende: Ein großes Problem von
Frontends, die MIME unterstützen wollen, sind die Zeichensätze, die
im Usenet/Internet benutzt werden. Nur die wenigstens im MausNet
verbreiteten Plattformem (als Plattform bezeichne ich eine
Kombination aus Hardware und Betriebssystem) unterstützen die
Zeichensätze ISO-8859-1 (Latin1) und (für die Zukunft) Unicode 2.0
von Hause aus. Es stellt sich also das Problem, diese beiden
Zeichensätze in den Zeichensatz der benutzten Plattform umzuwandeln.
Hierbei soll das ITZ helfen, indem es sämtliche Informationen zu im
MausNet gebräuchlichen Zeichensätzen zentral in einem
maschienenlesbaren Infofile zur Verfügung stellt. Das ITZ wird im
Prinzip nur genau einmal erstellt und dann über den Mechanismus
Infofile im ganzen MausNet verteilt.
Ich erkläre mich dazu bereit, das ITZ zu erstellen, es ggf. zu
pflegen und Informationen zum ITZ und diversen Zeichensätzen zentral
zu sammeln und über den Programmteil der Maus K2 sowie das Internet
zu verbreiten.
Format
======
Als Format für das ITZ schlage ich Folgendes vor:
Das ITZ besteht aus Z- und #-Blöcken. Die Z-Blöcke stehen alle vor
dem ersten #-Block, damit das ITZ leicht zu parsen ist.
Z-Zeile: Beginnt die Definition eines Zeichensatz. In der Zeile steht
eine Id für diesen Zeichensatz. Die Id bleibt für einen zeichensatz
auch bei geändertem ITZ immer gleich und kann damit ggf. im Frontend
fest verdrahtet werden.
I-Zeile: Diese Zeile definiert ein Kürzel von genau einem Zeichen mit
einem ASCII-Code von 33 bis 126 je Zeichensatz. Dieses eine Zeichen
dient dazu, die C-Zeilen leichter parsen zu können und spart viel
Speicherplatz.
B-Zeile: Gibt die Breite des Zeichensatz an: 7 oder 8 Bit.
D-Zeile: Die Beschreibung/der Name eines Zeichensatz in ausführlicher
Form
F-Zeile: Diese Zeile enthält Flags wie aus dem ITG bekannt. Als
einziges Flag schlage ich ein S-Flags mit den Werten '+' und '-' vor,
dessen Bedeutunmg weiter unten erläutert wird. Ggf kann man auch die
B-Zeile durch ein geeignetes Flag ersetzen.
#-Zeile Begin der Definition eines Unicode-Zeichens. In der Zeile
steht die Codeposition des Zeichens in Form von 4 Hex-Ziffern
N-Zeile: Der offizielle Unicode 2.0-Name des Zeichens
S-Zeile: Der SGML-Name des Zeichens (falls vorhanden). Das führenden
'&' und das abschießende ';' müssen noch ergänzt werden. Mit dieser
Zeile kann man das ITZ auch im Zusammenhang mit HTML und anderen SGML-
Ablegern benutzen.
E-Zeile: Eine Ersatzdarstellung des Zeichens mit den ASCII-Zeichen 32
bis 126. Hier können mehrere Zeichen vorkommen und auch Leerzeichen
am Zeilenende auftreten. (falls vorhanden).
C-Zeile: Gibt die Position des Zeichens in einem oder mehreren der
oben definierten Zeichensätze an. Die ersten beiden Zeichen bilden
mit 2 Hex-Ziffern die Codeposition des Zeichens, dann folgt ein
Gleichheitszeichen als syntaktischer Zucker (macht das Ganze etwas
übersichtlicher) und dann folgt eine Liste von Zeichensatzkürzeln (I-
Zeile) all der Zeichesätze, bei denen das Unicode-Zeichen an der
genannten Codeposition auftaucht. Je Unicode-Zeichen sind mehrere C-
Zeilen zulässig.
Ein erster Entwurf des ITZ befindet sich in der nachfolgenden
Mitteilung. Hier ist noch nichts endgültig und insbesondere über die
Ids der Zeichensätze kann man noch diskutieren.
unterstützte Zeichensätze
=========================
Nun zu dem Problem, welche Zeichensätze im ITZ enthalten sein
sollten. Als ich mich das letzte mal eine Maus neu eingetragen habe,
wurden mir folgende Umlautwandlungen angeboten:
>Umlaute: (N)icht, ISO 646-(D)E, (I)BM PC, Atari (S)T, ISO (8)859-1,
> (M)acintosh, Sinclair (Q)L oder Ne(X)T: I
Für fast alle diese Zeichensätze habe ich auf www.unicode.org oder an
anderen Quellen Abbildungstabellen von diesen Zeichensätzen auf
Unicode 2.0 gefunden. Diese Tabellen habe ich teilweise leicht
ergänzt und erzeuge daraus automatisch mit einem perl-Skript das ITZ.
Das einzige Problem ist zur Zeit der Sinclar Spectrum QL-Zeichensatz,
da ich für diesen keine Abbildungstabelle finden konnte. Aber ich
gehe mal davon aus, daß man diese Plattform heutzutage getrost
ignorieren kann.
Zusätzlich habe ich die Codepage 1251 aufgenommen. Dies ist der
übliche Windows-Zeichensatz. Im Prinzip ist es Latin1 mit
Erweiterungen im Bereich 80-9F, der in Latin1 unbenutzt ist.
Desweiteren habe ich ISO-8859-2 bis ISO-8859-9 aufgenommen, weil dies
neben US-ASCII die einzigen durch MIME im Usenet/Internet offiziell
definierten Zeichesätze sind. Ich habe diese Zeichensätze zwar nie in
einer Mitteilung zu Gesicht bekommen, aber außer 10 KB im ITZ schadet
ihre Aufnahe auch nicht.
ISO-646-DE ist der ASCII-Zeichensatz, bei dem die eckigen und
geschweiften Klammern und drei weitere Zeichen durch die 7 deutschen
Umlaute ersetzt wurden. Ein entsetzlicher Hack und nur auch
Kompatiblität zur Maus enthalten.
Zu einigen Adobe-Zeichensätzen (Postscript) besitze ich
Umwandlungstabellen, aber ich glaube, Ihr Einsatz ist für MausTausch-
Frontends nicht notwendig. Auch diverse nicht-mitteleuropäische
Ableger von Windows- und Apple-Zeichensätzen brauchen wir wohl nicht
zu berücksichtigen.
Unicode 2.0 selber ist durch die Struktur des ITZ bereits enthalten.
Es sind nur die Zeichen vorhanden, die in mindesten einem anderen
Zeichensatz vorkommen.
Die von mir für sinnvoll gehaltenen Zeichensätze sind:
Der eigentliche ASCII-Standard (nur 7 Bit!!!):
- ISO-646 (US-ASCII)
Die vollständige ISO-Familie
- ISO-8859-1 (Latin1)
- ISO-8859-2 (Latin2)
- ISO-8859-3 (Latin3)
- ISO-8859-4 (Latin4)
- ISO-8859-5 (Kyrillisch)
- ISO-8859-6 (Arabisch)
- ISO-8859-7 (Griechisch)
- ISO-8859-8 (Hebräisch)
- ISO-8859-9 (Latin5)
Die PC-Welt:
- Codepage 437 (MS-DOS)
- Codepage 850 (OS/2)
- Codepage 1252 (Windows Latin1)
- IBM-PC-Symbole im Textmodus
Andere Herstelle:
- Apple Roman
- Atari ST
- NextStep
Eine historische Altlast (7 Bit):
- ISO-646-DE (US-ASCII mit Umlauten)
Bei Bedarf kann ich auch etwas über die einzelnen Zeichesätze und
ihre Zusammenhänge und Geschichte erzählen. Wer Vorschläge für
weitere aufzunehmende Zeichensätze hat, darf die ruhig vorbringen und
mir nach Möglichkeit auch eine Quelle für eine Abbildungstabelle
nennen.
Erweiterungen des ITZ
=====================
Zu Unicode 2.0 gibt es eine große Datei, in der zu jedem der ca. 6500
Zeichen (ohne chinesiche Schriftzeichen) ein paar Attribute stehen.
Einige dieser Attribute sind vielleich auch im MausNet interessant,
so daß man sie im ITZ aufnehmen könnte. Zusätzlich könnte man das ITZ
auch um Zeichen erweitern, die nicht in einem der bisher im MausNet
benutzten Zeichensätze vorkommen.
Anwendungen des ITZ
===================
An Anwendungsmöglichkeiten für das ITZ habe ich folgendes im Sinn:
- Als allererstes natürlich die Zeichensatzwandlung von ISO-8859-1
bzw. Unicode 2.0 in den Zeichensatz der benutzten Plattform. Und zwar
sowohl bei Frontends, als auch bei Out- und Infilefiltern und ggf.
sogar in der Maus selber.
- Bei neu erstellen Mitteilungen könnte ein Frontend z.B. prüfen, ob
alle in der Mitteilung benutzten Zeichen auch in anderen, vorher
konfigurierten anderen Zeichensätzen vorkommen. Damit stellt man
sicher, daß man viele andere Mauser nicht mit Zeichen belästigt, die
diese im Regelfall nicht darstellen können. Im wesentlichem würde das
bedeuten, daß neben den 7 deutschen Umlauten auch noch viele
Buchstaben mit Akzenten benutzbar sind. Eine Default-Menge von diesen
Zeichensätzen könnte man in der F-Zeile durch das Flag S+
kennzeichnen.
Die Schnittmenge von Atari, Apple, Next, CP437, CP850, CP1252 und
ISO-8859-1 wären diese 48 Zeichen:
00A1: INVERTED EXCLAMATION MARK
00A2: CENT SIGN
00A3: POUND SIGN
00A5: YEN SIGN
00AA: FEMININE ORDINAL INDICATOR
00AB: LEFT-POINTING DOUBLE ANGLE QUOTATION MARK
00AC: NOT SIGN
00B1: PLUS-MINUS SIGN
00B5: MICRO SIGN
00B7: MIDDLE DOT
00BA: MASCULINE ORDINAL INDICATOR
00BB: RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK
00BF: INVERTED QUESTION MARK
00C4: LATIN CAPITAL LETTER A WITH DIAERESIS
00C5: LATIN CAPITAL LETTER A WITH RING ABOVE
00C6: LATIN CAPITAL LETTER AE
00C7: LATIN CAPITAL LETTER C WITH CEDILLA
00C9: LATIN CAPITAL LETTER E WITH ACUTE
00D1: LATIN CAPITAL LETTER N WITH TILDE
00D6: LATIN CAPITAL LETTER O WITH DIAERESIS
00DC: LATIN CAPITAL LETTER U WITH DIAERESIS
00DF: LATIN SMALL LETTER SHARP S
00E0: LATIN SMALL LETTER A WITH GRAVE
00E1: LATIN SMALL LETTER A WITH ACUTE
00E2: LATIN SMALL LETTER A WITH CIRCUMFLEX
00E4: LATIN SMALL LETTER A WITH DIAERESIS
00E5: LATIN SMALL LETTER A WITH RING ABOVE
00E6: LATIN SMALL LETTER AE
00E7: LATIN SMALL LETTER C WITH CEDILLA
00E8: LATIN SMALL LETTER E WITH GRAVE
00E9: LATIN SMALL LETTER E WITH ACUTE
00EA: LATIN SMALL LETTER E WITH CIRCUMFLEX
00EB: LATIN SMALL LETTER E WITH DIAERESIS
00EC: LATIN SMALL LETTER I WITH GRAVE
00ED: LATIN SMALL LETTER I WITH ACUTE
00EE: LATIN SMALL LETTER I WITH CIRCUMFLEX
00EF: LATIN SMALL LETTER I WITH DIAERESIS
00F1: LATIN SMALL LETTER N WITH TILDE
00F2: LATIN SMALL LETTER O WITH GRAVE
00F3: LATIN SMALL LETTER O WITH ACUTE
00F4: LATIN SMALL LETTER O WITH CIRCUMFLEX
00F6: LATIN SMALL LETTER O WITH DIAERESIS
00F7: DIVISION SIGN
00F9: LATIN SMALL LETTER U WITH GRAVE
00FA: LATIN SMALL LETTER U WITH ACUTE
00FB: LATIN SMALL LETTER U WITH CIRCUMFLEX
00FC: LATIN SMALL LETTER U WITH DIAERESIS
00FF: LATIN SMALL LETTER Y WITH DIAERESIS
- wenn ein Frontend ein Zeichen nicht umwandeln kann, weil das
Zeichen im Zeichensatz der Plattform nicht vorkommt, so sollte es
doch wenigstens versuchen, dem Benutzer den Unicode-Namen dieses
Zeichens anzuzeigen, da man aus diesem Namen in vielen Fällen auf die
Bedeutung des Zeichens schließen kann. Möglichkeiten der Anzeige
wären bei einer GUI eine Sprechblasen-Hilfe oder einfach eine Liste
der Namen der unbekannten Zeichen am Ende der Mitteilung.
Schö | |_|
|_|d|o
MausTausch-Doku
Einführung in das MausTausch-Format
MausTausch-Doku
Einführung in das MausTausch-Format
Blick über den Zaun
Im Usenet kennt man nicht nur eine Angabe für den Absender, sondern drei:
MausTausch-Doku
Einführung in das MausTausch-Format
Blick über den Zaun
MIME ist der Standard für Mail im Internet. MIME bietet unter anderem Multimedia. Im MausNet werden wahrscheinlich Teile davon übernommen, insbesondere 'text/enriched', der die Möglichkeiten von normalen Texten u.a. um Textattribute und Textformatierung erweitert.
MIME ist in RFC1521 beschrieben, 'text/enriched' in RFC1563. Für Gatewayprogrammierer ist auch noch RFC1522 interessant.
MausTausch-Doku
Einführung in das MausTausch-Format
Blick über den Zaun
Multipurpose Internet Mail Extensions
Um MIME-Nachrichten im MausNet durchreichen und gewisse Teile davon auch im MausNet nutzen zu können wurde folgende Regelung getroffen:
Content-Transfer-Encoding: (quoted-unreadable) quoted-printable
Content-Transfer-Encoding: quoted-printable
Anmerkung: Im Zusammenhang mit Textkludges (insbesondere Reply-To und Followup-To) entsteht das Problem, daß einige Programme die Kludges nur verarbeiten können, wenn sie die Kludges am Anfang der Nachricht finden. Daher sollten Textkludges (wenn man nicht ohnehin auch Headerzeilen ausweichen kann) in RFC-Syntax in den MIME-Header geschrieben werden.
MausTausch-Doku
Einführung in das MausTausch-Format
Blick über den Zaun
Multipurpose Internet Mail Extensions
Zur Verdeutlichung etwas C-Source (von Uwe Ohse):
... wpos zeigt auf das Ende der M-Headerzeile in voller Länge, nach
... Entfernung der Kommentare. line ist der Start dieser Zeile.
if (wpos - line > 200) {
/* Oh hilfe - das habe *ich* mit verschuldet (und ganz anders
* gemeint). */
fputs ("M1.0; Content-Type: obscure/anything; "
"really too many parameters", f);
/* "M1.0; " überspringen */
m_content_type_for_body = XSTRDUP (line + 6);
/* bis zum Beweis des Gegenteils glaube ich nicht daß das
gutgeht */
meta->mausflags.exportflag=XR_MINUS;
meta_add_trace(meta,4,"noexport set, too lang content-type
line");
} else
fputs (line, f);
... later ... "body"-Ausgabe
/* ich hoffe an dieser Stelle irgendwann >-Zeilen ausgeben zu
dürfen */
/* So, nun sind Textkludges auszugeben */
/* Eventuell paßte der Content-Type nicht in die Headerzeile */
if (m_content_type_for_body) {
textsize += fprintf (f, ":%s" LINEEND, m_content_type_for_body);
free (m_content_type_for_body);
}
/* sonstige MIME-relevante Header ausgeben */
if (meta->content_id)
textsize += fprintf (f, ":Content-ID: %s" LINEEND,
meta->content_id);
if (meta->content_description)
textsize += fprintf (f, ":Content-Description: %s" LINEEND,
meta->content_description);
... dann noch Keywords, Reply-To (wenn die Box das nicht sowieso
... schon kennt), Summary, Newsgroups (wenn Crossposting und die
... Box keine Crosspostings versteht), etc usw.
Anders gesagt: ich schleuse im MIME-Header noch so einiges
mehr durch ;-)
MausTausch-Doku
Einführung in das MausTausch-Format
MausTausch-Doku
Einführung in das MausTausch-Format
Was ein Frontend können sollte
Frontends sollten bei der Erzeugung von Kommentaren auf folgende Punkte achten:
MausTausch-Doku
Einführung in das MausTausch-Format
Was ein Frontend können sollte
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 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. 'Mehrere' ist eine möglicherweise große Zahl.
Hinweise
MausTausch-Doku
Einführung in das MausTausch-Format
Wenn eine Nachricht gesplittet werden muß (was man besser vermeiden sollte), dann müssen den einzelnen Teilen Message-IDs nach folgendem Verfahren gegeben werden:
abcd@x.y.z
abcd@x.y.z:2
...
abcd@x.y.z:{N-1}
abcd@x.y.z:N
abcd@x.y.z:12345
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:
Copyright © by Andreas Mayer
Letzte Aktualisierung am 10. September 1998