Michael Heydekamp ([EMAIL PROTECTED]) schreibt: > Was ich nur meinte:
> Wenn CHARSET: nicht existiert, liegt die Nachricht per Definition in > CP437 (aka "ZConnect-Zeichensatz" vor). > "TYP: TRANSPARENT" sagt mir jetzt: "Du darfst mich nicht nach ISO1 > oder sonstwas konvertieren". Vielleicht will man damit einfach nur > den konvertiertypischen Informationsverlust vermeiden. > Und wenn ich das nicht darf, m��te man ausgehend "IBM437" > deklarieren oder das ganze Ger�mpel UTF-8-codieren. Genau das ist die Frage. > F�r XP ist das irrelevant, weil es den Header nicht setzt, aber der > FreeXP-UUZ bekommt in der Praxis auch schon mal andere Nachrichten > vorgelegt. Unter ZConnect ist der CHARSET: eben nur optional. Bei der Weiterleitung in RFC-Netze kommt es dann zur willk�rlichen Festlegung. BTW ich halte auch viel von UTF-8, aber dazu mu� man erstmal wissen, welcher Zeichensatz dabei rauskommen soll. Und Deine Frage war ja wohl, was ist, wenn diese Angabe fehlt. Und die Frage ist nat�rlich ferner, ob es nicht ausgemachter Unsinn w�re, wenn man keinen Zeichensatz vorfindet, ihn willk�rlich in eine Bin�rnachricht mit textueller Struktur aus irgendwelchen Portabilit�tsbetrachtungen reinzumanschen. Es reicht wirklich, wenn sich das Programm f�r seine eigene Darstellung daran h�lt und nicht noch die anderen darauf festlegen will. >> Wie sich das auf den UUZ auswirkt oder auswirken m��te, wenn der >> TYP: TRANSPARENT zu einem CTE binary f�hrt, kann ich auch nur >> vermuten. > Einen Zusammenhang zu CTE binary sehe ich nicht, das ist > Transportebene. Die Bin�rnachricht mit textueller Struktur kannst Du Dir nur erlauben, wenn der Transportweg voll bin�rf�hig ist. Das Kuriose ist ja, das RFCs das unter anderem festlegen m�chten, ohne da� SMTP voll bin�rf�hig ist und ZConnect nicht um die M�ngel rumprogrammieren kann, weil es voll bin�rf�hig ist. Sobald Du ZConnect verl��t und nicht voll "tunnelst", gilt jetzt aus RFC-Sicht (!) die Festlegung von ZConnect, da� unbekannte TYP:-Header als reine Bin�rnachrichten zu betrachten sind. Anstatt also dem Rest der Welt etwa mit einer Erziehungsdikatur beizukommen, wird man sich an seinen eigenen Ma�st�ben messen m�ssen. >> Erstmal gehe ich davon aus, da� hier dann auch in Richtung RFC kein >> charset gesetzt werden mu�. > Auf jeden Fall, wenn es sich um eine Textnachricht handelt. Gar > keinen Charset zu deklarieren, w�re schlicht falsch. Halte ich f�r etwas �bertrieben, der eine hat dann ISO-8859-1 als Standardzeichensatz der andere IBM437. Wie soll das unter einen Hut gebracht werden? Du kannst dann nur noch eine reine Bin�rnachricht draus machen und application/octet-stream setzen und base64-codieren. -- Salut _)oachim ------------------------------------------------------------------------ FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
