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
