+- README.TXT -----------------------------+
| |
| ReadMe zum "Enhanced UUZ" |
| (c) 2003 FreeXP |
| 30.08.2003 |
+------------------------------------------+
Da alles, was man für den Betrieb des "Enhanced UUZ" unbedingt wissen
muß, im Announce-Posting vom 06.06.2003 enthalten ist, besteht dieses
ReadMe der Einfachheit halber im wesentlichen aus einer Wiedergabe des
Textes dieses Postings.
Vorweg sei auf nur drei Punkte ausdrücklich hingewiesen:
1. Eine vollständige Dokumentation aller Änderungen ist in der Textdatei
UUZ_ENH.TXT (Zeichensatz: DOS-Codepage 437) enthalten, die diesem
Paket beiliegt. Die Lektüre wird unbedingt empfohlen.
2. Die Adressen der Bezugsquellen haben sich aufgrund der Umbenennung
von "OpenXP/16" nach "FreeXP" wie folgt geändert:
WWW: http://www.freexp.de/download.php#uuz_download
FTP: ftp://ftp.freexp.de/freexp/snapshot/uuz_enh.zip
HTTP: http://www.freexp.net/ftp/freexp/snapshot/uuz_enh.zip
Die vollständige Dokumentation ist jetzt verfügbar unter:
http://www.freexp.de/files/uuz_enhanced.html
3. User, die den Mail-/News-Client "XPNews" von Markus Kämmerer
einsetzen, müssen wegen eines Bugs in allen XPNews-Versionen bis
v1.2.2 sowie eines damit unverträglichen Bugfixes im UUZ unbedingt
auf XPNews v1.2.3 (Build 455) vom 06.06.2003 oder neuer updaten -
ansonsten ist Datenverlust bei eingehenden News-Batches garantiert!
Der entsprechende Passus im untenstehenden Posting ist insofern
nicht mehr auf dem aktuellen Stand, als daß kurz nach Erscheinen des
"Enhanced UUZ" eine gefixte XPNews-Version veröffentlicht wurde. Die
UUZ-Sonderversion für XPNews-User wird aus diesem Grund nicht mehr
zum Download angeboten.
Weitere Hintergrundinformationen dazu siehe XPNEWS.TXT.
4. Ältere UKAW-Versionen (z.B. v1.37g) erzeugen wie XPNews per Default
ebenfalls fehlerhafte News-Batches. Zur Vermeidung von Datenverlust
ist die Datei <Server>.RC abzuändern, Details dazu am Ende des
nachfolgenden Postings. UKA_PPP oder aktuelle UKAD/UKAW-Versionen
erzeugen RFC-konforme News-Batches und sind daher nicht betroffen.
Düsseldorf, 30. August 2003
----------------------------------------------------------------------
Empfaenger : de.comm.software.crosspoint
Empfaenger : crosspoint.openxp16.pub.allgemein
Absender : my@openxp16.de (Michael Heydekamp)
Software : CrossPoint [OpenXP/16] v3.40 RC3 (XMS) @ 1805032224 R/C816
Betreff : Announce OpenXP/16: Enhanced UUZ
Datum : Do 06.06.03, 00:00
----------------------------------------------------------------------
## WICHTIG: Wer sich für dieses Posting interessiert,
## möge es bitte *vollständig* lesen.
Hi XP'ler,
was im August 2002 als Reparatur an der fehlerhaften MIME-Codierung
langer Betreffzeilen von mir begonnen wurde, ist in einen umfassenden
Rewrite wesentlicher Teile des ZC<->RFC-Nachrichtenkonvertierers "UUZ"
ausgeufert, dessen Resultat nach einer mehrmonatigen Entwicklungs- und
Testphase - und gleichsam als Vorbote der nächsten OpenXP/16-Version -
nun heute als "Enhanced UUZ" veröffentlicht werden kann. :-)
Im Laufe der Entwicklung sowie der damit einhergehenden RFC-Recherche
wurden Altlasten (Bugs, Schlampereien, Nicht-Konformitäten mit geltenden
RFCs bzw. Usenet-Usancen) zutage gefördert, die ich in diesem Umfang
nicht erwartet hatte - sonst hätte ich vermutlich auch gar nicht erst
damit angefangen.
Das hauptsächliche Augenmerk bei der Entwicklung der nun vorliegenden
Fassung lag in der Folge ganz eindeutig darauf, den UUZ an den aktuellen
Stand geltender RFCs (speziell (son-of)1036, 2045/2047 und 2822) sowie
die im Usenet herrschende Praxis anzupassen und damit unter allen in der
XP-Umgebung denkbaren Umständen saubere RFC-Nachrichten ohne unzulässige
oder gar defekte Header bzw. Texte zu erzeugen, sowie bei eingehenden
Nachrichten die bisher (theoretisch wie real) eintretenden Datenverluste
und fehlerhaften Konvertierungen zu beseitigen.
Die von diesem "Enhanced UUZ" eingehend wie ausgehend produzierten und
sichtbaren Ergebnisse dürften in vielen Belangen denn auch eher als
Referenz-Implementation geeignet sein als wie bisher Anlaß zur Kritik zu
geben und die XP-User der permanenten Gefahr auszusetzen, für defekte
und/oder nicht RFC-konforme Nachrichten verantwortlich gemacht zu werden
(auch wenn diese Vorwürfe nicht in allen Fällen berechtigt waren).
Auszugsweise und exemplarische Kurzübersicht der Änderungen
-----------------------------------------------------------
1. Die gesamte Behandlung von RFC-Headern berücksichtigt jetzt bei
eingehenden und ausgehenden Nachrichten die in RFC2045/2047 (MIME),
RFC2822 (Mail) und (son-of)RFC1036 (News) niedergelegten Regeln und
interpretiert jetzt z.B. auch Kommentare, Phrasen, quoted-strings
und quoted-pairs in Adressen- und allen anderen Headern korrekt.
Auch werden z.B. mehrere Adressen in "From:"- und "Reply-To:"-
Headern jetzt nicht mehr vernichtet, korrekte "Cc:"-Header und
Adressenformate erzeugt u.v.m.
2. Bei eingehenden Nachrichten werden jetzt alle Header prinzipiell bis
zu einer Länge von 65500 Zeichen lesend und in vielen Fällen auch
schreibend verarbeitet. Dadurch z.B. keine gekürzten bzw. nicht
decodierten Betreff- oder Pfad-Header oder gar kompletter Verlust
von Message-IDs oder Adressen mehr.
3. Die MIME-Decodierung ist jetzt deutlich fehlertoleranter (bis an die
Schmerzgrenze dessen, was im Rahmen des "robustness principle" noch
vertretbar ist) und decodiert auch noch die defektesten in der
Praxis vorkommenden Header bei eingehenden Nachrichten. Gleich-
zeitig wurden u.a. einige Bugs beim Entfernen bzw. Nicht-Entfernen
von Leerzeichen behoben.
4. Etliche relevante RFC-Header werden jetzt zur Kontrolle im Original-
zustand und in voller Länge als Backup mit dem Prefix "X-Orig-" im
ZConnect-Header abgelegt.
5. Umfassende Erweiterungen und Korrekturen bei der Deklaration
(ausgehend) und Konvertierung (aus- und eingehend) von Zeichensätzen
(speziell UTF-7/8, darüber hinaus fünf neue Zeichensätze
implementiert, weitere folgen in Kürze)
6. Bei ausgehenden Nachrichten werden alle Header jetzt RFC-konform,
"minimal invasiv", unter Beachtung der unterschiedlichen Regeln für
strukturierte und unstrukturierte Header und vor allem ohne Zeichen-
verluste (!) codiert bzw. "gequotet" sowie ggf. gefaltet. Die aus
der Codierung bzw. dem "Quoten" von Headern resultierende größere
Länge ist bei allen relevanten Headern jetzt nicht mehr auf 254
Zeichen begrenzt, dadurch können z.B. keine defekten MIME-
Codierungen ohne Abschluß-Delimiter o.ä. mehr entstehen.
7. Massive Bugs beim Schreiben des Nachrichtentextes (Body) von
ausgehenden Nachrichten behoben, dadurch u.a. Datenverluste bei
"quoted-printable"-codierten Nachrichten, willkürliche Zeilen-
umbrüche nach 254 Zeichen und das mysteriöse Verschwinden von
Punkten am Zeilenanfang bei SMTP-Mails beseitigt.
8. Euro-Support für ein- und ausgehende Nachrichten implementiert
(Details siehe Dokumentation).
9. Etliche Variablen vergrößert.
10. Neuen Schalter "-gate" für UUZ-Externbetrieb implementiert (im
Zusammenhang mit XP von Bedeutung für User, die einen externen
Client wie UKA_PPP oder ältere UKAW-Versionen in einer ZConnect-Box
betreiben): Der Nachrichtentext wird auf das Vorkommen von 8bit-
Zeichen nach einer IBM=>ISO-Konvertierung geprüft und somit der
korrekte Zeichensatz deklariert, statt sich auf eine u.U. fehler-
hafte Angabe im "X-Charset:"-Header zu verlassen oder einfach blind
"ISO-8859-1" zu deklarieren. Weitere Details siehe Dokumentation.
11. Rund 90 weitere Änderungen und Bugfixes. =%-|
Vorsichtshalber sei angemerkt, daß nicht behauptet wird, daß dieser neue
UUZ zu 100% fehlerfrei ist oder daß man alles nicht sowieso noch viel
besser machen kann. ;-)
Bezugsquellen
-------------
Den "Enhanced UUZ" selbst gibt's hier:
WWW: http://www.openxp16.de/download.php#uuz_download
FTP: ftp://ftp.openxp16.de/openxp16/snapshot/uuz_enh.zip
HTTP: http://www.openxp16.net/ftp/openxp16/snapshot/uuz_enh.zip
Eine vollständige Dokumentation aller Änderungen (knapp 58KB Text, also
gut 16 eng beschriebene DIN-A4-Seiten) liegt dem "Enhanced UUZ" bei, ist
aber auch separat unter folgendem Link abrufbar:
http://www.openxp16.de/files/uuz_enhanced.html
Viel Spaß mit diesem neuen UUZ. Für Feedback sind wir ausgesprochen
empfänglich und bitten, Kritik, Hinweise (und gerne auch Lob) bevorzugt
in die OpenXP/16-Mailingliste oder -Newsgruppen zu senden.
Hinweise zur Benutzung
----------------------
1. Einige Änderungen und Erweiterungen werden erst mit der nächsten
OpenXP/16-Version in vollem Umfang zur Geltung kommen bzw. offenbar
werden (z.B. Euro-Support auch für ausgehende Nachrichten, Unter-
stützung mehrerer Antwort-an:-Header). Es ist aber sichergestellt,
daß der "Enhanced UUZ" ohne Probleme mit jeder aktuell in Benutzung
befindlichen OpenXP/16-Version eingesetzt werden kann und auch dort
in allen Einsatzbereichen zu deutlich besseren Ergebnissen führt.
2. Dieser UUZ kann wie alle bisherigen UUZs von OpenXP/16 *nicht* mit
XP2 eingesetzt werden. Evtl. wird zu einem späteren Zeitpunkt eine
mit XP2 kompatible Version veröffentlicht werden (Nachfragen dazu
nicht notwendig).
3. XPNews-User bitte die Warnung am Ende dieses Postings beachten!
Credits
-------
An der Entwicklung des "Enhanced UUZ" haben mittel- oder unmittelbar
mitgewirkt:
MY - Michael Heydekamp (Redesign/Rewrite des UUZ)
SV - Stefan Vinke (Anlaufstelle für programmiertechnische
Detailfragen während der Entwicklung)
JM - Joachim Merkel (Profiling / Performance-Optimierung)
JG - Jochen Gehring (Euro-Support, erweiterter Unicode-Support)
Des weiteren wurden der EOL-Bugfix für News-Batches von MK (Markus
Kämmerer) aus OpenXP/32 sowie die Unterstützung des Parameters
"-bBoxname" von MH (Max Huckenbeck) und des Headers "X-XP-MODE:" von
RB (Robert Böck) aus XP2 übernommen (wobei die beiden letzten
Änderungen für OpenXP/16 im Moment noch nicht praxisrelevant sind).
Johann Addicks - Tests, ZC/Gate-Konformität
Frank Ellermann - RFC-Recherche und -Interpretation (Mail)
Urs Janßen - RFC-Recherche und -Interpretation (News)
Joachim Merkel - RFC/ZC-Konformität, Tests, Designfragen
Dirk Nimmich - RFC-Recherche und -Interpretation (Mail/News)
Sebastian Weiser - RFC-Recherche und -Interpretation (Mail)
OpenXP/16 bedankt sich bei allen Beteiligten.
Abschließend eine ebenso wichtige wie deutliche WARNUNG:
--------------------------------------------------------
XP-User, die den externen Client "XPNews" von Markus Kämmerer einsetzen,
müssen wegen eines Bugs in XPNews sowie eines damit unverträglichen UUZ-
Bugfixes desselben Autors, der in den "Enhanced UUZ" übernommen wurde,
eine einmalig erscheinende Sonderversion dieses UUZ verwenden -
ansonsten ist Datenverlust beim Empfang von News-Batches garantiert!
Bitte dazu die nächste Nachricht lesen, die sich direkt auf diesen
Announce bezieht.
User der Clients UKA_PPP oder aktueller UKAW/UKAD-Versionen sind nicht
betroffen. Lediglich bei älteren UKAW-Versionen (z.B. v1.37g) ist es
erforderlich, in der Datei <Server>.RC den Eintrag "$newline: crlf"
abzuändern in "$newline: lf", um Datenverlust durch nicht RFC-konforme
Längenangaben im "rnews"-Header zu vermeiden.
Michael