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: bbd2a6fe Sollten in der Original-RFC/ZC-ID Leerzeichen auftreten (UNERWUeNSCHT!), wird die gesamte ID in Anfuehrungszeichen gesetzt. Beispiel: ^aMSGID: "" 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 '') 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 rfc Fido Michael Holzt ping/Michael Holzt Lebenszeichen fido Eine automatische Auswertung wird ueberlegt. ------------------------------------------------------------------------- Gruss Michael