From: Michael_Holzt@p112.f4020.n2444.z2.fido.sub.org (Michael Holzt)
Date: Thu, 27 Jul 1995 15:35:00 +0200
Newsgroups: de.comm.gateways
Subject: Gatebau'94-Protokoll ueberarbeitete Version
Hallo All,
ich habe mich als Autor des Gatebau'94-Protokolls mal hingesetzt, und mein
Protokoll ergaenzt, und vor allem mit aktuellen Anmerkungen versehen (z.B.
wegen der neuen Gateway-Identifikationszeile, die sich dann ja doch nicht
durchgesetzt hat).
Gatebau '94
Das Protokoll mit nachtraeglichen Anmerkungen
-------------------------------------------------------------------------
Auf der Gatebau '94 trafen sich Programmierer von Gateways von und
nach Fido. Das Treffen fand statt am 23. Juli 1994 bei Joerg Stattaus
in Aachen.
Anwesenheitsliste:
Joerg Stattaus, Aachen, Programmierer Maus<->Fido
Joerg_Stattaus@ac.maus.de
Martin Junius, Aachen, Programmierer RFC<->Fido
2:2453/110.1, mj@morannon.fido.de
Albi Rebmann, Weinstadt, Programmierer RFC<->Fido
2:2471/77
Michael Holzt, Kierspe, Programmierer ZC<->Fidso
2:2444/4020,112, mh@florian.mark.sub.de
------------------------------------------------------------------------
1. MsgId auf Fidoseite nach Gatebau 94
Zur Erinnerung: Alter Standard war, das in den Adressteil der
Fido-MSGID die Adresse aus der RFC/ZC-MessageID gesetzt wurde,
und in die HexId eine CRC32, also z.B. MSGID: xyz.do.main 1234abcd
Nach dem alten Standard wurde die originalle RFC/ZC-ID als
^aORIGID transportiert. Leider unterstuetzt (ausser Yuppie) keine
Software die eigentlich vorgesehene Methode hierraus beim Reply
ein ^aORIGREF zu bilden. Dies hat zur Folge, das die Replys aus
dem Fido nach Wandlung nach ZC/RFC keinen vernuenftigen / richtigen
Bezug gesetzt haben.
Darum wurde von den Anwesenden ein neues Verfahren erdacht, welches
sich mittlerweile (Juli 1995) schon in der Praxis gut bewaehrt hat.
Die Original-RFC/ZC-ID wird genommen (die ZC-ID wird noch in
< > eingeklammert) und so komplett in den 'Adressteil' der
Fido-MSGID eingesetzt. Als HexId wird eine crc32 ueber die
MessageID (inklusive < >) und dem jeweiligen Fido-Brettnamen
(in Grossbuchstaben) errechnet. Der Brettname wird eingerechnet,
um auch fuer Crosspostings MSGIDs erzeugen zu koennen.
Hier ein aktuelles Beispiel aus der GATEWAYS.GER:
^aMSGID: <wEnpiMD41Banz7@eaa.escape.shnet.org> bbd2a6fe
Sollten in der Original-RFC/ZC-ID Leerzeichen auftreten
(UNERWUeNSCHT!), wird die gesamte ID in Anfuehrungszeichen
gesetzt.
Beispiel:
^aMSGID: "<so was aber auch@box.do.main>" 1234abcd
Wird die Nachricht in mehrere Teile gesplittet, wird in den
folgenden Teilen die HexId jeweils um 1 erhoeht.
Leider ist es, wie es neuerdings die Praxis zeigt, nicht ganz
unproblematisch ueberhaupt an mehreren Gateways zu splitten,
da eine sehr weit verbreitete Software, die selber auch splitten
kann (PktSort), die MsgId in den fortgesetzten Teilen wieder
entfernt.
Bisher wurde aus Kompatibilitaetsgruenden zu alter Software
weiterhin die ^aORIGID-Kludge erzeugt. Mittlerweile (Juli 1995)
ist diese Erzeugung ueberfluessig, und kann ruhig abgestellt werden.
Beim Zurueckgaten ist die Rang-Reihenfolge der MSGIDs folgende:
1. hoechste: Gatebau'94 MSGID
auf <*@*> bzw. "<*@*>" pruefen, und die CRC
nachrechnen. Wenn CRC falsch, dann weiter, ansonsten
die ID aus der MSGID rausschaelen
2. ^aORIGID
3. 'normale' Fido-MsgId
*NEU* (nach Mime-MsgId-Verfahren siehe MSGID:DOC von
Martin Junius!)
2. Splitting
Beim Splitten wird, wie weiter oben erwaehnt die HexId um je eins
erhoeht. Beispiel Teil 1: 0927276a, Teil 2: 0927276b usw..
Es wird eine Split-Kludge nach FSC47 erzeugt. Anmerkung: Es steht
zu ueberlegen eine eigene Split-Kludge zu definieren. (Aktuelle
Anmerkung: Was sich durch die Probleme mit PktSort ja auch
als besser zu bestaetigen scheint).
Die von jag und Fidogate erzeugten ' * Split / Splitted by xxxx ...'
Zeilen fallen weg.
Zwischen der letzen Zeile des gesplitteten Textteiles und der
Tearline wird exakt EINE Leerzeile eingefuegt. Eine sonstige
Veraenderung des Nachrichtentextes (zum Beispiel Einfuegen von
Texten wie '<continued in next message>') ist untersagt!
Der Betreff des ersten Teiles wird unveraendert uebernommen.
Bei den weiteren Teilen wird die Teilnummer in der Form
nn: davorgesetzt. Achtung! Maximale Betrefflaenge beachten,
ggf. cutten.
Eine gesplittete Mail darf nur dann zurueckgegated werden,
wenn a.) alle Teile aufzufinden sind, und die Nachricht vorher
ungesplittet wird.
3. Multi-Replys
Hier steht zu beobachten, wie verschiedene Programme darauf
reagieren. Vorerst ist das Erzeugen von mehreren Replys nicht
gatebau-konform.
4. Pseudo-Domain fidonet.org
Martin Junius wird versuchen eine Domain ftn.net fuer uns zu
erreichen, damit MsgIds nicht mehr auch fuer nicht-Fido (aber
Fido kompatible) Netze auf fidonet.org gebildet werden.
(Aktuelle Anmerkung: Wie die bisherige Erfahrung gezeigt hat,
wird eine entsprechende Domain wohl nicht akzeptiert werden,
was natuerlich Probleme aufwirft, wenn z.B. fuer ein Fremdnetz
mit z.B. Zone 99 eine andere Domain verwendet wird, aber nun
jemand mit Zone 99 in ein Fido-Echo schreibt. Denn dann wird
diese Nachricht eventuell zum einen auf einen Gate stossen,
der Zone 99 mit einer entsprechenden Domain kennt, weil er
das andere Fremdnetz kennt, aber dann zu einem anderen Gate,
der nur Fido kennt, und dann als Default @fidonet.org einsetzt.
Die einzige Loesung waere es, unbekannte Zonen nicht zu gaten,
wobei man unbekannte Zonen eigentlich je nach Echo einstellen muesste,
also z.B. fuer Fido-Bretter alles ausser Zone 1-6 unbekannt, und
fuer GerNet alles ausser Zone 21 unbekannt usw. Befriedigend sind
diese Loesungen aber meiner Meinung nach alle nicht).
5. Uebertragen von zusaetzlichen Informationen
Unbekannte Header-Zeilen aus dem RFC werden mit dem Vorsatz
RFC- eins zu eins ins Fido uebernommen. Ausnahme sind natuerlich
Zeilen, die ihren Ursprung aus dem Fido haben (s.u.)
Beispiel:
RFC-Headerzeile zzzz: ahjsaj
auf Fido: ^aRFC-zzzz: ahjsaj
Aber: RFC-Headerzeile x-ftn-wuerg: hahs
wird auf Fido: ^awuerg: hahs
Unbekannte Zconnect-Zeilen erhalten den Vorsatz ZC-.
Beim Gaten aus dem Fidonet heraus erhalten unbekannte
Fido-Kludges im RFC den Vorsatz X-FTN-, und im ZConnect
den Vorsatz F-.
Achtung: Wenn von Fido z.B. nach RFC gewandelt wird, duerfen
Kludges die mit ^aZC beginnen, natuerlich nicht nach X-FTN-ZC-
sondern nur nach X-ZC gewandelt werden. Genauso darf ein
Fido->ZC Gate aus ^aRFC nicht F-RFC sondern nur U- erzeugen.
Zusammenfassung
Headerzeilen aus ... Vorsatz im ... Fido ZConnect RFC
Fido --- F- X-FTN-
ZConnect ZC- --- X-ZC-
RFC RFC- U- ---
Anmerkung: Es sollten nicht unbedingt in unbegrenzten Masse
unbekannte Header-Zeilen gegatet werden. Im Ermessen des Programmierers.
Auf das Gaten von SeenBys sollte man zum Beispiel besser verzichten,
und auch der RFC-Path auf Fido wird oft nur negativ angesehen.
RFC-Gates erzeugen folgende zusaetzliche Header (optional (?) ):
X-FTN-Origin:
X-FTN-Seen-By:
X-FTN-Tearline:
X-Comment-To: Brettempfaenger aus Fido
X-FTN-From: optional die komplette Fido-Adresse in NORMALForm
Beispiel: X-FTN-From: Michael Holzt @ 2:2444/1168.112
DIESE INFORMATION IST SEHR SEHR VORSICHTIG ZU
BENUTZEN (WENN UEBERHAUPT). Auf jeden Fall pruefen,
ob die Adresse aus dem Ziel-FTN-Netz ueberhaupt
zu erreichen ist.
Die ZConnect Zeilen sind
F-Origin:
F-Seen-By:
F-Tearline:
F-To: Brettempfaenger aus Fido
F-From: siehe X-FTN-From.
6. Empfaenger
Leerzeichen in Empfaengernamen werden generell in Unterstriche
gewandelt.
7. Gateway-Identifikation
Auf der Gatebau 94 wurde eine neue Gateway-Identifikation
erdacht. In der Praxis hat sich diese aber nicht durchgesetzt.
Damit bleibt momentan nur die aus ZConnect entstammende Spezifikation
fuer ZC-Gate:
GATE: vonformat id adresse [software]
z.B. fuer ein ZConnect-Fido-Gateway
GATE: ZCONNECT H0 ftn.mark.sub.de [ZFGate 1.00]
Die GateId wurde frueher fuer einzelne Gateways vergeben, und
mittlerweile fuer eine einzelne Software, ist aber nach neuesten
Bestimmungen auch optional. Die Id wird von der ZConnect-GateKoo
vergeben.
Bei einer bereits bestehenden Gate-Zeile, haengt sich der neue
Gateway *vorne* ein.
Leider hat sich diese Gatekennung auf RFC nicht durchgesetzt.
Einige Gateways haben obwohl die Diskussion in der Gateways
gegen unser neues Format liefen, dennoch die neu beschlossene
Kennung implementiert (z.B. FidoZerb). Dies ist aergerlich, liegt
aber wohl daran, dass so mancher Autor nicht mitliest ;-(
Darum hier auch noch mal die neue Spezifikation. Wenn ein Gateway
auf diese treffen sollte, ist er angehalten, die einzelnen Zeilen
einfach durch Komma getrennt in eine GATE-Zeile zu verwandeln, und
sich einfach nach obigen Schema davorzusetzen.
- - - -
Jeder Gateway erzeugt beim Gaten eine Headerzeile / Kludge.
Diese lautet auf allen Netzen / Techniken uebereinstimmend
X-Gateway.
Aufbau:
X-Gateway: name(max 15 Zeichen) Programm Version Datum/Zeit
Fuer Datum und Zeit konnte kein einheitlicher Konsens gefunden
werden. Zeitangaben aber immer in UTC.
Vorschlag fuer Datum und Zeit: TTMMJJ.SSMM
Beispiel:
X-Gateway: fido.de fidogate 3.7 230794.1812
X-Gateway: mausac linkit x.0 110894.1023
Zeilen von anderen Gateways werden NICHT entfernt, der neue
Gateway schreibt sich in die Zeile nach einer eventuellen
alten X-Gateway. Vorschlag: X-Gateway generell am Ende der
Header-Zeilen.
8. Lebenszeichen Gatebau
Das momentane Lebenszeichen scheint selber nicht mehr zu leben.
Es soll ab sofort aus jedem Netz eines einmal die Woche geschickt
werden.
Es war zuerst ueberlegt worden, einen einheitlichen Namen dafuer
zu geben, aber das scheitert wohl an der Realnamenpflicht im Fido.
Aber eventuell kann man vor den Realnamen einen einheitlichen
Vorsatz senden.
Netz wer? username betreff
RFC Martin Junius ??? Lebenszeichen <datum> rfc
Fido Michael Holzt ping/Michael Holzt Lebenszeichen <datum> fido
Eine automatische Auswertung wird ueberlegt.
-------------------------------------------------------------------------
Gruss Michael