From: urlichs@smurf.sub.org (Matthias Urlichs)
Newsgroups: de.comm.gateways
Subject: Re: Gateway-TUeV (war: Hochgep
Date: 14 Apr 1992 12:33:08 +0200
Organization: University of Karlsruhe, FRG
NNTP-Posting-Host: smurf.smurf.sub.org

In de.comm.gateways, article <3576@sol.ccc.de>,
  Frank.Simon@sol.ccc.de (Frank Simon) writes:

< Nehmen wir als konkretes Beispiel fuer solche Probleme ruhig mal die
< MessageID-Problematik. Es gibt drei Moeglichkeiten im Zerberus mit
< diesen Problem umzugehen:
< 
< 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.

Was zu tun ist, wenn das nicht passiert, ist das naechste Problem.
Meiner Meinung nach aendert das aber NICHTS an der Notwendigkeit einer
Umstellung. Siehe unten.

< >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?
(Das schliesse naemlich ein, dass zumindest einer von der Meinung, sein Gate
waere eh der beste, abgeht...)

< >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.
Genau dieser Schritt fehlt aber ganz einfach!

< Das Problem der Dupes ?  Ja. Es gibt sie. Aber wie gehen wir damit um ?
< 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.
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.
Ich _habe_ ein Interesse an Mail&News aus anderen Netzen.
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.

< 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 
in ein und dieselbe Usenet-Newsgroup schleusen, ist sehr leicht zu pruefen,
sobald sich jemand hinsetzt und eine vernuenftige Spezifikation dafuer
schreibt. (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...)

Auf dem Usenet gibt es auch gelegentliche Dupes durch irgendwelche Software-
fehler. Na und? Man sieht die Dupes und die Fehler werden behoben.
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.
Dagegen hab ich was. Ich will mit Usenet-Site X Fido/Zerberus/Fasel-News
austauschen koennen, ohne erst noch nachzufragen, welcher ID-Generierungs-
Algorithmus, welcher Newsgroupnamen-Generierungs-Algorithmus und welcher
Mailadressen-Generierungs-Algorithmus verwendet werden. Das interessiert
mich nicht und meine Benutzer noch weniger.

< 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.
Welche Untermenge an Artikeln von den einzelnen Gates transportiert wird,
ist mir als Benutzer auch egal. Wenn Gate A die Untermenge X und Gate B die
Untermenge Y ins Subnetz transportiert, dann bitte in einer einheitlichen
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.
Wenn die Gates die von anderen Gates kommenden Artikel nicht ins Originalnetz
zuruecktransportieren wollen, dann ist das (wiederum gegeben einheitliche ID-
und Adressformate) sehr einfach. Das stoert mich als Subnetzler nicht, weil
meine Artikel von dem Gate, der die Untermenge X ins Subnetz importiert, auch
in die Originalarea zurueckleiten kann, und Gate B sich dafuer entweder eh
nicht interessiert oder die Dupe-Erkennung im Originalnetz verhindert, dass
Probleme auftreten.

< Desweiteren halte ich die Benutertransparenz fuer fast wichtiger, als
< paar Dupes. Wenn ich eine Mail im Zerberus bekomme, will ich darauf
< ANTWORTEN machen koennen. Wenn ich ein Artikel in einer de-Gruppe lese,
< will ich darauf Reply oder Follow-Up machen koennen OHNE jetzt den Header
< patchen zu muessen um eien netzspezifische Adressierung zu verwenden
< 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.).

< >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.
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. 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?

< 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.

-- 
Matthias Urlichs  --  urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  +49-721-9612521     \o)/