From: Frank.Simon@arbi.informatik.uni-oldenburg.de (Frank 'Terra' Simon)
Subject: Re: Gateway-TUeV (war: Hochgep
Organization: University of Oldenburg, Germany
Date: Tue, 14 Apr 1992 17:24:56 GMT

Hallo Leute, 

urlichs@smurf.sub.org (Matthias Urlichs) writes:
>< c) Mensch schafft eine Kruecke und bildet die MsgID's ab. Auch wenn die
><    MsgID-Routine gemaess GateBau eine Super-Denkleistung darstellt und 
><    jeden Anspruch von Ingenieuren standhalten wuerde, ist sie mit Defiziten
><    behaftet. Ausserdem klappt es nur, wenn ALLE diese MsgID-Routine ver-
><    wenden. Das durchzussetze halte ich aus obengenannten Gruenden fuer 
><    schwer.
>Wenn es nicht anders geht, dann eben so. Aber nach ein paar Wochen
>Uebergangszeit sollte das eigentlich jeder umgestellt haben.
Tjae. Das habe ich mir auch so gedacht. Aber z.B. ich hatte mal eine
Weile die GateBau-konforme MsgID laufen. Aber zwei Dinge haben mich 
daran gestoert:

a) Es war nicht vorgesehen, dass ein Artikel gesplittet wird. Da im
   Zerberus eine Artikel-Groesse von 10 KB vorherrscht, hast du zwei
   Moeglichkeiten:
	a) Artikel ablehnen
	b) Splitten
   Gegen a) bin ich, weil der Benutzer der z.B. im Subnet sitzt KEINE
   Groessenbegrenzung kennt. Erwartungskonform heisst, dass er auch in
   einer Newshierachie namens zer.* selbiges machen koennen soll.
   Ein anderes Defizit lag darin, dass die MsgID-Routine davon ausging,
   dass jemand das Zerberus z.B. fuer de.* oder das Subnet fuer zer.* als
   Transitnetz benutzt werden koennte. Da aber die MsgId laenger als die
   maximale Zerberus-Laenge sein sollte, blieb nur eine injektive Abbildung
   der MsgID. Damit du das zurueckkonvertieren konntest, wurde die "echte"
   MsgID im Body uebernommen. (Im Body haben keine Header-Informationen
   zu stehen!)
   
>Warum haben wir hier die Gruppen "fido.ger.bla" und "fido.bla-ger"? 
>< Vielleicht warum ihr cl.* und wir comlink.* haben ?  :-)  Sogar das 
>< hat Gruende. :-) >< 
>Vielleicht den Grund, dass die diversen Gatebetreiber ein so aufgeblasenes
>Ego haben, dass sie es nicht schaffen, sich mal zusammenzusetzen und sich
>auf einheitliche Formate fuer Groupnamen und IDs zu einigen?
Du machst es dir zu einfach. Es gab mal eine Weile eine einheitliche
Newshierachie namens zer.*. Dabei traten Defizite in der GateBau auf, die
auch nach mehrfacher Kritik UND Korrekturvorschlaegen nicht geaendert
wurden. Also gab es drei Loesungen:
a) Mit den Defiziten leben (wollte ich wg. der Benutzer nicht)
b) Mit den leuten diskutieren. nach paar Monaten hat mensch dafuer aber
   auch kein Nerv. Wenn durch diese Defizite einfach Dupes auftreten, 
   dann muss dir Ursache beseitigt werden. Es lief aber darauf hinaus,
   mich abklemmen zu wollen. 
c) Also habe ich fuer mich eine Inselloesung geschaffen. Die sieht so aus, 
   dass wir hier eben znet.* und comlink.* benutzen. Das hat nix damit zu
   tun, dass ich meine Software fuer besser halte. Im Gegenteil. Aber fuer
   MEIN Anwendungsgebiet macht sie das was ich will. Das leistet keine
   andere Software. 

