Joachim Merkel <[EMAIL PROTECTED]> wrote on 28.05.04:
> Michael Heydekamp ([EMAIL PROTECTED]) schrieb:
>>> Es *wäre* beim erneuten Folden ein weiteres Leerzeichen drin, weil
>>> das beim Unfolden nach -uz das mit reinkommt, es sei denn, es wird
>>> genau an derselben Stelle wieder gefoldet.
>> Auch das kann ich nicht nachvollziehen und wäre ein Bug. Ob an der
>> ursprünglichen oder einer anderen Stelle gefoldet würde: Es wird
>> immer nur da gefoldet (und kann nur da gefoldet werden), wo sowieso
>> schon ein Leerzeichen vorhanden ist. Und wenn keines da ist, wird
>> auch nicht gefoldet.
> Ok. Wenn Du die im letzten Posting anliegende msg mal mit UUZ -uz
> behandelst, hast Du im unfoldet X-Face doch die Leerzeichen
> zusätzlich drin, die vor den gefoldeten Teilen in der msg stehen.
Nochmal ganz klar, damit's da keine Mißverständnisse gibt: Das
Leerzeichen ist *nicht* zusätzlich, sondern es wird lediglich ein
bereits vorhandes Leerzeichen beim Entfalten nicht entfernt und es darf
auch nicht entfernt werden. Entfalten heißt nix weiter als LF|CRLF
entfernen.
Wenn an der Stelle kein Leerzeichen hingehört oder X-Face:-Header
generell keine Leerzeichen enthalten können/dürfen (ich kenne die Specs
von X-Face: nicht), dann hätte das Programm, das den Header erzeugt, den
Header eben nicht einfach an einer oder mehreren beliebigen Stellen
falten dürfen.
Das "zusätzliche" Leerzeichen entsteht also - wenn überhaupt - nicht
durch den UUZ, sondern durch das Programm, das den Header an Stellen
faltet, wo vermutlich gar kein Leerzeichen existiert.
Vielleicht werfen die Programme, die X-Face: auswerten, Leerzeichen auch
generell raus - keine Ahnung, worauf man sich da geeinigt hat.
Es gibt nur eine RFC-konforme Möglichkeit, lange Strings ohne
Leerzeichen trotzdem an Pos. 78 oder früher zu falten: Den Header MIME-
codieren (notfalls mit Zeichensatz US-ASCII). Da Blanks zwischen
encoded words beim Entfalten und Decodieren entfernt werden müssen,
entstehen dann auch keine zusätzlichen und unerwünschten Leerzeichen.
> Die würden dann exakt an der Stelle wieder gefoldet. Das würde
> dann ja wohl klappen.
Das ja.
>> deshalb muß in uz-Richtung immer entfaltet werden.
> Genau das ist der Punkt.
Aber keiner, an dem wir irgendwas tun könnten oder müßten. Wenn der
X-Face:-Header an den gefoldeten Stellen im Ursprungszustand (den wir ja
nicht kennen) wirklich keine Leerzeichen enthielt, dann ist der Header
so, wie wir ihn in der RFC-Nachricht sehen, bereits defekt, bevor der
UUZ überhaupt erstmalig in uz-Richtung zum Zuge kommt.
> Ob es dem "Antragsteller" nun um X-Face ging oder nicht, es schien
> mir nur mal der Hinweis darauf passend, ob es überhaupt möglich ist,
> den Original-Header wieder unversehrt zu versenden.
Das ist absolut möglich und das kann der UUZ auch - nur kann und wird er
keine bereits defekt gefalteten Header wieder reparieren. Dazu müßte er
raten oder eine Glaskugel implementiert bekommen. ;)
Michael
------------------------------------------------------------------------
FreeXP Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
