Joachim Merkel <[EMAIL PROTECTED]> wrote on 20.07.04:
> Michael Heydekamp ([EMAIL PROTECTED]) schreibt:
>> der ZConnect-Draft sagt zum TYP:-Header:
> [TYP: TRANSPARENT]
>> Wenn man das ernst nimmt, muesste man ZC-Puffer ohne
>> CHARSET:-Header, aber mit "TYP: TRANSPARENT" mit dem Zeichensatz
>> IBM437 deklarieren...?
> Wenn er nicht gesetzt ist, geht ZConnect - aber vermutlich nur f�r -
> eingehende Nachrichten vom ZConnect-Zeichensatz aus.
Ich denke, das h�ngt auch in diesem Fall immer noch vom CHARSET:-Header
ab. Wenn da "CHARSET: ISO1" steht, dann ist es eben ISO1, unabh�ngig
vom Typ.
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.
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.
> 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.
> 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.
Michael
------------------------------------------------------------------------
FreeXP Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
