Dupes durch Crossposting
terra
folgenes Problem:
Die Sol und die UniOl sind ueber eine Software (kein Gateway) ans
Zerberus angeschlossen. die zer.* und cl.* Gruppen werden von der
UniOl nur zur Sol gespoolt. Beide Systemen geben diese Gruppen an
niemanden weiter. Artikel sollen nur ueber diesen Weg geschickt
werden, weil nur die Software auf der Sol weiss, wie sie die Adressen
z.B. unter der Domain uni-oldenburg.de auf uniol.zer abzubilden
hat, etc.
Nun kommt es aber manchmal vor, dass jemand ein Crossposting macht.
Also z.B. auf der uniol ein "zer.z-netz.news,sub.general". Der
Artikel geht dann natuerlich ordnungsgemaess ueber Sol ins Zerberus.
Nun kann es vorkommen, dass ueber die Verteiung "sub" der Artikel
bei einen UUCP-Zerberus-Gateway landet, sich dieser dafuer
zustaendig fuehlt und das ganze ins Zerberus leitet. Jetzt entstehen
dabei potentiell zwei Probleme:
a) die Artikel landen im Zerberus als Dupe. (Message-ID wird 1:1
uebernommen).
b) die Sol und das Gateway erzeugen eine Message-ID gemaess Hannover-
Protokoll, aber der Absender ist verschieden. So wird der Absender
des Beitrages via Sol US...@UNIOL.ZER lauten. Ueber das Gateway wird
z.B. USER%ARBI.IN...@GATEWAY.ZER oder andere Konstrukte
erzeugt. Das heisst, dass im Zerberus dann die selbe Mail mit
zwei Adressen rumliegen. Dabei ist nur die eine eigentlich
administrativ korrekt.
Dann gibt es noch den Fall, dass irgendjemand im Subnet ein Cross-
posting obiger Art abschickt, und das ganze ueber die Sub-Verteilung
hier landet. Dann wird das Posting hier kommentarlos geloescht. Ein
Gateway wird sich schon zustaendig fuer fuehlen.
Das ganze schliesst aber immer noch nicht _alle_ Dupes aus. Das ganze
funktioniert naemlich nur, wenn sich die Gateway angewoehnen sich nur
fuer "ihre" Rechner als Gateway zustaendig fuehlen. Solange das nicht
gilt, funktioniert das ganze System nicht.
Nur so als Anregung fuer Hannover ...
Terra
--
-------------------------------------------------------------------------------
! Frank Simon (Terra), Ammerlaender Heerstr. 389, D-2900 Oldenburg, FRG !
! te...@sol.ccc.de, te...@sol.zer, ext/si...@kmx.gmd.dbp.de, +49 441 76206 !
! Bisher habe ich noch keine Prognose eines BWLer gehoert, die nicht von !
! einen anderen widerlegt wurde. (Vera) !
-------------------------------------------------------------------------------
Frank Simon
urlichs
schreibt te...@sol.ccc.de (Frank Simon):
<
< [ Nicht funktionierende Dupe-Vermeidungsregeln ]
<
< Das ganze schliesst aber immer noch nicht _alle_ Dupes aus. Das ganze
< funktioniert naemlich nur, wenn sich die Gateway angewoehnen sich nur
< fuer "ihre" Rechner als Gateway zustaendig fuehlen. Solange das nicht
< gilt, funktioniert das ganze System nicht.
<
nicht vernuenftig. Ich halte solche Einschraenkungen fuer undurchsetzbar:
es ist schlichtweg unmoeglich, feste "Zustaendigkeitsbereiche" fuer Gates
festzulegen, wenn sich die Netztopologie auf beiden Seiten staendig aendert
und (Subnetz) die Artikelpfade eh total verschlungen sind.
Das einzige, das das Problem loest, ist eine vernuenftige
Gate-Implementierung, die dafuer sorgt, dass
- Message-IDs eineindeutig vergeben werden
- Nachrichten zer->sub->zer und sub->zer->sub im wesentlichen unveraendert
bleiben.
Fuer ersteres sorgen schon die "alten" Gatebau-Regeln. Was noch fehlt, sind
eindeutige Methoden der Adresswandlung (us...@zer.sub.org vs. us...@zer.de vs.
user@irgendwas.*.uni-oldenburg.*) und die eindeutige Zuordnung von
Newsgroup-Namen.
Wenn diese Regeln erfuellt sind, ist es naemlich _egal_, wieviele Gates was
wohin gaten, weil dabei nix kaputtgeht. Darueber, ob solche Mehrfachgaterei
ueberhaupt erwuenscht ist, kann mensch danach immer noch reden; aber das
Problem als Ganzes zu verbieten hat noch nie funktioniert...
--
Matthias Urlichs -- url...@smurf.sub.org -- url...@smurf.ira.uka.de /(o\
humboldtstrasse 7 -- 7500 karlsruhe 1 -- germany -- +49-721-9612521 \o)/
Matthias Urlichs
< funktioniert naemlich nur, wenn sich die Gateway angewoehnen sich nur
< fuer "ihre" Rechner als Gateway zustaendig fuehlen. Solange das nicht
< gilt, funktioniert das ganze System nicht.
<
nicht vernuenftig. Ich halte solche Einschraenkungen fuer undurchsetzbar:
es ist schlichtweg unmoeglich, feste "Zustaendigkeitsbereiche" fuer Gates
festzulegen, wenn sich die Netztopologie auf beiden Seiten staendig aendert
und (Subnetz) die Artikelpfade eh total verschlungen sind.
Das einzige, das das Problem loest, ist eine vernuenftige
Gate-Implementierung, die dafuer sorgt, dass
- Message-IDs eineindeutig vergeben werden
- Nachrichten zer->sub->zer und sub->zer->sub im wesentlichen unveraendert
bleiben.
Fuer ersteres sorgen schon die "alten" Gatebau-Regeln. Was noch fehlt, sind
eindeutige Methoden der Adresswandlung (us...@zer.sub.org vs. us...@zer.de vs.
user@irgendwas.*.uni-oldenburg.*) und die eindeutige Zuordnung von
Newsgroup-Namen.
Wenn diese Regeln erfuellt sind, ist es naemlich _egal_, wieviele Gates was
wohin gaten, weil dabei nix kaputtgeht. Darueber, ob solche Mehrfachgaterei
ueberhaupt erwuenscht ist, kann mensch danach immer noch reden; aber das
Problem als Ganzes zu verbieten hat noch nie funktioniert...
--
Matthias Urlichs -- url...@smurf.sub.org -- url...@smurf.ira.uka.de /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany -- +49-721-9612521 \o)/
terra
url...@smurf.sub.org (Matthias Urlichs) writes:
>nicht vernuenftig. Ich halte solche Einschraenkungen fuer undurchsetzbar:
>es ist schlichtweg unmoeglich, feste "Zustaendigkeitsbereiche" fuer Gates
>festzulegen, wenn sich die Netztopologie auf beiden Seiten staendig aendert
>und (Subnetz) die Artikelpfade eh total verschlungen sind.
Es hat jetzt fast nicht geklappt, vernueftig mit MEssage-Ids umzugehen.
Waerend die Anmeldung bei Gateways, dass mensch darueber arbeiten will
schon laenger sehr gut funktioniert hat (z.B. ucerzp wg Realnames).
Bei mir habe ich das auch eingebaut und es ist ueberhaupt kein Problem. Es
klappt nur nicht, solange nicht die Gateways das von Natur aus machen.
>Das einzige, das das Problem loest, ist eine vernuenftige
>Gate-Implementierung, die dafuer sorgt, dass
>- Message-IDs eineindeutig vergeben werden
Das reicht eben NICHT aus. Das habe ich ja geschrieben. Woher sollen die
anderen Gateway bitte wissen, dass sie z.B. aus palantir.north.de ein
sol.zer zu machen haben ?
>Fuer ersteres sorgen schon die "alten" Gatebau-Regeln. Was noch fehlt, sind
>eindeutige Methoden der Adresswandlung (us...@zer.sub.org vs. us...@zer.de vs.
>user@irgendwas.*.uni-oldenburg.*) und die eindeutige Zuordnung von
>Newsgroup-Namen.
Schoen gesagt. Fuer sowas braeuchten wir nicht eine lose Gateway-Gruppe
sondern eine Gateway-Koordination, wo mensch dafuer entsprechende Maps
anfordern kann und regelmaessig bekommt, wie nach dem Vorbild von DEDOMAIN
NAMES oder die Maps fuer die Umsetzung Domain/X.400-Adressen.
Terra
--
-------------------------------------------------------------------------------
! Frank Simon (Terra), Ammerlaender Heerstr. 389, D-2900 Oldenburg, FRG !
! te...@sol.ccc.de, te...@sol.zer, ext/si...@kmx.gmd.dbp.de, +49 441 76206 !
-------------------------------------------------------------------------------
Frank Simon
url...@smurf.sub.org (Matthias Urlichs) writes:
>nicht vernuenftig. Ich halte solche Einschraenkungen fuer undurchsetzbar:
>es ist schlichtweg unmoeglich, feste "Zustaendigkeitsbereiche" fuer Gates
>festzulegen, wenn sich die Netztopologie auf beiden Seiten staendig aendert
>und (Subnetz) die Artikelpfade eh total verschlungen sind.
Es hat jetzt fast nicht geklappt, vernueftig mit MEssage-Ids umzugehen.
Waerend die Anmeldung bei Gateways, dass mensch darueber arbeiten will
schon laenger sehr gut funktioniert hat (z.B. ucerzp wg Realnames).
Bei mir habe ich das auch eingebaut und es ist ueberhaupt kein Problem. Es
klappt nur nicht, solange nicht die Gateways das von Natur aus machen.
>Das einzige, das das Problem loest, ist eine vernuenftige
>Gate-Implementierung, die dafuer sorgt, dass
>- Message-IDs eineindeutig vergeben werden
Das reicht eben NICHT aus. Das habe ich ja geschrieben. Woher sollen die
anderen Gateway bitte wissen, dass sie z.B. aus palantir.north.de ein
sol.zer zu machen haben ?
>Fuer ersteres sorgen schon die "alten" Gatebau-Regeln. Was noch fehlt, sind
>eindeutige Methoden der Adresswandlung (us...@zer.sub.org vs. us...@zer.de vs.
>user@irgendwas.*.uni-oldenburg.*) und die eindeutige Zuordnung von
>Newsgroup-Namen.
Schoen gesagt. Fuer sowas braeuchten wir nicht eine lose Gateway-Gruppe
sondern eine Gateway-Koordination, wo mensch dafuer entsprechende Maps
anfordern kann und regelmaessig bekommt, wie nach dem Vorbild von DEDOMAIN
NAMES oder die Maps fuer die Umsetzung Domain/X.400-Adressen.
Terra
--
-------------------------------------------------------------------------------
! Frank Simon (Terra), Ammerlaender Heerstr. 389, D-2900 Oldenburg, FRG !
! te...@sol.ccc.de, te...@sol.zer, ext/si...@kmx.gmd.dbp.de, +49 441 76206 !
-------------------------------------------------------------------------------
Michael Keukert
terra @ sol.ccc.de (Frank Simon) schreibt:
FS> Bei mir habe ich das auch eingebaut und es ist ueberhaupt kein Problem. Es
FS> klappt nur nicht, solange nicht die Gateways das von Natur aus machen.
Ich denke, Du waerest kein Gateway?
Das war uebrigens der running gag auf unserem Treffen in Hannover:
"Der Gateway, der hartnaeckig behauptet er waere gar keiner" ...
Kai Henningsen
te> Von: terra @ sol.ccc.de (So, 15.12.91 08:26)
te>> Das einzige, das das Problem loest, ist eine vernuenftige
te>> Gate-Implementierung, die dafuer sorgt, dass
te>> - Message-IDs eineindeutig vergeben werden
te> Das reicht eben NICHT aus. Das habe ich ja geschrieben. Woher sollen die
te> anderen Gateway bitte wissen, dass sie z.B. aus palantir.north.de ein
te> sol.zer zu machen haben ?
Das haben sie eben NICHT zu machen. Wer so etwas macht oder braucht, ist
"broken".
te> sind >eindeutige Methoden der Adresswandlung (us...@zer.sub.org vs.
te> us...@zer.de vs. >user@irgendwas.*.uni-oldenburg.*) und die eindeutige
Haben wir doch (ausser bei Fido, da werden eben die Regeln noch diskutiert; aber
es wird wohl auf dasselbe Prinzip hinauslaufen):
Es gibt 2 Moeglichkeiten:
a. Man erzeugt eine Mitteilung mit vollstaendiger Domain. Alle Gates muessen
diese Domain respektieren. Nur Trivialmappings sind erlaubt, falls das Netz
zu dumm ist (also zB Bang-Pfade unter uucp oder die bekannten %-Macro-Hacks
im Z-Netz).
b. Wenn das Netz fuer a zu dumm ist (und NUR dann), legt man *eine* Domain fest,
die alle Gates von diesem Netz zu einem anderen benutzen (siehe die Liste in
/T-NETZ/MACROS im Fall Z-Netz).
te> Zuordnung von >Newsgroup-Namen.
Na ja, *das* ist eher trivial, denke ich - und auf jeden Fall eine rein
administrative Frage.
te> Schoen gesagt. Fuer sowas braeuchten wir nicht eine lose Gateway-Gruppe
te> sondern eine Gateway-Koordination, wo mensch dafuer entsprechende Maps
Dafuer hatten wir ja die Gruppe GATE-BAU erfunden, deren Routing wir jetzt mit
Hochdruck in Ordnung bringen wollen. Da kann man entweder solche Fragen klaeren
oder einen Mechanismus dafuer auskochen.
MfG Kai
Frank Simon
Michael...@ac2.maus.de (Michael Keukert) writes:
>terra @ sol.ccc.de (Frank Simon) schreibt:
>FS> Bei mir habe ich das auch eingebaut und es ist ueberhaupt kein Problem. Es
>FS> klappt nur nicht, solange nicht die Gateways das von Natur aus machen.
> Ich denke, Du waerest kein Gateway?
Hah !!!! Da steht "solange nicht die Gateways das" .. da steht nicht
"die anderen Gateways". :-)
Darauf hatte ich geachtet. :-)
> Das war uebrigens der running gag auf unserem Treffen in Hannover:
> "Der Gateway, der hartnaeckig behauptet er waere gar keiner" ...
Gut. :-) Inzwischen haben wir uns entschlossen faktisch die Probleme die
m.E. durch Defizite in der Gateway-Koordination und den Richtlinien
entstanden sind durch "Schildkroetenmethode" zu ignorieren. Wir werden
riguros auf administrativer Ebene dafuer Sorgen, dass keine Artikel
von UNIOL und SOL AUSSER an UniOl und Sol rausgehen.
Beide Maschinen sind Zerberus-Rechner und als solche gemeldet. Die verwendete
Zerberus-Software ist abgenommen. Gecrosspostete Beitraege werden durch zwei
technische und eine administrative Massnahme nicht ueber sonstwas-uniol-sol
laufen. Fuer Beitraege die ueber die Sub-Verteilung von der UniOl auf anderen
Gateways gegated werden, koennen und wollen wir keine Verantwortung
uebernehmen.
SOLLTEN Probleme entstehen, dann zeigen wir uns unschuldig ... den wir haben
dann alle notwendigen Massnahmen ergriffen. :-)
Gerade habe ich noch eine Mail von Volker Ulle bekommen. Demnach darf ich
mein System eben nicht SOL.ZER und sol.ccc.de nennen, weil das zu den
Verwicklungen fuehrt. Sollte ich das richtig verstehen (auf die Mail gehe
ich dann im Detail gegenueber Volker ein), dann muesst ihr euch was neues
ausdenken. Einem Zerberus-System (und das ist die Sol) kann nicht verboten
werden neben ihren Zerberus-Namen eine Domain ihrer Wahl zu fuehren. DAS
muessen die Gateway in beiden Richtung auch unterstuetzen. Anders geht das
nicht. Es gibt einige Zerberus-Systeme die z.B. unter den Domains .north.de
oder .in-berlin.de laufen. Fuer die gilt faktisch dasselbe.
Kai Henningsen
MH> Z.B. ".ZER" -> ".zer.suub.org" (und NICHTS anderes)
^^
Das war aber ein Vertipper, ja?! :-)
MfG Kai
Frank Simon
Hallo,
url...@smurf.sub.org (urlichs) writes:
>in sub.gateways, artikel <25...@sol.ccc.de>,
> schreibt te...@sol.ccc.de (Frank Simon):
>nicht vernuenftig. Ich halte solche Einschraenkungen fuer undurchsetzbar:
>es ist schlichtweg unmoeglich, feste "Zustaendigkeitsbereiche" fuer Gates
>festzulegen, wenn sich die Netztopologie auf beiden Seiten staendig aendert
>und (Subnetz) die Artikelpfade eh total verschlungen sind.
Das sehe ich anders, aber eine andere Loesung ist mir auch recht. :-)
>Das einzige, das das Problem loest, ist eine vernuenftige
>Gate-Implementierung, die dafuer sorgt, dass
>- Message-IDs eineindeutig vergeben werden
>- Nachrichten zer->sub->zer und sub->zer->sub im wesentlichen unveraendert
> bleiben.
Jein. Ich habe eine Domain-Adresse, die relativ netzunabhaengig ist mit
ISO-Coutrycode (sol.ccc.de). Desweiteren habe ich eine netzspezifische
Adresse im Zerberus (sol.zer), die ich auch gern behalten will. Selbiges
gilt auch fuer arbi.informatik.uni-oldenburg.de (uniol.zer).
Das ganze hat einfach Vorteile, die ich mal vor geraumer Zeit dargelegt
hatte. Mir will scheinen, dass genau dies aber nicht machbar ist und mit
deinen beiden Praemissen nicht moeglich waere. In einer Maildiskussion
mit Volker Ulle habe ich paar Dinge eingesehen (obwohl es Flames waren. :-) )
und die MessageId-Routine wird bei mir geaendert (auf moeglichst die selbe,
die uzercp benutzt).
Aber was nuetzt das im Zweifelsfall ?
Gehen meine Artikel zwar ins Zerberus, aber in einen Teil des Zerberus
steht da terra%sol.$uu...@uucp.zer und in einen anderen Teil dann mit
te...@sol.zer (oder demnaechst dann auch frank...@sol.zer) ?
Oder muss im Zerberus gar der Absender UND die MesageID gleich sein, dann
gibt es weiter Dupes ? Irgendwie ist das zu teilen unklar.
Die Aussage, dass es unmoeglich ist den Gateways keine Zustaendigkeiten
zuzuweisen und/oder keine Maps a la DEDOMAIN NAMES fuer die Wandlung zu
verwenden (in beschraenkter Form gibt es sowas ja schon fuer die Makros
bei den Gateways), kann ich nicht akzeptieren. Es wurde bis dato nur
nicht mal versucht.
>Wenn diese Regeln erfuellt sind, ist es naemlich _egal_, wieviele Gates was
>wohin gaten, weil dabei nix kaputtgeht. Darueber, ob solche Mehrfachgaterei
>ueberhaupt erwuenscht ist, kann mensch danach immer noch reden; aber das
>Problem als Ganzes zu verbieten hat noch nie funktioniert...
Das Problem will ich auch nicht verbieten. :-) Meiner Meinung nach kann
das Problem nicht geloesst werden, in dem solche Adresswandlung (sol.ccc.de
-> sol.zer) einfach verboten werden. :-)
Aber unabhaengig davon, ob ich glaube ob ein Zustaendigskeitsbereich
moeglich ist oder nicht (jede andere Loesung ist mir auch lieber), sind
wir wohl einer Meinung. :-)
Terra
--
-------------------------------------------------------------------------------
! Frank Simon (Terra), Ammerlaender Heerstr. 389, D-2900 Oldenburg, FRG !
! te...@sol.ccc.de, te...@sol.zer, ext/si...@kmx.gmd.dbp.de, +49 441 76206 !
! Sie kennt weder Freund noch Feind - nur lohnende Ziele (Fr. ueber Z.) !
-------------------------------------------------------------------------------
Frank Simon
url...@smurf.sub.org (urlichs) writes:
>in sub.gateways, artikel <25...@sol.ccc.de>,
> schreibt te...@sol.ccc.de (Frank Simon):
>nicht vernuenftig. Ich halte solche Einschraenkungen fuer undurchsetzbar:
>es ist schlichtweg unmoeglich, feste "Zustaendigkeitsbereiche" fuer Gates
>festzulegen, wenn sich die Netztopologie auf beiden Seiten staendig aendert
>und (Subnetz) die Artikelpfade eh total verschlungen sind.
Das sehe ich anders, aber eine andere Loesung ist mir auch recht. :-)
>Das einzige, das das Problem loest, ist eine vernuenftige
>Gate-Implementierung, die dafuer sorgt, dass
>- Message-IDs eineindeutig vergeben werden
>- Nachrichten zer->sub->zer und sub->zer->sub im wesentlichen unveraendert
> bleiben.
Jein. Ich habe eine Domain-Adresse, die relativ netzunabhaengig ist mit
ISO-Coutrycode (sol.ccc.de). Desweiteren habe ich eine netzspezifische
Adresse im Zerberus (sol.zer), die ich auch gern behalten will. Selbiges
gilt auch fuer arbi.informatik.uni-oldenburg.de (uniol.zer).
Das ganze hat einfach Vorteile, die ich mal vor geraumer Zeit dargelegt
hatte. Mir will scheinen, dass genau dies aber nicht machbar ist und mit
deinen beiden Praemissen nicht moeglich waere. In einer Maildiskussion
mit Volker Ulle habe ich paar Dinge eingesehen (obwohl es Flames waren. :-) )
und die MessageId-Routine wird bei mir geaendert (auf moeglichst die selbe,
die uzercp benutzt).
Aber was nuetzt das im Zweifelsfall ?
Gehen meine Artikel zwar ins Zerberus, aber in einen Teil des Zerberus
steht da terra%sol.$uu...@uucp.zer und in einen anderen Teil dann mit
te...@sol.zer (oder demnaechst dann auch frank...@sol.zer) ?
Oder muss im Zerberus gar der Absender UND die MesageID gleich sein, dann
gibt es weiter Dupes ? Irgendwie ist das zu teilen unklar.
Die Aussage, dass es unmoeglich ist den Gateways keine Zustaendigkeiten
zuzuweisen und/oder keine Maps a la DEDOMAIN NAMES fuer die Wandlung zu
verwenden (in beschraenkter Form gibt es sowas ja schon fuer die Makros
bei den Gateways), kann ich nicht akzeptieren. Es wurde bis dato nur
nicht mal versucht.
>Wenn diese Regeln erfuellt sind, ist es naemlich _egal_, wieviele Gates was
>wohin gaten, weil dabei nix kaputtgeht. Darueber, ob solche Mehrfachgaterei
>ueberhaupt erwuenscht ist, kann mensch danach immer noch reden; aber das
>Problem als Ganzes zu verbieten hat noch nie funktioniert...
Martin Husemann
te...@sol.ccc.de (Frank Simon) writes:
>Aber was nuetzt das im Zweifelsfall ?
>Gehen meine Artikel zwar ins Zerberus, aber in einen Teil des Zerberus
>steht da terra%sol.$uu...@uucp.zer und in einen anderen Teil dann mit
>te...@sol.zer (oder demnaechst dann auch frank...@sol.zer) ?
>Oder muss im Zerberus gar der Absender UND die MesageID gleich sein, dann
>gibt es weiter Dupes ? Irgendwie ist das zu teilen unklar.
Ganz einfach: angenommen, wir haetten den 2.3.92 und auch die SOL waere
GateBau-Konform.
Dann wuerde bei einem Cross-Posting der von Terra beschriebene Effekt (unter-
schiedliche Absenderangaben) auftreten.
a) das hat keinen Einfluss auf die Dupe Erkennung im Z-NETZ. Zumindest
ZERBERUS benutzt dazu NUR die Message-ID. Wenn irgendein Z-NETZ
Programm das anders macht - selbst Schuld (und auch hier uninteressant,
solange die meisten Server ZERBERUS benutzen).
b) Wichtig ist die Situation, wenn die Nachricht wieder aus dem Z-NETZ
herauskommt: dann hat sie naemlich wieder den gleichen (Original-Absender)
und die gleiche Message-ID.
Also: kein Problem.
Gruss, Martin.
--
"Ich bin auch fuer putzfreundliche Schraenke!"
-- mein Schwager ueber die Unterdruckung der Frau im taeglichen Leben
Martin Husemann
>Aber was nuetzt das im Zweifelsfall ?
>Gehen meine Artikel zwar ins Zerberus, aber in einen Teil des Zerberus
>steht da terra%sol.$uu...@uucp.zer und in einen anderen Teil dann mit
>te...@sol.zer (oder demnaechst dann auch frank...@sol.zer) ?
>Oder muss im Zerberus gar der Absender UND die MesageID gleich sein, dann
>gibt es weiter Dupes ? Irgendwie ist das zu teilen unklar.
Ganz einfach: angenommen, wir haetten den 2.3.92 und auch die SOL waere
Frank Simon
m.hus...@bi-link.owl.de (Martin Husemann) writes:
> b) Wichtig ist die Situation, wenn die Nachricht wieder aus dem Z-NETZ
> herauskommt: dann hat sie naemlich wieder den gleichen (Original-Absender)
> und die gleiche Message-ID.
>Also: kein Problem.
Ok. Dann wissen wir also nur, dass ein Artikel im Zerberus mit zwei
verschiedenen Adresse steht. Wobei wir hier uniol.zer als korrekte
Adresse deklarieren. :-) Also sollte endlich mal der Schritt gemacht
werden, dass Gateways ueber eine Tabelle (viele Eintrage muss die nicht
haben. :-)) wissen, was sie wie zu wandeln haben. Die eine Richtung braucht
ihr ja eh (aus einigen Systemen wird .zer.de, andere comlink.de und wieder
andere zu ccc.de und die andere ist kein Problem, wenn der Willen dazu da ist.
Sobald das neue MessageID-Verfahren klar ist, baue ich das hier ein. Es
waere uebrigens nett, wenn ihr nicht jeder das einzeln entwickelt, sondern
das ihr die beiden Routinen (uucpmsgid->zermsgid und zermsgid->uucpmsgid)
mal postet. :-) Ihr spart den Leuten, die weniger Zeit haben dadurch
Arbeit und koennt gleichzeitig sicher sein, dass keine Implementationsfehler
auftreten.
Kai Henningsen
tc> ISO-Coutrycode (sol.ccc.de). Desweiteren habe ich eine netzspezifische
tc> Adresse im Zerberus (sol.zer), die ich auch gern behalten will. Selbiges
tc> gilt auch fuer arbi.informatik.uni-oldenburg.de (uniol.zer).
Die meines Erachtens einzig wahre Loesung fuer solche Probleme:
Beim Erzeugen der Mitteilung wird MsgId (und AbsenderId) festgelegt und dann
nie mehr veraendert.
Leider ist diese Loesung nicht unbegrenzt verwendbar, wegen diverser technischer
Probleme.
Ich denke, das GateBau-Prinzip ist ein vernuenftiger Kompromiss:
Jedes Netz mit derartigen einschraenkungen definiert eine Konvertierung zwischen
dem "allgemeinen" Format (das fuer obiges Ideal geeignet ist) und dem
netzinternen Format. Dazu gehoert insbesondere
* wie eine Mitteilung, die in diesem Netz entstanden ist, ihre "endgueltige"
(aeussere) Form bekommt
* wie die Informationen aus so einer aeusseren Form so in das Netzformat
uebertragen werden koennen, dass ein anderer Gateway sie wieder extrahieren kann
Natuerlich setzt das (eben fuer derartig eingeschraenkte Netze) voraus, dass sich
alle Gates an dies Prinzip halten.
tc> Das ganze hat einfach Vorteile, die ich mal vor geraumer Zeit dargelegt
Tja, solche Vorteile sind in technisch derart eingeschraenkten Netzen eben nicht
immer umzusetzen.
MfG Kai
Bruno Blissenbach
sagt Frank...@sol.ccc.de (Frank Simon) :
>
> m.hus...@bi-link.owl.de (Martin Husemann) writes:
> > b) Wichtig ist die Situation, wenn die Nachricht wieder aus dem Z-NETZ
> > herauskommt: dann hat sie naemlich wieder den gleichen (Original-Absender)
> > und die gleiche Message-ID.
> >Also: kein Problem.
> Ok. Dann wissen wir also nur, dass ein Artikel im Zerberus mit zwei
> verschiedenen Adresse steht. Wobei wir hier uniol.zer als korrekte
> Adresse deklarieren. :-)
Das ist Kaese, Terra. Eine message wird immer nur an einem Rechner
eingegeben, und selbst wenn der 1000 Netzadressen hat, dann fuehlt
er sich zur Zeit der Eingabe als maximal eine davon. Die und nur
die kommt in die message ID rein, die niemand mehr aendern darf (
wer's dennoch tut ist broken, macht einen Fehler) Womit es keine
Duplikate mehr geben darf.
Das betrifft nicht die Absender-Adresse, die koennte in unterschiedlicher
Form repraesentiert sein, in Abhaengigkeit von dem System, das gerade
eine Kopie der message hat, passend fuer das System umgesetzt. Ok?
> Also sollte endlich mal der Schritt gemacht
> werden, dass Gateways ueber eine Tabelle (viele Eintrage muss die nicht
> haben. :-)) wissen, was sie wie zu wandeln haben. Die eine Richtung braucht
> ihr ja eh (aus einigen Systemen wird .zer.de, andere comlink.de und wieder
> andere zu ccc.de und die andere ist kein Problem, wenn der Willen dazu da ist.
Das mag fuer "From: ", "Sender: ", "To: "und "Reply-To: " sowie Konsorten
gelten, fuer die message id waere es Schwachsinn!
> und koennt gleichzeitig sicher sein, dass keine Implementationsfehler
> auftreten.
Bzw. dass alle die gleichen Fehler drin haben. Das ist fuer das Umrechnen
von Message IDs jedenfalls sehr viel besser, als unterschiedliche Verfahren.
8-* Im Ernst, kein :-)
B.Blissenbach
- Domain: bru...@purodha.GUN.de GeoNet: MBK1:B.Blissenbach OshoNet: 49/52.
-- X.400: G=Bruno; S=Blissenbach; O=B.Blissenbach; PRM=GeoNet; ADM=DBP; CO=DE.