Content-Transfer-Encoding: binary

[Michael Heydekamp]

Joachim Merkel <j.merkel at tbx.berlinet.de> wrote on 03.07.04:

> Michael Heydekamp (my-news at freexp.de) 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.

Deine Ergänzung "TYP: BIN ist was anderes als Transfer-encoding-binary"
hinterließ bei mir den Eindruck, als würdest Du das sogar als
eigentliche und "echte" Lösung ansehen (und nicht nur als Temp-Fix).   
Das konnte ich mir nicht recht vorstellen, deshalb hatte ich
sicherheitshalber nochmal nachgefragt.

Denn "alten Zustand wiederherstellen" hieße ja auch, qp-codierte
Binärdaten nicht decodieren zu können, deshalb käme das für mich
wirklich nur als Temp-Fix in Frage.  Er wird IMO aber gar nicht nötig
sein.

Wobei sich, je länger ich darüber nachdenke, eine Reihe von Fragen
ergeben, die ich erst mal klären muß.

Derzeit neige ich dazu, bei Multiparts ein "outer labelling" im CTE- 
Header gänzlich zu ignorieren.  Nicht nur, um das von Alex vorgebrachte
Problem zu lösen, sondern auch, weil Multiparts mit äußerem CTE binary
schon seit jeher als "B" (statt als "M") in XP geflagged werden.   
Alleine das ist ja auch schon falsch - Multipart ist Multipart.

Das Ignorieren des äußeren CTE-Headers würde außerdem das Problem mit
den derzeit fehlenden CRLFs bereits lösen, aber da ist noch zu prüfen,
ob es z.B. Multiparts geben kann (bzw. ob sie standardkonform wären),
deren kompletter Body base64-codiert ist (inkl. der Boundaries und
allem, was zu einer Multipart gehört).  So daß die einzelnen Teile erst
nach einer b64-Decodierung zum Vorschein kämen... In diesem Fall könnte
man den Header nicht einfach ignorieren.

Des weiteren muß ich prüfen, ob der das Problem verursachende Fix
überhaupt und wirklich OK ist.  Bei base64-Binaries ist klar, wie die
Daten decodiert werden müssen, bei qp-Binaries bin ich jetzt gar nicht
(mehr) sicher, wie *uncodierte* Zeilenumbrüche behandelt werden müßten.   
Theoretisch müßten die Zeilen bei qp-Binaries durchgehend mit soft line
breaks versehen sein, aber das wird sich durch nochmalige RFC-Lektüre
hoffentlich klären lassen.

Ob und wie Singleparts in punkto Auswertung des CTE-Headers anders zu
behandeln sind als Multiparts, ist ein weiterer Punkt.

Dazu werde ich was in c.f.dev schreiben, sobald mir diese Dinge klar
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.

Schau mal in die einzelnen Teile der von Alex geschickten Nachricht.  Da
sehe ich z.B. "Content-Length: 1832" (obwohl diese gar nicht als binary
deklariert sind).

Aber das nur nebenbei, für die o.g. offenen Fragen ist das irrelevant.


        Michael