🚀 go-pugleaf

us> Von : urlichs@smurf.sub.org (Di, 29.09.92 18:14)
us> Name: Matthias Urlichs
us> Box : University of Karlsruhe, FRG
us> MId : <1aa2tlINNo08@smurf.smurf.sub.org>
us> RId : <A48740@MS.maus.de>

us> Mal ne dumme Frage: Wen interessieren diese Teile eigentlich ueberhaupt?
us>
us> Die Header kann man innerhalb eines Netzes unbesehen durchreichen.

Nun, abgesehen davon, dass das spaetestens bei Betaetigen der Antwortfunktion
wieder interessant wird ... ich weiss ja nicht, wie das im Z-Netz gesehen wird;
aber nachdem wir im MausNet seit Anbeginn Wert darauf legen, die
Benutzerfuehrung in Deutsch zu halten, wirft das gewisse Probleme auf :-)

Uebrigens noch ein ganz anderes, vom Implementationsaufwand voellig unabhaengiges
Problem: zumindest bei uns ist die erhoehte Datenmenge durch RFC-typische Header
*nicht* vernachlaessigbar.

us> [...] loest man dadurch, dass man sich auf das Standardformat festlegt, das
us> eh von 99% aller Systeme gefahren wird [Tue, 29 Sep 1992 17:35:00 +0100] --
us> [...] -- und den Rest notfalls von den Gates ins Netz umwandeln laesst.

Hmmja, ich gebe zu, wenn jemand sagt "verwendet doch RFC", dann verstehe ich
das als "verwendet doch RFC so, wie es in den RFCs steht", und nicht "verwendet
etwas, was ein stark eingeschraenkter Spezialfall von RFC ist". Offenbar hattet
Ihr das anders gemeint.

us> Wenn du den Kram vollstaendig implementieren, alle Header parsen und auf
us> 822-Konformitaet untersuchen willst, hast du vielleicht recht.

Siehe oben: genau so hatte ich Euch verstanden ...

us> [...] Resent-XXX:-Header korrekt zu generieren.

Da gehen uebrigens die Meinungen auch auseinander, was korrekt ist. Einig ist
man sich wohl, was klug ist: komplette alte Message als Body einer neuen
Mitteilung mit neuem Header und ohne Resent-Headerfelder verpacken. Nur am
Rande ...

us> Solange alles in Domainform vorliegt (dafuer sorgen im Zweifelsfall eh die
us> Unixsysteme, die die RFC->ZCONNECT-Gates versorgen ;-) [...]

Das hab' ich auch mal geglaubt :-)

us> Schoen. Du sagst mir, welche Features von RFC 822 aus diesem Bereich du
us> fuer "nett" haelst (im Gegensatz zu "essentiell" und/oder zu "wird im
us> realen Mailverkehr nunmal benoetigt, um die Intention des Absenders oder
us> des Betreibers einer Mailingliste darzustellen"), und ich bin gerne
us> bereit, zu lernen.

Ich hatte nicht vor, das hier ex cathedra zu verkuenden. Eben deswegen ja
parallel meine Anfrage zu dem Thema. Ich habe nur in der Vergangenheit oefter
mal den Eindruck gehabt, einer Art Alles-oder-Nichts-Position
gegenueberzustehen.

Das ist uebrigens auch ein Problem. Ich sehe es schon vor mir: Netz X fuehrt
eingeschraenktes RFC-Format ein. Ein Gate/Netzprogramm von einem anderen
Autor/Pointprogramm/... verwendet ein RFC-Feature, das nicht vorgesehen war.
Und schon geht die Klopperei los, wer denn nun recht hat ...

MfG Kai