Inhalt | Mailbox | Elektronik | Verkehr | Markt | Download | Geld | Suchen
|
Inhalt | Mailbox | Elektronik | Verkehr | Markt | Download | Geld | Suchen |
-Vorläufer-Draft-Vorläufer-Draft-Vorläufer-Draft-Vorläufer-Draft-
ß-VERSION
basierend auf ZConnect 3.0 (Zerberus GmbH)
und den Beschlüssen des ZConnect-Gremiums bis zum 1.10.1995
Diese Dokumentation darf frei aber nur komplett kopiert und weitergegeben werden. Änderungen an ZConnect beschließt das ZConnect-Gremium, Änderungen an dieser Dokumentation nimmt ausschließlich die Dokumentationskoordination vor. Vorschläge für Änderungen/Ergänzungen o.?. bitte an DOKUKOO@bingo.comlink.de senden.
-Vorläufer-Draft-Vorläufer-Draft-Vorläufer-Draft-Vorläufer-Draft-
>>> 15.10.1995 <<<
Anmerkungen zu diesem Vorläufer der endgültigen Version bitte in /T-NETZ/ZCONNECT/DISKUSSION posten. DOKUKOO ist derzeit noch nicht erreichbar, private Kommentare bitte an Sepro@bingo.comlink.de
Abschnitte, die mit "#" in der ersten Spalte gekennzeichnet sind, bedürfen vor einer endgültigen Formulierung der Diskussion im Gremium. Abschnitte, die nicht so gekennzeichnet sind, werden möglicherweise ebenfalls noch geändert werden. Mit einiger Sicherheit enthält die folgende Dokumentation noch Fehler. Außerdem sind komplette Kapitel "zur Diskussion" enthalten, so daß dieser Text _in dieser Form_ den Status von Sekundärliteratur hat.
-Vorläufer-Draft-Vorläufer-Draft-Vorläufer-Draft-Vorläufer-Draft-
INHALTSVERZEICHNIS
1. Hinweise zur Notation
2. Historie 2.1. Vom Hausstandard der Zerberus GmbH zu einem freien Protokoll 2.2. Kurzhistorie des /Z-Netzes 2.3. Das ZConnect-Gremium 2.4. Die ZConnect-Dokumentation 2.5. Rechte am Protokoll
3. Dokumentation 3.1. Onlinephase 3.2. Übertragene Dateien 3.3. Datenformat 3.3.1. Die Teile einer Nachricht 3.3.1.1. Headerinformationen 3.3.1.1.1. Aufbau und Zeichensatz von Headerinformationen 3.3.1.1.2. Adressenformat 3.3.1.1.2.1. Zeichensätze bei der Adresse 3.3.1.1.2.2. Private Nachrichten 3.3.1.1.3. Brettnamenformat 3.3.1.1.3.1. Öffentliche Nachrichten 3.3.1.1.4. Datumsangaben 3.3.1.2. Form des Bodys 3.3.2. ZConnect-Headerinformationen 3.3.2.1. Fest definierte Headerzeilen 3.3.2.2. Frei definierbare Headerzeilen 3.3.2.3. Headerzeilen aus anderen Datenformaten 3.3.2.3.1. UUCP 3.3.2.3.2. Fido 3.3.2.3.3. Z3.8 3.3.2.4. Headerzeilenvorhersage 3.4. Zusammenhänge 3.4.1. Informationelle Selbstbestimmung und Datenschutz 3.4.1.1. Zeitangaben 3.4.1.1.1. EDA 3.4.1.1.2. VIA 3.4.1.2. KOP 3.4.1.3. Wechsel von privaten Nachrichten über Netzgrenzen hinweg 3.4.2. Dupe- und Rekursionscheck 3.4.2.1. Dupecheck anhand der Message-IDs 3.4.2.2. Rekursionscheck anhand des Routepfads (ROT) 3.4.3. Weiterleiten 3.4.3.1. Manuelles Weiterleiten 3.4.3.1.1. Passives Weiterleiten 3.4.3.1.2. Aktives Weiterleiten 3.4.3.2. Automatisches Weiterleiten 3.4.3.3. Weiterleiten im Netz: Umleiten 3.4.4. Gemischtadressierung 3.4.5. Verschlüsselung 3.4.5.1. PGP 3.4.5.1.1. Grundsätzliches 3.4.5.1.2. Transport der Schlüsselinformation 3.4.5.1.3. Unterschriften 3.4.5.2. QPC: 3.4.6. Points 3.5. Maps-Standard 3.5.1. Die Maps-Befehle 3.5.1.1. Pflichtbefehle 3.5.1.2. Listenformat 3.5.1.3. Optionale Befehle 3.5.2. Kritik und Vorschläge 3.5.2.1. Maps und die vergessene Onlinephase 3.5.2.2. Maps aus Sicht des angeschriebenen Systems 3.5.2.3. Schwierigkeiten bei der Umsetzung des Gedankens, Maps transparent zu gestalten
4. Ergänzende Informationen 4.1. Datenschutzbestimmungen 4.2. Fremdformate 4.2.1. RFC 4.2.2. Z 3.8 4.2.3. Fido 4.3. MIME 4.4. Einige softwaretechnische Vorschläge 4.4.1. Hashverfahren für Rekursionscheck
5. Stand der Dinge
Anhänge
A) Literaturverzeichnis B) Glossar C) ZC 3.1 Grammatik in BNF D) Datenformatsübersicht D) 1. Tabellarische Übersicht der Headerinformationen D) 2. Liste der Pflichtinformationen D) 3. Liste der das Routing beeinflussenden Informationen E) Routing F) Janus und verwandte Protokollvarianten G) Zeichensätze H) Zeitzonen I) Liste der ZConnect-Programme
Fußnoten
1. HINWEISE ZUR NOTATION
Alle Zahlenangaben sind in dezimaler Schreibweise angegeben, sofern nicht ausdrücklich anderes ausgesagt wird. Ein Byte besteht aus acht Bits und deckt den Zahlenraum 0..255 ab.
Literaturhinweise sind im fließenden Text durch eckige Klammerung gekennzeichnet. Die Klammerinhalte sind der einfacheren Auffindbarkeit halber nicht schlicht durchnumeriert, sondern mit Kürzeln versehen. "PM" verweist hierbei auf eine persönliche Mitteilung, "D" auf einen Teil der zugrundegelegten Ursprungsdokumentation und "B" auf eine Brettnachricht. Daneben sind einige wichtige Dokumente direkt mit ihrem Namen gekennzeichnet (z.B. [Netikette]).
Die wichtigsten, im Zusammenhang mit ZConnect am häufigsten verwendeten Fachbegriffe werden im Anhang B in Form eines Glossars erläutert.
2. HISTORIE
Zum Verständnis vom ZConnect ist dessen Entstehungsgeschichte ein wichtiger Aspekt. Dieses Kapitel zeichnet die Entwicklung des Protokollumfelds bis zum heutigen Stand in Grundzügen nach.
2.1. Vom Hausstandard der Zerberus GmbH zu einem freien Protokoll
Das ZConnect-Protokoll wurde nach Aussage von Mitarbeitern der Zerberus GmbH im wesentlichen von Martin Husemann entworfen ([PM1]). Es wurde als Nachfolger des Z3.8-Netcallformats konzipiert, welches im Anhang G beschrieben ist und teilweise, allerdings ausschließlich im Rahmen der Janus-Protokollvarianten, noch immer Bedeutung hat.
Die Zerberus GmbH implementierte ZConnect zunächst für ihr Hauptprodukt "Zerberus", ein Mailboxprogramm. Am 3. August 1993 veröffentlichte die Firma dann ZConnect 3.0 als gedruckte Dokumentation ([D3.0]), schon im Dezember 1992 wurde aber in /T-NETZ/SUPPORT/ZCONNECT von einer vorliegenden ZConnect-Dokumentation gesprochen ([B1]).
2.2. Kurzhistorie des /Z-Netzes
Als privates Vernetzungsprojekt entstanden, verband das /Z-Netz in seinen Entstehungsjahren bürgerrechtsbewegte Menschen miteinander. Dabei wurde in den ersten Jahren mit dem Z3.8-Netcallformat zwischen Systemen ausgetauscht, die sich als "/Z-Netz-System" betrachteten, sich also bestimmten Regeln unterwarfen, wie z.B. der noch heute bestehenden Verpflichtung, die Bretter des Netzes immer komplett anzubieten und weiterzureichen. Das /Z-Netz versteht sich heute noch als mehr als die gleichnamige Bretthierarchie; mittlerweile sind UserInnenwahlen eingeführt worden, es gibt KoordinatorInnen (allgemein und technisch) und Benimmregeln, die in der [Netikette] formuliert sind.
Nachdem Anfang 1994 das technische Verfahren der Datennavigation im /Z-Netz auf das im Internet übliche Domainrouting (s. Kapitel "Adressen") umgestellt und damit das vorher verwendete, manuell erstellte und anhand von festen Plänen durchgeführte Verfahren ersetzt wurde, stellt sich das Netz logisch als Teil des Internetadreßraums dar.
Heute versteht sich das /Z-Netz als unabhängig von der eingesetzten Technik ([Netikette]), noch immer wird auf /Z-Netz-Systemen aber - vermutlich mehrheitlich - das Nachfolgeprotokoll der alten Z3.8-Technik, nämlich ZConnect, eingesetzt.
2.3. Das ZConnect-Gremium
Auf Vorschlag von Martin Husemann entstand Ende 1993 das anfänglich aus zehn Personen bestehende ZConnect-Gremium ([B2]). Auf der Grundlage der Dokumentation der Protokollversion 3.0 begann dann dessen Arbeit. Das Gremium bestand und besteht aus Menschen, die an der Pflege ZConnects mitarbeiten und erweitert sich durch ein Wahlverfahren. Etwa zeitgleich wurde die Arbeit an ZConnect von /T-NETZ/SUPPORT/ZCONNECT nach /T-NETZ/ZCONNECT/* verlagert.
In /T-NETZ/ZCONNECT/MELDUNGEN sind alle Wahlaufrufe und -ergebnisse, die aktuelle Liste der Gremiumsmitglieder ([Mitglieder]) und auch Listen von ZConnect-fähigen Programmen zu finden. Aktuelle Diskussionen sind in /T-NETZ/ZCONNECT/DISKUSSION mitzuverfolgen.
Seit Existenz des Gremiums sind unter Leitung von Hinrich Donner (hd@wf-hh.shnet.org) fünf Wahlen zu ZConnect 3.1 durchgeführt worden ([Wahl1]-[Wahl5]). Die Wahlen finden per geheimer Stimmabgabe an den/die Wahlleiter/in statt. Mit der fünften Wahl sollte die Version 3.1 geschlossen und mit der zur CeBIT'95 durch die Zerberus GmbH vorgestellte Print-Dokumentation ([D3.1Z]) abschließend dokumentiert werden. Jedoch geriet diese Dokumentation in die Diskussion, da sie sich nicht an alle Ergebnisse der erfolgten Wahlen (siehe Hinweise im folgenden bei den einzelnen Headerinformationen) hält und somit ---- nicht ZConnect-kompatibel ist.
Die vom Gremium beschlossenen Änderungen und Erweiterungen sind ohne
Übergangsfristen verbindlich für die AnwendungsprogrammiererInnen{1}.
Frühestens nach sechs Monaten ist eine erneute Abstimmung über eine
abgestimmte Änderungen zulässig ([Wahl1]).
2.4. Die ZConnect-Dokumentation
Die ZConnect-Dokumentation ist ein verstreutes und manchmal auch
etwas zerstreutes Gebilde. Sie bestand bis zum Erscheinen dieses
Textes aus der jeweils letzten Dokumentation der Zerberus GmbH und den
von diesem Zeitpunkt an beschlossenen Änderungen durch das Gremium. In
/T-NETZ/ZCONNECT/MELDUNGEN{2} waren und sind beschlossene
Protokollbestandteile nachzulesen.
Bisher mußte einE potentiellEr ProgrammiererIn die komplette Entwicklung mitverfolgen, [D3.0] zugrunde legen und die vereinzelt beschlossenen Änderungen oder Erweiterungen darauf anwenden, wobei Änderungen auch durchaus vorausgegangene Änderungen betreffen. Diese arbeitsaufwendige Dokumentationsbeschaffung wurde etwas vereinfacht durch zwei Zusammenstellungen von verschiedenen Änderungsständen. Zum einen ist dies das ZConnect-3.1-Proposal von Martin Husemann, wie es in das Brett /T-NETZ/ZCONNECT/DISKUSSION verschickt wurde. Zum anderen existiert eine Zusammenstellung vom Wahlleiter der Gremiumswahlen, mit der Bezeichnung "Änderungen ZConnect 3.1 März bis Dezember '93". Der Status des Proposals ist dabei nie endgültig geklärt gewesen. Anhand eines vollständigen Archivs aller Nachrichten in den einschlägigen Brettern seit deren Bestehen ist es nachträglich als sachlich richtige Zusammenfassung zu bestätigen. Daher fand das Proposal als [D3.1P] Eingang in diese Dokumentation, die Zusammenfassung der Änderungen als [D3.1M].
Die Beschreibung der Onlinephase hingegen liegt aktuell und zusammenhängend nur in der zur CeBIT'95 veröffentlichten Dokumentation "ZConnect 3.1" von der Zerberus GmbH ([D3.1Z]) vor. Diese Phase wurde seit Bestehen des Gremiums von diesem nicht nennenswert bearbeitet oder diskutiert (lediglich im Rahmen der PGP-Einbindung wurde eine neue Headerinformation für die Onlinephase eingeführt).
Beim Datenformat steht der Begriff "die Dokumentation" im folgenden für die Gesamtheit aus [D3.0], [D3.1P] und [D3.1M]. Auch [D3.1Z] beschreibt das ZConnect-Datenformat, weicht jedoch hierbei in einigen Punkten von den Gremiumsbeschlüssen ab. Daher ist es in die Kapitel zum Datenformat nur in Zweifelsfällen oder als Hinweisgeber für sinnvolle Änderungsvorschläge eingegangen.
Die Bezugnahme auf frühere Dokumente dient vor allem dem Konsitenznachweis dieses Textes. Nach Beschluß durch das ZConnect-Gremium ersetzt dieser Text alle früher veröffentlichten Dokumentationsbestandteile zum Datenformat "ZConnect".
2.5. Rechte am Protokoll
Mit der Veröffentlichung der Dokumentation zu ZConnect 3.0 ist das Protokoll für die lizenzfreie Verwendung - auch in kommerziellen Anwendungen - freigegeben. Dies gilt auch für die seitdem erfolgten Änderungen. [D3.0] und [D3.1Z] verlangen aber, daß neben den Copyrightvermerken in Dokumentation und im ZConnect implementierendem Programm, ein Copyrightvermerk der Zerberus GmbH angegeben werden muß. Dies war schon bei ZConnect 3.0 strittig, bei 3.1 ist es das erst recht, da die Änderungen in der Verantwortung des Gremiums und nicht in jener der Zerberus GmbH liegen.
Hintergrund des Bestehens auf das Copyright ist, daß das Protokoll "ZConnect" fest definiert sein, also nicht von Produkten verwendet werden soll, die nicht den vollen Umfang der Spezifikation erfüllen. In der Praxis erfüllt jedoch keine Software den vollen Umfang der Spezifikation.
3. DOKUMENTATION
3.1. Onlinephase
Der Datenaustausch zwischen zwei Systemen erfolgt bei ZConnect nach einem Store-And-Forward-Verfahren. Diese Tauschphase wird bei ZConnect Onlinephase genannt und folgt folgendem groben Schema:
Verbindung aufbauen
|
v
Systemdaten austauschen (Handshake)
|
v
Daten austauschen (Transfer)<--.
| | |
v `---'
Verbindung beenden (Logoff)
Dieser für Wählleitungen entworfene Aufbau weist zwei Besonderheiten auf. Zum einen einigen sich die Systeme in der Handshakephase selbsttätig auf zu verwendende Übertragungsprotokolle (z.B. XModem, ZModem), Packprogramme (z.B. ZIP, LHA) und mehr. Zum anderen kann die Transferphase mehrmals hintereinander ausgeführt werden, so daß z.B. in einem Local Area Network in der Zwischenzeit neu bereitgestellte Daten noch während der bestehenden Verbindung übertragen werden können.
Der Gedanke an Wählleitungen und die übliche Tarifierung, bei der die Anruferin für die Verbindung bezahlt, bedingen beim ZConnect-Design, daß die Anruferin über den Ablauf des Austausches bestimmt. So kann sie jederzeit die von der Angerufenen angebotenen Daten ablehnen oder nur Teile davon abfordern. Umgesetzt wird dies durch ein umfangreiches Verfahren von Anfrage-Antwort-Ablehnung/Bestätigung-Ausführung. Hierbei gilt immer, daß bereits - auch teilweise - korrekt übertragene Daten möglichst nicht noch einmal übertragen werden sollen.
Als weiteres Ziel gibt [D3.1Z] vor, daß das Protokoll auch bei nicht vollständig datentransparenten Verbindungen funktionieren muß. Außerdem soll die Protokollspezifikation ohne größeren Aufwand erweiterbar sein.
Die Verbreitung der ZConnect-Onlinephase beschränkt sich auf die Orte im Netz, an denen das Zerberus Mailboxprogramm oder UNIX/Connect eingesetzt wird. Pointprogramme, die die Onlinephase unterstützen, gibt es derzeit nicht. Es wird überwiegend Janus und zunehmend dessen Derivat JanusPlus eingesetzt. Diese Protokolle sind im Anhang beschrieben.
Die ZConnect-Onlinephase wird im Rahmen dieses Textes nicht näher beschrieben. Sicher bedarf die Dokumentation der Onlinephase als solche dringend der neuen Ausarbeitung, insbesondere unter Ergänzung von Ablaufdiagrammen und eindeutigen Zuordnungen der möglichen Informationen zu den einzelnen Phasen der Kommunikation. Jedoch wurde im Hinblick auf den notwendigen Zeitaufwand für diese Dokumentation der Schwerpunkt auf das weit verbreitete Datenformat gelegt. Sollte die ZConnect-Onlinephase den Status eines offenen Protokolls erlangen, ist über eine dokumentationstechnische Wiedervereinigung mit dem hier behandelten Datenformat neu zu entscheiden.
3.2. Übertragene Dateien
In ZConnect ist fesgelegt, wie die Dateien heißen müssen, die während der Onlinephase (auch der Onlinephase von JANUS, vgl. Anhang F) übertragen werden. Der Typ der Dateien wird von der DOS-üblichen Extension, also den drei Zeichen nach dem einzigen Punkt im Dateinamen, abhängig gemacht. Sowohl Dateinamen selbst als auch Extensions sind ohne Berücksichtigung der Groß-/Kleinschreibung zu bearbeiten. Grundsätzlich sollte beim Erzeugen nur Kleinschreibung verwendet werden.
Definierte Extensions sind:
.brt die so gekennzeichnete Pufferdatei enthält ausschließlich
öffentliche Nachrichten
.eil Datei enthält ausschließlich persönliche Nachrichten mit
PRIO: 20 Headerinformation
.kom Datei enthält private und öffentliche Nachrichten
.prv Datei enthält ausschließlich private Nachrichten
Unbekannte Extensions müssen behandelt werden, als wäre die .kom-Extension angegeben. Keine Pufferdatei darf wegen eines Fehlers beim Namen von der Bearbeitung ausgenommen werden.
Folgende Extensions sind laut [B9] definiert, die Verbindlichkeit ist jedoch noch nicht abschließend geklärt:
.err Datei enthält ausschließlich Nachrichten mit ERR-
Headerinformation
.dir Datei enthält ausschließlich persönliche Nachrichten mit
PRIO: 10 Headerinformation
Da in früheren ZConnect-Implementationen und auch zu Z3.8-Zeiten der Pufferdateiname "puffer." verwendet wurde, ist dieser in [D3.1M] gesondert erwähnt. Ein so benannter Puffer enthält Nachrichten im ZConnect-Datenformat, über deren EmpfängerInnen nichts ausgesagt wird (z.B. können öffentliche, private oder beide Adressierungsarten gemischt enthalten sein).
Für die Erzeugung des Dateinamens vor der Extension schlägt [D3.1P] im Zusammenhang mit der JANUS-Beschreibung vor, UNIXTIME (Zeit in Sekunden seit 1970) als achtstellige Hexadezimalzahl zu verwenden. In [JanusPlus] wird für JanusPlus eine besondere Namensgebung vorgeschrieben.
3.3. Datenformat
3.3.1. Die Teile einer Nachricht
Eine ZConnect-Nachricht wird eingeleitet durch den Header, welcher diverse Headerinformationen (s.u.) enthält. Beendet wird der Header durch eine einzelne CR/LF-Kombination (Leerzeile). Hierauf folgt der Nachrichtenkörper, bezeichnet auch als Inhalt oder Body:
+--------------------------------------------------+
| Nachrichtenheader |
| +-----------------------------------------------+
| | Headerinformation (abgeschlossen durch CR/LF) |
| +-----------------------------------------------+
| | ... |
| +-----------------------------------------------+
| | Headerinformation (abgeschlossen durch CR/LF) |
+--+-----------------------------------------------+
| Leerzeile (CR/LF) |
+--------------------------------------------------+
| Nachrichtenkörper |
| +-----------------------------------------------+
| | Optional vorangestellter Kommentar |
| +-----------------------------------------------+
| | |
| | Text/Daten |
| | |
+--+-----------------------------------------------+
Im allgemeinen Sprachgebrauch wird für eine einzelne Headerinformation fast immer der eigentlich besetzte Begriff "Header" verwendet. Um Verwirrungen zu vermeiden, ist dies in dieser Dokumentation nicht erfolgt. Da auch der Begriff "Inhalt" in einem anderen Kontext (beim Header) verwandt wird, wird die Bezeichnung "Nachrichtenkörper" verwendet.
Wird nicht ausdrücklich anderes erwähnt, so gilt, daß der Text-/Datenanteil des Nachrichtenkörpers nicht eingesehen, verändert oder ausgewertet werden darf. Der Transport von Steuerinformationen im Nachrichtenkörper (wie in anderen Netzen zur Umgehung von Schwächen der Protokolldefinition durchaus üblich) ist verboten. Aber auch für das Vorlegen fehlerhafter Nachrichten bei der Systemadministration ergibt sich bereits aus dieser Vorschrift, daß der Nachrichtenkörper bei privaten Nachrichten (s.u.) nicht mit vorgelegt werden darf.
Beim Header sind Einsicht, Auswertung und Änderungen dem Wesen nach vorgesehen. Einige Headerinformationen müssen von der behandelnden Software sogar verändert (z.B. ergänzt) werden, alle sind auszuwerten und i.d.R. dürfen sie auch von der Systemadministration eingesehen werden.
3.3.1.1. Headerinformationen
3.3.1.1.1. Aufbau und Zeichensatz von Headerinformationen
Die Headerinformationen in einem Header werden durch den in der DOS-Welt üblichen Zeilenvorschub CR/LF (ASCII 13/10) voneinander abgetrennt. Eine Headerinformation besteht aus der einleitenden, maximal 100 Zeichen langen Headerkennung; hierfür sind die Zeichen A bis Z, die Ziffern 0 bis 9 und der Bindestrich "-" erlaubt. Bei der Auswertung ist (auch gemischte) Groß-/Kleinschreibung zu ignorieren.
Auf die Kennung folgt ohne Abstand ein Doppelpunkt. Es schließen sich beliebig viele (möglicherweise auch null) Whitespaces, also entweder TAB (ASCII 9) oder Leerzeichen (ASCII 32), an.
Danach folgt der Informationsinhalt, der beliebig viele Zeichen enthalten kann (also auch gar keine). Der gültige Zeichensatz hierfür besteht aus den ASCII-Codes 32-255. In [D3.0] ist wörtlich formuliert: "Bei Informationsinhalten mit Text-Charakter (z.B. Betreff-Zeile) gelten die gleichen Zeichensatzeinschränkungen wie für den Inhalt von Standard-Textnachrichten." Es wurde des öfteren die Gültigkeit der CHARSET-Headerinformation für die Informationsinhalte diskutiert und verneint. Bei Informationsinhalten mit Textcharakter dürfen somit nur die Zeichen 9 (TAB), 10 (LF), 13 (CR) und 32-254 (255 wird als Leerzeichen gewandelt) gemäß ZConnect-Zeichensatz verwendet werden.
3.3.1.1.2. Adressenformat
Bei ZConnect werden Adressen der Form
<Lokalteil>@<System>.<Systemzugehörigkeit>
verwendet{3}. Die Systemzugehörigkeit wird allgemein als "Domain"
bezeichnet und kann mehrfach durch Punkte aufgeteilt sein. Dazu gehört
optional ein realer, bürgerlicher Name. Ist ein solcher "Realname"
angegeben, so ist er durch genau ein Leerzeichen abzutrennen und in
runden Klammern zu schreiben:
<Lokalteil>@<System>.<Domain> (<Realname>)
Groß- und Kleinschreibung finden keine Berücksichtigung. Gültige Beispiele wären also:
R.Juhser@BINGO.comlink.de (Rainer Juhser)
x99@bingo.ComLink.DE (Ix Neun Neun)
ai@ai.bingo.comlink.de
Der Teil hinter dem "@" (gelesen: at - "ätt") bezeichnet in seiner Gesamtheit weltweit eindeutig das System, zu welchem die Nachricht zugestellt werden soll. Die Auswertung erfolgt abhängig vom "Wissen" des routenden Systems (siehe Anhang E "Routing"). Daher sind auch Adresse ohne jedes "@" gültige Adressen, allerdings sind sie ausschließlich auf dem absendenden System selber zustellbar (dessen Name nebst Domain werden implizit als angegeben vorausgesetzt). Wenn also z.B. eine Mail an
Testi
vom System BINGO.comlink.de aus geschickt wird, so ist
Testi@BINGO.comlink.de damit gemeint. Wird eine Nachricht mit einem
Bestimmungsort (also einer Empfängerinnenadresse) ohne Domain
angeliefert, so wird die Pseudo-Systemzugehörigkeit (Pseudodomain)
"zer" angenommen. Für diese Domain ist das lokale System als
Smartserver{4} zu betrachten - es darf also nur an Systeme zustellen,
die lokal bekannt sind.
Diese Sonderregelung ist allerdings in Zeiten des Domainroutings anachronistisch. Zeitgemäßer ist hier eine Regelung, Adressen ohne Domain mit der Domain des routenden Systems aufzufüllen (was also auf dem ersten System auf dem Routeweg geschähe). Somit wäre nicht das routende System automatisch Smartserver, sondern der tatsächliche Smartserver würde die Zustellung, sofern möglich, übernehmen.
Nachrichten dürfen nur dann mit einer AbsenderInnenadresse mit der Domain "zer" versehen sein, wenn sie auf einem Z3.8-System abgesandt wurden. Seit [D3.1M] werden Z3.8-Netze jedoch als Fremdnetze betrachtet, daher ist auch diese Regelung nicht mehr im Rahmen ZConnects zu betrachten, sondern im Rahmen allgemeiner Gatewaybestimmungen.
3.3.1.1.2.1. Zeichensätze bei der Adresse
Für das System und die Systemzugehörigkeit sind in ASCII-Codierung die Zeichen A bis Z, die Ziffern 0 bis 9 und der Bindestrich "-" zulässig. Die Groß-/Kleinschreibung ist dabei irrelevant.
Der Lokalteil, also der Adreßanteil vor dem "@", darf die ASCII-Codes 35 bis 124 abzüglich der Codes 64, 60, 62, 92, 28, 29, 39, 44, 91, 93, 96 und 123 enthalten. Die Codes 33, 37 und 47 (!%/) sind erlaubt, aber reserviert und dürfen daher auch nicht in im Lokalteil enthaltenen UserInnennamen auftauchen.
Der in Klammern eingeschlossene Realname darf abzüglich eben dieser Klammern die ASCII-Code 32 bis 126 enthalten.
3.3.1.1.2.2. Private Nachrichten
Eine private Nachricht ist definiert als Nachricht, die ausschließlich Empfängerinnen (siehe EMP-Headerinformation) hat, in denen das Zeichen "@" vorkommt oder weder "@" noch "/" vorkommen. Es ist gerade bei gemischtadressierten Nachrichten leider bisher nicht üblich, aber besser, dies zu beachten (vgl. unbedingt Kapitel Gemischtadressierung).
3.3.1.1.3. Brettnamenformat
Brettnamen enthalten ASCII-codiert die Zeichen A bis Z, die Ziffern 0 bis 9, sowie die Zeichen 33, 43, 45, 47 und 95 (!+-/_); Umlaute und Kleinbuchstaben sind also nicht erlaubt. Der Schrägstrich "/" trennt Hierarchieebenen eines Brettnamens. Ein Brettname beginnt immer mit einem solchen Schrägstrich, endet hingegen nie mit einem. Zwischen zwei Schrägstrichen steht mindestens eines der anderen zulässigen Zeichen.
3.3.1.1.3.1. Öffentliche Nachrichten
Eine öffentliche Nachricht ist definiert als Nachricht, die mindestens eine Empfängerin (siehe EMP-Headerinformation) hat, in der nicht das Zeichen "@" aber das Zeichen "/" vorkommt. Es gibt eine Sonderform der Adressierung:
/BRETTGRUPPE/BRETT@system.domain
Diese Adressierung soll die Zustellung einer Nachricht in ein nur auf einem anderen System verfügbares öffentliches Brett ermöglichen, wird aber definitionsgemäß als private Nachricht behandelt und ggf. auch als solche abgerechnet. In der Praxis unterstützt nicht jede eingesetzte Software diese Art der Adressierung; anders ausgedrückt: eine solche Nachricht kommt mit hoher Wahrscheinlichkeit nicht an, wenn sie über das Netz transportiert werden muß. Insbesondere wenn das empfangende System die ZConnect-Brettnotation nicht kennt (Slashes werden in den wenigsten technischen Netzen eingesetzt), ist nicht mit einer ordnungsgemäßen Zustellung zu rechnen.
3.3.1.1.4. Datumsangaben
Datumsangaben enthalten bei ZConnect immer auch Zeitangaben und Zeitzone. Das Format ist
JJJJMMTThhmmss[S|W][+|- <Offset>]
wobei der Offset die Abweichung von GMT (Greenwich Meantime) angibt und im Bereich von -12 bis 12 liegt; ist die Abweichung allerdings nicht in ganzen Stunden zu messen, werden Minutenangaben nach einem Doppelpunkt hinzugefügt.
Beispiele:
19950419000000
19990520111111S+1
19800101010101W-7:30
19851211020304+0
19840911232359S-12
In der Bundesrepublik Deutschland gilt die MET (Middle European Time) bzw. im Sommer die MEST (Sommerzeit). Die Abweichungen zu GMT lauten "W+1" (MET) bzw. "S+2" (MEST). Der Bezug auf GMT sorgt dafür, daß die ersten 14 Stellen der Datumsangabe kontinuierlich weiterlaufen; z.B. die Sommerzeit wird durch die "S+2"-Angabe angegeben, ohne daß die JJJJMMTThhmmss-Angabe springen würde.
Im Anhang H sind die relevanten Zeitzonen aufgelistet, wie sie in [D3.0] enthalten sind.
Die Wechseltermine zu Winter- bzw. Sommerzeit sind gesetzlich geregelt, so daß ProgrammiererInnen diese Umstellung automatisieren können. Da ausgerechnet zum Zeitpunkt der Fertigstellung dieses Textes eine Gesetzesänderung die Termine verschiebt, fehlen die Details an dieser Stelle. Um Ergänzung qua Mail an DOKUKOO@bingo.comlink.de wird gebeten.
3.3.1.2. Form des Bodys
Wenn im Header keine TYP-Headerinformation angegeben ist, handelt es
sich beim Nachrichtenkörper um reinen Text. In diesem sind Zeilen
durch das übliche Paar ASCII 13/10 (CR/LF, die Reihenfolge ist
vorgeschrieben) voneinander getrennt. Das in manchen
Programmumgebungen übliche Dateiendezeichen ASCII 26 ("Ctrl-Z") gehört
zu den in Textnachrichten verbotenen Zeichen.
Textnachrichten sind per Definition unmittelbar lesbar und erfordern keine besonderen Anzeigeprogramme. Jedoch muß die anzeigende Software den verwendeten Zeichensatz in einen auf dem lokalen Gerät anzeigbaren umwandeln. Der Standardzeichensatz ist im Anhang G als ZConnect-Zeichensatz aufgelistet. Als Steuerzeichen sind darüberhinaus ausschließlich ASCII 9 (Tabulator) und 13/10 (Zeilenvorschub) zugelassen.
3.3.2. ZConnect-Headerinformationen
Dieser Abschnitt befaßt sich mit den einzelnen Headerinformationen. Diese unterteilen sich in fest definierte, frei definierbare und auf Fremdformate bezogene. Außerdem wird ein Ausblick auf zukünftige Erweiterungen gegeben.
3.3.2.1. Fest definierte Headerzeilen
Das Datenformat ZConnects zeichnet sich durch eine Mischung von Maschinen- und Menschenlesbarkeit aus. An manchen Stellen eingestreute Whitespaces machen es bearbeitender Software nicht unbedingt leichter, machen die Headerzeilen aber für menschliche Augen lesbar.
Die möglichen Headerkennungen sind einer ständigen Entwicklung unterworfen. Aus diesem Grund und weil auch frei definierte Kennungen auftreten können, dürfen Headerzeilen mit unbekannten Kennungen weder gelöscht noch in anderer Weise bearbeitet werden. Sie müssen vielmehr unverändert weitergegeben werden.
_Verwendete Schreibweisen, Unterteilungen und Symbolisierungen_
Im folgenden sind alle fest definierten Headerinformationen mit allen dazugehörigen Informationen aufgelistet. Für diesen zentralen Teil dieser Dokumentation werden folgende Schreibweisen, Unterteilungen und Symbolisierungen verwendet.
Zeilenumbrüche bei der Syntax der Kennung sind drucktechnisch bedingt und dürfen in einem ZConnect-Header niemals innerhalb einer Header-Information auftauchen.
In einfachen spitzen Klammern finden sich syntaktische Einheiten. Die spitzen Klammern gehören nicht zur gemeinten Information, sofern nicht explizit anderes ausgesagt wird. In eckigen Klammern sind optionale Parameter angegeben. Findet sich ein hochgestellter Stern neben der syntaktischen Einheit, kann diese gar nicht, einmal oder mehrfach angegeben werden. Die eckigen Klammern und der Stern gehören nicht zur Information.
Beispiel:
ERR <Fehlerklasse>[;<Fehlernummer>]* [<Fehlermeldungsklartext>]
Verbal beschrieben bedeutet das: Nach der Kennung ERR muß die Fehlerklasse angegeben werden (im erläuternden Text wird in diesem Fall angegeben, wie eine Fehlerklasse notiert wird), dann durch Semikolon abgetrennt beliebig viele (das sagt der Stern), also evtl. auch gar keine (das sagen die eckigen Klammern) Fehlernummern. Durch Leerzeichen abgetrennt kann dann genau ein Fehlermeldungsklartext nachgestellt werden, er kann aber auch ganz fehlen (das sagen wiederum die eckigen Klammern). Anstelle des "*" kann auch ein "+" stehen, was soviel bedeutet wie "beliebig oft, aber mindestens einmal".
Ein senkrechter Strich "|" meint ein exklusives Oder und gehört nicht zur Information; vielmehr ist genau eine der durch solche Striche getrennten Varianten zu verwenden.
Die in den rechtsstehenden Kästen mit Pfeilen (>>) versehenen Angaben
sagen aus, ob die jeweilige Kennung unbedingt in jedem Header
vorhanden sein muß (Pflicht) oder ob er wahlweise eingesetzt werden
kann (Optional).
+-----------------+
|>>Pflicht | Außerdem ist angegeben, ob die Headerinformation
| Optional | nur einmal oder auch mehrfach pro Header
+-----------------+ auftauchen darf. Auch mehrfach bedeutet nicht,
|>>Nur einmal | daß eine Information mehrfach vorkommen muß. Darf
| Auch mehrfach | die Reihenfolge von mehrfach auftretenden
| Stabil | Infomationen auf keinen Fall geändert werden, so
+-----------------+ ist stabil gekennzeichnet. Zwischen zwei - der
|**Nur PM | Kennung nach - gleichen Headerinformationen
+-----------------+ können aber beliebige Headerinformationen mit
anderer Kennung auftreten.
Manche Informationen dürfen nur in den Headern privater Nachrichten eingesetzt werden. Bei diesen ist "Nur PM" gekennzeichnet. Ist eine Eigenschaft nicht eindeutig anzugeben, so verweist die Kennzeichnung ** auf eine Erläuterung im Text.
Unter den Zwischenüberschriften findet sich die ausführlichere Beschreibung der _Funktion_ der Header-Information. Zumeist ist ein _Hinweis_ angegeben, der auf Unklarheiten oder Querbezüge aufmerksam macht, Implementierungstips gibt oder einfach nur der Illustration dient.
Die _Historie_ gibt an, wann der Header definiert wurde, und an welcher Stelle Modifikationen vorgenommen wurden. "D:" steht dabei für "Definiert:" und benennt das Dokument mit der Erstdefinition. "M:" steht für "Modifiziert:" und verweist auf das Dokument oder die Dokumente, in denen die Headerbedeutung abgewandelt, klargestellt oder in anderer Weise unmittelbar geändert wurde (eine zusätzliche Verwendung im Kontext der Einführung oder Veränderung einer anderen Headerkennung wird hier nicht vermerkt).
Die Einträge lesen sich [D3.0], [D3.1P] und [D3.1M]. "A:" steht für "Anders bei:" und hat als möglichen Eintrag derzeit nur [D3.1Z], die aktuelle Dokumentation der Zerberus GmbH, die in einigen Punkten von den Beschlüssen des ZConnect-Gremiums abweicht und daher nur ergänzenden Charakter hat. Ein schlichtes Datum schließlich bezeichnet den Tag, an dem das ZConnect-Gremium die Änderung beschlossen hat, wenn die Änderung nicht in einem der zusammenfassenden Dokumente aufgeführt ist.
Die Notation unter der Überschrift _Siehe auch_: In GROßBUCHSTABEN wird auf verwandte oder im Kontext interessante Headerkennungen verwiesen. Normaler Satz verweist auf ein Thema aus dem allgemeinen Teil dieses Textes. Durch umrahmende "*" symbolisierter *Fettdruck* sagt aus, daß der so dargestellte Querverweis unbedingt zu beachten ist, da er der gerade betrachteten Headerkennung wesentliche Informationen hinzufügt, die Funktion der Kennung abwandelt oder sie gar insgesamt verunmöglicht (manche Kennungen schließen sich gegenseitig aus).
Fußnoten sind mit geschweiften Klammern gekennzeichnet und am Ende des Dokuments zusammengefaßt.
Kennung: ABS +-----------------+
|>>Pflicht |
Kurzbeschreibung: Absenderin | Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: ABS: <ZConnect-Adresse> [(<Realname>)]
Funktion: Die Absenderinangabe dient zum einen natürlich der
Identifikation der Herkunft der Nachricht. In den
meisten Netzen wird zudem die Angabe des
bürgerlichen Namens verlangt (nicht im /Z-Netz, aber
auch dort wird mittlerweile überwiegend ein Realname
angegeben).
Bei Fehlern wird die Absenderin benachrichtigt (vgl.
ANTWORT-AN). Fehlt die ABS-Information im Header,
kann keine Fehlermeldung zugestellt werden; die
Nachricht wird kommentarlos gelöscht.
Hinweis: Der Realname muß sich selbstverständlich an die
Regeln für den Headerzeichensatz halten, wird also
insbesondere von einer CHARSET-Information nicht
betroffen. Da die Zeichen, die beim
Quoted-Printable-Zeichensatz (vgl. z.B. [RFC 1521])
zum Einsatz kommen, der ZConnect-Norm für Zeichen im
Header entsprechen, verwenden einzelne Personen eben
jenen Zeichensatz zum Ausdrücken von Sonderzeichen
im Namen. RFC->ZConnect Relays sollten diese
Notation allerdings zum ZC-Zeichensatz hin auflösen.
Historie: D: [D3.0]
Siehe auch: *ANTWORT-AN*, OAB, WAB, Adressenformat, Weiterleiten
Kennung: ANTWORT-AN +-----------------+
| Pflicht |
Kurzbeschreibung: Private Antwortempfängerin |>>Optional |
+-----------------+
| Nur einmal |
|>>Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: ANTWORT-AN: <ZConnect-Adresse>
Funktion: Wenn dieser Header angegeben ist, darf eine private
Antwort auf die Nachricht nicht an die Absenderin
geschickt werden, sondern muß an die hier angegebene
Adresse gehen. Das gilt insbesondere für automatisch
erzeugte Antworten (z.B. Fehlermeldungen).
Hinweis: Dieser Header ist für BenutzerInnen gedacht, die
unter mehreren Adressen schreiben, die Antworten
aber gerne an nur einer Stelle gesammelt vorfinden
möchten. Auch Mailerdemons, welche auf allgemeine
Rückfragen nicht antworten können, können hier einen
sinnvollen Rückkanal vermerken.
Mailinglistenserver, die den Originalabsender
erhalten, während Antworten aber nicht an diesen,
sondern wieder in die Mailingliste gehen sollen,
sind ein weiterer typischer Anwendungsfall.
Allerdings besteht hier die Problematik, daß auch
Fehlermeldungen an die ANTWORT-AN-Empfängerin
versandt werden und somit in der Liste landen. Eine
mögliche Abhilfe, die Einführung eines FEHLER-AN
konnte sich bisher im Gremium nicht durchsetzen, so
daß diese Problematik in ZConnect bisher nicht
auflösbar ist.
Es herrscht oft Verwirrung, in welchen Fällen
ANTWORT-AN und in welchen DISKUSSION-IN wie
eingesetzt bzw. ausgewertet werden soll. Letztere
Kennung erlaubt ebenfalls die Angabe einer privaten
Adresse als Argument. Diese scheinbare Redundanz ist
aber einfach aufzulösen:
Die ANTWORT-AN Information ist ausschließlich dann
auszuwerten, wenn eine rein private Antwort auf eine
Nachricht erstellt wird (unabhängig davon, ob die zu
beantwortende Nachricht privat oder öffentlich ist).
Ist bei DISKUSSION-IN eine private Adresse
angegeben, so ist bei einer öffentlichen
Beantwortung eine Kopie dieser Antwort an die
private Adresse zu schicken (der Begriff "Kopie" ist
natürlich unpassend, wenn ausschließlich eine
DISKUSSION-IN-Information mit privater Adresse als
Argument vorliegt). Bei privaten Antworten ist
DISKUSSION-IN nicht auszuwerten.
ANTWORT-AN darf auch mehrfach auftreten. In keinem
Teil der Dokumentation ist auf diesen Fall näher
eingegangen worden. Die möglichen Interpretationen
sind die Auswahl einer der angegebenen Adressen für
die Antwort oder das Senden der Antwort an alle
angegebenen Adressen. Beide Auslegungen sind
sinnvoll; bei automatisch generierten Antworten
sollte nur an eine der angegebenen Adresse
geantwortet werden, um unnötiges Datenaufkommen zu
vermeiden.
Augrund dieser Unsicherheit, aber auch aufgrund der
Einstellung, einer Anwenderin darf nicht technisch
vorgeschrieben werden, an wen eine Antwort geht, die
sie schreibt, betrachten einige Pointprogramme die
ANTWORT-AN-Information durchweg als Kann-Bestimmung.
ANTWORT-AN-Adressen werden also als mögliche
AdressatInnen angezeigt, nicht aber automatisch
verwendet.
Historie: D: [D3.0]
Siehe auch: ABS, DISKUSSION-IN, Adressenformat, Weiterleiten
Kennung: BET +-----------------+
|>>Pflicht |
Kurzbeschreibung: Betreff | Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: BET: <Betrefftext>
Funktion: Für jede Nachricht ist eine Betreffzeile
vorgeschrieben. Auch das Aussehen des Betrefftextes
ist verbindlich geregelt: Handelt es sich um die
Antwort auf eine vorausgegangene Nachricht, so ist
dem Betrefftext ein "Re: "{5} voranzustellen, sofern
dies dort noch nicht steht. "Re:Re:" darf also nicht
vorkommen. Auch ist "Re^2: ", "Re^3: " usw.
verboten. Ist eine Ordnungsnummer der Antwort
gewünscht, so soll sie aus den BEZ-Informationen
gewonnen werden.
Hinweis: Unschön sind Betrefftexte, die mit "Re:Re:" starten.
Auch ist z.B. bei Nachrichten im RFC-Format "Re^n: "
verboten. Es ist insgesamt aber in der Praxis kaum
gegeben, daß sich eine Software an die Regelung
hielte, die Ordnungsnummer der Antwort aus den
BEZ-Informationen zu gewinnen. Diese Problematik ist
bei BEZ genauer erläutert.
Inkonsequent ist die Forderung nach Angabe von
"Re: " im Betrefftext. Ist die Ordnungsnummer nur
unzuverlässig aus den BEZ-Informationen zu gewinnen,
so reicht aber das Vorhandensein einer
BEZ-Information aus, um festzustellen, daß es sich
um eine Antwort handelt. "Re: " kann also vom
anzeigenden Programm generiert werden.
Es gibt übrigens keinen wirklich zwingenden,
technischen Grund für die Definition der
BET-Information als Pflichtinformation. In dem
Zusammenhang ist darauf hinzuweisen, daß leere
Betreffzeilen vorkommen können
Historie: D: [D3.0]
M: [D3.1P]
Siehe auch: *BEZ*
Kennung: BEZ +-----------------+
| Pflicht |
Kurzbeschreibung: Bezugsnachricht |>>Optional |
+-----------------+
| Nur einmal |
|>>Auch mehrfach |
|>>Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: BEZ: <Message-ID>
Funktion: Wenn die zugehörige Nachricht eine Antwort auf eine
vorhergegangene Nachricht ist, dann gibt BEZ die
Message-ID von letzterer an.
Es wird unterschieden zwischen direkten und indirekten
Bezügen. Indirekte Bezüge sind solche, die schon in der
beantworteten Nachricht vorkamen und aus dieser
übernommen wurden. Diese Übernahme ist erlaubt, nicht
aber verpflichtend. Erfolgt sie, darf die Reihenfolge
nicht geändert werden.
Die indirekten Bezüge müssen im Header vor den
direkten Bezügen angegeben werden. Dies ergibt nicht
unbedingt eine chronologische Ordnung {6}.
Hinweis: In [D3.1Z] ist sinnvollerweise vorgeschrieben, daß
bei automatisch erzeugten Nachrichten grundsätzlich
eine BEZ-Information einzufügen ist. Eine Regelung,
daß bei Antworten aller Art grundsätzlich
BEZ-Informationen einzufügen sind, es sei denn, die
Anwenderin bestimmt Gegenteiliges, wird an dieser
Stelle empfohlen.
Eine stabile Reihenfolge von Bezügen zu vereinbaren,
ist einerseits sinnvoll. Andererseits erlaubt die
Syntax nicht, die tatsächliche Reihenfolge der
Bezugsnachrichten festzustellen: so kann eine
Nachricht mit zwei BEZ-Informationen zwei direkte
oder einen direkten und einen indirekten Bezug
transportieren. Dies ist die zentrale Problematik
der BEZ- und damit auch der BET-Information.
Die AutorInnen von [D3.1Z] lösen dieses Problem
abweichend von der Beschlußlage des Gremiums, indem
sie nur eine direkte BEZ-Information pro Mail
zuläßt. Dies verhindert in seiner Rigorosität
allerdings, daß bei gleichzeitigem Antworten auf
mehrere Nachrichten auch mehrere direkte Bezüge
gesetzt werden. Die programmiertechnische
Schwierigkeit soll also mit einer Einschränkung der
Möglichkeiten der AnwenderInnen erkauft werden.
Die erlaubte, aber nicht zwingenden Mitnahme der
indirekten Bezüge verhindert die Erfüllung der
Forderung, daß das "Re^n:" für den Betreff aus den
Bezügen zu generieren ist. Weder ist es sinnvoll, in
den Beiträgen z.B. zu einer Diskussion komplett alle
direkten und indirekten Bezüge mitzutransportieren,
um die richtige Ordnungszahl des Replys zu
errechnen, noch wäre dies dann überhaupt möglich: Da
nicht zwischen direkten und indirekten Bezügen
unterschieden werden kann, enthält die Anzahl der
BEZ-Informationen und selbst ein daraus gewonnener
Kommentarbaum keine zuverlässige Information über
die Ordnungszahl einer Antwort und ist mithin ohne
Aussage.
Stand der Dinge: Alle Bezüge vor dem zuletzt
angegebenen müssen als indirekt interpretiert
werden. Eine Auswertung darf keine chronologische
Reihenfolge voraussetzen. Es ist besser, im Betreff
auf Informationen über die Verschachtelungstiefe zu
verzichten, um dem ZConnect-Standard Folge zu
leisten; ProgrammiererInnen, die eine Ordnungszahl
wünschen, sollten X-REPLY-LEVEL (s.u.) unterstützen bzw.
den Kommentarbaum als (aber nicht ganz zuverlässige)
Quelle für ihre Numerierung verwenden.
Der Transport aller BEZ-Informationen eines
Kommentarbaums würde ohne echten Informationsgehalt
zu aufgeblähten Headern führen. Mehrere direkte
Bezüge sind hingegen sinnvoll verwendbar.
Einige Applikationen verwenden die erwähnte frei
definierte Information X-REPLY-LEVEL, um unabhängig
von Bezugsverkettung und Betreff die Tiefe der
Antwortverschachtelung zu transportieren. Es ist
auch darauf hinzuweisen, daß der Transport von mehr
als den direkten Bezügen ausschließlich die Funktion
hat, bei lokal nicht mehr verfügbaren Nachrichten
(die Anwenderin hat sie z.B. mittlerweile gelöscht)
trotzdem eine Verkettung mit vorhergehenden
Diskussionsbeiträgen herstellen zu können. Insofern
ist der Transport der direkten und des im Header
zuerststehenden und damit mit einer gewissen
Wahrscheinlichkeit den Beginn der Diskussion
kennzeichnenden, indirekten Bezugs die praxisnäheste
Lösung. Der zusätzliche Transport einer Zahl
indirekter Bezüge aus "der Mitte des Kommentarbaums"
ist als redundante Information zurückhaltend zu
dosieren.
Bei der Erstellung des Kommentarbaums sollte auf den
möglichen Fehler einer gegenseitigen Bezugnahme zweier
Nachrichten aufeinander geachtet werden.
Historie: D: [D3.0]
M: [D3.1P]
A: [D3.1Z]
Siehe auch: BET, MID
Kennung: CHARSET +-----------------+
| Pflicht |
Kurzbeschreibung: Zeichensatzfestlegung |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: CHARSET: ISO1 | ISO2 | ISO3 | ISO4 | ISO5 | ISO6 |
ISO7 | ISO8 | ISO9 | UNICODE
Funktion: CHARSET legt den Zeichensatz fest, der für den
Nachrichtenkörper gilt (nicht für den Header!). Kann
das anzeigende Programm den spezifizierten
Zeichensatz nicht darstellen, so ist der Anwenderin
dies nur mitzuteilen. Die Dokumentation empfiehlt in
diesem Zusammenhang dringend, den ISO1-Zeichensatz
zu unterstützen.
Mit ISOx ist immer die ISO-8859-x gemeint.
Groß-/Kleinschreibung ist bei den Parametern nicht
relevant.
Hinweis: Ist CHARSET nicht angegeben, gilt der normale
ZConnect-Zeichensatz.
CHARSET ist ausschließlich für Textnachrichten
vorgesehen, also definitionsgemäß solche
Nachrichten, die keine TYP-Kennung im Header haben.
CHARSET wirkt nicht auf einen evtl. enthaltenen
Kommentar.
Der MIME-Standard wird zukünftig von ZConnect
unterstützt werden. Genaue Regelungen sind noch
nicht getroffen worden. Insbesondere ZConnect->RFC
Relays sollten die Möglichkeiten MIMEs nutzen, um
z.B. die CHARSET oder TYP: BIN Fähigkeiten ZConnects
sicher durch den RFC-Raum zu transportieren.
UNICODE ist ein 16-Bit-Zeichensatz. Es ist nicht
bekannt, daß ZConnect-fähige Programme diesen
Zeichensatz bereits unterstützen.
Historie: D: [D3.1M]
M: [D3.1Z] (Klarstellung)
Siehe auch: CRYPT-CONTENT-CHARSET, Verschlüsselung,
*Zeichensätze*
Kennung: CONTROL +-----------------+
| Pflicht |
Kurzbeschreibung: Nachricht mit Steuerfunktion |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: CONTROL: [CANCEL <Message-ID> | ADD <Brettname> |
DEL <Brettname>]
Funktion: Mit den CONTROL-Informationen lassen sich bereits
verschickte Nachrichten löschen ("canceln") und
netzweit neue Bretter anlegen oder austragen. Es ist
genau vorgegeben, wer diese Aktionen durchführen
darf (siehe bei den Einzelinformationen), da dieser
Headerinformation eine nicht unerhebliche
Sabotagegefahr innewohnt.
Die Informationsinhalte sind unabhängig von ihrer
Groß-/Kleinschreibung auszuwerten ("CANCEL" ==
"canCeL"). Zwischen Befehl (CANCEL/ADD/DEL) und
dessen Parameter (<Message-ID>/<Brettname>) sind
beliebig viele Whitespaces (<TAB>, Leerzeichen)
zulässig, mindestens ist jedoch eines
vorgeschrieben.
CONTROL darf nur in Kombination mit STAT: CTL
auftreten. STAT: CTL sorgt auch dafür, daß
CONTROL-Nachrichten nur an Points und Systeme
weitergereicht, nicht aber in Onlinedatenbestände
einsortiert wird. Tritt CONTROL ohne STAT: CTL auf,
ist die Nachricht fehlerhaft.
CONTROL kann auch ohne Parameter angegeben werden.
Genau wie bei einem unbekannten Informationsinhalt
(also ungleich CANCEL/ADD/DEL) wird in diesem Fall
die CONTROL-Information ignoriert. Die Nachricht
behält aber ihren STAT: CTL-Status und wird auch
unverändert weitergegeben.
Hinweis: Bei der Wahl wurde CONTROL als "optional, auch
mehrfach" beschlossen, da dies aber nicht in die
RFC-Welt übertragbar ist, wurde der Wahlausgang
stillschweigend zu "optional, nur einmal"
korrigiert.
In manchen Netzen kann es per Netikette verboten
sein, insbesondere CANCELs auszuführen.
Applikationen müssen entsprechend konfigurierbar
sein.
Historie: D: [Wahl5]
Siehe auch: CONTROL: ADD, CONTROL: CANCEL, CONTROL: DEL,
ERSETZT, *STAT: CTL*, Weiterleiten
Kennung: CONTROL: ADD +-----------------+
| Pflicht |
Kurzbeschreibung: Nachricht zur automatischen Einrichtung |>>Optional |
von Brettern +-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: CONTROL: ADD <Brettname>
Funktion: Mit einer CONTROL: ADD Information kann sehr leicht
- z.B. netzweit - für die Einrichtung eines Bretts
gesorgt werden. Der als Parameter transportierte
<Brettname> bezeichnet das Brett, daß auf dem
empfangenden System eingerichtet werden soll.
SystembetreiberInnen werden nicht jeder Absenderin
gestatten, per Control-Nachricht Bretter
einzurichten. Daher sind zwei Möglichkeiten der
Legitimation vorgesehen. Die sicherste und
einfachste Möglichkeit ist, CONTROL: ADD und
CONTROL: DEL enthaltende Nachrichten grundsätzlich
der Systembetreuung zur Entscheidung vorzulegen.
Eine elegantere wenngleich "gefährlichere"
Möglichkeit ist es, über eine lokal geführte Liste
Absenderinnen zu bestimmen, deren
Control-Nachrichten akzeptiert werden.
Eine Nachricht mit CONTROL: ADD Information bräuchte
theoretisch keine EMP Informationen, da sie
empfängerinnenunabhängig umgesetzt wird. So dienen
die EMPs dann auch lediglich der Verteilung der
Control-Nachricht. Denkbar ist auch die private
Adressierung, um auf einem ganz bestimmten System
ein Brett einzurichten.
Hinweis: Eine korrekte Nachricht mit CONTROL: ADD sähe z.B.
so aus (Auszug):
EMP: /Z-NETZ/KOORDINATION/EINSTELLUNGEN
BET: Hier koemmt ein neues Brett
ABS: koordination@ttb.aworld.de (Kerstin)
STAT: CTL
CONTROL: ADD /Z-NETZ/UNWICHTIG
Für die lokale Legitimationstabelle wird folgendes
Format angeregt:
;Absenderin Brettgruppen PGP-Fingerprint
kerstin@ttb.aworld.de /Z-NETZ/* ...irgendwas...
postmaster@lokal.zc /* ...irgendwas...
Bestimmten Brettgruppen sollte also zuzuordnen sein,
welche Absenderinnen hierin Bretter einrichten (bzw.
löschen) dürfen. Die Spalte "PGP-Fingerprint" ist
als Fingerzeig zu verstehen, daß z.B. mit einer
PGP-Signatur geprüft werden könnte, ob die jeweilige
Absenderinnenangabe authentisch ist. Wo/wenn dies
durchführbar ist, ist eine solche Tabelle natürlich
das elegantaste _und_ sicherste Mittel.
An ZConnect<->RFC-Relays ("Gateways") sollten
CONTROL: ADD und das RFC-seitige "newgroup"
ineinander übersetzt werden.
Historie: D: [Wahl5]
Siehe auch: *CONTROL*, STAT: CTL
Kennung: CONTROL: CANCEL +-----------------+
| Pflicht |
Kurzbeschreibung: Nachricht zur Löschung einer früher |>>Optional |
versandten Nachricht +-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: CONTROL: CANCEL <Message-ID>
Funktion: Die mit der <Message-ID> bezeichnete Nachricht soll
gelöscht werden. Dies kann die Absenderin der zu
löschenden Nachricht veranlassen (also ABS oder,
falls vorhanden, WAB), darüberhinaus die SYSOP und
POSTMASTER Accounts des Absendesystems der zu
löschenden Nachricht sowie bestimmte Absenderinnen,
die in einer lokal geführten Legitimationsliste dazu
berechtigt werden (z.B. Netzkoordination).
Eine Nachricht mit CONTROL: CANCEL Information
transportiert in ihren EMP-Informationen die
Aussage, in welchen Brettern die zu löschende
Nachricht gelöscht werden soll. Ist die
Ursprungsnachricht also z.B. in zwei Brettern
verteilt worden und enthält die CANCEL-Nachricht nur
eine der EMP-Informationen der Ursprungsnachricht,
so bliebe diese in einem Brett erhalten.
Jede CONTROL: CANCEL enthaltende Nachricht enthält
auch eine BEZ-Information, die auf die Nachricht
verweist, die auch in der CONTROL: CANCEL-
Information bezeichnet ist. Fehlt diese Information,
ist die CANCEL-Aufforderung fehlerhaft und darf
nicht durchgeführt werden.
Hinweis: Die Fehlerhaftigkeit einer Nachricht mit
CONTROL: CANCEL-Information aber ohne redundante
BEZ-Information ist in [Wahl5] nicht eindeutig
geklärt. U.U. kann es sinnvoll sein, hier nicht zu
streng zu reagieren.
Beispiel einer Ursprungsnachricht (Auszug):
EMP: /BRETT/EINS
EMP: /BRETT/ZWEI
MID: Ursprung@system.zc
ABS: User@system.zc (Originalabsender)
WAB: Userin@system.zc (Ursprungsabsenderin)
BET: Ursprungsnachricht
Beispiel ein gültigen CANCEL-Nachricht dazu
(Auszug):
EMP: /BRETT/ZWEI
ABS: Userin@system.zc (Cancelabsenderin)
BEZ: Ursprung@system.zc
STAT: CTL
CONTROL: CANCEL Ursprung@system.zc
BET: Cancelnachricht
Hiermit würde die Ursprungsnachricht nur aus
/BRETT/ZWEI gelöscht. Die Löschende ist identisch
mit der Weiterleiterin der Ursprungsnachricht, also ist
das Canceln erlaubt (mensch beachte die
unterschiedlichen Realnames, die hierauf keinen
Einfluß haben) - wichtig ist, daß User@system.zc
_nicht_ canceln dürfte.
Noch ein gültiges CANCEL-Beispiel (Auszug):
EMP: /BRETT/EINS
EMP: /BRETT/ZWEI
ABS: POSTMASTER@system.zc (Systemadministration)
BEZ: Ursprung@system.zc
STAT: CTL
CONTROL: CANCEL Ursprung@system.zc
Hier cancelt also die Systemadministration des
Systems, von dem die Ursprungsnachricht kommt,
komplett. Es ist zu beachten, daß die
ZConnect-Festlegung der Systemadministrationsnamen
auf SYSOP oder POSTMASTER der Realität nicht
entspricht. Es sollte besser eine Liste der
möglichen Systemadministrationsnamen geführt werden.
Eine Minimallösung wäre, nur den POSTMASTER-Account
zuzulassen, da dieser im "Internet" auf _jedem_
System vorhanden sein muß.
Zu beachten ist, daß die tatsächliche Absenderin der
Cancel-Nachricht legitimiert sein muß. Ggf. ist also
auch bei dieser auf die Existenz einer
WAB-Information zu achten. Dies ist sehr wichtig,
weil sonst mit Konstrukten wie
EMP: /BRETT/EINS
EMP: /BRETT/ZWEI
ABS: POSTMASTER@system.zc (Trick 17)
WAB: Kicher@system.zc (Boeses Mensch)
BEZ: Ursprung@system.zc
STAT: CTL
CONTROL: CANCEL Ursprung@system.zc
BET: Cancelnachricht
der Sicherungsmechanismus ausgehebelt werden könnte.
Ein mögliches Format einer Legitimationsliste ist
bei CONTROL: ADD beschrieben. Es ist natürlich auch
denkbar, daß für alle Arten der Control-Nachricht
eine eigene Legitimationstabelle geführt wird.
Historie: D: [Wahl5]
Siehe auch: *CONTROL*, STAT: CTL
Kennung: CONTROL: DEL +-----------------+
| Pflicht |
Kurzbeschreibung: Nachricht zur automatischen Löschung |>>Optional |
von Brettern +-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: CONTROL: DEL <Brettname>
Funktion: Mit einer CONTROL: DEL Information kann sehr leicht
- z.B. netzweit - für die Löschung eines Bretts
gesorgt werden. Der als Parameter transportierte
<Brettname> bezeichnet das Brett, daß auf dem
empfangenden System ausgetragen werden soll.
SystembetreiberInnen werden nicht jeder Absenderin
gestatten, per Control-Nachricht Bretter zu löschen.
Daher sind zwei Möglichkeiten der Legitimation
vorgesehen, die bei CONTROL: ADD näher beschrieben
sind.
Eine Nachricht mit CONTROL: DEL Information bräuchte
theoretisch keine EMP Informationen, da sie
empfängerinnenunabhängig umgesetzt wird. So dienen
die EMPs dann auch lediglich der Verteilung der
Control-Nachricht. Denkbar ist auch die private
Adressierung, um auf einem ganz bestimmten System
ein Brett auszutragen.
Hinweis: Eine korrekte Nachricht mit CONTROL: DEL sähe z.B.
so aus (Auszug):
EMP: /Z-NETZ/KOORDINATION/EINSTELLUNGEN
BET: Hier verschwindet gleich ein Brett
ABS: koordination@ttb.aworld.de (Kerstin)
STAT: CTL
CONTROL: DEL /Z-NETZ/WICHTIG
Für die lokale Legitimationstabelle wird ein Format
angeregt, das bei CONTROL: ADD beschrieben ist.
An ZConnect<->RFC-Relays ("Gateways") sollten
CONTROL: DEL und das RFC-seitige "rmgroup"
ineinander übersetzt werden.
Historie: D: [Wahl5]
Siehe auch: *CONTROL*, *CONTROL: ADD*, STAT: CTL
Kennung: CRYPT +-----------------+
| Pflicht |
Kurzbeschreibung: Nachrichteninhalt ist verschlüsselt |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
|>>Nur PM |
+-----------------+
Syntax: CRYPT: <Kennung der Verschlüsselung>
Funktion: Der zugehörige Nachrichtentext ist verschlüsselt.
Bisher definiert sind folgende Werte für die
Verschlüsselungskennung (case-insensitive):
DES/ECB NSA Lowtech: Electronic Code Book
DES/CBC DES Cipher Block Chain
DES/CFB DES Cipher Feedback
DES/OFB DES Output Feedback
PGP Pretty Good Privacy
PGP2.1 Pretty Good Privacy (höhere Versionen mit
entsprechend erhöhter Versionskennzahl)
PMCRYPT2 Von Peter Mandrella vorgeschlagenes
Verschlüsselungsverfahren
QPC QuickPoint Crypt
Hinweis: Die aktuelle Dokumentation wankt offensichtlich
hinsichtlich der Kennzeichnung von PGP. Das
verarbeitende Programm sollte derzeit mit allen
Kennungen rechnen. Das pure "PGP" als Kennung ist
als aktuellste Version zu werten, da diese im Rahmen
des PGP-Gesamtkonzepts genannt wird. [D3.1Z]
bestätigt diese Auffassung.
Zu PMCRYPT2 teilte Peter Mandralla mit, daß es nie
implementiert wurde ([PM2]). Zu DES/* wird auf
Sekundärliteratur verwiesen (z.B. gibt [DES] einen
leicht verständlichen Überblick über die
Funktionsweise des Verfahrens). QuickPoint Crypt
stammt von der Urmutter aller /Z-NETZ-Pointprogramme
QuickPoint. Es handelt sich um ein sehr einfaches
Verfahren, welches beim QuickPoint-Programmierer
erfragt werden kann (siehe Kapitel Verschlüsselung).
Der Einsatz von CRYPT für öffentliche Nachrichten
kann sinnvoll sein, z.B. für geschlossene
BenutzerInnengruppen.
Historie: D: [D3.1P]
Siehe auch: CRYPT-CONTENT..., PGP..., SIGNED, STAT,
Verschlüsselung
Kennung: CRYPT-CONTENT-CHARSET +-----------------+
| Pflicht |
Kurzbeschreibung: Zeichensatz der in der verschlüsselten |>>Optional |
Nachricht enthaltenen Originalnachricht +-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
|>>Nur PM |
+-----------------+
Syntax: CRYPT-CONTENT-CHARSET: <Zeichensatz-ID>
Funktion: Enthielt eine verschlüsselte Nachricht eine
CHARSET-Headerinformation, so muß diese nach dem
Entschlüsseln wieder berücksichtigt werden.
CRYPT-CONTENT-CHARSET gibt also bei beliebigen
Verschlüsselungsarten an, welche CHARSET-Information
zum entschlüsselten Inhalt gehört.
Die Zeichensatz-ID kann entsprechend der
Dokumentation von CHARSET folgende Werte
(Groß-/Kleinschreibung irrelevant) annehmen: ISO1,
ISO2, ISO3, ISO4, ISO5, ISO6, ISO7, ISO8, ISO9 oder
UNICODE.
Hinweis: Dieser Header taucht bisher nicht explizit in der
Dokumentation auf. Er ergibt sich jedoch ohne jeden
Zweifel aus der beschlossenen PGP-Dokumentation zu
ZConnect. In [D3.1M] ist unter der Überschrift
"Zeichensatz verschlüsselter Nachrichten" wörtlich
geregelt: "Sollte einmal ein Zeichensatzheader
eingeführt werden, muß auch dabei das Original vor
der Verschlüsselung mit einem vorangestellten
'CRYPT-CONTENT' erhalten bleiben." Die eingeführte
Zeichensatzheaderinformation heißt CHARSET, also
existiert die gültige und beschlossene Information
CRYPT-CONTENT-CHARSET.
Es ergibt sich auch hier das bei CRYPT-CONTENT-KOM
näher erläuterte Problem der
Verschlüsselungsrekursion.
Historie: D: [D3.1P]
A: [D3.1Z] (definiert CRYPT-...-CHARSET nicht)
Siehe auch: *CHARSET*, *CRYPT-CONTENT-KOM*, Verschlüsselung
Kennung: CRYPT-CONTENT-KOM +-----------------+
| Pflicht |
Kurzbeschreibung: Verschlüsselung enthält einen Kommentar |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
|>>Nur PM |
+-----------------+
Syntax: CRYPT-CONTENT-KOM: <Kommentarlänge>
Funktion: Das derzeitige PGP-Konzept sieht vor, daß der
Nachrichtenkörper im vollen Umfang (also
entsprechend der LEN-Headerinformation)
verschlüsselt wird. Dies kann auch für andere
Verschlüsselungsverfahren gelten. Um dann beim
Entschlüsseln einen ehemaligen Kommentar (genauer:
die KOM-Information) wiederherzustellen, ist der
Transport dessen ehemaliger Länge mit
CRYPT-CONTENT-KOM vorgeschrieben (diese Auffassung
bestätigt [D3.1Z]). Diese Headerinformation ist im
Zusammenhang mit CRYPT Pflicht, wenn eine
KOM-Information in der Ursprungsnachricht enthalten
war.
Ist eine Nachricht inklusive Kommentar ersteinmal
verschlüsselt und die Länge in CRYPT-CONTENT-KOM
codiert, so kann die Nachricht neuerlich mit einer
KOM-Headerinformation versehen werden.
Hinweis: Wird eine Nachricht, die bereits verschlüsselt ist,
mit einem neuerlichen Kommentar versehen und dann
z.B. nocheinmal unterschrieben, so bricht die Logik
der ZConnect-PGP-Einbindung zwangsläufig
auseinander. Nun müßte ein
CRYPT-CONTENT-CRYPT-CONTENT-KOM eingesetzt werden,
was vielleicht machbar wäre (sogar nach derzeitiger
Dokumentation, welche allerdings - hier schnell
verbrauchte - maximal 100 Zeichen für die
Headerkennung vorsieht), aber sicher nicht
wünschenswert ist. Die Einbindung hat hier eine
grundsätzlichen Schwäche. Die Erzeugung von
"Verschlüsselungsrekursion" sollte also unbedingt
vermieden werden.
Andererseits ist auf jeden Fall mit einem KOM
# zusätzlich zu CRYPT-CONTENT-KOM zu rechnen. Es wird
# von der Dokumentation nicht vorgeschlagen, wie beim
# Entschlüsseln die zwei möglichen Kommentare
# behandelt werden sollen. Es bietet sich an, diese
zusammenzufassen. Da am Nachrichtenkörper keine
Änderung vorgenommen werden darf, verbietet sich
hierbei eine naheliegende optische Trennung der
beiden Kommentare.
Historie: D: [D3.1P]
M: [D3.1Z] (Klarstellung)
Siehe auch: *CRYPT: PGP*, CRYPT-CONTENT-CHARSET,
CRYPT-CONTENT-TYP, KOM, Verschlüsselung
Kennung: CRYPT-CONTENT-TYP +-----------------+
| Pflicht |
Kurzbeschreibung: Typ der in einer verschlüsselten |>>Optional |
Nachricht enthaltenen Originalnachricht +-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
|>>Nur PM |
+-----------------+
Syntax: CRYPT-CONTENT-TYP: <Nachrichtentyp>
Funktion: Enthielt eine verschlüsselte Nachricht eine
TYP-Headerinformation, so muß diese nach dem
Entschlüsseln wieder berücksichtigt werden.
CRYPT-CONTENT-TYP gibt also bei beliebigen
Verschlüsselungsarten an, welche TYP-Information zum
entschlüsselten Inhalt gehört.
Die möglichen Nachrichtentypen sind bei TYP
beschrieben.
Hinweis: Das im Kontext auftretende Problem der
Verschlüsselungsrekursion ist bei CRYPT-CONTENT-KOM
genauer beschrieben.
Historie: D: [D3.1P]
Siehe auch: *CRYPT-CONTENT-KOM*, TYP, Verschlüsselung
Kennung: DDA +-----------------+
| Pflicht |
Kurzbeschreibung: Dateidatum |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: DDA: <Datumsangabe>
Funktion: Wenn die Nachricht eine Datei repräsentiert, kann
hiermit das Datum der letzten Änderung angegeben
werden. Das Datum enthält auch die Uhrzeit und ggf.
die Zeitzone. Das Format ist im Kapitel
"Datumsangaben" beschrieben.
Hinweis: Laut Dokumentation ist diese Headerinformation nicht
auf Binärnachrichten beschränkt. Jedoch sollte
mensch bedenken, daß die EDA-Headerinformation bei
jeder Nachricht ohnehin vorhanden ist.
Historie: D: [D3.0]
Siehe auch: EDA, FILE, TYP, Datumsangaben
Kennung: DISKUSSION-IN +-----------------+
| Pflicht |
Kurzbeschreibung: Umleitung von öffentlichen Antworten |>>Optional |
+-----------------+
| Nur einmal |
|>>Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: DISKUSSION-IN: <Brettname> | <ZConnect-Adresse>
Funktion: DISKUSSION-IN leitet die öffentliche Antwort auf
eine Nachricht um. Die öffentliche Antwort landet
also nicht im selben Brett wie die beantwortete
Nachricht, sondern wird in die bei DISKUSSION-IN
spezifizierten Brettern geleitet.
Die Angabe einer ZConnect-Adresse hat laut
Dokumentation die "Semantik von: 'Followup-To
poster'". Übersetzt bedeutet dies, daß die Antwort
auf eine öffentliche Nachricht in ein Postfach
umgeleitet werden kann. Wenn also ein
DISKUSSION-IN: <Brettname> zusammen mit einem
DISKUSSION-IN: <ZConnect-Adresse> angegeben ist, hat
dies die Funktion einer Kopie ins Postfach (z.B.)
der Absenderin der Nachricht.
Hinweis: Den Beantwortenden sollte die Möglichkeit gegeben
werden, eine private Adresse als einzigen Ort eines
Diskussionsbeitrags abzulehnen, um dem
Mehrwegecharakter der Netze gerecht zu werden.
Es ist möglich, diese Headerinformation auch bei
privaten Nachrichten einzusetzen. Wenn BenutzerInnen
eine öffentliche Antwort unter Bezugnahme auf eine
private Nachricht in ein bestimmtes Brett schreiben
können sollen, so ist die Angabe einer
DISKUSSION-IN-Information eine Möglichkeit.
Üblicherweise wird DISKUSSION-IN gesetzt, wenn eine
Nachricht in ein reines Informationsbrett gestellt
wird, und etwaige Diskussionen daher in einem
anderen Brett stattfinden sollen. Eine Nachricht
kann so in vielen Brettern eine Diskussion anregen,
die dann aber nur in einem geführt werden soll.
# [D3.1Z] erläutert, daß das absendende System # verhindern sollte, daß eine andere ZConnect-Adresse # als die der Absenderin bei einem DISKUSSION-IN # eingesetzt wird, um Mißbrauch zu verhindern. # Andererseits verhindert eine solche Einschränkung # natürlich die sinnvollen Anwendungsmöglichkeiten von # z.B. mehreren DISKUSSION-IN: <ZConnect-Adresse> oder # im Zusammenhang mit Mailinglisten. Da im Gremium # hierzu kein Beschluß vorliegt, sollten # ProgrammiererInnen ihre Implementierungsentscheidung # sorgfältig abwägen. Von der Befolgung der Regelung # aus [D3.1Z] wird an dieser Stelle aber strikt # abgeraten.
Historie: D: [D3.0]
M: [D3.1P] (Klarstellung)
A: [D3.1Z] (s.o.)
Siehe auch: *ANTWORT-AN*, EMP, Adressenformat, Brettnamenformat
Kennung: EB +-----------------+
| Pflicht |
Kurzbeschreibung: Empfangsbestätigung anfordern |>>Optional |
+-----------------+
| Nur einmal |
|>>Auch mehrfach |
| Stabil |
+-----------------+
|>>Nur PM |
+-----------------+
Syntax: EB: [<ZConnect-Adresse>]
Funktion: Für die Reaktion auf EB sind zwei Fälle vorgesehen:
Ist das Endsystem ein Point, der mit ZConnect
angeschlossen ist, so wird erst von ihm die
Empfangsbestätigung erzeugt. Ist die Mailbox{7}
dagegen das letzte ZConnect-System auf dem Weg zur
Empfängerin, so muß bereits sie (beim Einsortieren)
die Bestätigung verschicken.
Die Empfangsbestätigung ist von der Aussagekraft her
wörtlich zu nehmen: Das bestätigende System verrät
nicht, ob die Nachricht gelesen wurde, sondern nur,
daß sie bei ihm angekommen ist. Dies könnte aus
Sicht des Datenschutzes auch gar nicht anders sein.
Wird bei der EB-Headerinformation eine Adresse
mitgeschickt, so ist die Empfangsbestätigung nicht
an die Absenderin, sondern an eben jene Adresse zu
schicken. Hiermit erklärt sich auch, warum die
Information mehrmals vorkommen darf (mehrere
EB-Kennungen ohne Argument sind allerdings sinnlos).
WICHTIG: Wird keine Adresse mitgeschickt, so ist die
Bestätigung an eine eventuell vorhandene
ANTWORT-AN-Adressatin zu schicken. Ist diese nicht
angegeben, so wird sie an die WAB-Absenderin
versandt. Sind beide nicht vorhanden, wird gegenüber
der in der ABS-Headerinformation angegebenen Adresse
bestätigt.
Einige Details der Prozedur der Empfangsbestätigung
sind vorgeschrieben:
* Die bestätigende Nachricht erhält die STAT: EB
Headerinformation
* Die Message-ID der bestätigten Nachricht wird als
BEZ-Headerinformation eingefügt.
Hinweis: Janus-Points sind im engeren Sinn der Regelung für
Empfangsbestätigungen nicht als ZConnect-Systeme zu
werten, erzeugen also keine Empfangsbestätigungen.
Es werden hierzu auch andere Meinungen vertreten
([B3], [PM3]). In der Praxis ist das
Softwareverhalten so unterschiedlich wie die
Meinungen.
Die EB-Headerinformation bleibt unabhängig von der
eventuellen Abarbeitung durch die Mailbox auf dem
Weg zur Anwenderin erhalten. Gelöscht wird sie
hingegen beim Weiterleiten (Ausnahme: Umleiten),
beim Zurückschicken im Fehlerfall, beim Antworten
etc..
Wenn es auch nicht verboten wäre, die indirekten
Bezüge in die Empfangsbestätigung zu übernehmen, so
würde dies doch wenig Sinn machen.
Manche Pointprogramme verschicken die
Empfangsbestätigung mit einer einstellbaren Anzahl
Tage Verzögerung. Dies ist unter Datenschutzaspekten
eine äußerst sinnvolle Erwägung.
Historie: D: [D3.0]
Siehe auch: ABS, BEZ, STAT: EB, MID, Adressenformat, Points,
Weiterleiten
Kennung: EDA +-----------------+
|>>Pflicht |
Kurzbeschreibung: Erstellungsdatum | Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: EDA: <Datumsangabe>
Funktion: Jede Nachricht muß mit einem Erstellungsdatum
versehen werden. Das Datum enthält wie immer auch
Zeit und ggf. Zeitzone.
Hinweis: Beim Einsetzen des Erstellungsdatums sind unbedingt
Datenschutzaspekte zu beachten. AnwenderInnen müssen
die Möglichkeit haben, zumindest die Angabe der
Uhrzeit der Erstellung zu verweigern. Es empfiehlt
sich, das automatische Setzen der Uhrzeit auf
generell 0:00 Uhr (oder einen anderen, beliebigen,
immer gleichen Wert) zu ermöglichen.
Historie: D: [D3.0]
Siehe auch: DDA, Datenschutz, Datumsangaben
Kennung: EMP +-----------------+
|>>Pflicht |
Kurzbeschreibung: Empfängerin | Optional |
+-----------------+
| Nur einmal |
|>>Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: EMP: <Brettname> |
<ZConnect-Adresse> [(<Realname>)]
Funktion: Diese Headerinformation gibt die Empfängerin der
Nachricht an. Es kann sich um ein Brett oder eine
private Adressatin handeln. EMP kann mehrfach
vorkommen, also ist es auch möglich, daß beide
Möglichkeiten im selben Header gemischt auftreten
(vgl. Kapitel Gemischtadressierung). Unverändert
gilt die ZConnect 3.0-Regelung, daß eine private
Empfangsadresse mit Realname in der üblichen
Schreibweise versehen sein darf.
Bei öffentlichen Nachrichten, die aus dem Netz
kommen{8}, und die ins Netz gehen{9}, darf niemals
(es existiert keine Ausnahme von der Regel) eine
öffentliche Empfängerin zu einer Kopienempfängerin
werden, also *keine* Wandlung von EMP nach KOP
stattfinden.
Bei privaten Empfängerinnen ist dies hingegen
ausdrücklich vorgesehen. Wird also z.B. ein
Mischcrossposting an einer Stelle aufgetrennt in die
private Nachricht und die öffentliche Nachricht, so
tauchen in der privaten Nachricht alle öffentlichen
Empfängerinnen als KOPs auf. In der abgetrennten
öffentlichen Nachricht taucht die private
Kopienempfängerin ebenfalls als KOP auf (wenn nicht
STAT: NOKOP angegeben wurde).
Wenn ein System eines oder mehrere der in einer
EMP-Information aufgeführten Bretter nicht führt
oder nicht bestellt hat, dürfen dennoch keine
EMP-Informationen gelöscht werden. Insbesondere
dürfen in diesem Fall auch bei Nachrichten, die aus
dem Netz kommen, und die in das Netz gehen, EMPs
nicht in KOPs gewandelt werden.
Hinweis: Weist die EMP-Headerinformation einer Nachricht auf
ein Brett, welches lokal auf Schreibverbot (z.B.
geschlossene BenutzerInnengruppe) steht, so sollte
die Nachricht nicht in das Brett gestellt, aber auch
nicht mit einem KOP-Header versehen werden. Vielmehr
sollte sie komplett zensiert, also z.B. den
SystemverwalterInnen zur Entscheidung vorgelegt
werden.
Crosspostings, also Nachrichten mit mehreren EMPs,
sind mittlerweile eher die Regel als die Ausnahme.
Häufig ist Verwirrung hinsichtlich der Regelung für
das Ersetzen von EMP durch KOP festzustellen. Dieses
Thema wird daher bei KOP ausführlich behandelt.
Historie: D: [D3.0]
M: [D3.1P] (Klarstellung), [D3.1M] (Klarstellung)
Siehe auch: *DISKUSSION-IN*, EB, *KOP*, STAT: NOKOP,
Adressenformat, Brettnamenformat,
*Gemischtadressierung*, Points
Kennung: ERR +-----------------+
| Pflicht |
Kurzbeschreibung: Fehlerkennung |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
|>>Nur PM |
+-----------------+
Syntax: ERR: <Fehlerklasse> [;<Fehlernummer>]* [<Fehlermeldungsklartext>]
Funktion: Eine Nachricht mit dieser Headerinformation befindet
sich auf dem Rückweg von einem System, welches einen
Fehler in ihr bemerkt hat (z.B. Empfängerin
unbekannt, Fehler im Header). ERR enthält mindestens
eine Fehlerklasse. Die möglichen Klassen sind im
folgenden aufgelistet:
Klasse | Typ | Bedeutung
-------+---------+----------------------------------------
0 | Warnung | anwenderdefiniert
1-4 | Warnung | Zustellung trotz Problemen erfolgt
5-9 | Fehler | Zustellung wegen Fehlern nicht erfolgt
>=10 | Panik | anwenderdefiniert
Die Fehlerklassen 0 und >=10 sind nur lokal zu
verwenden und sollten nicht über das Netz gehen.
Grundsätzlich sind alle natürlichen Zahlen inkl. der
0 möglich. Als Zahlentyp schlägt [D3.1M] wörtlich
"intern mindestens [...] 4 Byte (LongInt)" vor. Die
Fehlerklassifizierung soll insbesondere der Software
zwischen Warnungen und Fehlern unterscheiden helfen.
Zusätzlich sind beliebig (!) viele Fehlernummern
möglich.
Optional, aber nur bei vorangegangener Fehlerklasse
(und evtl. vorangegangenen Fehlernummern), ist ein
Fehlermeldungsklartext enthalten, für den in der
Dokumentation die englische Sprache nahegelegt wird.
Numerische Werte werden durch ein Semikolon
voneinander getrennt, der Klartext hingegen ist
durch ein Leerzeichen abgetrennt.
Eine Nachricht mit ERR-Headerinformation darf nicht
erneut fehlerbehandelt werden. Sollte keine
Empfängerin angegeben sein, ist die Nachricht zu
entsorgen.
Ist bei einer Nachricht eine Weiterleitabsenderin
(WAB) oder eine ANTWORT-AN-Adresse angegeben, so
sind diese statt der Absenderin von dem
aufgetretenen Fehler zu unterrichten. ANTWORT-AN hat
hierbei höhere Priorität.
Hinweis: Aus der Dokumentation ist nicht ersichtlich, ob zur # Abtrennung des Klartextes ein beliebiges Whitespace # verwendet werden darf, oder ob ein Leerzeichen # verpflichtend ist. Es ist sinnvoll, mit Whitespaces # zu rechnen, aber in der eigenen Software ein # Leerzeichen zu erzeugen. # # Die ZConnect 3.1 Spezifikation der # ERR-Headerinformation ist nicht abwärtskompatibel zu # ZConnect 3.0, welches ausschließlich Klartext als # Argument vorsah (3.0-Systeme verstehen zwar # 3.1-ERR-Informationen, 3.1-Systeme aber nicht die # von 3.0-Systemen). Vermutlich aus diesem Grunde # beschreibt [D3.1Z] die Syntax der ERR-Information, # unter der Maßgabe, daß eine ERR-Information ohne # Parameter unzulässig ist, wie folgt: # # ERR: [<Fehlerklasse>[;<Fehlernummer>]*] [<Fehlermeldungsklartext>] # # Eine ERR-Information mit reinem Klartext wäre demnach # nachwievor zulässig. Vermutlich durch einen # Cut&Paste-Fehler widerspricht [D3.1Z] sich hier aber # fünf Zeilen später und benennt wieder die von [D3.1M] # beschriebene Syntax als gültig. # # [D3.1Z] definiert auch Fehlernummern, die das Gremium # bisher nicht beschlossen hat, die vermutlich dem # Ist-Stand beim Zerberus-Programm entliehen und zudem # von vielen Gremiumsmitgliedern abgelehnt werden ([B4]): # # Fehlernummer | Bedeutung # -------------+---------------------------------------------- # 1 | Versand nicht möglich # 1;1 | Konto überzogen # 1;2 | Nachricht zu alt # 1;3 | Netzzugriff für Absenderin gesperrt # | # 2 | Private Nachricht kann nicht zugestellt werden # 2;1 | Keine Empfängerin angegeben # 2;2 | Empfängerin beim Zielsystem unbekannt # 2;3 | Zieladresse ist ein Verteiler, und der ist # | Zschreibgeschützt # | # 3 | Private Nachricht kann nicht geroutet werden # 3;1 | Routesystem unbekannt oder gesperrt # 3;2 | Direktmails und Routemails gesperrt # 3;3 | Nachricht zu lang # 3;4 | System beim Domainserver unbekannt # 3;5 | Domainserver unbekannt # 3;6 | Rekursion aufgetreten # 3;7 | Empfangssystem gesperrt # 3;8 | Domain unbekannt # | # 4 | Zustellung in Brett nicht möglich # 4;1 | Brett nur für Onlinezugriff # 4;2 | Brettname unzulässig # 4;3 | Brett existiert nicht # 4;4 | Brett gesperrt # 4;5 | Kein Autoeintrag; mehrfache Brettangaben # | # 5 | Fehlerhafte Headerinformationen # 5;1 | Nur einmal erlaubter Header tritt mehrfach auf # 5;1;1 | ABS # 5;1;3 | EMP # 5;1;4 | BET # 5;1;5 | ROT # 5;1;6 | LEN # 5;1;7 | MID # 5;1;8 | WAB # 5;1;10 | OAB # 5;2 | Ein Pflichtheader ist nicht vorhanden # 5;2;1 | ABS # 5;2;2 | EMP # 5;2;3 | EDA # 5;2;4 | BET # 5;2;5 | ROT # 5;2;6 | LEN # 5;2;7 | MID # 5;3 | Eine Headerinformation hat ein falsches Format # 5;3;1 | ABS # 5;3;2 | EMP # 5;3;3 | EDA # 5;3;4 | BET # 5;3;5 | ROT # 5;3;6 | LEN # 5;3;7 | MID # 5;3;8 | WAB # 5;3;9 | KOP # 5;3;10 | OAB # 5;3;11 | OEM # 5;3;12 | EB # 5;3;13 | ANTWORT-AN # 5;3;14 | DISKUSSION-IN # # In der Tabelle sind etliche Widersprüche zu # konstatieren: Die Fehlernummern 1;x bis 4;x sind # schwerlich sämtlich als "Warnung" interpretierbar # (vgl. Tabelle der Fehlerklassen), da teilweise die # Zustellung aus technischen Gründen unmöglich ist. # Eine Fehlernummer wie 4;5 ist ohne weitere # Erläuterungen schwer nachvollziehbar. # # Zudem ist von einer "GAB"-Headerinformation die # Rede, welche es natürlich nicht gibt. Sicher handelt # es sich um einen Druckfehler; aus der Logik der # Fehlernummernvergabe ergibt sich, daß es sich an den # entsprechenden Stellen um die LEN-Information # handeln müßte, wie in der obigen Tabelle # dargestellt.
Historie: D: [D3.0]
M: [D3.1M]
A: [D3.1Z]
Siehe auch: Aufbau und Zeichensatz von Headerinformationen,
Weiterleiten
Kennung: ERSETZT +-----------------+
| Pflicht |
Kurzbeschreibung: Nachrichtenaktualisierung |>>Optional |
+-----------------+
| Nur einmal |
|>>Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: ERSETZT: <Message-ID>
Funktion: Die Nachricht mit der ERSETZT-Headerinformation
ersetzt die Nachricht mit der als Argument
angegebenen Message-ID. Dies ist zugleich Anweisung
und Information. Die zu ersetzende Nachricht (z.B.
eine aktuelle Brettliste) wird von der
ERSETZT-Nachricht überschrieben. Anschließend steht
die Headerinformation dann für die Aussage, daß
ersetzt wurde.
Hinweis: ERSETZT wird von mehreren Programmen als
Cancelmail{10}-Ersatz verwendet. Dies ist insofern
eine Zweckentfremdung, als die Cancelmail dann
anstelle der Originalmail tritt, statt sie zu
löschen.
[D3.1Z] ist bemüht, ERSETZT zu einem vollwertigen
Cancelmail-Ersatz umzudokumentieren. Dazu wird
definiert, daß abweichend von den Gremiumsbeschlüssen
eine Nachricht mit leerem Nachrichtenkörper und ERSETZT
im Header die zu ersetzende Nachricht löscht, ohne an
ihre Stelle zu treten. Zudem sei eine
Autorisierungsprüfung notwendig, deren Durchführung
aber nicht näher erläutert wird.
Seit der Einführung der CANCEL-Headerinformation hat
sich die Diskussion um die Verwendung von ERSETZT
als Cancelmail-Ersatz erledigt.
# Ohne eine Autorisierung ist die # ERSETZT-Headerinformation problematisch, da sie als # Sabotagemittel geeignet ist. Dies ergibt sich # daraus, daß ERSETZT mehrfach angegeben werden kann. # So kann eine einzige Nachricht theoretisch das # gesamte Netzleben lahmlegen.
Bei [D3.1Z] ist angemerkt, daß es für die Umsetzung von
ERSETZT in die Praxis ausreichen würde, der alten, zu
ersetzenden Nachricht einen Hinweis anzufügen, daß
diese ersetzt worden sei. Angesichts der Tatsache, daß
Nachrichtenkörper nicht geändert werden dürfen, ist nur
das Hinzufügen eines Kommentars nebst
KOM-Headerinformation möglich.
BenutzerInnenschnittstellen sollten unter Beachtung
des Umstandes implementiert werden, daß ERSETZT in
den Datenbestand einer Anwenderin eingreift, wenn es
auf einem Endsystem ausgewertet wird. Die Umsetzung
von ERSETZT sollte also sorgfältig erwogen werden.
STAT: AUTO ist eng verwandt mit ERSETZT. Als
Unterschied ist ausschließlich zu nennen, daß zur
Identifizierung der zu aktualisierenden Information
bei STAT: AUTO andere (FILE und EMP)
Headerinformationen herangezogen werden als die
Message-ID.
Historie: D: [D3.0]
A: [D3.1Z]
Siehe auch: BEZ, CANCEL, MID, STAT: AUTO
Kennung: FILE +-----------------+
| Pflicht |
Kurzbeschreibung: Dateiname |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: FILE: <Dateiname>
Funktion: Enthält die Nachricht eine Datei (z.B. bei einer
Binärnachricht), so kann mit FILE ein Dateiname
angegeben werden. Dieser darf keine
Directoryinformationen enthalten, ist aber je nach
Betriebsystem unterschiedlich lang.
Der Dateiname kann wegen seiner unbestimmten
Herkunft jederzeit auch beliebige Sonderzeichen
(z.B. auch Leerzeichen, Hochkommata, mehr als einen
Punkt) enthalten. Die verarbeitende Software muß
hierauf vorbereitet sein und evtl. eine Umwandlung
vornehmen oder einen neuen Namen generieren.
Hinweis: Angesichts der Tatsache, daß der Dateiname absolut
beliebige Zeichen (Einschränkung: Zeichensatz in
Headerinformationen) enthalten darf, ist das Verbot
von Directoryinformation natürlich hauptsächlich
beim Erzeugen zu berücksichtigen; es ist dabei auf
eine möglichst betriebsystem-ökumenische
Namensgebung zu achten. Wenn ein Betriebsystem
zwischen Groß- und Kleinschreibung nicht
unterscheidet, wird die Angabe des Dateinamens in
Kleinbuchstaben empfohlen.
Historie: D: [D3.0]
Siehe auch: DDA, STAT: AUTO, TYP: BIN
Kennung: KOM +-----------------+
| Pflicht |
Kurzbeschreibung: Kommentarlänge |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: KOM: <Kommentarlänge>
Funktion: Der Nachrichtenkörper einer Nachricht kann
unterteilt sein in Kommentar und eigentliche
Nachricht (z.B. ausführliche Dateibeschreibung als
Kommentar und anschließende Binärnachricht). In
diesem Fall gibt KOM die Anzahl Bytes an, die der
Kommentar in der Mail ausmacht. Der Kommentar selber
steht am Anfang des Nachrichtenkörpers.
Für den Inhalt des Kommentars gelten die
Standardregeln für den Nachrichtenkörper allgemein.
Das bedeutet insbesondere, daß eine CHARSET- oder
eine TYP-Headerinformation auf den Kommentaranteil
keine Wirkung hat!
Die LEN-Information ist die Summe aus der Länge des
Kommentaranteils und der Länge des Rests des
Nachrichtenkörpers.
Graphisch dargestellt:
Ú-----------------------+
| Header |
+-----------------------+-. --.
| Kommentar | |- KOM |
+-----------------------+-' |
| | |- LEN
| Daten/Text | |
| | |
+-----------------------+ --'
Hinweis: Der Kommentar kann nicht nur einem Binärteil
vorangestellt werden. Insbesondere kann er auch in
einer normalen Textnachricht vorkommen.
Es ist mit KOM: 0 zu rechnen.
Historie: D: [D3.0]
Siehe auch: LEN, *CRYPT-CONTENT-KOM*
Kennung: KOP +-----------------+
| Pflicht |
Kurzbeschreibung: Kopienempfängerin |>>Optional |
+-----------------+
| Nur einmal |
|>>Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: KOP: <Brettname> | <ZConnect-Adresse>
Funktion: Bei Nachrichten mit mehreren Empfängerinnen kann es
unter bestimmten Voraussetzungen zur Ersetzung von
EMPs durch KOPs kommen. Eine KOP-Headerinformation
sagt aus, daß eine Kopie der Nachricht an die
angegebene Empfängerin gegangen ist.
Die KOP-Information hat keine Steuerfunktion. Sie ist
ein Dienst für die menschliche Adressatin der
Nachricht. Diese ist die einzige Instanz, die mithilfe
der BenutzerInnenschnittstelle irgendwelche Schlüsse
aus KOPs ziehen darf; z.B. darf der Inhalt der
KOP-Headerinformationen niemals zu Routingzwecken
herangezogen werden.
Hinweis: Aus Datenschutzgründen wurde die Headerinformation
STAT: NOKOP eingeführt, mit welcher der Einsatz von
KOP im Zusammenhang mit privaten Nachrichten
untersagt werden kann. Dies ist sehr sinnvoll,
kompliziert aber auf den ersten
ProgrammiererInnenblick die Implementierung. Daher
erfolgt bereits an dieser Stelle die Einbeziehung
von STAT: NOKOP in die Erläuterung; der Querverweis
sollte dennoch nicht übersehen werden, da es weitere
Details zu beachten gilt.
Bei der Erläuterung von EMP in [D3.1M] ist das
Einsetzen von KOP-Headerinformationen bei
Privatnachrichten, die von einer gemischt
adressierten Nachricht abgetrennt werden, als
Pflicht beschrieben.
Der Einsatz von KOPs zunächst einmal dem Sinn nach
aufgeschlüsselt:
* Bei gemischtadressierten Nachrichten hat die
private Empfängerin evtl. ein Interesse daran, zu
erfahren, daß und in welche öffentliche Bretter
Kopien gegangen sind. Auch ist diese Information
nicht schutzwürdig, da die öffentlichen Kopien
jedermensch lesen kann.
* Bei Crosspostings, die (auch) an mehrere private
Empfängerinnen geht, kann die Absenderin
berechtigte Einwände dagegen haben, daß die
Empfängerinnen erfahren, an wen private Kopien
gegangen sind. Dies entspricht einem konsequenten
Datenschutzgedanken.
* Bei Crosspostings, die (auch) öffentliche
Empfängerinnen haben, kann die Absenderin
vermeiden wollen, daß im öffentlich werdenden
Header zu lesen ist, an wen private Kopien
gegangen sind (Datenschutz).
* Auch eine private Empfängerin könnte etwas dagegen
einzuwenden haben, daß öffentlich oder anderen
privaten Empfängerinnen kundgetan wird, daß sie
eine Kopie erhalten hat. Jedoch liegt es dann "wie
im richtigen Leben" bei der Empfängerin, sich mit
der Absenderin auseinanderzusetzen. Das Protokoll
darf der Absenderin nur technisch Notwendiges
vorschreiben. Das Pointprogramm (z.B.) könnte aber
sinnvollerweise STAT: NOKOP als Normalfall
behandeln und seine Nicht-Verwendung explizit
auswählen lassen.
Vor den technischen Schlußfolgerungen zunächst eine
sprachliche Definition: Die Ursprungsnachricht wird
aufgeteilt in die Abspaltung und den Rest. Die
Abspaltung ist der fortan selbständig auf den
(Route-) Weg geschickte Teil mit einer oder mehreren
privaten Empfängerinnen{11}. Der Rest ist die
übrigbleibende, öffentliche Nachricht (eine
Nachricht ist dann öffentlich, wenn eine der
Empfängerinnen nicht privat ist). Es wird also immer
der Moment betrachtet, in dem rein private
Nachrichten entstehen.
Zwei Logiktabellen machen im folgenden deutlich, wie
die Programmierung aussehen muß. Zunächst eine
Logiktabelle für die Behandlung des Rests:
| EMP- | |
| Typen | |
| im | |
| Rest | |
| | S |
| P | Ö | T |
| r | f | A |
| i | f | T |
| v | e | : |
| a | n | |
| t | t | N |
| | l | O |
| | i | K |
| | c | O |
| | h | P | | Aktion
+---+---+---+ +--------------------------------
| | x | | -> | Abgespaltener EMP wird zu KOP
| | x | x | -> | Abgespaltener EMP verschwindet
| x | | | -> | Abgespaltener EMP wird zu KOP
| x | | x | -> | Abgespaltener EMP verschwindet
| x | x | | -> | Abgespaltener EMP wird zu KOP
| x | x | x | -> | Abgespaltener EMP verschwindet
Es ist deutlich, daß beim Rest sehr einfach
vorgegangen werden kann: Ist STAT: NOKOP gesetzt, so
wird kein KOP erzeugt, die Information des
abgetrennten EMPs verschwindet. Ist STAT: NOKOP
nicht gesetzt, werden aus abgetrennten EMPs KOPs.
Die Logiktabelle für die Abspaltung:
| EMP- | |
| Typen | |
| im | |
| Rest | |
| | S |
| P | Ö | T |
| r | f | A |
| i | f | T |
| v | e | : |
| a | n | |
| t | t | N |
| | l | O |
| | i | K |
| | c | O |
| | h | P | | Aktion
+---+---+---+ +----------------------------------------
| | x | | -> | Alle EMPs des Rests werden zu KOPs
| | x | x | -> | Alle EMPs des Rests werden zu KOPs
| x | | | -> | Alle EMPs des Rests werden zu KOPs
| x | | x | -> | Die EMPs des Rests verschwinden
| x | x | | -> | Alle EMPs des Rests werden zu KOPs
| x | x | x | -> | Alle öffentlichen EMPs des Rests werden
| | | | | zu KOPs, alle privaten EMPs verschwinden
Hier stellt sich die Aufgabe ebenfalls sehr
übersichtlich dar: Ist STAT: NOKOP nicht gesetzt, so
werden alle nach der Abtrennung übrigbleibenden EMPs
des Restes zu KOPs der Abspaltung.
Bleiben drei Fälle, in denen STAT: NOKOP gesetzt
ist, und die sich ganz einfach so zusammenfassen
lassen: Die öffentlichen EMPs des Rests (sofern
vorhanden) werden zu KOPs der Abspaltung, die
privaten EMPs des Rests (sofern vorhanden) nicht.
Eine neue Message-ID muß übrigens für die ja rein
private Abspaltung nicht erzeugt werden, da der
ZConnect-Rekursionscheck (und auch andere
Netzstandards, z.B. die RFC-Suite) den Dupecheck bei
privaten Nachrichten nicht vorsieht.
Bei der Auftrennung gemischtadressierter Nachrichten
ist, wegen des Designproblems ZConnects in diesem
Kontext (siehe Kapitel Gemischtadressierung), zu
beachten, daß Headerinformationen wie PGP: PLEASE,
VIA, STAT: TRACE, EB usw. nicht in einer rein
öffentlich adressierten Nachricht weitergereicht
werden, soweit dies vermeidbar ist.
Historie: D: [D3.0]
M: [D3.1P] (Klarstellung), [D3.1M] (Klarstellung)
Siehe auch: EMP, *STAT: NOKOP*, Adressen, Brettnamen,
*Gemischtadressierung*, Points, Dupecheck
Kennung: LANGUAGE +-----------------+
| Pflicht |
Kurzbeschreibung: Nachrichtensprache |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
|>>Nur PM |
+-----------------+
Syntax: LANGUAGE: <Englischsprachiger Name der Sprache>
Funktion: Die Absenderin einer Nachricht kann mit dieser
Headerinformation angeben, in welcher Sprache sie
gerne die Antwort bekommen würde. Kann die
gewünschte Sprache nicht angeboten werden, so
empfiehlt die Dokumentation, die englische zu
benutzen.
Als Parameter sind die englischsprachigen
Bezeichnungen der jeweiligen Sprache zugelassen.
Also z.B. GERMAN für Deutsch, ENGLISH für Englisch,
AMERICAN ENGLISH für amerikanisches Englisch,
CUCKOOISH für das Piepsen der Kuckucks, SPANISH,
GREEK, FRENCH...
Hinweis: Diese Headerinformation ist in der derzeitigen
Fassung nur für automatisch generierte Antworten
sinnvoll.
# Eine weitere Anwendung für einen dann aber erweitert # zu definierendes LANGUAGE ist denkbar: Abseits von # der technischen CHARSET-Regelung ist es für die # Empfängerin möglicherweise von Interesse, in welcher # Sprache eine Nachricht geschrieben ist. Aus # japanischen Zeichen läßt sich z.B. auch bei # gegebener Darstellbarkeit für Laien nicht erkennen, # ob es sich z.B. um Katakana, Hiragana oder etwas # ganz anderes handelt. # # Auch wäre vorstellbar, daß eine Empfängerin bei # einer imaginären Pointsoftware einstellt, daß sie # nur französischsprachige Nachrichten überhaupt # angezeigt bekommen möchte. Oder, um der Vision des # Globalen Dorfes eine linguistische Dimension zu # geben, es könnte auch Pointsoftware geben, die # automatisch Übersetzungen vornimmt. Dies ist schon # heute teilweise, insbesondere für die englische # Sprache, realistisch, z.B. durch Einbindung eines # externen Übersetzungsprogramms. Denkbar ist auch das # Angebot eines automatischen Übersetzungsservices # über per eMail oder Onlineverbindungen erreichbare # Netzautomatismen. Umsetzungen werden bereits erprobt # [B5].
Historie: D: [D3.1M]
Siehe auch: Points, Weiterleiten
Kennung: LDA +-----------------+
| Pflicht |
Kurzbeschreibung: Löschdatum |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: LDA: <Datumsangabe>
Funktion: Verfallsdatumangabe :-) Ab dem angegebenen Datum
soll die Nachricht automatisch gelöscht werden.
Nützlich für Veranstaltungshinweise oder z.B. auch
die Urgent Actions von amnesty international.
Hinweis: Ein Pointprogramm sollte nicht ohne Einwilligung der
Inhaberin des Datenbestands in diesem löschen. LDA
kann also bestenfalls zusammen mit einer Rückfrage
bei der Benutzerin einen Automatismus ergeben.
Anders sieht es in Onlinedatenbeständen aus, hier
kann LDA im Rahmen der automatischen Pflege
bearbeitet werden.
Historie: D: [D3.0]
Siehe auch: Datumsangaben, Points, Weiterleiten
Kennung: LEN +-----------------+
|>>Pflicht |
Kurzbeschreibung: Nachrichtenlänge | Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: LEN: <Länge des Nachrichtenkörpers>
Funktion: LEN gibt die Anzahl der Bytes an, die nach dem
Header noch folgen und zur Nachricht gehören
(sprich: die Länge des Nachrichtenkörpers).
Hinweis: Die Länge Null ist in der Dokumentation explizit als
erlaubt definiert. Negative Längen sind verboten.
Historie: D: [D3.0]
Siehe auch: KOM
Kennung: MAILER +-----------------+
| Pflicht |
Kurzbeschreibung: Name des Mailerprogramms |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: MAILER: <Kennung des Mailers>
Funktion: Hiermit kann sich der Mailer der Absenderin und/oder
ein Gate identifizieren. Die Kennung sollte
eindeutig sein (Versionsnummer usw.). Gedacht ist
diese Headerinformation für das Ausfindigmachen von
fehlerhafter Software.
Hinweis: MAILER wird nicht von Software ausgewertet, das
Format ist also frei.
# Mailboxsoftware hängt meistens an bereits bestehende # MAILER-Zeilen ein "via Mailboxsoftware XYZ" an. # Dieses Vorgehen ist nicht überall gern gesehen, wird # aber geduldet, wenn die Mailerinformation nicht # allzu lang gerät. Sinnvoll wäre es, wenn sich alle # Gatewayprogramme in ähnlicher Weise benennen würde, # da sie sehr häufig Quelle von Fehlern sind.
Historie: D: [D3.0]
Siehe auch: Headerzeichensatz, Weiterleiten
Kennung: MID +-----------------+
|>>Pflicht |
Kurzbeschreibung: Message-ID | Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: MID: <Message-ID>
Funktion: Die Message-ID muß so erzeugt werden, daß sie
weltweit für mindestens zwei Jahre eindeutig ist.
Tritt eine Message-ID innerhalb von zwei Jahren zum
wiederholten Mal bei einer Nachricht auf, handelt es
sich um eine zu löschende Rekursion.
Das Aussehen der Message-ID ist recht genau
vorgeschrieben: Sie muß wie eine ZConnect-Adresse ohne
Realname aussehen und unbedingt eine Domain enthalten
(falls das absendende System keine Domain hat, ist
".zer.sub.org" zu verwenden).
Für Points wird vorgeschlagen, die Message-ID in der
Form lokale_id@pointname.systemname.domain aufzubauen.
Der Teil vor dem '@' wird häufig und sinnvollerweise
aus der von vielen Compiler-Standardbibliotheken
gelieferten "Unixtime" (Zeit in Sekunden seit 1970) und
einer laufenden Nummer gebildet. Diese Daten sind dann
aber noch geeignet zu verfremden, um das
Datenschutzbedürfnis der Absenderin (vgl. EDA) nicht
auszuhebeln.
# Ein weiterer, äußerst sinnvoller und daher bitte nicht # zu ignorierender Vorschlag in der Dokumentation ist, # bei Points, die mehr als ein System als Tor zum Netz # verwenden, den Teil nach dem '@' nicht systemabhängig # zu generieren. Für System A und System B lautet es dann # also lokale_id@point.A.domain. Dies verhindert Dupes # (die andernfalls entstünden, sobald einE BenutzerIn auf # den Gedanken käme, dieselbe Mail in mehrere Boxen zu # schicken, z.B. damit sie sich schnell verbreitet).
Die Zeichen '<', '>' und '/' sind in Message-IDs
verboten. Aus dem für Header zulässigen Zeichensatz
ergibt sich aber z.B., daß deutsche Sonderzeichen
enthalten sein könnten.
Hinweis: Die Message-ID ein und derselben Mail darf niemals
verändert werden! Der früher übliche Umbau der
Point-Message-ID bei der ersten Mailbox auf dem
Routeweg hat zu erheblichen Problemen und Dupewellen
geführt.
Auf Rekursionen muß jede Software prüfen und diese
dann entsprechend behandeln. Näheres ist im Kapitel
Rekursionscheck erläutert.
# Es findet sich in der Dokumentation kein Hinweis # darauf, ob die Groß-/Kleinschreibung bei einer # Message-ID zu beachten ist. In der Spezifikation zum # MAPS-Standard (in [D3.1M]) wird beim ORDER-Befehl # beschrieben, bei der Message-ID sei die # Groß-/Kleinschreibung zu beachten. [D3.1Z] hingegen # bestimmt in gleichem Kontext, die Message-ID sei bis # zum "@" case sensitive und dahinter case insensitive. # Angesichts der Definition von Mailadressen, die hinter # dem "@" case insensitive zu behandeln sind, und # angesichts deren Eingang in die Bildung der Message-ID, # trifft die Beschreibung durch [D3.1Z] zu.
Historie: D: [D3.0]
M: [B5], [D3.1M]/[D3.1Z] (Klarstellung)
Siehe auch: BEZ, ERSETZT, Adressenformat, *Dupecheck*
Kennung: MIME +-----------------+
| Pflicht |
Kurzbeschreibung: Art der MIME-Codierung |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
|>>Nur PM |
+-----------------+
Syntax: MIME: <Version>.<Unterversion>
Funktion: Gibt für Nachrichten mit TYP: MIME an, welche
MIME-Version und Unterversion verwendet wurden.
Hinweis: MIME ist in [RFC 1521] definiert.
ACHTUNG: Sämtliche Diskussionen um die
MIME-Integration in ZConnect und auch die vom
Gremiumswahlleiter hierzu versandten Texte weisen
eindeutig daraufhin, daß dringend davon abzuraten
ist, aufgrund der derzeitigen MIME-Beschlußlage eine
Implementierung vorzunehmen. Es wird mit Sicherheit
größere Änderungen geben, potentiell werden dabei
sämtliche bisherigen Beschlüsse zu ZConnect-MIME
aufgehoben.
Historie: D: [Wahl5]
Siehe auch: TYP: MIME, Kapitel "MIME"
Kennung: O-EDA +-----------------+
| Pflicht |
Kurzbeschreibung: Originalempfangsdatum |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: O-EDA: <Datumsangabe>
Funktion: Die EDA-Headerinformation einer weiterzuleitenden
Nachricht kann auf diese Weise in der Weiterleitung,
welche eine eigene EDA-Information haben muß,
überleben.
Hinweis: [D3.1Z] erläutert, daß O-EDA nur bei der ersten
Weiterleitung aus der verlorengehenden
EDA-Information erzeugt wird. Hintergrund sei, daß
für weiterzuleitende Nachrichten eine neue
EDA-Headerinformation erzeugt werden muß und die
Originalerstellungszeit dadurch verloren ginge.
# O-EDA wird nur beim manuellen Weiterleiten eingesetzt, # da beim automatischen Weiterleiten und beim Umleiten # davon ausgegangen wird, daß private Nachrichten # transportiert werden, für die weder eine neue # Message-ID (zur Vermeidung einer irrtümlichen # Rekursionsdetektion) noch ein neues EDA (zur Vermeidung # einer Löschung als "zu alt") erforderlich sind. Dies # ist jedoch eine unzulässige Annahme, da beim # automatischen Weiterleiten einer PM, z.B. einer # Nachricht aus einer Mailingliste, in ein (z.B. lokales) # Brett, die Nachricht verlorengehen könnte, weil die # Systemsoftware ein zu hohes Alter diagnostiziert (vgl. # MID, Rekursionscheck: Nachrichten, die älter als 90 # Tage sind, werden gelöscht).
Historie: D: [D3.1P]
M: [D3.1Z] (Klarstellung)
Siehe auch: EDA, Rekursionscheck, *Weiterleiten*
Kennung: O-ROT +-----------------+
| Pflicht |
Kurzbeschreibung: Originalrouteweg |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: O-ROT: <Routestring>
Funktion: Beim Weiterleiten muß der Routeweg der
weiterzuleitenden Nachricht gelöscht werden, da die
Weiterleitung eine neue ROT-Headerinformation
erhält. Mittels O-ROT kann der alte Routeweg in der
Weiterleitung transportiert werden.
Hinweis: [D3.1Z] erläutert, daß dieser Header bei
Weiterleitungen über einen Vertreter
(VER-Headerinformation) aus der ROT-Information
erzeugt werden soll, um bei privaten Nachrichten das
vermeintliche Feststellen eines Pingpongroutings zu
vermeiden. Dies würde passieren, wenn unter
Beibehaltung der ROT-Information eine Nachricht
wieder auf den Weg ins Netz geschickt und dabei
wieder über Systeme geroutet werden würde, die
bereits auf dem Weg zum weiterleitenden System
passiert wurden.
# Mit dieser Begründung ist es entgegen der bisherigen # Dokumentation auch erforderlich, O-ROT beim # automatischen Weiterleiten einzusetzen (vgl. # Weiterleiten).
Historie: D: [D3.1P]
M: [D3.1Z] (Klarstellung)
Siehe auch: O-EDA, ROT, VER, *Weiterleiten*
Kennung: OAB +-----------------+
| Pflicht |
Kurzbeschreibung: Originalabsender |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: OAB: <ZConnect-Adresse>
Funktion: Beim manuellen, aktiven Weiterleiten wird in die
OAB-Headerinformation der Weiterleitung der ABS der
weitergeleiteten Nachricht übernommen, sofern noch
keine OAB-Information im Header enthalten ist.
Historie: D: [D3.0]
Siehe auch: ABS, WAB, *Weiterleiten*
Kennung: OEM +-----------------+
| Pflicht |
Kurzbeschreibung: Originalempfängerin |>>Optional |
+-----------------+
| Nur einmal |
|>>Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: OEM: <Brettname> | <ZConnect-Adresse>
Funktion: Beim automatischen und beim manuellen Weiterleiten
müssen die EmpfängerInnen der weiterzuleitenden
Nachricht als OEMs aufgeführt werden. Beim manuellen
Weiterleiten wird dies nicht durchgeführt, wenn
bereits OEM-Informationen im Header enthalten sind.
Historie: D: [D3.0]
Siehe auch: EMP, *Weiterleiten*
Kennung: ORG +-----------------+
| Pflicht |
Kurzbeschreibung: Organisation |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: ORG: <Organisation>
Funktion: Wenn die Absenderin sich einer Organisation
zugehörig fühlt, dann kann sie in der
ORG-Information eine einzeilige Beschreibung angeben
(z.B. "PoeM e.V., Vorstand").
Hinweis: BenutzerInnen von ORG sollten z.B. durch einen
Hilfstext darauf aufmerksam gemacht werden, daß
durch die Angabe einer Organisation geschriebene
Nachrichten als Meinung der Organisation verstanden,
also ggf. mißverstanden werden können.
Historie: D: [D3.0]
Siehe auch: POST, TELEFON, Weiterleiten
Kennung: PGP +-----------------+
| Pflicht |
Kurzbeschreibung: PGP-Aufforderung |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
|>>Nur PM |
+-----------------+
Syntax: PGP: PLEASE | REQUEST
Funktion: PGP: PLEASE fordert die Empfängerin auf, den
ebenfalls im Header enthaltenen PGP Public Key (!)
zu unterschreiben. Der Empfängerin sollte dieses
Ansinnen nicht ohne den Hinweis vorgetragen werden,
daß eine Unterschrift unter einen PGP Public Key
eine Aktion von weittragender Bedeutung ist. Es ist
unbedingt darauf hinzuweisen, daß ein persönlicher
Kontakt erforderlich ist, um z.B. anhand eines
Fingerprints sicher sagen zu können, daß der zu
unterschreibende Key zu der Absenderin gehört.
Für die Antwort auf PGP: PLEASE sollte die
Headerkennung PGP-KEY-OWN verwendet werden.
PGP: REQUEST bittet die Empfängerin um die Zusendung
von deren Public Key.
Sowohl PGP: PLEASE als auch PGP: REQUEST dürfen
nicht bei öffentlichen Nachrichten eingesetzt
werden.
Hinweis: Das Verbot des Einsatzes dieser Information bei
öffentlichen Nachrichten ist bei der Auftrennung von
gemischtadressierten Nachrichten zu beachten! Bei
strenger Auslegung (gemischtadressierte Nachrichten
sind öffentliche Nachrichten) heißt das, daß diese
Informationen bei gemischtadressierten Nachrichten
nicht eingesetzt werden dürfen.
PGP: REQUEST ist auch bei Non-PGP-Nachrichten
sinnvoll und kann und darf daher auch bei ihnen
auftreten. Für PGP: PLEASE gilt ähnliches,
allerdings ist zu beachten, daß hier der Einsatz nur
Sinn macht, wenn außerdem eine
PGP-PUBLIC-KEY-Headerinformation im Header enthalten
ist (natürlich wäre es auch denkbar, daß PGP: PLEASE
die formalisierte Aufforderung an eine Empfängerin
ist, die den Public Key der Absenderin bereits hat -
die Dokumentation sieht dies nicht vor).
Auch wenn eine große Verbreitung des eigenen Public
Keys zu dessen Fälschungs"sicherheit" beiträgt,
sollte ihn das Pointprogramm - ähnlich wie bei
Empfangsbestätigungen - nicht ohne Rückfrage bei der
Benutzerin versenden.
Es ist darauf hinzuweisen, daß die
ZConnect-PGP-Lösung sich sehr rasch verbreitet.
Aufgrund der ohne Unterstützung durch die
BenutzerInnenschnittstelle nicht verarbeitbaren
Schlüsselcodierungen im Header wird dringend
empfohlen, ZConnect-PGP zu implementieren.
Historie: D: [D3.1P]/[D3.1M]
Siehe auch: PGP-KEY-OWN, *Gemischtadressierung*,
*Verschlüsselung*, Weiterleiten
Kennung: PGP-ID +-----------------+
| Pflicht |
Kurzbeschreibung: PGP Userinnen-ID |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: PGP-ID: <Realname> <<Netzadresse>>
Ein Hinweis auf einem Sonderfall in der Notation:
Einfache, spitze Klammern um die Netzadresse sind
ausnahmsweise tatsächlich anzugeben. Eine gültige
PGP-ID-Information sähe also so aus:
Ce Brunke <Sepro@bingo.comlink.de>
Funktion: Normalerweise ist die in der PGP Userinnen-ID
enthaltene Nutzinformation bereits durch die
ZConnect-Pflichtheader im Header vertreten. Die
Dokumentation sieht PGP-ID für den Fall vor, daß "dies
einmal nicht möglich ist".
Hinweis: Der Fall, daß "dies einmal nicht möglich ist", ist z.B.
dann gegeben, wenn die Absenderin normalerweise auf die
Angabe des Realnames zu verzichten wünscht, diesen in
der ID aber angeben möchte.
Zu beachten ist, daß die Übergabe der PGP-ID an PGP
in Hochkommata erfolgen sollten, da PGP Leerzeichen
als Trenner zwischen mehreren EmpfängerInnen
betrachtet.
Historie: D: [D3.1P]/[D3.1M]
Siehe auch: *Verschlüsselung*, Weiterleiten
Kennung: PGP-KEY-AVAIL +-----------------+
| Pflicht |
Kurzbeschreibung: PGP Public Key erhältlich |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: PGP-KEY-AVAIL: [<Systemtelefonnummer in internationalem
Format> [Systemname des Keyservers]
[Adressenanteil der PGP-Userinnen-ID]]
Funktion: Die Absenderin gibt mit dieser Kennung an, daß sie
den Bezug ihres Public Keys anbietet. Wird
PGP-KEY-AVAIL ohne Parameter angegeben, kann bei der
Absenderin nur mittels PGP: REQUEST dieser Public
Key erbeten werden.
PGP-KEY-AVAIL ist auch ein Bindeglied zwischen
Onlinephase und Datenformat. Hierzu dient der
Parameter der Kennung, welcher in angibt, bei
welchem System online (per ZConnect-Onlinephase mit
deren Headerinformation PGP-KEYREQ) der Public Key
der Absenderin requestet werden kann.
Ein Beispiel für die Parameter von PGP-KEY-AVAIL für
den Keyrequest:
+49-40-6912028 bingo.comlink.de Sepro@bingo.comlink.de
+------------+ +--------------+ +--------------------+
| | |
Systemtelefon- | |
nummer in | |
internationalem | |
Forma | |
Systemname des |
Key-Servers |
Adressenanteil der
PGP-Userinnen-ID
Die Systemtelefonnummer bezeichnet die Rufnummer der
Box, bei der per ZConnect-Onlinephase der Public Key
der Absenderin requestet werden kann. Die Syntax
folgt dabei weitestgehend dem Format der
TELEFON-Headerinformation: Lediglich die
vorangestellten Buchstaben (für Voice/Box/Fax)
entfallen.
Der Systemname ist optional. Ist er nicht angegeben,
handelt es sich bei dem servenden System um jenes,
welches auch in der Adresse der Absenderin enthalten
ist.
Auch die Adresse, die Teil der PGP User-ID ist,
welche zum zu requestenden Public Key gehört. ist
optional. Fehlt sie, ist diejenige der Absenderin
der Nachricht zu verwenden.
Hinweis: Die BINGO ist kein ZConnect-System (sondern
verwendet Janus[Plus]), es ist also wenig
erfolgversprechend, das Beispiel auszuprobieren ;-)
Es wird empfohlen, die Parameterkomponenten durch je
genau ein Leerzeichen voneinander zu trennen, von
anderer Software aber eine beliebige Anzahl
Whitespaces (mindestens eines) zu erwarten.
# [D3.1Z] definiert PGP-KEY-AVAIL abweichend als auch # mehrfach vorkommend. Dies ist durchaus sinnvoll, # aber vom Gremium nicht so beschlossen. Auch sieht # [D3.1Z] einen vierten optionalen Teil der Parameter # der PGP-KEY-AVAIL-Information vor, welcher als # "ISDN" spezifiziert wird und aussagen soll, daß es # sich bei der vorausgegangenen Telefonnummer um eine # ISDN-Nummer handelt. Im Zusammenspiel mit der # Möglichkeit, mehrere PGP-KEY-AVAIL-Informationen # angeben zu können, ebenfalls sinnvoll - aber nicht # beschlossen.
Historie: D: [D3.1P]/[D3.1M]
A: [D3.1Z]
Siehe auch: *Verschlüsselung*, Weiterleiten
Kennung: PGP-KEY-COMPROMISE +-----------------+
| Pflicht |
Kurzbeschreibung: Widerrufener PGP Public Key |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
|**Nur PM |
+-----------------+
Syntax: PGP-KEY-COMPROMISE: <ZConnect-Schlüsseldarstellung>
Funktion: PGP-KEY-COMPROMISE darf nur zusammen mit
PGP-PUBLIC-KEY auftauchen. Auf diese Weise kann der
zu widerufende Public Key durch den neuen ersetzt
werden.
Aus dem Kontext ergibt sich, daß PGP-KEY-COMPROMISE
nur bei privaten Nachrichten eingesetzt werden darf
- mit der bei PGP-PUBLIC-KEY beschriebenen
Einschränkung.
Hinweis: Es gibt aus dem PGP Konzept heraus keinen Grund
dafür, daß ein zurückgezogener Public Key durch
einen neuen ersetzt werden müßte. Nur ZConnect
schreibt dies vor.
Historie: D: [D3.1P]/[D3.1M]
Siehe auch: *Gemischtadressierung*, *Verschlüsselung*,
Weiterleiten
Kennung: PGP-KEY-OWN +-----------------+
| Pflicht |
Kurzbeschreibung: Unterschriebener PGP Public Key |>>Optional |
der Empfängerin; +-----------------+
Antwort auf PGP: Please |>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
|>>Nur PM |
+-----------------+
Syntax: PGP-KEY-OWN: <ZConnect-Schlüsseldarstellung>
Funktion: PGP-KEY-OWN ist i.d.R. die Antwort auf PGP: PLEASE.
PGP-KEY-OWN enthält den Schlüssel der Empfängerin
mit einer neuen Unterschrift, wahrscheinlich, aber
nicht unbedingt jener der Absenderin.
Historie: D: [D3.1P]/[D3.1M]
Siehe auch: *Gemischtadressierung*, *Verschlüsselung*,
Weiterleiten
Kennung: PGP-PUBLIC-KEY +-----------------+
| Pflicht |
Kurzbeschreibung: PGP Public Key der Absenderin |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
|**Nur PM |
+-----------------+
Syntax: PGP-PUBLIC-KEY: <ZConnect-Schlüsseldarstellung>
Funktion: Die Absenderin transportiert in dieser
Headerinformation ihren PGP Public Key. Die
Empfängerin kann ihn für die Verschlüsselung
zukünftiger Kommunikation benutzen.
Hinweis: Der Public Key sollte nicht mit jeder öffentlichen
Nachricht versendet werden. Für die Verbreitung des
Keys mag das zwar nützlich sein, die Kopflastigkeit
des ZConnect-Datenformats steigert es jedoch dabei
sehr.
Umgekehrt kann diese Headerinformation für private
Nachrichten technisch nicht verboten sein, da es
durchaus sinnvoll ist, in bestimmten, dafür
vorgesehenen Brettern den Public Key in einer
öffentlichen Nachricht zu versenden.
Historie: D: [D3.1P]/[D3.1M]
Siehe auch: PUBLIC-KEY, *Gemischtadressierung*,
*Verschlüsselung*, Weiterleiten
Kennung: PGP-SIG +-----------------+
| Pflicht |
Kurzbeschreibung: PGP-Signatur |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: PGP-SIG: <PGP-Signatur in ZConnect-Schlüsseldarstellung>
Funktion: Ist eine Nachricht mit PGP unterschrieben
(SIGNED: PGP), wird die Signatur(datei) der
Absenderin als PGP-SIG in BASE64-Codierung
transportiert. So können auch Binärnachrichten
unterschrieben werden.
Hinweis: Um mit PGP eine vom Dokument abgelöste Unterschrift
zu erzeugen, werden die Parameter "-sb" verwendet.
Bei öffentlichen Nachrichten ist möglichst die
Abtrennung der Unterschrift vorzunehmen, um auch
LeserInnen ohne PGP das Lesen zu ermöglichen. Ist
hingegen die Nachricht ohnehin PGP-verschlüsselt,
kann die Unterschrift auch als Teil der
Verschlüsselung transportiert werden.
Es ist nicht sinnvoll, in einer unterschriebenen
Nachricht zugleich den Public Key der Absenderin zu
versenden, da bei einer Fälschung der Unterschrift
unterwegs auch der Public Key gefälscht werden kann.
Historie: D: [D3.1P]/[D3.1M]
Siehe auch: *SIGNED*, *Verschlüsselung*, Weiterleiten
Kennung: POST +-----------------+
| Pflicht |
Kurzbeschreibung: Postanschrift |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: POST: <Postanschrift>
Funktion: Es gibt nicht nur das Netz... Die Absenderin kann
ihre postalische Adresse in der
POST-Headerinformation unterbringen. Die Zeilen
einer Postanschrift werden dabei nebeneinander
geschrieben, durch Semikola getrennt.
Beispiel:
POST: Wachtelstr. 6; 22305 Hamburg
Historie: D: [D3.0]
Siehe auch: ORG, TELEFON, Weiterleiten
Kennung: PRIO +-----------------+
| Pflicht |
Kurzbeschreibung: Priorität |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: PRIO: <Prioritätskennzahl>
Funktion: Definiert sind bisher drei Dringlichkeitsstufen, die
als Kennzahl hinter der PRIO-Kennung auftauchen
können:
0 - Normales Routing
10 - Direktversand
20 - Eilversand (sofortige Auslieferung)
Ist der Header nicht vorhanden, wird die Priorität
Null angenommen.
Hinweis: Direktversand bedeutet, daß bei bestehende
Direktverbindung zwischen zwei Systemen eine mit
PRIO: 10 versehene Nachricht direkt ausgetauscht
wird, auch wenn sie nach einer Routingtabelle einen
anderen Weg nehmen würde. Beispiel: Die Systeme A
und B haben eine Verbindung zum gemeinsamen
Domainserver S und auch eine Direktverbindung
untereinander. Normalerweise würden private
Nachrichten von A nach B nicht über die
Direktverbindung sondern über den (zumeist
schnelleren, weil aus frequenteren Verbindungen
bestehenden) Umweg über S geschickt. PRIO: 10 würde
bewirken, daß die Nachricht während der nächsten
Direktverbindung direkt von A an B zugestellt wird.
Eilversand ist z.B. bei Einsatz der
ZConnect-Onlinephase, die den Kontakt zwischen sich
unbekannten Systemen definiert, möglich. Eine mit
PRIO: 20 versehene Nachricht kann vom routenden
System durch einen direkten Anruf beim Zielsystem
zugestellt werden, sofern die Rufnummer ihm bekannt
ist.
Prioritäten sind grundsätzlich, wegen der
möglicherweise verursachten Kosten oder nicht
gegebener Direktverbindungen, als Wunsch zu
verstehen, nicht als Vorschrift. Bei anderer
Interpretation muß eine ERR-Nachricht bei nicht
beachteter PRIO-Information erzeugt werden.
PRIO ist insgesamt auch für öffentliche Nachrichten
sinnvoll verwendbar.
Historie: D: [D3.0]
M: [D3.1M]
Siehe auch: ERR, Weiterleiten
Kennung: PUBLIC-KEY +- - - - - - - - -+
| Pflicht |
Kurzbeschreibung: PGP Public Key |>>Optional |
+- - - - - - - - -+
|>>Nur einmal |
VERALTET Auch mehrfach
| Stabil |
+- - - - - - - - -+
|**Nur PM |
+- - - - - - - - -+
Syntax: PUBLIC-KEY: <PGP Public Key in Base64 Notation>
Funktion/Hinweis: Keine mehr. Durch das durchgängige # ZConnect-PGP-Konzept ist diese Headerkennung # eigentlich nicht mehr zu verwenden. Die # Dokumentation versäumt diesen Hinweis, aber auch # [D3.1Z] erwähnt diese Headerinformation nicht mehr.
Historie: D: [D3.1P]
A: [D3.1Z]
Siehe auch: *PGP-PUBLIC-KEY*, Verschlüsselung
Kennung: ROT +-----------------+
|>>Pflicht |
Kurzbeschreibung: Routepfad | Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: ROT: [<Routeweg>]
Funktion: Im Routeweg tragen sich alle das
ZConnect-Datenformat unterstützende Systeme, über
die die Nachricht geroutet wurde, im Moment des
Empfangs ein. Der Eintrag in den Routestring erfolgt
inklusive Domainangabe (falls keine bekannt ist,
dann "zer.sub.org"), wobei das gerade empfangende
System seinen Namen an den Anfang des Routewegs
schreibt und ein Ausrufungszeichen als Trenner
verwendet. Kam eine Mail also mit der
Headerinformation
ROT: bingo.comlink.de
beim System CL-HH an, so fügt letzteres seinen Namen
ein, und
ROT: cl-hh.comlink.de!bingo.comlink.de
entsteht.
Points müssen bei ausgehenden Nachrichten einen
leeren Routeweg einsetzen (sie empfangen ja nicht).
Mailboxsoftware sollte die Einhaltung dieser Regel
prüfen und muß sich als erstes System in den
Routeweg eintragen.
Steht ein System bereits im Routestring, darf die
Nachricht (öffentlich oder privat) nicht nochmals an
dieses weitergereicht werden. Handelt es sich bei
der aufgrund eines solchen Rekursionschecks
aufgefallenen Nachricht um eine private Nachricht,
sollte der Header den SystembetreiberInnen vorgelegt
werden (Datenschutz: nicht die komplette
Nachricht!), damit diese ein evtl. vorliegendes
Pingpongrouting abstellen können.
Hinweis: Es kann bei Änderungen von Routwegen wegen neuer
Beziehungen von Systemen untereinander vorkommen,
daß zufällig und unschädlich ein System mehrfach in
den Routestring gerät. Auch gibt es schonmal durch
Konfigurationsfehler, z.B. von
Mailinglistenmechanismen, doppelte Einträge in der
ROT-Information. Implementationen sollten daher
selber diesen Fehler vermeiden, ihn von anderen
Implementationen jedoch erwarten. Sinnvoll ist hier
z.B. eine Rekursionsdetektion erst bei dreifachem
Eintrag.
Die Pseudodomain "zer.sub.org" ist ein
Hilfskonstrukt aus der Anfangszeit des
Domainroutings im /Z-Netz. "zer.sub.org" war eine
auf dem A-LINK-H-System verwaltete Domain, die alten
Z3.8-Systemen die Teilnahme am Domainrouting
ermöglichen sollte. Voraussetzung war eine geringe
monatliche Zahlung und der Verzicht auf
internationalen Datenverkehr. Da diese Bedingungen
von vielen Systemen mißachtet wurden, ist die
"zer.sub.org"-Regelung heute ohne jede
protokollstrategische Bedeutung.
Historie: D: [D3.0]
M: [B5]
Siehe auch: Points, Rekursionscheck
Kennung: SIGNED +-----------------+
| Pflicht |
Kurzbeschreibung: Nachricht wurde unterschrieben |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: SIGNED: [PGP]
Funktion: Wenn die Nachricht mit PGP unterschrieben wurde, ist
diese Headerinformation gesetzt (andere Parameter
als PGP gibt es derzeit nicht)
Wenn die Nachricht nicht zusätzlich
PGP-verschlüsselt ist (CRYPT: PGP nicht gesetzt),
ist die zugehörige Unterschrift in der
PGP-SIG-Information zu suchen, andernfalls kann sie
bei PGP Teil der verschlüsselten Nachricht sein.
Hinweis: Ein SIGNED: ohne Parameter ist nicht definiert aber
auch nicht verboten. Tauchte eine solche Information
auf, würde sie besagen, daß die Nachricht nicht
unterschrieben wurde und somit überflüssig sein.
# CrossPoint ab Version 3.1 verwendet # SIGNED: PGPCLEAR, wenn die Nachricht unterschrieben # ist, diese Unterschrift aber nicht mittels PGP-SIG # sondern als Klartext im Nachrichtenbody # transportiert wird. Dies ist eigentlich eine # unnötige Abweichung vom Standard, da SIGNED: PGP im # Zusammenhang mit einem fehlenden PGP-SIG nichts # anderes als SIGNED: PGPCLEAR aussagt.
Historie: D: [D3.1P]/[D3.1M]
Siehe auch: CRYPT: PGP, PGP-SIG, Verschlüsselung, Weiterleiten
Kennung: SPERRFRIST +-----------------+
| Pflicht |
Kurzbeschreibung: Frühester Zeitpunkt der Anzeige |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: SPERRFRIST: <Datumsangabe>
Funktion: Wie bei einer Pressemitteilung kann auch bei
Nachrichten eine Sperrfrist gesetzt werden, also ein
Datum, vor dem die Veröffentlichung nicht gestattet
ist. Für ZConnect-Programme heißt das, daß
AnwenderInnen die so gekennzeichnete Nachricht erst
zum angegebenen Zeitpunkt angezeigt bekommen dürfen.
Hinweis: Richtiger wäre es, eine mit Sperrfrist versehene
Nachricht überhaupt erst zum spezifizierten
Zeitpunkt an Endsysteme zuzustellen. Die Logik einer
Sperrfrist bei Pressemitteilung wäre erst dann
richtig und sinnvoll abgebildet, wenn SPERRFRIST für
private Nachrichten lediglich ein Hinweis für die
Empfängerin wäre und für öffentliche Nachrichten die
Zustellung an Points bzw. die Anzeige online erst ab
dem angegebenen Veröffentlichungsdatum erfolgen
würde.
ZConnect definiert all dies nicht. Wie beschrieben
verbietet es die Anzeige, nicht aber die Zustellung
vor einem bestimmten Zeitpunkt. Für den Pointbetrieb
ist dies unhaltbar, da der Anwenderin nicht
zugemutet werden kann, Daten auf dem eigenen
Massenspeicher zu halten, von deren Existenz sie
nicht einmal informiert ist (eine sich strikt an
ZConnect haltende Implementierung sollte sich mit
dieser Argumentation auseinandersetzen und evtl.
zumindest den Header der gesperrten Nachricht
zusammen mit dem Sperrvermerk anzeigen und die
Löschung zulassen).
Historie: D: [D3.0]
Siehe auch: Datumsangaben, Points, Weiterleiten
Kennung: STAT +-----------------+
| Pflicht |
Kurzbeschreibung: Status der Nachricht |>>Optional |
+-----------------+
|**Nur einmal |
|**Auch mehrfach |
| Stabil |
+-----------------+
|**Nur PM |
+-----------------+
Syntax: STAT: AUTO | CTL | DES | EB | NOCIPHER | NOKOP |
PGP | TRACE
Funktion: Die derzeit acht Stati haben unterschiedliche
Semantiken. Teilweise charakterisieren sie eine
Nachricht (z.B. CTL für Control-Nachricht),
teilweise modifizieren sie deren Behandlung in
bestimmten Fällen (z.B. NOKOP, welches das Verhalten
von ZConnect-Software bei Crossposting ändert),
teilweise haben sie Konsequenzen für eine etwaige
Antwort (z.B. NOCIPHER legt für eine Nachricht und
die Antwort darauf fest, daß diese nicht in
irgendeiner Form verschlüsselt sein sollen) und
teilweise beschreiben sie (redundant, vgl. CRYPT),
daß die Nachricht verschlüsselt ist (z.B. DES weist
auf das Verschlüsselungsverfahren "Data Encryption
Standard" hin).
STAT darf beliebig oft vorkommen, die
unterschiedlichen Parameter von STAT dürfen aber je
nur einmal pro Header vorkommen (z.B. nicht zweimal
die Information STAT: NOCIPHER). Sie sind unabhängig
von Groß-/Kleinschreibung auszuwerten.
Hinweis: Die möglichen Stati sind auf den folgenden Seiten
einzeln erläutert, da eine gemeinsame Darstellung
aufgrund der grundsätzlich unterschiedlichen Typen
von STAT-Headerinformationen nicht sinnvoll möglich
ist. Z.B. sind manche Stati nur bei PMs, andere auch
bei öffentlichen Nachrichten einsetzbar.
# Gemäß Dokumentation darf STAT beliebig oft # eingesetzt werden. Eine ZConnect-konforme Software # muß damit rechnen, daß DES und PGP gleichzeitig # gesetzt sind, ohne daß die Reihenfolge des Einsatzes # der Verschlüsselungsverfahren erkennbar ist. Aus # diesem Grunde sind STAT: DES und STAT: PGP # angesichts der Existenz der CRYPT-Information (die # nur einmal vorkommen darf) auf keinen Fall mehr zu # verwenden, auch wenn sie hier aufgezählt werden # müssen, weil sie nie offiziell zurückgezogen wurden.
Historie: D/M: siehe bei Einzelerläuterungen
Siehe auch: EB, ERSETZT, CONTROL, CRYPT, KOP, STAT: AUTO,
STAT: CTL, STAT: DES, STAT: EB, STAT: NOCIPHER,
STAT: NOKOP, STAT: PGP, STAT: TRACE,
Verschlüsselung, Weiterleiten
Kennung: STAT: AUTO +-----------------+
| Pflicht |
Kurzbeschreibung: Regelmäßige Nachricht |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: STAT: AUTO
Funktion: Die so gekennzeichnet Nachricht ist eine regelmäßig
aktualisierte und ins Netz geschickte Information.
Identifiziert wird sie am Parameter der FILE- oder
# der EMP-Kennung (keine Details in der Dokumentation
# enthalten). Die BET-Information darf nicht
ausgewertet werden.
Kommt eine Nachricht mit STAT: AUTO und einer
bestimmten FILE- oder EMP-Kennung an, so kann darauf
z.B. mit der Umleitung in ein lokales Brett oder ein
Verzeichnis reagiert werden. Die Dokumentation sieht
vor, daß hierbei ggf. eine ERSETZT-Kennung eingefügt
wird.
Historie: D: [D3.1P]
Siehe auch: STAT
Kennung: STAT: CTL +-----------------+
| Pflicht |
Kurzbeschreibung: Steuernachricht |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: STAT: CTL
Funktion: Die so gekennzeichnete Nachricht ist eine
Steuernachricht. Diese darf, auch wenn sie defekt
ist, niemals an die Absenderin zurückgeschickt
werden.
Hinweis: STAT: CTL kommt in TRACE-Antworten zum Einsatz. Da
solche auch mit STAT: TRACE versehen sind, ist
STAT: CTL hier redundant.
Darüberhinaus wird STAT: CTL derzeit nur für
Nachrichten mit CONTROL-Headerinformation
eingesetzt.
# Für die Zukunft sind weitere Anwendungen denkbar. # Z.B. ließe sich die Programmierung von ZConnect # orthogonalisieren, wenn alle Nachrichten, die # Steuercharakter haben und nicht zurückgeschickt # werden dürfen, eine STAT: CTL Headerinformation # erhalten würden (also z.B. auch eine Nachricht mit # ERR-Kennung). Dann wäre mit einer einzigen Prüfung # das Verhalten der Software steuerbar.
Historie: D: [D3.0]
Siehe auch: CONTROL, STAT, TRACE
Kennung: STAT: DES +- - - - - - - - -+
| Pflicht |
Kurzbeschreibung: Nachricht ist mit DES verschlüsselt |>>Optional |
+- - - - - - - - -+
|>>Nur einmal |
VERALTET Auch mehrfach
| Stabil |
+- - - - - - - - -+
|>>Nur PM |
+- - - - - - - - -+
Syntax: STAT: DES
Funktion/Hinweis: Zeigt an, daß die Nachricht mit dem DES (Data # Encryption Standard) verschlüsselt wurde. Diese # Headerinformation ist durch die aktuellere # CRYPT-Kennung ersetzt. [D3.1Z] unterstützt diese # Auffassung, indem sie STAT: DES nicht mehr erwähnt.
Historie: D: [D3.0]
A: [D3.1Z]
Siehe auch: *CRYPT*, STAT, Verschlüsselung
Kennung: STAT: EB +-----------------+
| Pflicht |
Kurzbeschreibung: Nachricht ist eine Empfangsbestätigung |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
|>>Nur PM |
+-----------------+
Syntax: STAT: EB
Funktion: Diesen Status führt eine automatisch generierte
Empfangsbestätigung, die auf dem Weg zur
Bestätigungsempfängerin ist.
Historie: D: [D3.0]
Siehe auch: *EB*, STAT
Kennung: STAT: NOCIPHER +-----------------+
| Pflicht |
Kurzbeschreibung: Antworten auf unverschlüsselte Nachricht |>>Optional |
dürfen nicht verschlüsselt werden +-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
|>>Nur PM |
+-----------------+
Syntax: STAT: NOCIPHER
Funktion: STAT: NOCIPHER hat eine doppelte Bedeutung: Zum
einen sagt diese Headerinformation aus, daß die
Nachricht, deren Header sie enthält, nicht
verschlüsselt ist. Zum anderen, und das ist die im
Vordergrund stehende Bedeutung, wird für Antworten
jede Verschlüsselung untersagt.
Hinweis: Es ist zwar ein guter Gedanke,
KommunikationspartnerInnen formalisiert den Wunsch
mitteilen zu können, daß die Antwort unverschlüsselt
sein sollte. Dies kann der antwortenden Person aber
unmöglich vorgeschrieben werden. ProgrammiererInnen
von BenutzerInnenschnittstellen sollten sich
hierüber Gedanken machen.
Historie: D: [D3.1P]/[D3.1M]
Siehe auch: STAT, Points, Verschlüsselung
Kennung: STAT: NOKOP +-----------------+
| Pflicht |
Kurzbeschreibung: Private Empfängerinnen der Nachricht |>>Optional |
dürfen nirgendwo in KOPs +-----------------+
gewandelt werden |>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: STAT: NOKOP
Funktion: STAT: NOKOP wirkt auf die Umwandlung von EMPs zu
KOPs, z.B. bei der Auftrennung privater
Crosspostings. Ist STAT: NOKOP gesetzt, dürfen
private EMPs nicht in KOPs gewandelt werden. Auf
öffentliche KOPs hat dieses Flag keinen Einfluß.
Hinweis: Die Auswirkung von STAT: NOKOP ist bei KOP
detailliert erläutert.
Historie: D: [D3.1M]
Siehe auch: KOP, STAT
Kennung: STAT: PGP +- - - - - - - - -+
| Pflicht |
Kurzbeschreibung: Nachricht ist mit PGP verschlüsselt |>>Optional |
+- - - - - - - - -+
|>>Nur einmal |
VERALTET Auch mehrfach
| Stabil |
+- - - - - - - - -+
|>>Nur PM |
+- - - - - - - - -+
Syntax: STAT: PGP
Funktion/Hinweis: Dieser Status ist durch das aktuelle PGP-Konzept # nicht mehr aktuell. CRYPT: PGP tritt an seine # Stelle. [D3.1Z] bestätigt diese Auffassung.
Historie: D: [D3.0]
A: [D3.1Z]
Siehe auch: *CRYPT*, STAT, Verschlüsselung
Kennung: STAT: TRACE +-----------------+
| Pflicht |
Kurzbeschreibung: Nachricht ist eine Antwort auf eine |>>Optional |
TRACE-Kennung +-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
|>>Nur PM |
+-----------------+
Syntax: STAT: TRACE
Funktion: STAT: TRACE kennzeichnet eine TRACE-Antwortmail.
Systeme auf dem Routeweg einer Nachricht erzeugen
als Antwort auf die TRACE-Anforderung Nachrichten
eines wie folgt definierten Formats:
STAT: TRACE gesetzt
STAT: CTL gesetzt
BEZ: verweist auf Message-ID der
auslösenden Nachricht mit
TRACE-Headerkennung
BET: enthält den Text
"Trace-Info " und danach die
Message-ID der auslösenden
Nachricht
Nachrichtenkörper enthält eine parsebare Liste
der Systeme und der
Empfängerinnen, an die die
Nachricht geroutet wurde
Das Format der Liste sieht pro System, an das
geroutet wird, einen Abschnitt vor. Innerhalb dieses
Abschnitts ist dann für jede Empfängerin eine Zeile
einzutragen. Systemname wie Empfängerinnennamen
müssen durch spitze Klammern ('<', '>') geklammert
sein. Abschnitte beginnen mit einer Zeile, an deren
erster Stelle ein Non-Whitespace steht. Zeilen mit
Empfängerinneneinträgen hingegen beginnen mit einem
Whitespace (Leerzeichen oder Tabulator).
Beispiel für eine korrekte Nachricht mit STAT:
Headerinformation:
EMP: SYSOPTEAM@bingo.comlink.de
ABS: Zerberus@cl-hh.comlink.de
BEZ: 12345678@sysopteam.bingo.comlink.de
BET: Trace-Info 12345678@sysopteam.bingo.comlink.de
MID: 42@cl-hh.comlink.de
STAT: TRACE
STAT: CTL
EDA: 19950401000000W+0
An System <nadeshda.gun.de> gingen die folgenden EMPs:
<S.Musterfrau@nadeshda.gun.de>
An System <schwarzwald.gun.de> gingen die folgenden EMPs:
<Weissbart@schwarzer.wald.de>
<K.Mustermann@schwarzwald.gun.de>
<Frau_Holle@weisswald.pistole.us>
Historie: D: [D3.1P]
Siehe auch: STAT, STAT: CTL, TRACE
Kennung: STICHWORT +-----------------+
| Pflicht |
Kurzbeschreibung: Stichwort zum Nachrichteninhalt |>>Optional |
+-----------------+
| Nur einmal |
|>>Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: STICHWORT: <Genau ein Stichwort>
Funktion: Die Absenderin kann pro STICHWORT-Kennung ein
Stichwort zum Nachrichteninhalt angeben. Die
beliebig vielen Stichworte können dann z.B. bei
Suchfunktionen ausgewertet werden.
Hinweis: [D3.1Z] definiert, daß Groß-/Kleinschreibung nicht # ausgewertet werden darf, und nur die Zeichen von A-Z # zulässig sind.
Definiert mensch das Leerzeichen als zulässiges
Zeichen im Stichwort selbst (und abgesehen von
[D3.1Z] widerspricht dem derzeit nichts), wäre eine
Stichwortzeile mit mehreren Begriffen legitim.
Mittlerweile gibt es aber keine bekannte Software
mehr, die sich diese Interpretation leistet.
Aufgrund des Einsatzes älterer Software (z.B.
CrossPoint 3.0x) ist jedoch mit solchen Abweichungen
vom Standard zu rechnen.
Historie: D: [D3.1P]
A: [D3.1Z]
Siehe auch: ZUSAMMENFASSUNG
Kennung: TELEFON +-----------------+
| Pflicht |
Kurzbeschreibung: Telefonnummer(n) der Absenderin |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: TELEFON: <Telefonnummer>[;<Telefonnummer>]*
Funktion: Die Absenderin kann in dieser Headerinformation ihre
Telefonnummer(n) in internationaler Schreibweise.
Diese Notation folgt folgender Syntax:
[V|F|B]++<Ländervorwahl ohne führende Nullen>-<Städtevorwahl>-<Durchwahl>[Q]
'V' steht dabei für "Voice", 'F' für "Fax" und 'B'
für "Box". Mindestens eine der Kennungen ist
anzugeben, es können aber auch alle gleichzeitig (in
beliebiger Reihenfolge) angegeben werden. Ist an der
Leitung ein Anrufbeantworter angeschlossen, kann
dies durch das optional nachgestellte 'Q'
symbolisiert werden.
Sollen mehrere Nummern angegeben werden, so werden
diese jeweils durch ein Semikolon getrennt. Statt
des Semikolons ist auch ein Leerzeichen gestattet.
Beispiel:
TELEFON: VF+49-40-6910419Q B+49-40-6912028
Hinweis: Es sollten als Trennzeichen zwischen den Rufnummern # beliebige Whitespaces erwartet werden. Für neue # Dienste, wie z.B. SCall der Deutschen Telekom, ist # zwar nicht per Wahl eine Kennung vereinbart worde, # für solche und ähnliche Dienste wurde aber das "P" # für "Pager" vorgeschlagen und mangels Protesten für # eingeführt erklärt ([B6]).
Nur sehr wenige Programme testen die
ZConnect-Konformität der Parameter von TELEFON. Dies
sollte für ProgrammiererInnen Anlaß sein, es
korrekter zu handhaben, umgekehrt aber nicht von
korrekten TELEFON-Headerinformationen auszugehen.
Historie: D: [D3.0]
Siehe auch: ORGANISATION, POST, Weiterleiten
Kennung: TRACE +-----------------+
| Pflicht |
Kurzbeschreibung: Routinganalyse |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: TRACE: <ZConnect-Adresse>
Funktion: Durch die Angabe der TRACE-Headerinformation kann
die Absenderin jedes ZConnect-System auf dem
Routeweg auffordern, eine Information über dessen
Verfahren mit der Nachricht an die angegebene
Adresse zu senden.
Das Format der Antwort der Systeme auf dem Routeweg
ist vorgeschrieben und bei STAT: TRACE beschrieben.
Hinweis: Es ist nicht vorgesehen, daß TRACE ohne Argument
angegeben wird. Mensch könnte sich aber gut
vorstellen, daß in einem solchen Fall einfach die
Adresse der Absenderin genommen werden kann,
aktuelle Implementationen handhaben dies aber
definitiv nicht so{12}.
Die Dokumentation weist darauf hin, daß der Header
sparsam eingesetzt werden und auch nicht von jeder
Benutzerschnittstelle aus erzeugt werden können
soll.
Historie: D: [D3.1P]
M: [D3.1Z] (Klarstellung)
Siehe auch: *STAT: TRACE*, Adressen, Weiterleiten
Kennung: TYP +-----------------+
| Pflicht |
Kurzbeschreibung: Typ des Nachrichtenkörpers |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
|**Nur PM |
+-----------------+
Syntax: TYP: <Typkennung>
Funktion: Die TYP-Information gibt Auskunft über die
Beschaffenheit des Nachrichtenkörpers. Definierte
Bedeutung haben die Kennungen "BIN" (für
Binärnachricht), "TRANSPARENT" (für
Nachrichtenkörper, in denen keine Umlaute gewandelt
werden dürfen), "MIME" (für Nachrichten, die nach
dem MIME-Standard aufgebaut sind - bitte nicht
benutzen, Begründung siehe bei Headerinformation
MIME) und "RFC1563" (siehe vorige Klammerbemerkung).
Darüberhinaus sind aber beliebige weitere Kennungen
erlaubt (z.B. "TIFF", "GIF", "WAV", "ZIP").
Ist die angegebene Kennung dem ausgebenden Programm
unbekannt, wird die Nachricht wie eine normale
Binärnachricht behandelt. Ist keine TYP-Information
angegeben, handelt es sich um eine Textnachricht.
Hinweis: Aktuell wird eine Einführung der MIME-Kodierung
diskutiert. An dieser Stelle wird sich also für
ZConnect > 3.1 eine größere Änderung ergeben. Es ist
in diesem Kontext u.U. damit zu rechnen, daß manche
TYP-Informationen nur in PMs erlaubt sind.
# Die TYP-Information sagt gleichzeitig etwa über den # Nachrichten- und den Nachrichtenkörpertyp aus. Genau # diese Verquickung ist dafür verantwortlich, daß für # textuelle Nachrichtentypen, deren Körper aber z.B. # Steuerinformationen für "enriched Text" (vgl. # [RFC1563]) enthalten, als Binärnachrichten # gehandhabt werden müssen. Hier wäre eine # syntaktische Trennung, die die semantische # nachvollzieht, sinnvoll.
Historie: D: [D3.0]
Siehe auch: CHARSET, *MIME*, Kapitel "MIME", Zeichensätze
Kennung: VER +-----------------+
| Pflicht |
Kurzbeschreibung: Vertreterinlokalisierung |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
|>>Nur PM |
+-----------------+
Syntax: VER: <ZConnect-Adresse>
Funktion: Insbesondere private Nachrichten werden häufig per
Vertreterin an den Point weitergeleitet. Dies kann
unter Umständen auf einem ganz anderen System
geschehen als jenem, an dem der Point angeschlossen
ist. Verbreitet ist z.B. der "Nachsendeauftrag",
wenn ein Point das System wechselt.
Die VER-Information nimmt dann die Adresse auf, an
die die Zustellung ursprünglich erfolgte.
Hinweis: [D3.1Z] definiert VER abweichend als auch mehrfach # möglich. Zur Begründung wird richtigerweise # angemerkt, daß eine Weiterleitung durch # Vertreterinnen ebenfalls mehrfach erfolgen kann.
Historie: D: [D3.1P]
A: [D3.1Z]
Siehe auch: Adressen, Weiterleiten
Kennung: VIA +-----------------+
| Pflicht |
Kurzbeschreibung: Bestimmung von Routeweg und -zeit |**Optional |
+-----------------+
| Nur einmal |
|>>Auch mehrfach |
|>>Stabil |
+-----------------+
|>>Nur PM |
+-----------------+
Syntax: VIA: <Routinginformation>
Funktion: VIA ermöglicht im Gegensatz zu ROT, die Stationen
auf dem Routeweg einer Nachricht mit einem
Zeitstempel zu versehen, was dem Aufspüren von
Datensenken oder Verzögerungsgründen dienen soll..
Die case-insensitive Routinginformation besteht aus
der Systemzeit im ZConnect-Format (wie bei EDA),
einem anschließenden '@' und der Systemadresse. Z.B.
also
VIA: 19950401000000W+0@bingo.comlink.de
Die VIA-Information muß auf jedem ZConnect-System
für private Nachrichten erzeugt werden. Aus Gründen
der Abwärtskompatiblität wurde VIA jedoch nicht als
Pflichtinformation eingeführt. Es ist in ZConnect
nicht vorgesehen, daß neue Pflichtinformationen
eingeführt werden.
Die erste VIA-Information wird vom ersten ZConnect
3.1 kompatiblen System/Point auf dem Routeweg
eingefügt. Bei dieser ersten VIA-Information im
Header ist die Systemzeit fest auf 0:00 Uhr des
jeweiligen Tages zu setzen (Datenschutz).
Hinweis: Die obenstehende Funktionsweise ist eine # Interpretation, die durch eine gänzlich unklare # Beschreibung in der Dokumenation notwendig ist. Aus # dem Originaltext wird nicht klar, welche Funktion # und welche Funktionsweise VIA hat. Die # VIA-Information wurde auf dem /Z-NETZ-Treffen 1994 # in Hamburg beschlossen, Nachfragen bei den daran # Beteiligten hinsichtlich der Intention von VIA # ergaben eindeutig oben dargestellte Sichtweise [B7].
Historie: D: [B8]
M: [B7] (Klarstellung)
Siehe auch: ROT, Datenschutz, Weiterleiten
Kennung: WAB +-----------------+
| Pflicht |
Kurzbeschreibung: Adresse der Weiterleitenden |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: WAB: <ZConnect-Adresse>
Funktion: Beim manuellen, passiven Weiterleiten wird der ABS
nicht verändert und die Weiterleitende in die
WAB-Headerinformation eingetragen. Beim aktiven
Weiterleiten wird eine vorhandene WAB-Information
hingegen gelöscht.
Der WAB-Parameter kann auch mit einem Realnamen
versehen sein.
Hinweis: Bei der Wandlung von ZConnect- nach Z3.8-Datenformat
wird laut älterer Dokumentation (die Z3.8-Regelungen
sind mit [D3.1M] aus ZConnect ausgegliedert worden)
die Weiterleitabsenderin der ZConnect-Nachricht als
Absenderin der Z3.8-Nachricht eingesetzt. Da noch
immer an wenigen Stellen im Netz tatsächlich
Gatewaysoftware die strikt verbotene Wandlung
ZConnect->Z3.8->ZConnect vornimmt, kann dies sehr
verwirrend wirken und sollte von
GatewayprogrammiererInnen überdacht werden.
Die bei ZConnect getroffene Unterscheidung zwischen
Point und System hat u.a. die Auswirkung, daß die
meiste Systemsoftware die Absenderinnenadresse der
beim System angeschlossenen Points prüft und ggf.
ersetzt. Wenn also der Point A@System als B@System
schreibt, ersetzt die Systemsoftware ungefragt
B@System durch A@System. Dies soll Mißbrauch,
insbesondere das Schreiben unter falscher Adresse
verhindern.
Das passive Weiterleiten definiert, daß hierbei die
ABS-Information und beinahe alle anderen
Headerinformationen ebenfalls erhalten bleiben,
während eine WAB-Information hinzugefügt wird. Wenn
A@System also als B@System schreibt, dann ist zu
prüfen, ob nicht WAB: A@System angegeben und die
fremde ABS-Angabe somit legitim ist. Einige
Systemprogramme machen dies zum aktuellen Zeitpunkt
leider falsch, teilweise wird sogar bei der
Ersetzung der Realname der Absenderin mit der
Adresse der Weiterleiterin gemischt, weil angesichts
geduldeter unterschiedlicher Realnamen für dieselbe
Mailadresse dieser nicht mitersetzt wird.
Historie: D: [D3.0]/[D3.1P]
M: [D3.1M]
Siehe auch: ABS, OAB, Adressen, Weiterleiten
Kennung: ZUSAMMENFASSUNG +-----------------+
| Pflicht |
Kurzbeschreibung: Einzeilige Nachrichtenkurzfassung |>>Optional |
+-----------------+
|>>Nur einmal |
| Auch mehrfach |
| Stabil |
+-----------------+
| Nur PM |
+-----------------+
Syntax: ZUSAMMENFASSUNG: <Einzeiliger Text>
Funktion: Die Absenderin kann ihre Nachricht in einer Zeile
zusammenfassen. Pointprogramme können dies z.B. in
einer Übersichtsdarstellung oder für Suchoperationen
nutzen.
Hinweis: [D3.1Z] verweist auf die Gefahr, daß durch eine
umfangreiche Zusammenfassung die Grenzen für
Nachrichtenlängen oder deren Abrechnung umgangen
werden könnten. Vorgeschlagen wird daher eine
Größenbegrenzung auf 10% der Gesamtnachrichtenlänge,
oberhalb welcher die bearbeitende Software das
Routen ablehnen kann. Jede beliebige frei definierte
Headerinformation birgt jedoch die Gefahr des
Mißbrauchs des Headers zum Transport von
Inhaltsdaten - eine Implementation, die solchen
Mißbrauch ausschließen soll, muß das Problem also an
grundsätzlicherer Stelle lösen, z.B. durch fest
vorgegebene Maximalgrößen oder -verhältnisse von
Header und Nachrichtenkörper.
Historie: D: [D3.1P]
Siehe auch: STICHWORT, Frei definierbare Headerzeilen
3.3.2.2. Frei definierbare Headerzeilen
Eine offizielle ZConnect-Headerkennung wird niemals mit "X-" beginnen. Dies ist der für lokale Erweiterungen reservierte Kennungspräfix, den jede Software beliebig erzeugen und auch verschicken darf. Manche Programme übertragen hierin Informationen, die auf der Gegenseite ausgewertet werden, wenn dort mit dem gleichen Programm gearbeitet wird (z.B. X-REPLY-LEVEL bei einigen Pointprogrammen für die Anzeige der Kommentarbaumtiefe).
Frei definierte Headerzeilen können natürlich auch zum Transport von Daten mißbraucht werden, die normalerweise im Nachrichtenkörper befördert und somit z.B. kostenpflichtig sein würden. Soll diese Problematik gelöst werden, sind z.B. feste maximale Headergrößen oder Größenverhältnisse Header/Nachrichtenkörper einstellbar zu machen. Dieses Problem kann nur durch lokale Einstellungsmöglichkeiten gelöst werden, darf dabei aber keinesfalls so auf die Implementierung abgebildet werden, daß die nicht vorhandene Größenbeschränkung, wie sie der ZConnect-Standard vorschreibt, ausgehebelt wird.
Es ist zu beachten, daß fatalerweise einige, definitiv fehlerhafte aber im Einsatz befindliche Gateways den Transport von Headerzeilen mit "X-"-Präfix nicht garantieren.
3.3.2.3. Headerzeilen aus anderen Datenformaten
3.3.2.3.1. UUCP
Headerkennungen, die mit dem Präfix "U-" versehen sind, sind sog. "UUCP-Header". Dies beschreibt Headerzeilen nach RFC822/1036 und ggf. deren Nachfolgerinnen. In diesen Headerzeilen können Informationen aus dem Usenet unbeschadet durch ZConnectsysteme transportiert werden. Sie sollten aber nur für Kennungen eingesetzt werden, zu denen es bei ZConnect wirklich keine Entsprechung gibt. Beispielsweise sollte "Date: Thu, 12 Jan 1987 PDST" nicht als "U-DATE: ..." transportiert, sondern nach EDA gewandelt werden (auch wenn dadurch vielleicht die ursprüngliche Notation des Datums nicht wiederherstellbar ist - die transportierte Information ist es auf jeden Fall). "Lines: 256" hingegen würde als "U-LINES: 256" sinnvoll transportiert werden können.
3.3.2.3.2. Fido
Mit dem Präfix "F-" beginnen Headerkennungen, die direkt aus dem FTS0001-Format oder ggf. dessen Nachfolgern und anderen Formaten aus der Fido-FTS/FSC-Welt übernommen wurden. Es ist an dieser Stelle nicht sinnvoll, die Erfordernisse von Fido-ZConnect-Gateways zu beschreiben. Zu beachten ist aber, daß es die aus dem Fido kommende "Kludgeline", die in [D3.1M] als "^A" (ASCII 1) beschreibt, in ein einfaches "F-" ohne dahinter stehenden weiteren Buchstaben übersetzt wird.
3.3.2.3.3. Z3.8
Ab [D3.1M] werden Nachrichten im Z3.8 Format als ZConnect-fremd betrachtet und somit nicht mehr im Rahmen von ZConnect beschrieben. Headerzeilen aus Z3.8 erhalten den Präfix "ZNETZ-", mehr wird hierzu nicht mehr ausgesagt.
3.3.2.4. Headerzeilenvorhersage
Die PGP-Integration in ZConnect schreibt vor, daß Headerinformationen, die durch Verschlüsselungsprogramme beeinflußt werden (z.B. CHARSET, welcher nicht mehr gilt, wenn der Nachrichtentext z.B. durch PGP in das Base64-Alphabet übersetzt wird), mit einem vorangestellten CRYPT-CONTENT- weitertransportiert werden müssen. Wird also eine neue Headerinformation XYZ eingeführt, deren Informationsgehalt nach einer Verschlüsselung nicht mehr gegeben oder falsch und nicht rekonstruierbar (wie etwa LEN) ist, so gilt automatisch auch CRYPT-CONTENT-XYZ als eingeführt.
Es wird voraussichtlich bald über eine komplette Einbindung des MIME-Standards in ZConnect abgestimmt werden. Hier wird eine Flut von neuen Headerinformationen nötig sein. Die Diskussion hierzu ist in /T-NETZ/ZCONNECT/DISKURS mitzuverfolgen. Die einschlägigen RFCs lauten 1521, 1522 und 1563.
3.4. Zusammenhänge
Dieser Abschnitt beschreibt technische Verfahren und Besonderheiten ZConnects. Neben Datenschutzaspekten werden Rekursionscheck, Weiterleitungsmechanismen, Probleme der Gemischtadressierung, Veschlüsselung und die Besonderheiten von Points bei ZConnect angeprochen.
3.4.1. Informationelle Selbstbestimmung und Datenschutz
Der Datenschutzgedanke basiert auf dem Grundrecht zur
informationellen Selbstbestimmung. Bei der Betrachtung von ZConnect
muß Datenschutz daher nicht nur von gesetzlichen Regelungen ausgehen
(die aber notwendig sind, um SystembetreiberInnen die Möglichkeit zu
geben, im Gegensatz z.B. zu Fido-SystembetreiberInnen{13},
datenschutzrechtskonform zu arbeiten), sondern schon die
ProgrammiererInnen auf sensiblen Umgang mit der Privatsphäre der
NutzerInnen verpflichten.
Hier spielt ZConnect eine Vorreiterrolle, die im Gremium nicht unumstritten ist (zuletzt bei der Diskussion um die Einführung der VIA-Headerinformation, s.u.). Es handelt sich jedoch um ein handfestes Argument für den Einsatz des ZConnect-Protokolls nicht nur bei privaten Vernetzungsprojekten. Daher müssen die bereits vorhandenen Regeln strikt eingehalten (und daher hier nochmal # zusammengefaßt), und es sollte die Übereinkunft getroffen werden, im # Zweifelsfall für die informationelle Selbstbestimmung der UserInnen # zu votieren.
3.4.1.1. Zeitangaben
Zeitangaben in Nachrichten erlauben ohne technische Notwendigkeit die Erstellung eines BenutzerInnenprofils hinsichtlich Netzanrufverhalten u.ä.. Die mit Zeiangaben versehenen Headerinformationen ZConnects sind also Gegenstand besonderer Betrachtung.
3.4.1.1.1. EDA
Jede Nachricht im ZConnect-Datenformat ist mit einem Erstellungsdatum versehen. Dieses Datum sagt über die (z.T. überflüssige) technische Information hinaus etwas über die Gewohnheiten der Absenderin aus. Auf dem Routeweg kann ein Anwenderinnenprofil aufgrund der Erstellungsdaten von Nachrichten erstellt werden. Die Anwenderin kann dies durch Verschlüsselung nicht verhindern, auch wäre dies bei öffentlichen Nachrichten kein einsetzbares Mittel.
Grundsätzlich muß sich die Anwenderin bewußt sein, daß ein aus öffentlichen Nachrichten gewonnenes BenutzerInnenprofil nicht mit Datenschutzbestimmungen kollidiert. Umso wichtiger ist es, ihr alle Möglichkeiten in die Hand zu geben, vermeidbare Informationen (sofern sie denn vermieden werden sollen) zurückzuhalten. Dies geschieht im Zusammenhang mit dem Erstellungsdatum, indem optional der Uhrzeitanteil weggelassen wird (bei privaten wie bei öffentlichen Nachrichten); diese Detailinformation ist für den Transport nicht von Bedeutung, behindert also nicht die Funktionalität ZConnects.
3.4.1.1.2. VIA
Die VIA-Headerinformation erneuert das für EDA gelöste Problem: Sortiert das erste System auf dem Weg der Nachricht sofort nach dem Netcall ein, läßt dies bei Store- and Forward Netzen, für welche ZConnect eingesetzt wird, Rückschlüsse auf das Netcallverhalten der Anwenderin zu.
# Anders als bei EDA läßt sich diese Schwierigkeit nicht dadurch aus # dem Weg räumen, daß das erste System den Zeitanteil der # Datumsangabe fest auf 0 Uhr setzt, wie ZConnect dies vorsieht. Denn # zum einen liegt dies nicht im Einflußbereich der Absenderin (auch # der Verzicht auf Datenschutz gehört zur informationellen # Selbstbestimmung), zum anderen kann auch das zweite System - z.B. # in einem LAN - unmittelbar nach dem Netcall der Absenderin # einsortieren und die Schutzfunktion hinfällig machen.
# Eine Statusinformation STAT: NOVIA wäre hilfreich.
3.4.1.2. KOP
ZConnect kennt seit einiger Zeit das Flag STAT: NOKOP, welches das Umwandeln privater Empfängerinnen in die rein informativen KOP-Headerinformationen unterbindet. Bei öffentlichen Nachrichten bleibt dies aber ohne Wirkung. Es ist nicht zu vermeiden, daß veröffentlichte Informationen für die Öffentlichkeit auswertbar sind.
# Jedoch sollten die BenutzerInnen soweit wie möglich bei der # Entstehung öffentlicher Daten die Kontrolle haben, also auch # hierbei STAT: NOKOP mit entsprechenden Auswirkungen setzen können. # Dies bedürfte beim derzeitigen Stand jedoch einer Änderung durch # das Gremium.
3.4.1.3. Wechsel von privaten Nachrichten über Netzgrenzen hinweg
Soweit anhand der Zieladresse feststellbar, sollte die Software den UserInnen mitteilen, wenn sie eine Nachricht in ein "Fremdnetz" schicken. Diese Spezifikation überfordert aber einen technischen Standard. Es ist also darüber nachzudenken, ob z.B. eine einfache Standardverschlüsselung für private Nachrichten den Protokollcharakter festigen und unabhängig von abstrakten Netzgebilden bewahren kann.
# Bereits eine primitive, synchrone Verschlüsselung (z.B. XOR 1 # byteweise) würde nach bundesdeutschem Datenschutzrecht dafür # sorgen, daß ein Geheimhaltungsinteresse von dem/der Absender/in # unterstellt wird, dessen Unterlaufen - und sei es noch so einfach - # strafbar ist ([Netzrecht]).
Die Verschlüsselung müßte natürlich auf ausdrücklichen Wunsch des/der Anwender/in abschaltbar sein.
3.4.2. Dupe- und Rekursionscheck
Dupe- bzw. Rekursionscheck erfolgt, um das Netz nicht mit Nachrichten zu belasten, die aufgrund technischer Fehler mehrfach dasselbe System passieren oder erneut auf den Routeweg gelangt sind.
3.4.2.1. Dupecheck anhand der Message-IDs
Ein routendes System muß anhand der Message-IDs öffentlicher Nachrichten einen Dupecheck durchführen, bei privaten Nachrichten ist dies untersagt. Für eine Message-ID gilt per Definition, daß sie innerhalb von zwei Jahren nur einmal weltweit erzeugt wird. Hat eine Nachricht eine Message-ID, welche innerhalb der letzten beiden Jahre bereits das routende System passiert hat, handelt es sich um eine zu löschende Rekursion.
Nun ist es unrealistisch, die Message-IDs von zwei Jahren aufzubewahren und zum Dupecheck heranzuziehen. Es wird empfohlen, die IDs von 90 Tagen aufzubewahren und Nachrichten, die älter als 90 Tage sind, per default als "zu alt" zu löschen.
Tatsächlich erzeugen auf einem großen System bereits die Message-IDs von 90 Tagen große Probleme - weniger aufgrund des nicht zu unterschätzenden Platzbedarfs, vielmehr aufgrund der benötigten Rechenzeit für den Dupecheck selber. Manche Software führt diesen Check tatsächlich linear durch. Andere Implementierungen verwenden eine Art Hashverfahren ohne Kollisionsbehandlung, also mit möglicherweise zu unrecht als Dupe gelöschten Nachrichten. Im Kapitel "Softwaretechnische Vorschläge" ist ein leistungsfähiges, vollständiges Hashverfahren ohne systembedingte Fehler beschrieben.
3.4.2.2. Rekursionscheck anhand des Routepfads (ROT)
Ein System, an welches eine Nachricht (privat oder öffentlich) weitergereicht werden soll, darf noch nicht im Routepfad der Nachricht stehen. Andernfalls ist die Nachricht nicht weiterzureichen; betrifft dies eine private Nachricht, so ist die Systembetreuung zu informieren (vgl. Spezifikation von ROT), um ein eventuelles Ping-Pong-Routing abzustellen.
Bei privaten Nachrichten ist aber zu beachten, daß es aufgrund von Routingumstellungen durchaus ohne schädliche Auswirkung passieren kann, daß ein System mehrfach im ROT-String auftaucht. Es wird daher empfohlen, frühestens bei der dritten Rekursion die Systembetreuung einzuschalten.
3.4.3. Weiterleiten
ZConnect kennt mehrere Formen des Weiterleitens, die davon abhängen, wer mit welcher Intention weiterleitet. Eine Änderung am Nachrichtenkörper darf dabei nur mithilfe eines Kommentars (KOM-Headerinformation) erfolgen.
Die Message-ID muß bei öffentlichen Nachrichten beim Weiterleiten immer verändert werden, um die weitergeleitete Nachricht vor einer Löschung als vermeintlicher Dupe zu bewahren. Die an dieser Stelle aktuellste Dokumentation [D3.1Z] unterscheidet automatisches, manuelles und Netzwerk-Weiterleiten (letzteres ist eigentlich eher ein Umleiten).
3.4.3.1. Manuelles Weiterleiten
Für das manuelle Weiterleiten einer Nachricht gibt es zwei Verfahren, die bei ZConnect bisher nur dem Verfahren nach unterschieden werden, ohne ihnen unterschiedliche Bedeutungen zuzuweisen. Die Verfahren unterscheiden sich wesentlich in der Behandlung der ABS-Headerinformation und können als *aktives* bzw. *passives* *Weiterleiten* umschrieben werden. In beiden Fällen sind aber folgende Schritte auszuführen:
1. Die Weiterleitung bekommt eine eigene Message-ID (diejenige der Originalnachricht darf also nicht übernommen werden, auch wenn dies bei privaten Nachrichten ohne Auswirkung wäre)
2. ROT wird gelöscht und neu erzeugt, als ob es sich um eine neu erstellte Nachricht handeln würde
3. Existieren noch keine OEM-Headerinformationen, so werden die EMP-Headerinformationen in OEMs umgewandelt
4. Existiert noch keine O-EDA-Headerinformation, so wird aus der EDA-Headerinformation O-EDA, und es wird eine neue EDA-Information erzeugt. Dies ist immer erforderlich, um die Entsorgung einer als öffentliche Nachricht weitergeleiteten Nachricht als "zu alt" zu verhindern (vgl. MID, Rekursionscheck)
5. Sind CONTROL-, ERR-, ZNETZ-CONV-*, TRACE-, VER-, STAT-, VIA- und/oder EB-Headerinformation vorhanden, werden sie jeweils gelöscht
Dann wird je nach Form des Weiterleitens unterschiedlich vorgegangen. Da es hierbei in der Vergangenheit immer wieder Interpretationsschwierigkeiten gegeben hat, werden die beiden Formen hier als aktives und passives Weiterleiten benannt.
3.4.3.1.1. Passives Weiterleiten
Das passive Weiterleiten wird definiert als Ausdruck für das Anliegen der Weiterleiterin, einer Nachricht eine neue Richtung zu geben, sie also unverändert zu belassen außer der Tatsache, daß sie wieder auf die Netzreise geschickt wird (wobei natürlich aus technischer Sicht sehr wohl Änderungen, z.B. an der Message-ID, vorgenommen werden).
6. Alle weiteren Headerinformationen bleiben unverändert, da die weiterzuleitende Nachricht dem Wesen nach original (also insbesondere mit den personenbezogenen Informationen der ursprünglichen Absenderin) erneut verschickt werden soll.
7. Es wird eine WAB-Information eingefügt, die die Adresse der Weiterleiterin enthält.
3.4.3.1.2. Aktives Weiterleiten
Für das aktive Weiterleiten wird definiert, daß die Weiterleiterin sich den Inhalt der Weiterleitung zu eigen macht. Zwar darf auch hier der Nachrichtenkörper nicht verändert werden (sonst handelt es sich nicht mehr um eine Weiterleitung), aber es ist z.B. möglich, den Betreff zu wandeln, auf die Person der Weiterleitenden bezogene Informationen (wie POST, TELEFON) in den Header einzufügen, eine ZUSAMMENFASSUNG einzufügen oder zu ändern, STICHWORTe hinzuzufügen oder die Nachricht mit dem eigenen PGP-Key zu unterschreiben; letzteres illustriert besonders deutlich die Zueigenmachung der Weiterleitung.
Umgekehrt folgt aus diesen Überlegungen, daß beim aktiven Weiterleiten alle auf die Originalabsenderin bezogenen Headerinformationen zu löschen sind, wobei dieser Punkt insofern kritisch ist, als einer älteren Software unbekannte, neue personenbezogene Headerinformationen hinzugekommen sein können. Da dieses Problem nicht aufzulösen ist (es sei denn, das aktive Weiterleiten würde gänzlich anders definiert), ist zumindest bei zukünftigen Erweiterungen die Dokumention an dieser Stelle nachzuführen.
Aktuell ist beim aktiven Weiterleiten folgendes zu tun:
6. ANTWORT-AN, LANGUAGE, LDA, MAILER, ORG, PGP, PGP-ID, PGP-KEY-AVAIL, PGP-KEY-COMPROMISE, PGP-KEY-OWN, PGP-PUBLIC-KEY, PGP-SIG, POST, PRIO, SIGNED, SPERRFRIST und TELEFON sind zu entfernen. LDA und SPERRFRIST sind hierbei mit Vorsicht zu behandeln und sollten z.B. der Weiterleiterin explizit zum Löschen/Beibehalten vorgelegt werden. Sofern veraltete Headerinformationen berücksichtigt werden, ist auch PUBLIC-KEY zu löschen
7. Nur wenn noch keine OAB-Information vorhanden ist, wird sie aus der ANTWORT-AN-Information oder, wenn diese nicht oder im Gegenteil mehrfach angegeben ist, aus der ABS-Information erzeugt
8. Die Adresse der Weiterleitenden wird als ABS-Information eingefügt
9. Eine evtl. vorhandene WAB-Information wird gelöscht
3.4.3.2. Automatisches Weiterleiten
Das automatische Weiterleiten erfolgt z.B. bei Mailinglistenverteilern. Ein solcher Verteiler verschickt jede an ihn gerichtete Nachricht an alle beim Verteiler akkreditierten Mailadressen. Dies hat die Wirkung eines öffentlichen Brettes, welches aber nicht öffentlich transportiert wird, z.B. weil es weltweit zuwenige InteressentInnen gibt. Natürlich sind die versandten Nachrichten technisch betrachtet in beiden Richtungen private Nachrichten.
Eine beim Verteiler eingehende Nachricht wird wie folgt behandelt:
1. Wenn eine Empfangsbestätigung angefordert wurde (EB-Information), wird diese verschickt und die EB-Information aus dem Header gelöscht
2. Die EMP-Information (also die Adresse des Verteilers) wird in die OEM-Information gewandelt
3. Alle akkreditierten Mailadressen werden als Empfängerinnen eingetragen (entsprechend viele EMP-Informationen)
4. Die Absenderinangabe bleibt erhalten.
Hat der Verteiler eine Betreuerin, so kann deren Mailadresse als WAB-Information eingetragen werden, was zu einer Zustellung von evtl. Fehlermeldungen an die Weiterleiterin führt, aber auch privat in die Liste verschickte Beiträge würden so fälschlicherweise bei der Betreuerin landen: Da die "öffentlichen" Nachrichten des Verteilers als private Nachrichten bei der Anwenderin erscheinen, antwortet diese häufig auch privat, wenn sie eigentlich in den Verteiler schreiben will.
Es ist absolut üblich, ANTWORT-AN auf die Verteileradresse zu setzen, was aber, schlechter noch als bei Verwendung von WAB, eine private Antwort an die Absenderin und die sinnvolle Zustellung von Fehlermeldungen verhindert (vgl. Spezifikation ANTWORT-AN). ZConnect sieht dies aber nicht unbedingt vor; ein Newsreader sollte vielmehr bei einer privaten Antwort Weiterleitabsenderin und Absenderin als Adressatinnen zur Auswahl vorlegen.
In jedem Fall ist es sinnvoll, eine DISKUSSION-IN-Information auf die Adresse des Verteilers weisen zu lassen, um den Mailinglisten-Charakter als privat verteiltes öffentliches Brett zu unterstreichen.
5. Evtl. vorhandene KOP-Informationen werden nicht gelöscht
6. Evtl. vorhandene TRACE- und VIA-Informationen werden gelöscht
# Es kann notwendig sein, EDA als O-EDA weiterzutransportieren und # ein neues EDA zu erzeugen, da die Annahme, daß bei einer # automatischen Weiterleitung immer nur private Nachrichten betroffen # sind, fahrlässig ist. Bei der automatischen Umleitung privater # Nachrichten in ein öffentliches Brett (z.B. Nachrichten an den # Postmaster-Account in ein vom SystembetreuerInnenteam gelesenes # Brett oder bei der Umsetzung einer Mailingliste in ein lokales # Brett) kann eine pflichtbewußte Systemsoftware die entstehende # Nachricht potentiell als "zu alt" entsorgen.
Sinngemäß Gleiches gilt für ROT/O-ROT.
3.4.3.3. Weiterleiten im Netz: Umleiten
Ist in einem System für die Empfängerin einer privaten Nachricht eine Vertreterin angegeben (z.B. kann dies bei einem Nachsendeantrag eines Points bei Systemwechsel der Fall sein), so wird das umleitende System wie folgt vorgehen:
1. Keine Empfangsbestätigung versenden, daß tut erst das laut Vertreterineintrag empfangende System
2. Keine Änderung der Message-ID vornehmen, da es sich immer um PMs handelt, für die ein Dupecheck nicht stattfindet
3. Die EMP-Information wird in die VER-Information umgewandelt (VER kann nach [D3.1Z] mehrfach vorkommen, was sinnvoll ist; laut älteren Gremiumsbeschlüssen müßte aber ein bereits vorhandenes VER gelöscht werden, da diese Headerinformation dort als "nur einmal" beschrieben ist). Es kann nur eine EMP-Information im Header enthalten sein, da es sich um eine private Nachricht handelt, die am vorläufigen Ende ihres Routewegs angelangt ist
4. Die neue Empfängerin wird in die EMP-Headerinformation eingetragen
5. Eine evtl. vorhandene Information O-ROT wird gelöscht (hier zeigt sich eine Inkonsistenz der Änderung auf "auch mehrfach" bei der VER-Information: mehrfache Routepfade können nicht transportiert werden)
6. ROT wird in O-ROT umgewandelt
7. Eine neue ROT-Information wird so angelegt, als sei die Nachricht auf dem umleitenden System geschrieben worden (also mit dem umleitenden System nebst Domain als ersten Eintrag)
# Es ist bisher keine O-VIA-Headerinformation für die Verwendung # beim VER-Umleiten definiert. Dies (vgl. O-ROT) könnte eine # sinnvolle Erweiterung darstellen. Allerdings würden beim aktuellen # Vorgehen bereits vorhandene VIA-Headerinformationen nicht gelöscht, # so daß in Kombination mit der VER-Information selber ersichtlich # wird, welche VIA-Informationen zu welchem Teil des Routeweges # gehören.
Der Logik folgend, daß erst das endgültige Empfangssystem die Empfangsbestätigung versendet, darf auch eine evtl. vorhandene TRACE-Headerinformation nicht gelöscht werden.
3.4.4. Gemischtadressierung
In ZConnect ist vorgesehen, daß eine Nachricht gleichzeitig private und öffentliche Empfängerinnen haben darf. Gleichzeitig gibt es in ZConnect sehr viele Headerinformationen, die nur für den Einsatz bei privaten Nachrichten bestimmt sind (z.B. PGP-KEY-OWN, PGP-PUBLIC-KEY, EB, O-ROT, PGP: PLEASE | REQUEST, TRACE, VIA). Die Absenderin einer gemischtadressierten Nachricht wird bei Einsatz solcher Informationen deren Zustellung an die privaten Empfängerinnen, nicht aber an die öffentlichen im Sinn haben. Bei der Aufsplittung der gemischtadressierten in eine private und eine potentiell wieder gemischtadressierte oder rein öffentliche Nachricht ergibt sich jedoch eine unauflösbare Schwierigkeit:
Die routende Software müßte testen, welche der Headerinformationen nur für Privatnachrichten gedacht sind, diese in den privaten Header kopieren und aus dem öffentlichen löschen (in einer gemischtadressierten Abspaltung müßten sie hingegen verbleiben). Dies erforderte jedoch, mangels einer grundsätzlichen Attributierung von Headerkennungen in ZConnect, daß die Software eine Liste der Headerinformationen zur Verfügung haben müßte, welcher die Eigenschaft "nur in privaten Nachrichten erlaubt" zu entnehmen wäre. Aber auch dies löste das Problem nicht grundlegend, da jederzeit neue Headerinformationen beschlossen werden können, die nur in privaten Nachrichten erlaubt sind. Es würde auch immer Software geben, die mindestens nicht auf dem aktuellsten Stand der Dinge ist.
Auch eine Umspezifizierung der Regelung, daß manche Headerzeilen nicht in öffentlichen Nachrichten auftreten dürfen, in eine Festlegung, daß nur das Auswerten bestimmter Headerinformationen bei öffentlichen Nachrichten nicht erfolgen sollen, löst das Problem nicht. Zum einen würden unnötig Daten transportiert, die recht voluminös sein können (z.B. im Zusammenhang mit PGP). Zum anderen kann auch eine komplette Nachricht als öffentliche Nachricht verboten sein. Z.B. ist die vor der Einführung nach ZConnect stehende MIME-Spezifikation ausschließlich für private Nachrichten erlaubt. MIME definiert eine Nachrichtenkörperform, die in öffentlichen Sendungen unerwünscht ist. In diesem Fall wäre eine gemischtadressierte Nachricht insgesamt zu unterbinden, da öffentliche Empfängerinnen nicht erlaubt sind.
Bei einer gemischtadressierten Nachricht wird bei der Aufteilung keine neue ID für den privaten Anteil erzeugt. Begründung ist, daß es keinen Dupecheck für private Nachrichten gibt. Tatsächlich ist einige Routesoftware hier nicht standardkonform und führt den Check auch für private Nachrichten durch. Aus Sicht dieser fehlerhaften Software ist eine aufgetrennte, ehemals gemischtadressierte Nachricht also automatisch ein Dupe. Aber auch ohne fehlerhafte Software ergeben sich Probleme z.B. für die lokale Kommentarverkettung: Zwei de facto nicht identische Nachrichten (daß sie den gleichen Nachrichtenkörper haben, bedeutet keine technische Gleichheit) liegen potentiell mit derselben Message-ID in der lokalen Nachrichtendatenbank.
# ZConnect wohnt eine einfache Lösung für all diese Probleme inne, # die bisher kaum beachtet wird, es aber unbedingt werden sollte: Es # ist festgelegt, daß eine Nachricht privat ist, wenn ihre sämtlichen # Empfängerinnen privat sind. Also ist eine gemischtadressierte # Nachricht als öffentliche Nachricht zu interpretieren. In einer # solchen ist dann alles verboten, was nur für private Nachrichten # erlaubt ist. Dies schränkt zwar auf den ersten Blick den Komfort # für die Absenderin ein. Aber die Teilung von privaten und # öffentlichen Empfängerinnen kann unaufwendig schon bei der # Erzeugung der Nachricht von der BenutzerInnenschnittstelle # automatisch durchgeführt werden. An dieser Stelle ist auch noch # leicht zu unterscheiden, welche Headerinformationen in welchem Teil # der Sendung erlaubt sind.
3.4.5. Verschlüsselung
Grundsätzlich verfolgt ZConnect die Absicht, Verschlüsselungen im Standard zu erfassen, um sie automatisch durch Software behandelbar zu machen. Dies drückt sich in der Positionierung von Verschlüsselungsinformationen im Header aus. An dieser Stelle unterscheidet sich ZConnect sehr von anderen Standards der Netzwelt, was insbesondere für Gateways nicht ganz einfach ist. Angesichts der Möglichkeit, z.B. das manuell umständlich zu verwendende PGP dadurch beinahe für die Anwenderin transparent in eine Software zu integrieren, ist dies aber eindeutig als Vorsprung ZConnects zu werten und damit besonderes Augenmerk wert.
Durch die Verschlüsselung werden Headerinformationen wie CHARSET, TYP und KOM z.T. ihrer Aussage beraubt. Evtl. ändern sich Zeichensatz und Typ, der Kommentar wird üblicherweise mitverschlüsselt. Daher werden diese Header für die Decodierung mit dem Vorspann CRYPT-CONTENT- versehen (vgl. Datenformat CRYPT-CONTENT-CHARSET ff.).
3.4.5.1. PGP
Pretty Good Privacy, kurz: PGP, ist ein nach heutigen Maßstäben sicherer Verschlüsselungsmechanismus für Nachrichten. In ZConnect wird er auf Headerebene eingebunden.
3.4.5.1.1. Grundsätzliches
Auf die Funktionsweise von PGP soll an dieser Stelle nicht näher eingegangen werden. Hierzu empfiehlt sich vor einer Implementierung dringend die Lektüre der Dokumentation vom Autoren des Programms, Philip Zimmerman. Diese wird mit den PGP-Komplettpaketen verteilt. PGP ist ein als Public Domain freigegebenes Verfahren, dessen Verwendung in ZConnect und auch in jedem anderen Kontext ohne Bedingungen gestattet ist.
Der Public Key ist beim PGP-Verfahren nicht nur problemlos frei veröffentlichbar, er gewinnt sogar an Sicherheit und Brauchbarkeit, je weiter er verbreitet ist. Zwar kann ein Public Key jederzeit gefälscht werden, aber zum einen sieht PGP Mechanismen vor, die dies wirksam erkennen lassen, zum anderen ist die Fälschung umso schwieriger, je weiter ein korrekter, öffentlicher Schlüssel verbreitet ist.
ZConnect sieht zwei Möglichkeiten vor, Public Keys zu verbreiten. Zum einen ist dies das Versenden des Public Keys im Header einer Nachricht, mit der jederzeit gegebenen Gefahr der Manipulation. Zum anderen ist es der Abruf mithilfe der ZConnect-Onlinephase in einer Mailbox, z.B. jener der Heimat-Mailbox der Anwenderin, deren Schlüssel gewünscht ist, mit der ebenfalls jederzeit gegebenen Gefahr, daß die MailboxbetreiberInnen Schlüssel fälschen oder für UserInnen generieren, die PGP gar nicht verwenden. Zwischen beiden Methoden existiert ein Bindeglied, welches im Kopf einer Nachricht lediglich anzeigt, daß und wo der Public Key der Absenderin per ZConnect-Onlinephase abzurufen ist (vgl. Datenformat: PGP-KEY-AVAIL bzw. Onlinephase: PGP-KEYREQ).
Die Anwenderin sollte möglichst von der Software zu einem verantwortungsvollen Umgang mit den PGP-Möglichkeiten ZConnects hingeführt werden. Das bedeutet zum einen die Vermeidung von übertrieben großem Datenaufkommen, wie es durch Mitschicken des eigenen Public Keys in jeder öffentlichen Mail entstünde. Zum anderen sollte auf die Gefahren aufmerksam gemacht und z.B. auf die Überprüfungsmöglichkeit per Telefon und Fingerprint hingewiesen werden.
Aus Protokollsicht soll die PGP-Integration die Zusammenarbeit mit dem PGP-Programm vollautomatisch ermöglichen, insbesondere also die Weitergabe von Keys in die Public Key Verwaltung von Philip Zimmermans PGP. Aus UserInnensicht sollte möglichst nichts Verschlüsseltes oder durch Unterschrift Codiertes auf dem Bildschirm erscheinen. Vielmehr sollte die Software soweit wie möglich Entschlüsselung und Unterschriftenprüfung automatisieren und z.B. nur Statusmeldungen wie "Nachricht war PGP-verschlüsselt" oder "Nachricht war unterschrieben, Unterschrift geprüft" anzeigen.
PGP verschlüsselt Daten so, daß auch die Absenderin sie nicht mehr lesen kann. Soll die versandte Nachricht für die Absenderin lesbar bleiben (was ein gewisses Sicherheitsleck bedeutet), gibt es eine bessere Lösung für dieses Problem als die getrennte Speicherung des Klartextes. PGP unterstützt die Verschlüsslung an zwei Empfängerinnen - nämlich die wirkliche Empfängerin und (in diesem Fall) die Absenderin mit dem Befehl "pgp -e dateiname UserID1 UserID2". So kann unter Eingabe des Paßwortsatzes auch die Absenderin die eigenen Nachricht noch entschlüsseln.
3.4.5.1.2. Transport der Schlüsselinformation
Die Schlüsselinformation wird, dem eingangs erwähnten Konzept folgend, im Header einer Nachricht transportiert (die Möglichkeit des Keyrequests hier einmal außer acht gelassen). Hierzu wird nicht die "verpackte" (bei PGP "amor" genannt) Version verwendet, welche PGP mit dem Kommando "pgp -kxa" liefert, sondern die die reine Schlüsselinformation, wie sie (bei angenommener Nicht-Existenz eines Armor vorschreibenden Configfiles) "pgp -kx" produziert; diese wird allerdings Base64-codiert.
Die Base64-Codierung ist ein einfaches Verfahren zur 6-Bit-Codierung,
welche einen problemlosen Transport über wohl sämtliche Netzgrenzen
hinweg garantiert. Drei Bytes … 8 Bit werden hierbei in vier Bytes … 6
Bit{14} aufgeteilt. Das verwendete 6-Bit-Alphabet harmoniert mit dem
ZConnect-Zeichensatz für den Header:
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/".
Darüberhinaus ist im ZConnect-Kontext nur noch das Füllzeichen '=' zu
beachten, welches beim Dekodieren zu überlesen ist. Der auf der
beiliegenden CD enthaltene Source MKKEY.C illustriert das Vorgehen
beim Codieren. Aus dem PGP-Sourcepaket stammt die Routine ARMOR.C,
welche für das Decodieren zuständig ist.
ZConnect-Headerinformationen sind einzeilig; dies gilt natürlich auch
für solche, die einen Public Key oder eine Unterschrift enthalten. Im
Gegensatz zum Armor-Format wird also nicht nach 64 Zeichen
umgebrochen.
Beispiel: Der Public Key von Sepro@bingo.comlink.de in Armor-Darstellung von PGP:
-----BEGIN PGP PUBLIC KEY BLOCK----
Version: 2.6
mQCNAi4bNc0AAAEEAOc6GczyLdnA4FtHjqIzDHetafHO6nnNAkMZNBIbu7aXFcj1
sGo9X5NUmKcC2nb33l5BDeKjql7leSTmxtvrABcd6clndd+YOKCo0DMtU8o2Z/+y
75hssRZAhLEJWM/d+qGP712jg6vMJmKiDBbop+N/FNxnXXMauQqcFQabFzW9AAUR
tCJDZSBCcnVua2UgPFNlcHJvQGJpbmdvLmNvbWxpbmsuZGU+iQBVAgUQLz+cI/95
3NsQf2DxAQGQGgH6AlpZuYCAPHDx2Cxl0qGTZx5WMp6PM63ZJMtKZe1LJSEWv1vh
8KLWwsFH+KGV/ExkRPC5eVSA1Flwaigrex9F8YkAlQMFEC8qhcQKnBUGmxc1vQEB
BC8EAJO2RcXB7ppRIMi70PQsEANbTzgfSbRvTsT8T0XqZIooLu6/ALBZSVNTir8R
X1eXJT1YKDm8/r7/TsraqMJ52feGvHMwGf6Jrs1+6VblANu8DQqyPWQ0wRwjBWz+
sqKk4boJrbK7Qy9RZXP2Tw83ADquViQjlTiMqeTOsRMr4pavtClDYXJzdGVuIEJy
dW5rZSA8U2Vwcm9AQW10cmFzaC5jb21saW5rLmRlPokAlQIFEC7i0pYKnBUGmxc1
vQEBhnkD/1Rc+xVaJNkN3Mw7DIHpMLBh0rCChb70PHsfUGOk/TBt00ujuuyyR9SF
worS9GJANkyiGKDYC+tCbYRriBlBLvhvR3xQRntdQIcNwwJBdaa3zXCIEx/lUtF0
YJCH9+hLdGUH6kILpfj2+YMKpBjh2HulBqVesOXpGoC9HgFWn3QMiQBVAgUQLj59
HkHx4UColTddAQH7iwH/d79Dhd8GYjgWzR1zmCf6g9loKOQsbEHG4/ivAPznJ2y+
s5rCaNbpg8yavGrhp3iV6f5Wncw7/637J7Qb6nft2A==
=vGi/
----END PGP PUBLIC KEY BLOCK-----
Die binäre Entsprechung (bin) ergäbe sich, als C-Pseudocode formuliert, mit einer ord-Funktion gemäß Base64-Alphabet, exemplarisch, ohne Berücksichtigung der Füllzeichen, für das erste Armor-Quadrupel (armor) wie folgt:
bin[0] = (ord(armor[0])<<2) | (ord(armor[1])>>4)
bin[1] = (ord(armor[1])<<4) | (ord(armor[2])>>2)
bin[2] = (ord(armor[2])<<6) | ord(armor[3])
Und der umgekehrte Weg mit einer chr-Funktion gemäß BASE64-Alphabet:
armor[0] = chr(bin[0] >> 2)
armor[1] = chr(bin[0] << 4) | chr(bin[1] >> 4)
armor[2] = chr((bin[1] & 0xF) << 2) | chr(bin[2] >> 6)
armor[3] = chr(bin[2] & 0x3F)
3.4.5.1.3. Unterschriften
Wenn eine Nachricht verschlüsselt und unterschrieben ist, ist die Signatur in der Verschlüsselung enthalten, braucht also nicht einzeln transportiert zu werden. Nur wenn eine Nachricht nur unterschrieben wurde, wird die Unterschrift in der Headerinformation PGP-SIG transportiert.
PGP kann die Unterschrift auch direkt auf den zu unterschreibenden Text anwenden. Dieser wird dabei zugleich ins Armor-Format umgewandelt und somit ohne PGP unlesbar, was nicht der Sinn einer Unterschrift ist. Es ist daher unbedingt sinnvoll, zumindest bei öffentlichen Nachrichten, die ZConnect-Methode des Transportes der abgelösten Unterschrift im Header zu verwenden. "PGP -sb" erzeugt eine Binärdatei, die die solitäre Unterschrift enthält, welche äquivalent zur Behandlung der Public Keys Base64 codiert und einzeilig in den Header geschrieben wird.
# Die Möglichkeit PGPs, Signaturen als Klartext im Nachrichtenkörper # unterzubringen, wie sie teilweise von Pointprogrammen verwandt # wird, ist besonders relaykompatibel (gatetauglich), paßt aber nicht # zu ZConnect-PGP-Regelung. Was hauptsächlich bedeutet, daß die # ZConnect-Regelung einer grundsätzlichen Überarbeitung bedarf.
Es ist nicht sinnvoll, mit einer unterschriebenen Nachricht immer auch den Public Key mitzuschicken: Wer unterwegs die Unterschrift fälschen kann, wird dies mit dem Key auch tun können. Unnötiges Datenaufkommen sollte hier vermieden werden.
3.4.5.2. QPC:
QPC:, kurz für QuickPointCrypt, ist für das Pointprogramm QuickPoint entwickelt worden. Es ist sehr einfach zu implementieren und mit ebenso einfachen kryptographischen Methoden angreifbar. Um es als schnelle, umschlagähnliche Codierung einzusetzen, können ProgrammiererInnen sich bei Marc Zimmermann (75240.1241@compuserve.com), dem QuickPoint-Autor, die Dokumentation zu QPC: besorgen.
QPC: wird von mehreren Pointprogrammen angeboten; !!MessageBase bietet eine Abwandlung an, die auch binäre Dateien verschlüsseln kann, was mit QPC: sonst nicht möglich ist. Auch für dieses abgewandelte Verfahren ist bei obiger Mailadresse eine Dokumentation erhältlich.
3.4.6. Points
In der Welt der privaten Vernetzung, welche bis vor nicht allzu langer Zeit fast ausschließlich mit FIDO-, Z-Netz- und unzähligen sich mehr oder weniger ähnelnden Protokollen betrieben wurde, gab es überwiegend die Unterscheidung zwischen routenden Systemen (Mailbox) und Endsystemen. Ursprünglich wählten sich die UserInnen online in eine Mailbox ein, um dort z.B. Nachrichten zu lesen oder auch unter ihrem UserInnennamen zu schreiben.
Dieses Vorgehen ist kostspielig und unkomfortabel, daher wurden Offlinereader entwickelt, mit denen regelmäßig oder auch nur ab und zu eine Mailbox angerufen und en block die bis dahin neu aufgelaufenen Nachrichten/Daten auf den heimischen Computer übertragen werden konnte. In vielen Netzen bildete sich für diese Offlinereader der Begriff Point. Technisch stellt der Point also die einfachere Alternative zu einer Systemsoftware dar, hat aber seinen Ursprung in der Automatisierung der Datenübertragung vom System zu den AnwenderInnen.
Hierin liegt begründet, warum noch immer, z.B. bei ZConnect, Unterschiede zwischen einem System und einem Point existieren und Points nicht einfach nur nicht anrufbare Systeme sind, wie es vielfach im RFC-Bereich der Fall ist.
Es gibt keinen protokolltechnisch zwingenden Grund für die Aufteilung in Systeme und Points. Faktisch ist denn auch bei ZConnect der Unterschied heute nicht mehr sehr groß. Besonderheiten ergeben sich aus der Sichtweise von Points als Quelle bzw. letzte Lagerstätte einer Nachricht und aus der zwingenden Zuordnung von PointuserInnen zu einem System.
Die Zuordnung zu einem System bedeutet, daß der Routepfad aus ZConnect-Sicht erst ab dem ersten System beginnt. Points müssen also einen leeren ROT-Pfad erzeugen. Auch überprüft ein System, ob "seine" Points unter der dem System bekannten AbsenderInnenadresse schreiben. Dies ist zwar nicht ZConnect-immanent, es wird aber von allen ZConnect-Mailboxprogrammen so gehandhabt, daß, wenn Point A@box.do.main als B@box.do.main schreibt, die Mailboxsoftware ohne jede Rückfrage oder Fehlermeldung A@box.do.main daraus macht. Insbesondere bei weitergeleiteten Nachrichten führte dieses Vorgehen, welches die Verifizierbarkeit einer Absenderin erhöhen soll, in der Vergangenheit immer wieder zu weittragenden Fehlern, die den Netzfrieden gefährdeten. Z.B. hat Mailboxsoftware bei einer passiv weitergeleiteten Nachricht den Adreßanteil der ABS-Information verändert, den Realnamenanteil jedoch unverändert gelassen.
Dies zeigt auch, daß das "Eigentumverhältnis" zwischen Point und System gerade aus protokolltechnischen Gründen unhaltbar ist: Sollte in der Zukunft eine neue Art der Weiterleitungsinformation beschlossen werden, in der die Weiterleiterin z.B. in der Headerinformation MODERATORIN untergebracht ist, wird ältere Software fälschlicherweise eine "gefälschten" Absenderinangabe erkennen und selbst die eigentliche Fälschung vornehmen.
Für das erste System auf dem Routeweg ist auch der "Notfall" vorbehalten, welcher für die Erlaubnis der Ersetzung von EMPs durch KOPs (vgl. bei KOP) eintreten muß. Dieses erste System (und nur dieses!) darf ausnahmsweise EMPs in KOPs wandeln, wenn lokale Begebenheiten dies unausweichlich machen. Wenn eine Nachricht mit einem Brett als Empfängerin aufwartet, das für die Absenderin nicht beschreibbar ist, sollte die Nachricht bevorzugt der Systembetreuung zur Entscheidung vorgelegt werden, auch in diesem Fall also auf die Ersetzung verzichtet werden. Hintergrund ist, daß die Absenderin andernfalls nie erfährt, daß ihre Nachricht nicht dort angekommen ist, wo sie plaziert werden sollte.
Auf der anderen Seite wird ein Point als letztes Glied in der Kette eines Nachrichtenwegs betrachtet. Aus diesem Grund legt das Zerberus-Mailboxprogramm eine sehr eigene Interpretation der EMP/KOP-Regelung an den Tag. Wenn eine Nachricht von einem Zerberussystem zum Point geschickt wird, werden alle EMPs, die nicht mit der Liste der vom Point beim System bestellten Bretter übereinstimmen, zu KOPs gewandelt. Tatsächlich kann dies für NutzerInnen einer weniger intelligenten Pointsoftware sehr hilfreich sein, da solche Software die ankommende Nachricht häufig genau so oft einsortiert, wie EMP-Angaben vorhanden sind. Bei einer hohen Zahl von EMP-Informationen kann dies sehr unhandlich geraten. Technisch ist gegen diese Art der EMP/KOP-Wandlung nichts einzuwenden, da die Nachricht ihren Bestimmungsort erreicht hat und somit keine Routinglücken mehr entstehen können. Faktisch können die meisten Pointprogramme heute mit Crosspostings sehr gut umgehen (insbesondere seit Einführung des ZConnect-Maps-Standards), so daß Systemsoftware Klimmzüge wie die beschriebenen unterlassen sollte. Innerhalb des Datenbestands eines Pointprogramms kann die Benutzerin beliebig verfahren. Sobald für eine Nachricht kein weiteres Routing erforderlich ist, sind Software und Mensch in ihrem Vorgehen frei, dürfen also intern beliebig EMPs in KOPs wandeln. Bei internen Verschiebungen oder Kopien muß auch die Message-ID nicht gesondert betrachtet werden, es sei denn, die Pointsoftware selber erfordert dies.
Es ist sehr fraglich, ob die Headerinformationen SPERRFRIST und LDA von Pointprogrammen automatisch ausgeführt werden sollten. Hier zeigt sich dann auch ein eklatanter Unterschied zwischen Points und OnlineuserInnen: Für den Onlinedatenbestand eines Systems sind Informationen wie die genannten schlicht Hilfsmittel für die automatische Datenverwaltung. Für eine Pointsoftware gilt jedoch, daß die Daten in den exklusiven Verfügungsbereich der Anwenderin übergegangen ist. Ein Automatismus, der in diesem Verfügungsbereich ungefragt Daten löscht, ist abzulehnen.
Im Rahmen dieser Überlegung sind auch LANGUAGE und STAT: NOCIPHER nur als Empfehlungen zu interpretieren. Es ist zu jeder Zeit davon auszugehen, daß oberhalb der ISO-Schicht 7 unter anderem menschliche Entscheidungen angesiedelt sind, so daß technisch nicht notwendige Bevormundungen als schlechter Stil zu werten sind.
Ein ZConnect-fähiger Point antwortet auf die Anforderung einer Empfangsbestätigung (sofern die Anwenderin dies nicht abgeschaltet hat). Für nicht-ZConnect-fähige Points übernimmt dies das ZConnect-System. Diese Regelung ist insofern völlig unklar, als es derzeit keine ZConnect-fähigen Points gibt (nur ZConnect-Datenformat-fähige). De facto werden derzeit Empfangsbestätigungen von Pointprogrammen und nicht von Systemen verschickt.
3.5. Maps-Standard
Die Handhabung von Brett(ab)bestellungen beim servenden System, sei es von einem anderen System oder vom Point aus, erfolgt häufig über einen Automatismus, der im Anschreiben einer automatischen Userin besteht, die darauf mit Brettlisten, An- und Abbestellung und, je nach Implementation, auch mit weiteren Funktionen zu Diensten ist. Die Syntax dieser Automatismen war für verschiedene Systeme immer nur beinahe gleich. Der am weitesten verbreitete Name für den Automatismus ist MAPS - oft, aber eben nicht immer muß die Anwenderin eine Nachricht an Maps@box.domain schicken, bekommt von dieser eine Antwort und muß diese Antwort wieder selber interpretieren.
Auf dem /Z-NETZ-Treffen 1994 in Hamburg entwarfen die Anwesenden aus dem Gremium einen Standard für dieses Verfahren. Dies soll Programmen ermöglichen, die Kommunikation mit der Autouserin auch Anwenderinnenseitig zu automatisieren, also die Anwenderin vom Schreiben und auch Lesen dieser eigentlich technischen Informationen zu entlasten. Stattdessen kann z.B. ein graphischer Dialog zur Brettbestellung verwendet werden, welcher dann vom Userinneninterface in entsprechende Maps-Anweisungen umgesetzt werden kann.
Damit wäre auch schon gesagt, wie Maps zukünftig bei ZConnect heißen wird: Maps. Maps ist von beliebiger Stelle aus dem Netz unter der Adresse MAPS@System.Domain erreichbar, wird aber manche Antworten nur lokalen AnwenderInnen oder besonders als Maps-berechtigt vermerkten UserInnen aus dem Netz geben.
3.5.1. Die Maps-Befehle
Befehle an Maps stehen grundsätzlich in der Betreffzeile und können eine beliebige Groß-/Kleinschreibung aufweisen. Die Parameter stehen im Nachrichtenkörper. Auch bei ihnen muß mit beliebiger Groß-/Kleinschreibung gerechnet werden, auch wenn oder gerade weil die Dokumentation an dieser Stelle keine eindeutige Aussage trifft. Parameter im Betreff werden grundsätzlich ignoriert!
Empfängt Maps einen unbekannten oder nicht implementierten Befehl, wird eine Antwort mit dem Betreff "Your Help" generiert, die einen Hilfstext mit allen dem antwortenden Maps bekannten Befehlen nebst deren Erläuterung enthält. Antworten auf bekannte Befehle erhalten zwingend den Betreff "Your <Befehl>", also z.B. "Your ADD", "Your LiSt" (auch hier keine Festlegung der Groß-/Kleinschreibung!) und eine BEZ-Information, welche zur Message-ID der beantworteten Nachricht einen Bezug herstellt.
3.5.1.1. Pflichtbefehle
Um eine Maps-Implementation ZConnect-konform nennen zu dürfen, bedarf es zusätzlich zum bisher Beschriebenen der vollständigen Implementierung der folgenden Pflichbefehle:
-----------------------------------------------------------------------------
ADD
Funktion: dient der Bestellung von Brettern für das
absendende System oder Point beim angeschriebenen
System. Das angeschriebene System wird natürlich
die Berechtigung zur Bestellung einzelner Bretter
prüfen.
Nachrichtenkörper: enthält zeilenweise, beginnend mit einem Slash
('/') die Brettnamen, die bestellt werden sollen,
wobei Groß-/Kleinschreibung zu ignorieren sind.
Zeilen ohne Slash am Beginn werden ignoriert.
Antwort: enthält ein Protokoll über die angeforderten
Bretter (also den Erfolg/Mißerfolg der Bestellung)
in dem unter "Listenformat" beschriebenem Format
(s.u.)
Hinweis: das Ergebnisprotokoll enthält genau diejenigen
Bretter, die in der Anforderung aufgezählt wurden
-----------------------------------------------------------------------------
DEL
Funktion: dient der Abbestellung von Brettern. Falls das
angeschriebene Systeme Pflichtbretter kennt, wird
es deren Abbestellung negativ bescheiden.
Nachrichtenkörper: enthält zeilenweise, beginnend mit einem Slash
('/'), die Brettnamen, die abbestellt werden
sollen, wobei Groß-/Kleinschreibung zu ignorieren
sind. Zeilen ohne Slash am Beginn werden ignoriert.
Antwort: enthält ein Protokoll über die angegebenen Bretter
(also den Erfolg/Mißerfolg der Abbestellung) in dem
unter "Listenformat" beschriebenem Format (s.u.)
Hinweis: das Ergebnisprotokoll enthält genau
diejenigen Bretter, die in der Abbestellung
aufgezählt wurden
-----------------------------------------------------------------------------
HELP
Funktion: dient der Anforderung eines kompletten Hilfstexts
Nachrichtenkörper: wird ignoriert
Antwort: ein für menschliche Rezipienten gedachter Klartext,
der alle Informationen über den eingesetzten Maps
enthält.
-----------------------------------------------------------------------------
LIST
Funktion: dient der Anforderung einer Liste von verfügbaren
Brettern
Nachrichtenkörper: wird ignoriert
Antwort: enthält eine Liste mit den für die Anfragende
verfügbaren Bretter in dem unter "Listenformat"
beschriebenen Format (s.u.)
3.5.1.2. Listenformat
Das für verschiedene Fälle genutzte Listenformat wird hier als
Grammatik in BNF formuliert ('|' bedeutet "oder" und trennt
Alternativen voneinander; 'e' heißt Epsilon und steht für "nichts"; zu
starten ist bei "Zeilen"). Zu beachten ist, daß es keine
Längenbeschränkung gibt, insbesondere auch nicht für die Länge einer
Zeile.
Zeilen = Zeile Zeilen | e Zeile = Steuerzeichen <Leer> <Brett> Brettbeschreibung Zeilenende Steuerzeichen = '+' | '-' | ' ' | '!' | ';' Brettbeschreibung = [Whitespace]+ <Beschreibung> | e Zeilenende = <CR><LF> Whitespace = <TAB> | <Leer>
<Brett> ist der Name des gewünschten Bretts in Großbuchstaben
(!), beginnend mit einem Slash
<Beschreibung> ist eine beliebige Beschreibung des Bretts, kann also
seinerseits Whitespaces (auch am Ende) enthalten und
geht bis zum abschließenden Zeilenende
<Leer> steht für das Leerzeichen (ASCII 32)
<CR> steht für Carriage Return (ASCII 13)
<LF> steht für Linefeed (ASCII 10)
<TAB> steht für den Hard Tab Stop (ASCII 9)
[Whitespace]+ bedeutet mindestens ein Whitespace
Die Steuerzeichen haben folgende Bedeutung:
'+' Brett ist bestellt bzw. bestellbar '-' Brett ist nicht bestellbar ' ' Brett ist nicht bestellt aber bestellbar '!' Brett ist bestellt und nicht abbestellbar (Pflichtbrett) ';' Zeile ist ein Kommentar
Eine Beispielantwort auf eine ADD-Nachricht, die obiger Grammatik folgt:
; ZC-Maps Version 3.1
;
; Antwort von <bingo.comlink.de> auf Sendung
; vom 11.11.99
;
+ /TESTNETZ/BEISPIEL1 Dies ist ein Kommentar
+ /Testnetz/BEISPIEL2 Kommentare sind
- /Forbiddennet/Group durch beliebig
- /Schubi/DU viele Whitespaces abgetrennt
Eine Beispielantwort auf eine DEL-Nachricht:
; ZC-Maps Version 3.1
; SuperMapsio 3 (c)SEPROductions
! /LOKAL/WICHTIG
/LOKAL/NICHT/SO/WICHTIG
/LOKAL/AUCH/NICHT/SO/WICHTIG
/LOKAL/ABBESTELLT
! /Z-NETZ/WICHTIG
/T-NETZ/SEX
; Und tschüß
Eine Beispielantwort auf eine LIST-Nachricht:
; ZC-Maps Version 3.1
+ /Bestelltes/Brett
/Bestellbares/Nicht/bestelltes/Brett
! /Bestelltest/Nicht/Abbestellbares/Brett
; Kommentar
/Bestellbares/Brett mit Kommentar
3.5.1.3. Optionale Befehle
Idealerweise sollte eine Maps-Implementation auch alle folgenden Befehle zur Verfügung stellen. [D3.1Z] will einen Maps erst dann "ZConnect-kompatibel" nennen, wenn dies geschehen ist, nimmt aber selber die Befehle ORDER-PM und FILES aus. Dazu mehr im nächsten Abschnitt "Kritik und Vorschläge".
-----------------------------------------------------------------------------
FILES
Funktion: dient der Bestellung beliebig vieler Dateien
Nachrichtenkörper: enthält zeilenweise die Namen der Dateien, die
bestellt werden sollen. Optional kann, durch
mindestens ein Whitespace abgetrennt, ein Paßwort
(Groß-/Kleinschreibung ist nicht beachten)
angegeben werden. Statt eines konkreten Dateinamens
kann auch ein sogenanntes "Magic" angegeben werden.
Folgende Magics sind definiert:
HELP Hilfstext zur Bedienung des Fileservers
ALLFILES Liste aller verfügbaren Dateien (auf CD +
anderen Datenträgern)
CDFILES Liste aller verfügbaren Dateien, die nur
auf CD vorhanden sind
FILES Liste aller verfügbaren Dateien, die auf
anderen Datenträgern vorhanden sind
NEWFILES Liste aller "neuen" Dateien
Antwort: Der Betreff der Antwort ist hier um den Dateinamen
erweitert, also "Your Files: <Dateiname>". Dies
impliziert, daß pro versandter Datei genau eine
Binärnachricht zu erzeugen ist. Für jede nicht
bediente Anforderung ist eine Nachricht mit dem
Betreff "Your Files: Failed <Dateiname>" zu
erzeugen.
Das Format der per Magic angeforderten Listen wird
nicht spezifiziert, es wird aber vorgeschlagen
folgenden Zeilenaufbau zu wählen:
Dateiname.Extension Größe Datum Uhrzeit Beschreibung
Es ist möglich, ein Protokoll zusammen mit der oder
den Binärnachricht(en) zu verschicken. Dieses
Protokoll wird immer als Kommentar (vgl.
KOM-Headerinformation) vorangestellt; und zwar
entweder genau einer der Binärnachrichten oder
genau einer extra verschickten Nachricht ohne
Inhalt (Informationen nur als Kommentar!) mit dem
Betreff "Your Files: Costs". Das vorgeschlagene
Format des Protokolls ist am besten in Form eines
Beipiels zu beschreiben:
ZC-MAPS Version 3.1
Order of <Userin>
Ordered <Dateibereich> <Dateiname> (x bytes) (x.x <Währung>).
...
Found x files (x bytes).
Sent x files (x bytes).
Denied x files (x bytes).
Total cost for this order: x.x <Währung>.
Die erste Zeile dient dabei der Kennung des
Maps-Standards und ist fest vorgeschrieben.
Copyrightmeldungen der eigenen Implementierung
können als Kommentare eingefügt werden, die durch
ein Semikolon an der ersten Position in der Zeile
gekennzeichnet werden.
Die zweite Zeile ist vielleicht auf
MultiuserInnensystemen sinnvoll. Die <Userin>
sollte daher mit deren Mailadresse angegeben
werden. Die dritte bis n-te Zeile zählt die
bearbeiteten Anforderungen auf, die positiv, also
mit Zusendung der Datei beschieden wurden; die
Angaben von Kosten und Nachrichtengrößen können in
diesen Zeilen von hinten nach vorne weggelassen
werden (also nur Längenangabe oder gar keine Angabe
möglich).
In den letzten vier Zeilen, die wiederum von hinten
nach vorne weggelassen werden können, können
statistische Angaben untegebracht werden.
Die Währungskennzeichen sind nicht spezifiziert,
sollten aber die in den zu den Währung gehörigen
Ländern üblichen Abkürzungen darstellen. Der
fragwürdige Sinn des Vorschreibens der Form des
Protokolls ist, eine automatische Auswertung (z.B.
Prüfung) zu ermöglichen.
Hinweis: Dieser Befehl wird von [D3.1Z] mit der Begründung
abgelehnt, daß er nicht nach ZConnect passe, weil
Fileserver über die Onlinephase realisiert werden
können. Dieser Einwand ist nur in dem Maße richtig,
wie er für den gesamten ZConnect-Maps gilt. Hierzu
mehr im Abschnitt "Kritik und Vorschläge" in diesem
Kapitel. Im übrigen ist FILES vom Gremium
beschlossen worden und hat somit Gültigkeit
-----------------------------------------------------------------------------
HOLD ON bzw HOLD OFF
Funktion: stellt eine Art "Urlaubsfunktion" dar. Mit diesem
Befehl bestellt die Anwenderin alle Bretter ab
(HOLD ON), kann aber z.B. Wochen später wieder mit
einer einzigen Anweisung an Maps (HOLD OFF) genau
die Bretter bestellen, die zum Zeitpunkt der
Abbestellung bestellt waren, da das System sich
diese merkt.
Nachrichtenkörper: wird ignoriert
Antwort: hat einen leeren Nachrichtenkörper
-----------------------------------------------------------------------------
INDEX
Funktion: dient der Anforderung eines
Brettinhaltsverzeichnisses.
Nachrichtenkörper: enthält pro Zeile einen Brettnamen
(Groß-/Kleinschreibung wird nicht beachtet),
beginnend mit einem Slash. Zeilen ohne Slash an der
ersten Position werden ignoriert.
Antwort: enthält im Nachrichtenkörper die ZConnect-Header
aller Nachrichten in den in der Anfrage angegebenen
Brettern (sofern zulässig, also z.B. Bretter nicht
gesperrt sind). Diese Header werden jeweils durch
eine Leerzeile voneinander getrennt. Genauer gesagt
wird gefordert, daß Header durch eine Leerzeile
abgeschlossen sein müssen - das bedeutet
einerseits, daß beliebig viele Leerzeilen zwischen
zwei Headern stehen können und andererseits, daß
auch hinter dem letzte Header eine Leerzeile
eingefügt werden muß. Die Header werden nicht ganz
unbehandelt belassen:
1. Alle EMPs bis auf den angefragten (also den
denjenigen Brettnamen enthaltenden EMP, der
angefragt wurde) werden gelöscht
2. Optional können ROT, F-*, G-*, U-*, X-*, Z-*,
ZNETZ-*, GATE, MAILER und nicht definierte
Headerinformationen gelöscht werden
-----------------------------------------------------------------------------
ORDER
Funktion: dient der Anforderung von Nachrichten aus Brettern,
die beim angeschriebenen System archiviert werden.
Nachrichtenkörper: enthält zeilenweise eine Beschreibung der
gewünschten Nachrichten. Die Beschreibung folgt
folgender Syntax:
<Brettname><Whitespace><Message-ID><Zeilenumbruch>
Der Brettname muß wie immer mit einem Slash
beginnen und wird ohne Berücksichtigung der
Groß-/Kleinschreibung behandelt. Als Whitespace,
welches genau einmal auftritt, ist ASCII 9 (TAB)
oder 32 (Leerzeichen) zulässig. Bei der Message-ID
wird für den Teil vor dem "@" die
Groß-/Kleinschreibung beachtet, für den Teil
dahinter hingegen nicht (vgl. Headerinformation
MID).
Antwort: ist eine Binärnachricht und enthält einen
ZConnect-Puffer mit den angeforderten Nachrichten.
Es dürfen auch mehrere Binärnachrichten erzeugt
werden, eine einzelne bestellte Nachricht sollte
dann aber nicht über mehrere Antwortnachrichten
verteilt sein. [D3.1Z] möchte dies sogar verboten
wissen.
Genau einer der Antwortnachrichten kann ein
Protokoll als Kommentar vorangestellt werden (vgl.
KOM-Headerinformation). Das vorgeschlagene Format
ist beinahe identisch zu jenem beim Maps-Befehl
FILES beschriebenen: Lediglich die "Ordered"-Zeile
folgt nun folgender, veränderter Syntax:
Ordered <Brett> <Message-ID> (x bytes) (x.x <Währung>)
-----------------------------------------------------------------------------
ORDER-PM
Funktion: entspricht jener von ORDER, unterscheidet sich nur
im Format der Antwort.
Nachrichtenkörper: wie bei ORDER beschrieben
Antwort: besteht aus mehreren Textnachrichten. Die
angeforderten Nachrichten werden einzeln als
private Nachricht an die Anfordernde verschickt.
Dabei wird folgender Minimalheader vorgeschlagen
wird:
EMP: <Anfordernde>
OEM: <Brettname, wie in der Bestellung angegeben>
ABS: MAPS@<System>
OAB: <Originalabsenderin>
STAT: CTL
MID: <neu zu generieren>@<System>
Genau betrachtet wäre diese Headerspezifikation ein
weiterer Fall des automatischen Weiterleitens, bei
dem die vorgeschlagene Headerinformation STAT: CTL
allerdings etwas fehl am Platze anmutet. Da es sich
um einen Vorschlag handelt, wird an dieser Stelle
vorgeschlagen, STAT: CTL nicht einzusetzen. Die
vermutlich geplante Anwendung, der anfordernden
Software die automatische Behandlung der Antworten
zu ermöglichen, erübrigt sich, da ORDER-PM in
seiner Gesamtheit nicht für ZConnectsysteme
konzipiert ist.
Das bei ORDER beschriebene Protokolllayout gilt
auch für ORDER-PM, wird hier aber nicht als
Kommentar einer Antwortnachricht vorangestellt,
sondern als einzelne Textnachricht versandt. Eine
Abweichung in der Beschreibung des Protokolls bei
[D3.1M] weist darauf hin, daß daran gedacht gewesen
sein könnte, pro ORDER-PM Befehl nur die Bestellung
genau einer Nachricht zu ermöglichen. Dies mag eine
vorsichtige, strenge Implementierung
berücksichtigen, sinnvoll erscheint es hingegen
nicht.
Hinweis: Dieser Befehl wird von [D3.1Z] mit der Begründung
abgelehnt, er unterscheide sich "nur durch
verstümmelte Header von ORDER". Das Format des
Headers ist beim ZConnect-Maps jedoch ausdrücklich
nur als Vorschlag definiert.
Tatsächlich bricht ORDER-PM mit der Absicht von
ZConnect-Maps, maschinenlesbare Antworten zu
produzieren. Dies tut HELP allerdings auch. Die
genannte Anwendung des Requests über das Netz von
AnwenderInnen, die das ZConnect-Datenformat nicht
verarbeiten können, ist jedoch Grund genug, die
Spezifikation von ORDER-PM in diese Aufzählung
aufzunehmen. Zudem ist der Befehl vom Gremium
beschlossen worden.
-----------------------------------------------------------------------------
3.5.2. Kritik und Vorschläge
3.5.2.1. Maps und die vergessene Onlinephase
Die (Ab-)Bestellung von Brettern über Mails an eine automatische Userin ist hinsichtlich Brettbestellungen beim eigenen Server ein Relikt aus Zeiten, als ohne Protokolländerungen die neu erkannte Notwendigkeit der Bestimmung bezogener Bretter durch die AnwenderInnen selbst (also ohne Eingriff der SystembetreiberInnen) eingeführt werden sollte. In Store-And-Forward verwendenden Netzen ist dies für die Kommunikation mit entfernten Systemen nachwievor sinnvoll.
Bei Direktverbindungen, wie sie zwischen zwei direkt miteinander z.B. per Telefonleitung telefonieren und hierbei die ZConnect-Onlinephase einsetzen, wäre hingegen eine Integration der meisten Maps-Befehler in diese Onlinephase sinnvoll. ADD- und DEL-Listen könnten online übertragen und beantwortet werden (ggf. im Nach-Logoff - vgl. EXECUTE: L). LIST und HELP sind gar problemlos durch Definition neuer Magics für den FILEREQ-Header integrierbar. Auch die Online-Verwendung von ORDER und INDEX ist gut denkbar.
ADD und DEL als Maps-Kommandos haben jedoch nicht nur in Protokollvarianten wie Janus ihre Daseinsberechtigung. Es ist durchaus denkbar, daß ein System seinen UserInnen erlaubt, für das System Bretter beim Server zu bestellen (wobei das Serversystem diese Erlaubnis technisch umsetzen können muß, was derzeit nicht gegeben sein dürfte - s.u.). Jedoch wäre es dem ZConnect-Datenformat und dem Anliegen des ZConnect-Maps, UserInnen weitgehend von der technischen Seite der Maps-Kommunikation zu entlasten, angemessen, wenn Nachrichten von und an Maps regelmäßig das STAT: CTL Flag erhalten würden. Am Fehlen dieses Flags wären dann auch Anfragen/Antworten alter, nicht ZConnect-kompatibler Maps-Implementationen zu erkennen.
Unabhängig von einer möglichen Einführung von ORDER und INDEX in die Onlinephase sind diese und ORDER-PM (welches online unsinnig ist, da das anrufende System mit Sicherheit ZConnect-fähig ist) auch als Maps-Kommandos sinnvoll. Mit ihnen kann über Systemgrenzen hinweg z.B. auf die Daten von Archivsystemen zugegriffen werden.
Der HOLD Befehl wird immer nur gegenüber dem direkt servenden System eingesetzt werden. Für Janus-Protokollvarianten ist dieser Befehl daher sinnvoll, bei einem kompletten ZConnect gehört er jedoch eindeutig in die Onlinephase.
3.5.2.2. Maps aus Sicht des angeschriebenen Systems
Die herkömmliche Sichtweise, nur bestimmten UserInnen fremder Systeme die "Mapsberechtigung" einzeln (manuell oder per Onlinephase) zuzuteilen, muß überdacht werden, da der ZConnect-Maps systemübergreifend konzipiert ist. Denkbar wäre, daß ein Mailboxsystem seine UserInnen berechtigt, bei einem Serversystem beliebig Bretter für das Mailboxsystem zu bestellen. Die Einstellungsmöglichkeiten von Systemen müssen also sehr erweitert werden. So müssen bei einigen Maps-Befehlen Anfragen von beliebigen Absenderinnen beantwortet (z.B. ORDER) werden und bei anderen (z.B. ADD) möglicherweise nur diejenigen, die von bestimmten, autorisierten Systemen aus abgesandt wurden.
3.5.2.3. Schwierigkeiten bei der Umsetzung des Gedankens, Maps transparent zu gestalten
Die Antwort auf den HELP-Befehl kann nur insofern durch z.B. ein Pointprogramm verarbeitet werden, als der empfangene Hilfstext nicht als normale Mail sondern als Text mit einer bestimmten Zugehörigkeit bewertet und z.B. nicht in das Postfach der Empfängerin einsortiert sondern gesondert gespeichert wird. Für eine sinnvolle und zugleich mächtige Implementierung von ZConnect-Maps fehlt jedoch eine Funktion, die es einem UserInneninterface erlaubt, den konkreten Befehlsumfang eines Maps abzufragen.
# Ein solches Interface könnte natürlich testweise alle theoretisch # möglichen Maps-Befehle abschicken und die Antworten auswerten. Dies # ist aber wohl als unschön abzulehnen. Daher wird an dieser Stelle # ein weiterer Maps-Pflichtbefehl vorgeschlagen, über den das Gremium # abstimmen sollte:
FEATURES
Funktion: dient der Feststellung des Befehlsumfangs der mit
diesem Befehl konfrontierten Maps-Implementation.
Nachrichtenkörper: wird ignoriert
Antwort: enthält zeilenweise ohne Leerzeilen eine Aufzählung
der dem Maps bekannten Befehle. Es wird pro Zeile
nur ein Befehl angegeben. Groß-/Kleinschreibung ist
zu ignorieren. Kommentarzeilen sind möglich; sie
werden durch ein Semikolon in der ersten Spalte
gekennzeichnet. Es gibt keine
Zeilenlängenbegrenzung, Whitespaces sind verboten.
Zeilen werden durch das übliche CR/LF (ASCII 13/10)
voneinander getrennt oder enden mir dem Dateiende.
Wenn die aufgelisteten Befehle den Namen einer der
ZConnect-Maps-Befehle tragen, so kann die
anfragende Applikation davon ausgehen, daß sich der
Befehl so verhält, wie der ZConnect-Maps-Standard
es festlegt.
Mit der Übertragung von unbekannten Befehlen muß
gerechnet werden, auch mit solchen, die aus
mehreren Wörtern bestehen - entsprechend der
Vorschrift, daß Whitespaces verboten sind, können
solche Befehlslisteneinträge als fehlerhafte Zeilen
ignoriert oder aufgrund besonderer Vereinbarung
ausgewertet werden. Ein Befehl wie
"LIST MY BRETTER" darf aber niemals als "LIST"
mißverstanden werden.
Hinweis: Die mögliche Übertragung einer Versionsnummer des
ZConnect-Maps' erscheint nicht unbedingt unnötig
(die zukünftige Bedeutung oder Antwortform eines
Befehls könnte sich mit neuen Maps-Spezifikationen
ändern). Jedoch ist der Transport bei den derzeit
bekannten Befehlen mal als Kommentar (vgl. LIST),
mal als eigenständige Zeile (vgl. ORDER) definiert
oder besser: undefiniert geblieben.
Für FEATURES wird vorgeschlagen, die erste Zeile
der Feature-List grundsätzlich der Versionsangabe
vorzubehalten. Das Format sollte hierbei dem des
Antwortprotokolls beim FILES-Befehl folgen.
4. ERGÄNZENDE INFORMATIONEN
Dieser Teil der Dokumentation besteht bis auf wenige Ausnahmen aus komplett anzuheftenden Fremdtexten. Diese Vervollständigung soll nicht Bestandteil der Aufgabenstellung sein, unter den einzelnen Überschriften ist aber angegeben, welche Informationen gemeint sind, und, sofern bekannt, wo diese erhältlich sind.
Bei einigen Fremdtexte, z.B. RFCs, ist eine Anheftung der Originaltexte sinnfrei, da diese frei erhältlich sind. Bei besonders wichtigen Texten wäre aber eine deutschsprachige Übersetzung durchaus angebracht.
4.1. Datenschutzbestimmungen
Datenschutzbestimmungen sind im Globalen Dorf eine sehr voluminöse Angelegenheit. In der Bundesrepublik sind sie zudem zum größten Teil Ländersache. Die jeweils gültigen Datenschutzgesetze können bei den Landesdatenschutzbeauftragten zumeist kostenlos angefordert werden.
An dieser Stelle soll eine grundlegende Zusammenfassung der wichtigsten Grundregeln erfolgen, also insbesondere auf die zeitlich begrenzte Zulässigkeit von Logdateien und Protokollen über die UserInnenaktivität hingewiesen werden. Dazu gehört hierher eine Übersicht über die Anschriften der Landesdatenschutzbeauftragten, welche ihrerseits bei den Einzelnen Beauftragten erhältlich ist.
4.2. Fremdformate
Es ist nicht Aufgabe einer reinen ZConnect-Dokumentation alle Konkurrenzprotokolle aufzulisten und zu beschreiben. Beschreibungen von Fremdformaten sind jedoch insbesondere da hilfreich, wo klare Bezugspunkte zu ZConnect bestehen (z.B. Z3.8 als Vorgängerprotokoll oder die RFC-Suite als Weltstandard).
4.2.1. RFC
Aus dem RFC-Bereich sind insbesondere die Nummern 822 (Mail), 1036 (News), 1521 (MIME), 1522 (MIME Part 2) und 1563 (text/enriched) interessant.
4.2.2. Z 3.8
Das Z3.8 Netcallverfahren besteht wie ZConnect aus einer Login-/ Datentauschphase und einem Datenformat. Letzteres hat heute keinerlei Bedeutung mehr. An dieser Stelle wird daher nur auf das "Hitchhiker's Guide to the /Z-NETZ" ([Hitchhiker]) hingewiesen. Das Loginverfahren von Z3.8 wird bei den sehr weit verbreiteten JANUS-Protokollvarianten verwendet und ist daher im Abschnitt "Janus und verwandte Protokollvarianten" ausführlich beschrieben.
4.2.3. Fido
Die Regelungen für Fido-Datenaustausch und -format sind umfangreich und sollten an dieser Stelle nur soweit grob beschrieben werden, daß die "F-"-Headerzeilen ZConnects dadurch illustriert werden.
4.3. MIME
Nach Diskussion und Entscheidungsfindung durch das Gremium ist es von großer Wichtigkeit, MIME ausführlich zu beschreiben. Anspruch sollte dabei sein, die Lektüre der einschlägigen RFC-Regelungen überflüssig zu machen, um den "einfacheren" Charakter von ZConnect aufrecht zu erhalten.
4.4. Einige softwaretechnische Vorschläge
Die Lösung einiger Standardprobleme bei der Implementierung von ZConnect kann die Datensicherheit im Netz beeinflussen. Insbesondere schnelle, fehlerfreie Dupecheckalgorithmen können helfen, eine "beliebte" Fehlerquelle auszuschließen.
4.4.1. Hashverfahren für Rekursionscheck
An dieser Stelle soll ein auf einem, Nicht-InformatikerInnen meistens unbekannten, Hashverfahren aufbauender Check auf doppelte Message-IDs zumindest im Pseudocode beschrieben werden. Evtl. kann dabei aufgezeigt werden, wie die Forderung von "90 Tagen Aufbewahrungsfrist" für Message-IDs mit schnellem Check kombiniert werden kann. Da einige ProgrammiererInnen bereits dazu übergehen, nicht mehr die komplette Message-ID zu prüfen, sondern aus "Effizienzgründen" bereits ähnliche IDs, die z.B. dieselbe CRC-Summe ergeben, als Dupe zu löschen, scheint ein entsprechender Verfahrensvorschlag geboten.
5. STAND DER DINGE
An dieser Stelle sollte immer der aktuelle Stand der Dokumentation und unmittelbar bevorstehende Entscheidungen des Gremiums erwähnt werden.
ZC 3.1 ist mit dem Ende der fünften Gremiumswahl am 5.3. geschlossen worden. Zur CeBIT'95 erschien daraufhin [D3.1Z], welches in der Folge zu Irritationen wegen Widersprüchen zwischen Gremiumsbeschlüssen und [D3.1Z] geführt hat. Es herrscht Einigkeit und Wille, eine grundlegend neue Dokumenation zu schaffen. Dieser Text soll dazu die Grundlage stellen.
In der Diskussion ist, wie die Entwicklung von ZConnect weiter verlaufen soll. Dabei geht u.a. um die Frage, ob ZConnect in Zukunft noch ZConnect heißen soll, und wie die Bindung der Zerberus GmbH zu ZConnect vollständig getrennt werden kann, um das Kompetenzwirrwarr zu entwirren und gleichzeitig Copyright-Fragen eindeutig zu beantworten.
ANHÄNGE
A) Literaturverzeichnis
Verwendete Quellen
[PM1] Mündliche, persönliche Mitteilung von Felix Heine
(Zerberus GmbH) vom 25.2.1995
[PM2] Persönliche Mitteilung von Peter Mandrella
(Crosspoint-Autor) vom 16.5.1995
[PM3] Persönliche Mitteilung von Holger Lembke
(!!MessageBase-Autor) vom 25.5.1995
[D3.0] Zerberus GmbH: "ZConnect, das Datenaustauschformat für
Mailbox-Netze, Version 3.0", Verlag Art d'Ameublement,
Bielefeld 1993
[D3.1M] Änderungssammlung März bis Dezember 1993, z.B. als
Nachricht von hd@wf-hh.sh.sub.de vom 23.02.1995,
Message-ID 5gPrhK4WbB@p-alf.wf-hh.sh.sub.de
[D3.1P] ZConnect-Proposal, zusammengestellt von Martin Husemann,
z.B. als Nachricht von h.fricke@laguna.han.de vom
15.2.1995, Message-ID:
5FuuqDhpZQB@ncbmail-development-labs.laguna.han.de
[D3.1Z] Zerberus GmbH: "ZConnect. Datenaustauschformat für
Mailboxnetzwerke Version 3.1", Verlag Art d'Ameublement,
Bielefeld 1994
[B1] Nachricht von H. Fricke (H.Fricke@laguna.zer) vom
5.12.1992, Message-ID: 4rGKpeGhwz@LAGUNA
[B2] Nachricht von martin%bi-link.owl.de@UUCP.ZER (Martin
Husemann) vom 30.7.1993 in /T-NETZ/SUPPORT/ZCONNECT,
Message-ID: CB01q1.744@bi-link.owl.de
[B3] Nachricht von Martin Husemann in
/T-NETZ/SUPPORT/ZCONNECT, Message-ID:
idC8LJqA.DB9@bi-link.owl.de
[B4] Nachrichten in /T-NETZ/ZCONNECT/DISKUSSION: (zB. von
Packbart@people-s.people.sub.org, Message-ID:
5KO_df2ufRB@point47.people-s.people.sub.org und
holger_lembke@laguna.han.de, Message-ID:
r0mrmjb8je33h6ob877SKgxholger_lembke@holger.laguna.han.de
[B5] Nachricht von GATEKOO@heather.hanse.de vom 4.7.1994,
Message-ID: 17.10937@heather.hanse.de
[B6] Nachricht von hd@wf-hh.sh.sub.de in
/T-NETZ/ZCONNECT/MELDUNGEN vom 23.2.1995, Message-ID:
5g0d4-pW3bB@p-alf.wf-hh.sh.sub.de
[B7] Nachricht von holger_lembke@laguna.han.de (Holger Lembke)
vom 1.6.1995, Message-ID:
58cp7w8eqf33qey8e3fsyhsholger_lembke@holger.laguna.han.de
[B8] Nachricht von hd@wf-hh.sh.sub.de vom 14.3.1995,
Message-ID: 5hqnSF0_WbB@p-alf.wf-hh.sh.sub.de
[B9] Nachricht von hd@wf-hh.shnet.org vom 1.10.1995,
Message-ID: 5v1oc-Y$WbB@p-alf.wf-hh.shnet.org
[Hitchhiker] Hitchhikers Guide to the /Z-NETZ, z.B. erhältlich in der
Crosspoint-Supportbox (Telefonnummer 06241-592184)
[JanusPlus] Nachricht von h.fricke@laguna.han.de vom 1.6.1995,
Message-ID:
5n0MZ0D_ZQB@ncbmail-developement-labs.laguna.han.de
[Netikette] Netikette, in der aktuellen Fassung regelmäßig im Brett
/Z-NETZ/WICHTIG als Nachricht von KERSTIN@TTB.aworld.de
zu finden
[Mitglieder] Liste der Gremiumsmitglieder, in der aktuellen Fassung
regelmäßig im Brett /T-NETZ/ZCONNECT/MELDUNGEN zu finden,
z.B. als Nachricht von hd@wf-hh.shnet.org vom 15.6.1995,
Message-ID: 5nrR_6T_WbB@p-alf.wf-hh.shnet.org
[Netzrecht] Günther Freiherr von Gravenreuth: "Netze in den Maschen
der Gesetze", Compulaw-Verlag, München 1993, S. 10ff
[RFC822] RFC822 definiert das Aussehen und die Behandlung von
Internet-Messages, geschrieben von David H. Crocker, 13.
August 1982
[RFC1521] RFC1521 definiert die Multipurpose Internet Mail
Extension, geschrieben von N.Borenstein et al, September
1993
[RFC1563] RFC1563 definiert den MIME-Content-Type text/enriched,
geschrieben von N.Borenstein et al, Januar 1994
[Wahl1] Ergebnis der ersten Wahl des Gremiums zu ZConnect, im
Brett /T-NETZ/ZCONNECT/MELDUNGEN zu finden, z.B. als
Nachricht von hd@wf-hh.shnet.org vom 7.6.1995,
Message-ID: 5nPL4bJ_WbB@p-alf.wf-hh.shnet.org
[Wahl2] Siehe [Wahl1], Message-ID:
5nPL5f0_WbB@p-alf.wf-hh.shnet.org
[Wahl3] Siehe [Wahl1], Message-ID:
5nPL6EMKWbB@p-alf.wf-hh.shnet.org
[Wahl4] Siehe [Wahl1], Message-ID:
5nPL6i14WbB@p-alf.wf-hh.shnet.org
[Wahl5] Siehe [Wahl1], Message-ID:
5nPL7gq4WbB@p-alf.wf-hh.shnet.org und zusätzlich das
Addendum zur fünften Wahl, die Nachricht mit der
Message-ID:5vlod264WbB@ü-alf.wf-hh.shnet.org
Empfohlene Literatur
[DES] A.K. Dewdney: "Computer-Kurzweil", in: Spektrum der
Wissenschaft, Januar 1989, S. 6 bis 10
[RFC1036] Standard for interchange of USENET messages, geschrieben
von M.R. Horton und R.Adams, Dezember 1987
[RFC1522] MIME (Multipurpose Internet Mail Extensions) Part Two:
Message Header Extensions for Non-ASCII Text,
geschrieben von K. Moore, September 1993
B) Glossar
Ein Glossar soll die verwendeten unausweichlichen Fachtermini erläutern. Darüberhinaus sollen auch Begriffe, die in der Dokumentation selber keine Verwendung finden, hier untergebracht werden. Aktuell werden nur diejenigen Begriffe hier erläutert, die ZConnect-spezifisch sind oder häufig verwendet werden.
Brett Siehe GABELN
Control-Nachricht Nachricht eines bestimmten Formats, die z.B. für
das Löschen von Nachrichten, das Einrichten eines
Bretts o.ä. sorgt
Crossposting (Physikalisch) eine Nachricht mit mehreren
EmpfängerInnenangaben
Dupe Doppelt vorhandene Nachricht
Dupecheck Testen auf doppelt vorhandene Nachrichten (bei
ZConnect anhand der Message-ID). Gefundene Dupes
werden üblicherweise gelöscht
GABELN Gruppen, Areas, Bretter, Echos, Listen,
Newsgroups - Kunstbegriff, welcher die in
verschiedenen Netzzusammenhängen gebräuchlichen
Bezeichnungen für offentliche Nachrichtenforen
zusammenfaßt
kreuzvernetzt /Z-NETZ/FORUM/NETZWESEN und de.soc.netzwesen sind
kreuzvernetzt. Das heißt, daß die in eines dieser
->Bretter geschickte Nachricht sowohl im
deutschsprachigen Usenet als auch im /Z-Netz
verteilt wird, ohne als ->Crossposting verschickt
werden zu müssen. Wird in kreuzvernetzte Bretter
ein Crossposting verschickt, kommt es zu ->Nopes
Mail Begriff aus der ->RFC-Welt für eine private
Nachricht. Synonym: PM (private Mail)
Mailbox Per Modem anrufbares System, welches
üblicherweise für mehrere ->Points und/oder
->OnlineuserInnen den Netzanschluß gewährleistet,
indem es Nachrichten für sie entgegennimmt bzw.
verteilt
News Begriff aus der ->RFC-Welt für eine öffentliche
Nachricht. Synonym: Brettnachricht
Nope Verkürzt gesagt das Gegenstück zu einem ->Dupe,
also eine gar nicht vorhandene Nachricht. Ein
Nope hebt sich von einer normalen, nicht
vorhandenen Nachricht dadurch ab, daß er nicht
als Nope gedacht war :-). Er entsteht, wenn eine
Nachricht irrtümlich als Dupe entsorgt wird. Dies
kann passieren, wenn eine Nachricht auf mehreren
Wegen gleichzeitig in ein ->kreuzvernetztes
->Brett geschickt wird. Wird also z.B. eine
Nachricht nach /Z-NETZ/FORUM/NETZWESEN und
de.soc.netzwesen geschickt, wobei die Message-ID
gleich ist (z.B. durch ein fehlerhaftes Gateway),
entsteht ein Nope, weil auf Systemen die beide
Bretter führen, die später ankommende Variante
als Dupe gelöscht wird. Dann bekommen z.B. die
LeserInnen von de.soc.netzwesen die
Nope-Nachricht nicht zu Gesicht, während sie in
/Z-NETZ/FORUM/NETZWESEN vorhanden ist
OnlineuserIn UserIn, der/die in physikalischer Verbindung z.B.
zu einer Mailbox steht, etwa um Nachrichten zu lesen
Point UserIn, der/die nur kurz und periodisch zu einer
Mailbox Kontakt aufnimmt, um paketweise für
ihn/sie bestimmte Daten abzuholen und diese nach
Trennung der Verbindung zu verarbeiten (z.B.
Nachrichten zu lesen)
RFC Request For Comment, mit diesem Kürzel werden
Texte gekennzeichnet, die für die Verwendung im
Internet gedachte Festlegungen enthalten
C) ZC 3.1 Grammatik in BNF
Auch wenn eine Protokollspezifikation nicht kontextfrei und die Semantik nur schwer formal zu beschreiben ist, sollte zum Zwecke der Eindeutigkeit der Notation die Syntax ZConnects in Backus Naur Form notiert werden. Fleißarbeit.
D) Datenformatsübersicht
Die folgende, tabellarische Aufstellung gibt eine Übersicht über alle ZConnect-Headerinformationen. Die Spalte "Minimal-ZC" stellt den Versuch dar, diejenigen Headerinformationen zu kennzeichnen, die eine Implementation minimal auswerten/erzeugen können muß, um sich ZConnect-kompatibel nennen zu dürfen. Naturgemäß gehören alle Pflichtinformationen dazu, genauso naturgemäß reicht aber eine Unterstützung der Pflichtinformationen nicht aus, um ZConnect-Nachrichten korrekt handhaben zu können.
D) 1. Tabellarische Übersicht der Headerinformationen
Kennung | P | N | S | N | M |
| f | u | t | u | i |
| l | r | a | r | n |
| i | | b | | i | Legende:
| c | e | i | P | m |
| h | i | l | M | a | x = Ja
| t | n | | | l | - = Nein
| | m | | | - | E = Erzeugen
| | a | | | Z | A = Auswerten
| | l | | | C | * = Siehe Dokumentation
----------------------+---+---+---+---+---+ v = veraltet
ABS | x | x | - | - | x |
----------------------+---+---+---+---+---+
ANTWORT-AN | - | - | - | - | x |
----------------------+---+---+---+---+---+
BET | x | x | - | - | x |
----------------------+---+---+---+---+---+
BEZ | - | - | x | - | E |
----------------------+---+---+---+---+---+
CHARSET | - | x | - | - | A |
----------------------+---+---+---+---+---+
CONTROL: ADD | - | x | - | - | A |
----------------------+---+---+---+---+---+
CONTROL: CANCEL | - | x | - | - | A |
----------------------+---+---+---+---+---+
CONTROL: DEL | - | x | - | - | A |
----------------------+---+---+---+---+---+
CRYPT | - | x | - | x | - |
----------------------+---+---+---+---+---+
CRYPT-CONTENT-CHARSET | - | x | - | x | - |
----------------------+---+---+---+---+---+
CRYPT-CONTENT-KOM | - | x | - | x | - |
----------------------+---+---+---+---+---+
CRYPT-CONTENT-TYP | - | x | - | x | - |
----------------------+---+---+---+---+---+
DDA | - | x | - | - | - |
----------------------+---+---+---+---+---+
DISKUSSION-IN | - | - | - | - | A |
----------------------+---+---+---+---+---+
EB | - | - | - | x | - |
----------------------+---+---+---+---+---+
EDA | x | x | - | - | x |
----------------------+---+---+---+---+---+
EMP | x | - | - | - | x |
----------------------+---+---+---+---+---+
Kennung | P | N | S | N | M |
| f | u | t | u | i |
| l | r | a | r | n |
| i | | b | | i | Legende:
| c | e | i | P | m |
| h | i | l | M | a | x = Ja
| t | n | | | l | - = Nein
| | m | | | - | E = Erzeugen
| | a | | | Z | A = Auswerten
| | l | | | C | * = Siehe Dokumentation
----------------------+---+---+---+---+---+ v = veraltet
ERR | - | x | - | x | A |
----------------------+---+---+---+---+---+
ERSETZT | - | - | - | - | - |
----------------------+---+---+---+---+---+
FILE | - | x | - | - | - |
----------------------+---+---+---+---+---+
KOM | - | x | - | - | A |
----------------------+---+---+---+---+---+
KOP | - | - | - | - | - |
----------------------+---+---+---+---+---+
LANGUAGE | - | x | - | x | - |
----------------------+---+---+---+---+---+
LDA | - | x | - | - | - |
----------------------+---+---+---+---+---+
LEN | x | x | - | - | x |
----------------------+---+---+---+---+---+
MAILER | - | x | - | - | - |
----------------------+---+---+---+---+---+
MID | x | x | - | - | x |
----------------------+---+---+---+---+---+
MIME | - | x | - | x | - |
----------------------+---+---+---+---+---+
O-EDA | - | x | - | - | E |
----------------------+---+---+---+---+---+
O-ROT | - | x | - | - | E |
----------------------+---+---+---+---+---+
OAB | - | x | - | - | E |
----------------------+---+---+---+---+---+
OEM | - | - | - | - | E |
----------------------+---+---+---+---+---+
ORG | - | x | - | - | - |
----------------------+---+---+---+---+---+
PGP | - | x | - | x | - |
----------------------+---+---+---+---+---+
PGP-ID | - | x | - | - | - |
----------------------+---+---+---+---+---+
PGP-KEY-AVAIL | - | x | - | - | - |
----------------------+---+---+---+---+---+
PGP-KEY-COMPROMISE | - | x | - | * | - |
----------------------+---+---+---+---+---+
PGP-KEY-OWN | - | x | - | x | - |
----------------------+---+---+---+---+---+
PGP-PUBLIC-KEY | - | x | - | * | - |
----------------------+---+---+---+---+---+
PGP-SIG | - | x | - | - | - |
----------------------+---+---+---+---+---+
Kennung | P | N | S | N | M |
| f | u | t | u | i |
| l | r | a | r | n |
| i | | b | | i | Legende:
| c | e | i | P | m |
| h | i | l | M | a | x = Ja
| t | n | | | l | - = Nein
| | m | | | - | E = Erzeugen
| | a | | | Z | A = Auswerten
| | l | | | C | * = Siehe Dokumentation
----------------------+---+---+---+---+---+ v = veraltet
POST | - | x | - | - | - |
----------------------+---+---+---+---+---+
PUBLIC-KEY | v | v | v | v | v |
----------------------+---+---+---+---+---+
ROT | x | x | - | - | x |
----------------------+---+---+---+---+---+
SIGNED | - | x | - | - | - |
----------------------+---+---+---+---+---+
SPERRFRIST | - | x | - | - | * |
----------------------+---+---+---+---+---+
STAT: AUTO | - | x | - | - | - |
----------------------+---+---+---+---+---+
STAT: CTL | - | x | - | - | x |
----------------------+---+---+---+---+---+
STAT: DES | v | v | v | v | v |
----------------------+---+---+---+---+---+
STAT: EB | - | x | - | x | - |
----------------------+---+---+---+---+---+
STAT: NOCIPHER | - | x | - | x | * |
----------------------+---+---+---+---+---+
STAT: NOKOP | - | x | - | - | A |
----------------------+---+---+---+---+---+
STAT: PGP | v | v | v | v | v |
----------------------+---+---+---+---+---+
STAT: TRACE | - | x | - | x | E ---> falls TRACE empfangen
----------------------+---+---+---+---+---+
STICHWORT | - | - | - | - | - |
----------------------+---+---+---+---+---+
TELEFON | - | x | - | - | - |
----------------------+---+---+---+---+---+
TRACE | - | x | - | - | A |
----------------------+---+---+---+---+---+
TYP | x | x | - | * | x |
----------------------+---+---+---+---+---+
VER | - | x | - | x | - |
----------------------+---+---+---+---+---+
VIA | * | - | x | x | E |
----------------------+---+---+---+---+---+
WAB | - | x | - | - | x |
----------------------+---+---+---+---+---+
ZUSAMMENFASSUNG | - | x | - | - | - |
----------------------+---+---+---+---+---+
D) 2. Liste der Pflichtinformationen
ABS, BET, EDA, EMP, LEN, MID, ROT, TYP, VIA (vgl. Dokumentation)
D) 3. Liste der das Routing beeinflussenden Informationen
ABS.............. Hierhin sind ggf. Fehlermeldungen zu schicken
ANTWORT-AN....... Hierhin sind ggf. Fehlermeldungen zu schicken
CONTROL: CANCEL.. Hierauf ist ggf. mit Löschung zu reagieren
DISKUSSION-IN.... Hierhin muß ein Pointprogramm öffentliche Antworten
umleiten
EMP.............. Hierhin soll die Nachricht
ERR.............. Es handelt sich um eine ohne Rücksicht auf Verluste
zu routende Fehlermeldung
(LDA)............ Evtl. ist eine Nachricht nicht mehr zu routen, wenn
sie das LDA-Alter überschreitet
MID.............. Dupecheck
ROT.............. Rekursionscheck
(SPERRFRIST)..... Evtl. ist eine Nachricht nicht vor der SPERRFRIST
an Endsysteme zu routen
STAT: CTL........ Evtl. handelt es sich um eine auszuwertende
Nachricht (CONTROL: CANCEL)
STAT: NOKOP...... Bei Auspaltungen gemischtadressierter bzw. privater
Nachrichten zu beachten
TRACE............ Hierauf ist von Systemen eine Antwort zu generieren
WAB.............. Hierhin sind ggf. Fehlermeldungen zu schicken
E) Routing
Das Thema Routing ist sehr komplex. An dieser Stelle sollten Teile
von RFC822 (Abschnitt "address specification") und die komplette RFC
1711 ("Classification in eMail Routing"), möglichst in deutsche
Sprache übersetzt, eingebunden werden.
Wer immer diesen Anhang mit einem Text füllen möchte, ist dringend dazu aufgefordert, diesen bei der DOKUKOO vorzustellen.
F) Janus und verwandte Protokollvarianten
JANUS
Das Loginverfahren von Z3.8 hat Eingang in die JANUS-Protokollvariante von ZConnect gefunden. JANUS transportiert reines ZConnect-Datenformat, regelt Login und Pufferaustausch aber nicht per ZConnect-Onlinephase sondern nach im folgenden beschriebener Methode (vgl. [3.1P]). Die verwendeten Übertragungsprotokolle (ZModem o.ä.) und Packprogramme (ZIP o.ä.) müssen von den beteiligten Parteien zuvor mit einem menschlichen Protokoll vereinbart worden sein.
Die "Z3.8-Onlinephase" wird aus Sicht der Anruferin beschrieben, die Sicht der Angerufenen ergibt sich entsprechend:
0. Verbindung aufbauen
1a. Auf den String "Username:" warten
1b. mit dem String "JANUS" und anschließendem CR (ASCII 13) antworten
2a. auf den String "Systemname:" warten
2b. eigenen Systemnamen bzw. Pointnamen (nicht UserInnennamen!) senden
In [3.1P] wird empfohlen, die Reihenfolge von 1 und 2 beliebig zu erwarten. Groß- und Kleinschreibung sind zu beachten, der abschließende Doppelpunkt dient als hinreichende Unterscheidung zum vielleicht vor dem Login auftauchenden Text "Username" ohne Doppelpunkt.
3a. auf den String "Passwort:" oder "Password" warten
3b. mit dem Systempaßwort-String und abschließendem CR antworten
4. wenn nicht "Running ARC...." empfangen wird, entweder auflegen oder wieder bei 1a beginnen. Sollte das angerufene System "Netzzugriff verweigert" senden, ist auf jeden Fall aufzulegen
5. wenn nicht innerhalb einer voreingestellten Zeit (10 Minuten wird empfohlen) ein NAK (ASCII 21) oder ein ACK (ASCII 6) empfangen wird, dann auflegen. Andere empfangene Zeichen sind zu ignorieren. Auf ACK wird mit dem Fortfahren bei 5. reagiert, auf NAK mit dem Senden einer Seriennummer.
Diese Seriennummer besteht aus vier beliebigen Bytes plus einem für eine Prüfsumme. Auf diese Weise prüfen manche Produkte auf eventuelle Raubkopien (identische Seriennummer bei Senderin und Empfängerin). Software, die diesen Mechanismus nicht nutzen möchte, sollte fünf Nullen (ASCII 0) senden.
Es sollte nur eine begrenzte Zahl von NAKs akzeptiert werden (z.B. 10). Das Timeout kann ab dem ersten empfangenen NAK auf eine Minute oder weniger eingestellt werden. Zur Illustration als C++-Konstrukt beschrieben:
void online (void)
{
// ... diverser Code ...
BOOL bo_exit = false,
bo_ok = false;
word w_nakcount = 0;
while (bo_exit)
{
switch (LeseZeichen())
{
case ACK :
bo_ok = bo_exit = true;
break;
case NAK:
set_timeout(60);
w_nakcount++;
if (w_nakcount>10)
{
bo_exit = true;
break;
}
sende_seriennummer();
default:
}
}
if (!bo_ok)
{
// Auflegen, -räumen und solche Sachen
}
else
{
// Weiter bei 6.
}
}
6. Übertragungsprotokoll starten zum Senden der einen (!) Datei mit allen Daten, die gesendet werden sollen. Die zu sendende Datei heiß "CALLER" und wird mit einer DOS-üblichen Extension von DOS-üblichen Packprogrammen versehen, also z.B. ".ZIP" oder ".ARJ"
7. Wenn das verwendete Übertragungsprotokoll eine Init-Sequenz hat, also das Senden mit einer bestimmten Bytesequenz ankündigt, dann auf diese Sequenz warten (genauso ist die Empfängerin während Phase 5 der Übertragung vorgegangen), andernfalls direkt weiter bei 8.
8. Übertragungsprotokoll starten zum Empfangen der einen (!) Datei mit allen Daten, die die Angerufene zu übertragen hat. Die zu empfangende Datei heiß "CALLED" und ist mit einer DOS-üblichen Extension von DOS-üblichen Packprogrammen versehen, also z.B. ".ZIP" oder ".ARJ"
9. Verbindung trennen
10. Wenn irgendeine Phase dieses Austausches nicht ordnungsgemäß
durchgeführt werden konnte, ist der gesamte Netcall als
gescheitert zu betrachten. Insbesondere sind (evtl. erfolgreich)
gesendete Nachrichten beim nächsten Netcall erneut zu senden und
empfangene Daten komplett zu löschen. Dies gilt für Anruferin und
Angerufene gleichermaßen.
Die empfangenen bzw. gesendeten Pakete sind ZConnect-Puffer. D.h. daß nach dem Auspacken beliebig viele Dateien mit den bekannten Dateinamen (siehe Kapitel "Übertragene Dateien") einzusortieren sind.
JANUS+
JANUS+ ist als Reaktion auf die umständliche Onlinephase ZConnects entstanden. Es verbreitet sich immer mehr, seine Dokumentation ([JanusPlus]) sollte daher im Rahmen der ZConnect-Dokumentation aufgenommen werden. Das Gremium entscheidet derzeit über die Aufnahme des JanusPlus-Logins in den ZConnect-Standard.
G) Zeichensätze
Hier sollten alle Zeichensätze in Tabellenform aufgelistet werden, die im Rahmen von ZConnect relevant sind. Neben dem im Folgenden enthaltenen Standardzeichensatz sind dies vor allem (vgl. CHARSET) ISO1-9. Die IBM Codepages 437 und die internationale 850 sind von informativem Wert. Unicode als Zwei-Byte-Code ist sehr umfangreich und vermutlich nicht im Rahmen der ZConnect-Beschreibung dokumentierbar.
ZConnect Standardzeichensatz
In Textnachrichten sind folgende Zeichen erlaubt: 9 (<TAB>), 13 (<CR>), 10 (<LF>) sowie die folgenden Zeichen:
IBM ISO Zeichen IBM ISO Zeichen
32 32 80 80 P
33 33 ! 81 81 Q
34 34 " 82 82 R
35 35 # 83 83 S
36 36 $ 84 84 T
37 37 % 85 85 U
38 38 & 86 86 V
39 39 ' 87 87 W
40 40 ( 88 88 X
41 41 ) 89 89 Y
42 42 * 90 90 Z
43 43 + 91 91 [
44 44 , 92 92 \
45 45 - 93 93 ]
46 46 . 94 94 ^
47 47 / 95 95 _
48 48 0 96 96 `
49 49 1 97 97 a
50 50 2 98 98 b
51 51 3 99 99 c
52 52 4 100 100 d
53 53 5 101 101 e
54 54 6 102 102 f
55 55 7 103 103 g
56 56 8 104 104 h
57 57 9 105 105 i
58 58 : 106 106 j
59 59 ; 107 107 k
60 60 < 108 108 l
61 61 = 109 109 m
62 62 > 110 110 n
63 63 ? 111 111 o
64 64 @ 112 112 p
65 65 A 113 113 q
66 66 B 114 114 r
67 67 C 115 115 s
68 68 D 116 116 t
69 69 E 117 117 u
70 70 F 118 118 v
71 71 G 119 119 w
72 72 H 120 120 x
73 73 I 121 121 y
74 74 J 122 122 z
75 75 K 123 123 {
76 76 L 124 124 |
77 77 M 125 125 }
78 78 N 126 126 ~
79 79 O 127 127 &127;
128 199 € 183 192 +
129 252 ü 184 169 +
130 233 ‚ 189 162 +
131 226 ƒ 190 165 +
132 228 ä 198 227 +
133 224 … 199 195 |
134 229 † 207 164 -
135 231 ‡ 208 240 +
136 234 ˆ 209 208 -
137 235 ‰ 210 202 +
138 232 Š 211 203 +
139 239 ‹ 212 200 +
140 238 Π214 205 +
141 236 215 206 +
142 196 Ä 216 207 +
143 197 221 166 +
144 201 222 204 +
145 230 ‘ 224 211 à
146 198 ’ 225 223 ß
147 244 “ 226 212 â
148 246 ö 227 210 ã
149 242 • 228 245 ä
150 251 – 229 213 å
151 249 — 230 181 æ
152 255 ˜ 231 222 ç
153 214 Ö 232 254 è
154 220 Ü 233 218 é
155 248 › 234 219 ê
156 163 œ 235 217 ë
157 216 236 253 ì
160 225 237 221 í
161 237 ¡ 238 175 î
162 243 ¢ 239 180 ï
163 250 £ 240 173 ð
164 241 ¤ 241 177 ñ
165 209 ¥ 243 190 ó
166 170 ¦ 244 182 ô
167 186 § 245 167 õ
168 191 ¨ 246 247 ö
169 174 © 247 184 ÷
170 172 ª 248 176 ø
171 189 « 249 168 ù
172 188 ¬ 250 183 ú
173 161 251 185 û
174 171 ® 252 179 ü
175 187 ¯ 253 178 ý
181 193 +
182 194 |
Diese Zeichen werden gemäß dem IBM-PC Zeichensatz interpretiert. Das Zeichen mit dem Code 255 wird bei Konvertierungen in ein # Leerzeichen gewandelt. Das Zeichen mit dem Code 254 ist in der # ZConnect-Ausgangsdokumentation nicht erwähnt. Obige Tabelle zeigt in der Spalte "Zeichen" die gewünschte Darstellung auf dem Bildschirm, in der Spalte "ISO" den dafür nötigen Code im ISO-1-Zeichensatz und in der Spalte "IBM" den in Textnachrichten verwendeten Code. Nicht aufgeführte Codes sind verboten.
H) Zeitzonen
Zone W/S Diff. Name NT W -11:00 Nome Time AHST W -10:00 Alaska-Hawaii Standard Time YST W -9:00 Yukon Standard Time PST W -8:00 Pacific Standard Time MST W -7:00 Mountain Standard Time PDT S -7:00 Pacific Daylight Time CST W -6:00 Central Standard Time MDT S -6:00 Mountain Daylight Time EST W -5:00 Eastern Standard Time CDT S -5:00 Central Daylight Time AST W -4:00 Atlantic Standard Time EDT S -4:00 Eastern Daylight Time NST W -3:30 Newfoundland Standard Time GST W -3:00 Greenland Standard Time ADT S -3:00 Atlantic Daylight Time AT W -2:00 Azores Time WAT W -1:00 West Africa Time UT W +0:00 Universal Time Z W +0:00 Universal Time GMT W +0:00 Greenwich Mean Time BST S +1:00 British Summer Time CET W +1:00 Central European Time MET W +1:00 Middle European Time MEWT W +1:00 Middle European Winter Time SWT W +1:00 Swedish Winter Time FWT W +1:00 French Winter Time HFH W +1:00 Heure Francais d'Hiver MEST S +2:00 Middle European Summer Time EET W +2:00 Eastern European Time SST S +2:00 Swedish Summer Time FST S +2:00 French Summer Time HFE S +2:00 Heure Francais d'Ete BT W +3:00 Bagdad Time ZP4 W +4:00 GMT 4 hours ZP5 W +5:00 GMT 5 hours IST W +5:30 Indian Standard Time ZP6 W +6:00 GMT 6 hours WAST W +7:00 West Australian Standard Time JT W +7:30 Java Time WADT S +8:00 West Australian Daylight Time CCT W +8:00 China Coast Time JST W +9:00 Japan Standard Time CAST W +9:30 Central Australien Standard Time SAST W +9:30 South Australien Standard Time EAST W +10:00 East Australien Standard Time CADT S +10:30 Central Australian Daylight Time SADT S +10:30 South Australien Daylight Time EADT S +11:00 East Australien Daylight Time NZT W +12:00 New Zealand Time NZST W +12:00 New Zealand Standard Time NZDT S +13:00 New Zealand Daylight Time
I) Liste der ZConnect-Programme
Die folgende Liste ist eine von Hinrich Donner regelmäßig in /T-NETZ/ZCONNECT/MELDUNGEN veröffentlichte Liste der bekannten ZConnect-Programme und ihrer ProgrammiererInnen.
[Dieser Anhang macht in der ASCII-Doku keinen Sinn, wäre nur in einer gedruckten Variante von Belang.]
Fußnoten
In der Dokumentationsendversion werden diese Fußnoten in der Näher des Verweises auf sie untergebracht werden.
{1} In der Praxis sind einige sehr weit verbreitete Anwendungen heute
aufgrund sehr langer Innovationszyklen nicht sehr nah am
Standard. Umgekehrt sorgt ihre hohe Verbreitung für einen
Defacto-Standard, den andere Applikationen berücksichtigen
müssen.
{2} T-NETZ steht für "teilvernetztes /Z-NETZ" und beschreibt eine
Brettgruppe, die unter Systemen auf freiwilliger Basis getauscht
werden; die Namensgebung leitet sich also aus dem Pflichtbezug
der /Z-NETZ-Hierarchie ab. Über eine Umwandlung von /T-NETZ nach
/Z-NETZ/ALT wird aktuell heftig diskutiert.
{3} [D3.0] verweist hierzu auf [RFC 822]
{4} Als Smartserver wird dasjenige System bezeichnet, zu welchem das
lokale System sämtliche Nachrichten schickt, die es selber nicht
oder nicht über einen anderen Weg zustellen kann. Voraussetzung
ist, daß die EmpfängerInnenadresse syntaktisch korrekt ist.
{5} "Re" kürzt "Reply" ab, meint also "Antwort".
{6} Es kann nicht tatsächlich von einer Chronologie gesprochen
werden, da die Reihenfolge von Antworten nicht unbedingt eine
chronologische Ordnung aufweisen muß. Insbesondere kann beim
Antworten auf mehrere Nachrichten gleichzeitig keine
chronologische Reihenfolge der übernommenen BEZ-Informationen
festgestellt werden.
{7} Die in der deutschsprachigen Netzlandschaft gebräuchliche
Bezeichnung "Mailbox" würde im sprachlichen Herkunftsland des
Begriffs auf Unverständnis stoßen. Die dort üblichere Bezeichnung
ist "Bulletin Board System" (kurz: BBS). Da ZConnect zum
allergrößten Teil im deutschsprachigen Raum eingesetzt wird, soll
dennoch von Mailboxen gesprochen werden.
{8} Das erste System auf dem Routeweg (ROT-Information also leer)
einer Mail darf EMPs in KOPs wandeln, wenn es wegen
Schreibverboten in bestimmte Bretter unbedingt notwendig ist. Von
diesem Recht Gebrauch zu machen, ist unbedingt als absoluter
Notfall zu betrachten und gilt selbst dann noch als schlechter
Stil.
{9} Endsysteme, also solche Systeme, von denen die Nachricht nicht an
ein anderes System weitergereicht wird, dürfen mit den
Nachrichten natürlich machen, was sie wollen.
{10} Steuernachricht, welche zum Zwecke der Löschung ein zuvor
versandten Nachricht dieser nachgesandt wird.
{11} Auch wenn im folgenden von "der" abgespaltenen Empfängerin die
Rede ist, so kann es trotzdem immer auch sein, daß die Abspaltung
wiederum eine Nachricht an mehrere Empfängerinnen ist, wenn auch
immer eine mit ausschließlich privaten solchen.
{12} Entsprechende Versuche ergaben, daß Systeme, die üblicherweise
auf TRACE antworten, dies bei fehlenden Parametern nicht tun.
Dies läßt sich insbesondere für die aktuelle Version 5.2, Release
3.0, des Zerberus-Mailboxprogramms aussagen.
{13} Im FIDO-Netzwerk ist es üblich, die Existenz privater Nachrichten
zu verneinen. Aus diesem Grund sind z.B.
Verschlüsselungsprogramme wie Pretty Good Privacy verboten und
werden die NetMails (Bezeichnung für private Nachrichten) von
SystembetreiberInnen eingesehen oder gar zensiert. Nach Ansicht
netzerfahrener Datenschützer ist die Interpretation privater
Nachrichten als "öffentliche Nachrichten mit nur einem/einer
Empfänger/in" unhaltbar.
{14} Ein Byte hat nicht zwangsläufig acht Bit.