Dazu: Inzwischen haben mind. die URANUS und die SOL das realisiert, was
ich im CoC-Text vorgeschlagen habe. Wir haben daher jetzt dieselben
Hierachienamen (znet.*) und kommen uns NICHT ins Gehege - obwohl wir
verschiedene MsgID-Routinen verwenden. Wenn wir die vereinheitlichen 
wuerden, wuerde ein weiterer Sicherheitsmechanismus da sein. 

>< >Mal so gefragt: wenn Du davon nicht begeistert bist, Terra, welche
>< >Alternativen schlaegst Du denn vor? Den Wildwuchs so weitertreiben
>< >lassen? Dupes und Chaos ohne Ende? 
>< Aus dem (kreativen) Chaos erwaechst neue Gedanken und Entwicklungen. 
>Das ist eine nette Behauptung, die aber nur dann funktioniert, dass sich
>aus dem Wettbewerb der divergierenden Ideen irgendwannmal eine entwickelt,
>die als "beste" Idee selektiert wird (nach welchen Kriterien und von wem
>auch immer), die dann als neuer Standard festgeschrieben wird, damit darauf
>wieder neue Ideen aufbauen koennen.
Eine TUeV muss mit Testdaten arbeiten. Es gibt paar Dinge (ich erwaehne
nur das mit der Laenge von Artikeln), die technisch korrekt, aber aus
bestimmten Gruenden eben doch vereinheitlicht sein muessen. Das heisst 
ein TUeV braeuchte ein Referenzsystem an dem sich alle anderen zu
orientieren haetten. 

Zu deinen Argument direkt: Natuerlich gibt es einen solchen Wett-
bewerb. Das ganze laeuft so in Richtung Defacto-Standard.

>< Die GateBau und die bekannten Ansaetze gehen davon aus, dass Dupes 
>< entstehen und das sie nur erkannt werden. Meine Wenigkeit ist ein
>< Anhaenger des Prinzips "Dupe-Vermeidung vor Dupe-Erkennung".
>Du gehst damit aber leider davon aus, dass ein jeder Gate 100% funktioniert
>und nie News verliert. Ausserdem: Administrative Massnahmen schoen und gut,
>aber fuer die Administration gibt es momentan zwei Gruende -- (a) Dupes
>verbraten Uebertragungskapazitaet, (b) inkompatible Implementierungen fuehren
>zu Schleifen und anderen unschoenen Effekten.
Halt. Nein. Mit administrativen Massnahmen meine ich z.B. Zustaendig-
keitsgebiete von Gateways. Wenn ich ein Artikel von einen System bekomme,
fuer das ich mich nicht zustaendig fuehle, leite ich es nicht weiter. 
Basta. Es geht garnicht erst ins Zielnetz um dort als Dupe erkannt zu
werden. Das meinte ich mit Dupe-Vermeidung vor Dupe-Erkennung. 

Deinen ersten Satz verstehe ich nicht. Gerade ICH gehe davon aus, dass
eben NICHT jedes Gateway 100% funktioniert. Die GateBau-Spezifikation
geht davon aus, dass jeder diesselbe Software faehrt bzw. 100% 
kompatible Software benutzt. Gerade das war in der Vergangenheit nicht
gegeben. Meine Methode setzt diese Praemisse eben nicht. Sie sieht
technische Spezifikation als Ergaenzung. Nicht als Non-Plus-Ultra.

