Michael Heydekamp ([EMAIL PROTECTED]) schrieb: > Joachim Merkel <[EMAIL PROTECTED]> wrote on 02.07.04:
>> Michael Heydekamp ([EMAIL PROTECTED]) schrieb: >>> in diesem Punkt den vorherigen Zustand als Temp-Fix erstmal wieder >>> herzustellen - dazu bitte Meinungen. >> Ja, TYP: BIN ist was anderes als Transfer-encoding-binary. > Abgesehen davon, dass "TYP: BIN" IMO exakt CTE binary entspricht: Was > heisst das "Ja"? Alten Zustand wiederherstellen? Deine Frage war doch "den alten Zustand wieder hergestellen" und ich schreibe ja. Also nochmal ja. "Abgesehen davon", f�hrte mein Hinweis, das sie nicht das gleiche seien, auf den Kern des Themas. Wenn die Passagen identisch sind, also *dasselbe* "meinen", hei�t es ja noch lange nicht, da� sie faktisch *gleich* sind. Wenn ZConnect voll bin�rf�hig ist, weil es bytecount - also einen LEN:-Header hat, dann ist es bei RFC eben noch nicht so. Wenn man mit einem solchen Header unter RFC arbeiten w�rde, k�me der Vorteil, da� es gegen fehlende trailing-spaces oder Ver�nderungen bei cr/lf robust ist, nicht mehr zum Tragen. > Wenn sich bewahrheiten sollte, dass der Text aus RFC2045 immer noch > aktuell ist, wuerde ich lieber einen Fix bauen, der *beide* Szenarien > (qp-codierte Binaerdaten und als "binary" deklarierte Textdaten) > korrekt behandelt. > MIME ist IMO noch gar nicht da angelangt, sowas wie unter ZConnect zu > machen, sondern es ist allenfalls angedacht. [...Text aus RFC2045...] > Auf die Passage war ich auch gestern abend noch gestossen. Ich kann > nur offen, dass sie noch der Realitaet entspricht. Da� sich der Zustand dahingehend �ndern soll, da� auch Blobs unencoded versandt werden k�nnen, ist ja schon lange ein Thema, aber ich habe nicht nur meine Zweifel, da� jemand einfach dazu einen bytecount- Header erfindet und implementiert, sondern ebenso, da� dieses Verfahren den Transport durch die Netze �bersteht. Wenn es kommt, wird es ein Verfahren sein, da� auf speziell daf�r vorgesehen Verbindungen zum Tragen kommt und nicht einfach in die gegenw�rtigen RFC-Netze geworfen wird. -- Salut _)oachim ------------------------------------------------------------------------ FreeXP Support-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
