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