>Letzteres ist ein technisches Problem und ich fuer meinen Teil habe keinerlei
>Lust, dieses mit administrativen Massnahmen beheben zu wollen. Das ist
>unnoetiger Aufwand, den ich als jemand aufzubringen habe, der an Gate-
>programmierung und -betrieb an sich Null Interesse hat und der nicht
>gewillt ist, lokal die von zwei Fido- und drei Comlink-Gates jeweils
>mehrfach zu halten, nur weil sich die Gates nicht auf ein einheitliches
>Format einigen koennen.
Bei der Adressierung hast du recht. Durch diesen Wildwuchs entstehen
evntl. verschiedene Adressierungsarten. Aber die Frage ist, was du 
davon mitbekommst. Ich erzeuge z.B. im Zerberus die Adressen SOL.ZER 
und UNIOL.ZER. Das sind eingetragende Systemnamen dort. Ein Zerberus-
Benutzer (und auch meine Benutzer) kriegen davon nix mit. Die Adresse
ist (m.E.) sogar korrektor aus die Makrokruecken. (Auch wenn sie die
einzige Loesung fuer Gateways ist, die eben alles und jeden versorgen
wollen).

>Ich bin aber nicht gewillt, den administrativen Aufwand in Kauf zu nehmen,
>von dem 90% durch technische Massnahmen (eben Kompatibilitaet zwischen
>den Gates -- auf beiden Seiten) vermeidbar sind.
Das ist die Theorie. Die Praxis zeigt, dass es bei der Theorie bleibt.
Wenn 5 Leute an 5 Gateways programmieren gemaess GateBau-Spezifikation
gibt es trotzdem 3-4 Ergebnisse. 

>< Wir koennen Dupoes nicht vermeiden, weil
>< a) es unmoeglich ist eine komplexe Software auf richtige Implementation
><    zu testen, [...]
>Falsch. Ob zwei Gates dieselbe ID generieren und eine bestimmte Fido-Area 
Richtig. Hier steht, dass du komplexe Software nicht auf richtige
Implementierung testen kannst. Das ist Fakt. Mit was willst du das den
Verfizieren ?  wp-Semantik ? Fixpunktsatz ?  Dann guck nochmal ins
Script was da zu "Praxisbezug" steht. :-)

>in ein und dieselbe Usenet-Newsgroup schleusen, ist sehr leicht zu pruefen,
>sobald sich jemand hinsetzt und eine vernuenftige Spezifikation dafuer
>schreibt. 
Wie du vielleicht gesehen hast, muss bei einer weitverbreiteten Zerberus-
Version die MsgId, die Laenge und der Absender gleich sein. Und das bei
Systemen die (wenn sie mit Makros arbeiten) einen Teil des Headers
in den Body schreiben und den Artikel verlaengern. 

>(Bei divergierenden Ansichten ueber Vernunft muessen sich die
>beteiligten Leute eben solange in ein Zimmer einsperren lassen, bis die
>Divergenz auf ein vernuenftiges Mass gesunken ist...)
Wenn du eine perfekte Speizifikation (z.B. auf dem Niveau von RFC's) hast
und eine perfekte Implementierung (oder sagen wir mal eine 99% perfekte),
dann hast du recht. 

Nur: Das ist viel Arbeit. Arbeit die sich schon eine Gruppe von Leuten
     gemacht hat. Arbeit die leider doch zu Problemen vielschichtiger
     Art gefuehrt hat. Diese Realitaet moege ich nicht uebersehen. :-)
     Daher stoert mich das "theoretisieren" ueber einen Gateway-TUeV.
     Besonders solange, wie sich dafuer niemand freiwillig meldet. :-)

>Auf dem Usenet gibt es auch gelegentliche Dupes durch irgendwelche Software-
>fehler. Na und? Man sieht die Dupes und die Fehler werden behoben.
Eben. Im EARN/Bitnet gab es auch manchmal Dupes z.B. in Listservern. Und ?
Es ist eben das Risiko der Vernetzung, mit solchen sinnlosen Traffic zu
leben. Daher sind mir "Abklemmungsgedanken" oder solche Saetze wie, "Wer
bis zum 1.4.1992 kein Gatebau-konformes System benutzt, wird abgeklemmt"
einfach nur suspekt.

