Alfred Schroeder <[EMAIL PROTECTED]> wrote on 02.07.04:
> Michael Heydekamp ([EMAIL PROTECTED]) schrieb am 02.07.04:
>> Der jetzt notwendige Fix w�re also nicht, den obigen Fix wieder
>> r�ckg�ngig zu machen, sondern konsequenterweise bei als "binary"
>> deklarierten Nachrichten ein EOL erst gar nicht zu entfernen -
>> sondern 1:1 im Originalzustand zu belassen. Man k�nnte h�chstens
>> daran denken, in diesem Punkt den vorherigen Zustand als Temp-Fix
>> erstmal wieder herzustellen - dazu bitte Meinungen.
> Ich pl�diere f�r 1:1 durchreichen,
Aber eben das k�me einem neuerlichen Komplettumbau gleich. Nebenbei
h�ttest Du dann jede Menge LFs statt CRLFs als Zeilentrenner in Deiner
Mail, die ja eigentlich Text und gar kein Binary ist.
> zumal in echten Binarys 0A oder 0D durchaus vorkommen.
Klar k�men sie in uncodierten Bin�rdaten vor - sofern bei RFC �berhaupt
uncodierte Bin�rdaten vorgesehen sind.
Ich habe nach meinem Posting gestern abend noch etwas RFC-Lekt�re
betrieben. Derzeit stellt es sich f�r mich so dar, da� die MIME-
Spezifikation uncodierte Bin�rdaten prinzipiell ber�cksichtigt (genau
daf�r wurde CTE "binary" ja geschaffen), aber RFC2045 sagt andererseits
auch:
----------8<----------
> Mail transport for unencoded 8bit data is defined in RFC 1652. As of
> the initial publication of this document, there are no standardized
^^^^^ ^^^ ^^ ^^^^^^^^^^^^
> Internet mail transports for which it is legitimate to include
^^^^^^^^ ^^^^ ^^^^^^^^^^ ^^^ ^^^^^ ^^ ^^ ^^^^^^^^^^ ^^ ^^^^^^^
> unencoded binary data in mail bodies. Thus there are no
^^^^^^^^^ ^^^^^^ ^^^^ ^^ ^^^^ ^^^^^^ ^^^^ ^^^^^ ^^^ ^^
> circumstances in which the "binary" Content-Transfer-Encoding is
^^^^^^^^^^^^^ ^^ ^^^^^ ^^^ ^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^ ^^
> actually valid in Internet mail. However, in the event that binary
^^^^^^^^ ^^^^^ ^^ ^^^^^^^^ ^^^^
> mail transport becomes a reality in Internet mail, or when MIME is
> used in conjunction with any other binary-capable mail transport
> mechanism, binary bodies must be labelled as such using this
> mechanism.
----------8<----------
Und wenn ich's recht �berlege, habe ich auch noch nie eine RFC-Mail mit
uncodierten Bin�rdaten bewu�t und live gesehen.
Es w�re also zu kl�ren, ob der obige Text noch aktuell und zutreffend
ist. Wenn ja, habe ich ein gro�es Problem weniger und mu� nur eine
L�sung f�r solche d�mlicherweise als "binary" deklarierten Mails finden,
ohne den angesprochenen Fix f�r qp-codierte Bin�rdaten zu brechen. Das
sollte kein gr��eres Problem sein, man behandelt "binary" dann einfach
als "8bit".
Sollte er allerdings nicht (mehr) zutreffen und uncodierte Bin�rdaten im
RFC-Raum inzwischen vorkommen, dann m��ten die Lese/Schreibroutinen im
UUZ in der Tat komplett neu geschrieben werden. Derzeit arbeitet der
UUZ ausschlie�lich zeilenorientiert (wenn auch die Zeilen unbegrenzt
lang sein d�rfen).
Ich werde das Thema mal mit meinen RFC-Beratern diskutieren und in dcsn
ansprechen.
>> Und ganz dramatisch w�rde es werden, wenn nicht im "outer
>> labelling", sondern in einem der inneren Nachrichtenteile als CTE
>> "binary" deklariert ist - das w�rde n�mlich hei�en, da� der UUZ
>> komplett die einzelnen Teile der MIME-Nachricht parsen m��te,
Und das m��te dann auch gemacht werden, wenn uncodierte Bin�rdaten
ber�cksichtigt werden m��ten.
> Mir war ja klar, dass dieser Bug Arbeit f�r Dich bedeutet, aber wenn
> ich geahnt h�tte, *was* ich da lostrete, h�tte ich wohl eher
> geschwiegen und weiterhin die (wenigen) Rfc-Mails bearbeitet... ;-)
Nein, genau solche Dinge sind ja eminent wichtig, und sei es nur, da�
man etwaigen Handlungsbedarf bzw. dessen Nichtexistenz erstmal nur
erkennt und dokumentiert.
Michael
------------------------------------------------------------------------
FreeXP Support-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
