From: Frank.Simon@sol.ccc.de (Frank Simon)
Newsgroups: de.comm.gateways
Subject: Re: Stockende Gates :-/ III
Date: 31 Aug 92 04:22:38 +0200
Article-I.D.: sol.1261
Organisation: Solar System, Ls 441, Oldenburg, Germany

Hallo,

heiko@Harpo.Chemie.FU-Berlin.DE (Heiko Schlichting) writes:
>Frank.Simon@sol.ccc.de (Frank Simon) writes:
>>lp@shlink.hanse.de (Lutz Petersen) writes:
>>> Ich kann es einfach nicht mehr lesen %/($/-(((. Wie kann jemand (noch
>>> dazu derjenige, der im Z-Netz die Gateway-Koordination macht) immer
>>> und immer wieder behaupten, dass die Message-ID _nicht_ das Kriterium
>>> fuer einen Dupe-Check darstellt, unglaublich..
>>Durch Wiederholung der Aussage, dass die MsgID das alleinige Kriterium
>>zum Dupecheck darstellt, wird diese Aussage fuer das Z-Netz nicht
>>richtiger. 
>Deine aber auch nicht.
Doch. :-)

>Ich denke, wir sind uns einig: die Message-ID ist das einzige Kriterium,
>was zu Dupeerkennung herangezogen kann. 
Oh - wenn das nicht klar geworden ist: Ich kenne den RFC und daher
ist es klar, dass die MsgID das einzige Kriterieum zur Dupeerkennung
ist. Fakt. Klar.

Ich verweise nur darauf, dass es im Z-Netz NICHT so ist und daher alle 
Gateways die ins Z-Netz reingaten das gefaelligst zu beruecksichtigen
haben. Dies ist hier meines Wissen GATEWAYS, also das Brett in allen
Netzen fuer Gatewayproblematik. Es ist klar, dass durch diese
Z-Netz-Restriktion das deutsche UseNet nicht betroffen ist. Aber das
Z-Netz.

>Dass es noch Software gibt, die
>das nicht macht, ist schlecht und verbesserungswuerdig, aber aendert
>nichts daran, dass bei Gateways (und darum geht es), einzig und allein
>die Message-ID eine Rolle spielt (spielen sollte).
Wenn die MsgID von allen Gateways gleicht erzeugt wird, dann ist sogar
durch die GateBau fast gesichert, dass die Laenge der Artikel NICHT gleich
sind (durch die Zeile ueber welches Gateway der Kram kam). Im Z-Netz
wird also brav geduped, bis Zerberus 4.0 und 5.0 Systeme die Artikel 
rausfiltern und nicht weiterleiten. 

Nirgends ist aber festgelegt, dass ein Gateway nur an ein Zerberus 4.0
oder Zerberus 5.0 System angeschlossen werden darf. Also hat mind. ein
Teil des Z-Netz mit Dupes dadurch zu kaempfen - und es waere ziemlich
arrogant sich jetzt auf die Stufe zu stellen: Im de.* macht es keine
Probleme, also geht es mich nix an.

>Richtlinien generiert werden. Kann das aus irgendwelchen Gruenden nicht
>passieren, ist sie nicht "gatefaehig", da eine Dupeerkennung bei mehrfacher
>Umsetzung nicht gewaehrleistung nicht moeglich ist.
*mit_unterschreib*

>Beim Gateway hat die Dupeerkennung an der Message-ID als alleiniges
>Kriterium zu erfolgen. 
Es ist ja wohl klar, dass Artikel bei 2 Gateways etwa zur selben
Zeit eintruddeln koennen und daher die Artikel nicht auf den Gateways
kollidieren und aussortiert werden (darum geht es ja auch garnicht),
sondern beide Gateways erstmal Artikel ins Z-Netz einspielen und die
DORT irgendwo kollidieren - und dann eventuell eben nicht erkannt
werden.

>Gateways, die nicht gatebaukonform arbeiten, erzeugen Dupes - spaetestens
>wenn es ein weiteres Gate zwischen den gleichen Netzen gibt. 
Gateways die gatebaukonform arbeiten, erzeugen auch manchmal Dupes.
Gateways die nicht gatebaukonform arbeiten, erzeugen genauso selten Dupes
wie die gatebaukonformen. 

Alle Saetze sind durch Beispiele (>1) belegbar. :-)   

>Es ist
>ja richtig, dass z.B. das von Dir betriebene Gate schon lange nicht-
>gatebaukonform funktioniert, aber unter was fuer Einschraenkungen...
Ich sehe das nicht als Einschraenkung. Es hilft den Benutzer mehr, als
"wildes" Gaten. 

>Wie schlecht so ein nicht-gatebaukonformes Gate ist, kann man einfach
>demostrieren, wenn ich naemlich die hier vorhanden Z-Netz-news zur
>UniOl schicken wuerde oder mir die Z-Netz-News von dort hierher holen
>wuerde.
Du koenntest die Sachen zur UniOl spoolen und auf der UniOl gebe es
zwei Hierachien. Wir koennten sogar die Namen (wiedermal) verein-
heitlichen. Auch kein Problem. Ich wuerde nur Artikel die von 
berechtigten Systemen gepostet werden, ins Z-Netz durchrouten. DAs
Problem sind nicht die Gateways SOL, URAUNUS oder KRISKI. Das Problem
ist, dass die GateBau-konformen Systeme patou Postings der UniOl und
Sol ins Z-Netz weiterleiten - und das sogar unter falscher Absende-
Adresse (wenn Z-Netz-Systeme wie SOL und UNIOL ins Z-Netz posten,
dann tun wir das als SOL.ZER und UNIOL.ZER - und nicht als 
user%arbi.$$UU53@UZERCP.ZER. DIE Netzadresse will ich auch den Benutzern
hier garnicht zumuten - und auch nicht den Leuten im Z-Netz, die
garnicht mehr wissen, wo der Kram herkommt.

>Du kannst doch Dein Gateway kaum als gut funktionierendes beispiel
>anfuehren (wie in einem Posting vor wenigen Tagen hier geschehen), wenn
>es dadurch nicht moeglich ist, zwischen Rechnern im Internet (fub + uniol)
>die gleichen Newsgroups auszutauschen. 
Doch. Es ist moeglich. Beispielsweise ist ha /SCHULE eine Hierachie
die im Internet als schule.* bekannt ist. Zwischen URANUS und SOL wird
das "wild" gegated. Wir kommen uns trotzdem nicht in die Quere. Mir
znet.* (oder nach der Vereinheitlichung zer.*) waere das genauso
moeglich, WENN nicht - ja WENN nicht, die GateBau-Konformen Gateways
alles kalt lassen wuerde, und trotzdem einfach froehlich die Sachen
ins Z-Netz gaten und damit immer Probleme erzeugt haben (ich erinnere
an das Problem der Crosspostings, die auch heute noch zu Dupes fuehren
wuerden und fuehren - wenn wir das von unserer Seite nicht einfach
durch "nichtverbreitung" unterbinden wuerden). 

Wir haben damals gesagt: Wir werden uns nicht weiter Angriffen der
GateBau aussetzen, weil die einfach bestimmte Probleme nicht sehen
wollen - obwohl Loesungsmoeglichkeiten angeboten wurden. Also ziehen
wir uns in die Schmollecke zurueck, machen unseren Kram und gehen
damit erstmal restriktiv um.

Terra
-- 
-----------------------------------------------------------------------------
!   Frank Simon (Terra), Ammerlaender Heerstr. 389, D-2900 Oldenburg, FRG   !
! terra@sol.ccc.de, terra@sol.zer, ext/simon@kmx.gmd.dbp.de, +49 441 76206  !
-----------------------------------------------------------------------------