>Wenn man die Duplikate auf administrative Art beheben will, kommt es statt-
>dessen erstmal zum grossen Krieg, wer mit seiner Sicht nun recht hat und wer
>zuerst was wohin gegatet hat und deshalb unmoeglich auf dieses "Recht"
>verzichten kann.
Ich werde den Coc-Text dochmal posten. Der Inhalt ist eben nicht 
technischen, sondern definiert administrative Massnahmen zum Betrieb 
von Gateways. Evntl. verstehen wir uns einfach nur falsch.

>Mailadressen-Generierungs-Algorithmus verwendet werden. Das interessiert
>mich nicht und meine Benutzer noch weniger.
Im UseNet sollen die Leute ISO-Domain-Adressen oder die im Zielnetz
ueblichen Adressierungen verwenden koennen. Einer der beiden Methoden.
NIX anderes. Nur DAS kann der Benutzer verstehen. Aber selbst diese
einfache Aussage, und da sind wir ja wohl einer Meinung, wird kaum 
bis garnicht beruecksichtigt. Und genau DAS ist keine technische Frage
(die Implementierung schon) sondern eine ... na ... netzsoziale Frage.
Was geben wir dem Benutzer an die Hand. Die gestige Kraft sollte in
solche Fragen bei den Konzepten von Gateways gesteckt werden und nicht
auf die Frage, wie mache ich moeglichst geschickt ein Makrosystem.

>< b) Auch ein Gateway-TUeV kann nur mit Testdaten arbeiten. Da werden die
><    Anwendungen nur schwer nachvollziehbar sein. Es gibt Gateways, die
><    alles durchschleusen, was sie bekommen (Beispiel: EARN/UUCP)
><    Es gibt Systeme die nur einen eingeschraenkten Raum versorgen, weil
><    diese an einer Domain teilnehmen (Beispiel: bi-link)
><    Es gibt Systeme die auf einen "artfremden" Systemen an einen Netz
><    teilnehmen (Beispiel: Sol). 
>Im deutschen Raum sollte es wohl relativ einfach sein, eine Adresse zu
>generieren, auf die jeder von ueberallher antworten kann.
Ja. Bei uns im Subnet. Diese komischen Makros entstehen aber im Zerberus.
Und da beobachte ich eben eine "einseitige" Sichtweise. Was fuer das
Subnet und deren Benutzer gelten soll, muss so genauso fuer die Benutzer
im Zerberus gelten. SONST hast du naemlich eine Glaubensdiskussion am
Hals, die deinen Befuerchtungen ueber "Mein Gateway ist besser als deins"
noch um Laengen schlaegt.

>Form, so dass ich auf dem Subnetz beide in einer Hierarchie fuehren kann und
>mir nicht jedesmal ueberlegen muss, welcher Satz Gruppen jetzt wo zu finden
>und ueber welchen Gate zu erreichen ist.
Der Benutzer soll sich das nicht denken. Klar. Aber der Betreiber. Der
Betreiber eines Subnet-Systems der znet.* und comlink.* News will, soll
gefaelligst die wenige Arbeit machen in seinen sys-File und paths-Datei
vernueftige Eintraege zu machen, damit er die News nicht "ueberall"
hinspoolt oder sich von ueberallher holt. Das kann er im UseNet machen.
Wenn er aber maus.*, fido.* und zer.* will, dann geht das eben nicht. 
DIESEN Minimalaufwand verlange ich vom Systembetreiber. ER will die
Informationen aus dem anderen Netz. 

[..]
Hmmm ... das scheinst du im naechsten Absatz auch geschrieben zu 
haben. :-)

>< oder aehnliche Scherze. Das hat fuer mich hoehere Prioritaet. Wer den
>< Mischmasch bei der Benutzung einiger Gateways kennt (teile des Headers
>< im Body vom Benutzer einzugeben, etc) kennt, der ahnt evntl. was ich meine.
>Fuer mich ist das ein Argument fuer Standardisierung der Gates und fuer
>das Beheben der Fehler bei dem Gate, das den zu patchenden Header erzeugt
>hat. (Den musst du eh beheben, egal ob der Gate jetzt sein eigenes Sueppchen
>kocht oder mit anderen zusammenarbeitet.).
Eben. Aber dafuer brauchst du nix Standardisieren bei den Gateways. Es
gibt nur zwei zulaessige Arten der Adressierung unter dieser Praemisse.

a) Du fuehlst dich als netzwerkunabhaengiges System: Dann hat das 
   Gateway ISO-Domain-Adressen zu generieren. Dafuer brauchst du keine
   Gateway-Spezifikation. Wie sowas auszusehen hat, ist schon ganz
   woanders definiert. 
b) Du willst als neues System an einen anderen Netz teilnehmen (z.B.
   Zerberus). Dann hast du die dort ueblichen Adressen oder ISO-
   Domain-Adressen zu erzeugen. 

Meines erachtens ist das eine Spezifikation die selbstverstaendlich
sein sollte. Mensch braucht das (Adressierungs)-Rad nicht dauernd
neu erfinden. 

>< >Wohl kaum... was bleibt da anderes
>< >als eine Kontrollinstanz, wenn die Selbstkontrolle nicht stattfindet?
>< Meiner Meinung nach sollte durch administrative Massnahmen zusammen
>< mit technischen Empfehlungen die Wahrscheinlichkeit zum eintreten von
>< Dupes und anderen Probleme (Informationsdefizite ueber Nettiqette des
>< anderen Netzes, etc) veringert werden.
>Das reicht mir nicht. Ich will eine technische Empfehlung, anhand derer durch
>das Betrachten einer Originalnachricht und zweier in wesentlichen Teilen
>(also Message-ID oder Benutzeradressen) nicht uebereinstimmender Nach-
>richten im Zielsystem eindeutig entschieden werden kann, welcher der
>Gates Mist gebaut hat.
Das "reicht" dir nicht. Ich ging noch ueber die technische Empfehlung
hinaus. Nochmal lesen. Ok ? :-)  Oder mir erlaeutern, was du meintest. 

>Zu den Informationsdefiziten: Guter Punkt. Angenommen, du bist im Netz B und
>willst den benutzer ueber Netz A informieren, wie man da hinkommt, wo es die
>entsprechenden Netnews gibt, etc. 
Im UseNet ist meine Adresse terra@sol.ccc.de. Im Zerberus terra@sol.zer. 
Das schliesst natuerlich nicht aus, dass jene Zerberussysteme die schon
ISO-Domain verstehen nicht auch terra@sol.ccc.de adressieren koennen. 

>Willst du in diesem Dokument wirklich
>N verschiedene Gates einzeln auffuehren, jeder mit einem anderen Adressformat
>und anderen Namen fuer die Bretter/Newsgroups/was-auch-immer?
Eben nicht. Gerade nicht. Genauso. Der Benutzer soll aber auch nicht 
explizit Mails an blahdroehnfasel@gateway.suelz schicken muessen. Das
interessiert ihn nicht.  

>< Das ganze habe ich ja schon im ...
>< *ueberleg* ... vor paar Wochen wenigstens in //GATEBAU in einen groesseren
>< Text (Code of Conduct for Gateways) genauer dargelegt. 
>Da es auf dem Subnetz kein GATEBAU gibt, waere es sehr nett, das mal hier
>irgendwohinzuposten.
Na. In Gateways war er wohl auch schonmal. Ich geh den Text nochmal durch
und poste ihn dann.

Terra
-- 
-------------------------------------------------------------------
! Nickname: Terra                        UUCP: terra@sol.north.de !
! Realname: Frank Simon                  Geo: geod: chaos-team    !
! Tel.    : +49 441 76206                   EARN: CHAMNT@DOLUNI1  !
!       Sozusagen das Control-Y des Lebens (Peter Bruells)        !
-------------------------------------------------------------------