Joachim Merkel <[EMAIL PROTECTED]> wrote on 20.07.04:
> 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.
Soweit scheint mir das doch gesichert zu sein. Beides kann man machen
(praktisch ginge derzeit allerdings nur "IBM437").
>> 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.
Wieso willkürlich? Kein CHARSET:=Header => IBM437. So sagen doch die
ZC-Specs, oder nicht? Und so verfahren XP und der UUZ seit Ewigkeiten.
> BTW ich halte auch viel von UTF-8, aber dazu muß man erstmal wissen,
> welcher Zeichensatz dabei rauskommen soll.
Wie meinst Du das? UTF-8 soll rauskommen. Man muß nur wissen, was der
(lokale) Quellzeichensatz ist, um es korrekt codieren zu können.
Ein Zeichen ist in UTF-8 doch fest definiert, egal aus welchem
Quellzeichensatz es kommt.
Aber lassen wir UTF-8 mal beiseite, darum geht's im Moment nicht.
> Und Deine Frage war ja wohl, was ist, wenn diese Angabe fehlt.
Die Frage war eher, ob man wie bisher "TYP: TRANSPARENT" ignoriert und
bei fehlendem CHARSET:-Header weiterhin fröhlich nach ISO-8859-1
konvertiert (weil man bei fehlendem "CHARSET:" von CP437 ausgeht), oder
ob man den Wunsch des Erstellers respektiert und die Nachricht so
verschickt, wie sie ist (ob als "IBM437" deklariert oder UTF-8-codiert,
ist dabei zweitrangig und nahezu gleichwertig, außer daß "IBM437" viele
Programme nicht kennen, weil das kein IANA-registrierter MIME-Alias ist
und es für CP437 seltsamerweise auch keinen gibt).
>>> 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.
Sorry, ich komme nicht mit, was das mit Binärnachrichten zu tun hat.
Ich spreche von einer ganz normalen 8bit-Textnachricht, die der Autor
nicht zu konvertieren wünscht und das deshalb mit "TYP: TRANSPARENT"
kenntlich macht.
> 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.
TRANSPARENT ist aber doch nicht unbekannt...?
>> 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,
Das ist Gesetz, und zwar ein unumstößliches (RFC2076). Natürlich ist
der Parameter als solcher optional, aber wenn er nicht existiert, ist es
per Definition US-ASCII. Was in der Praxis i.d.R. dazu führt, daß bei
Nachrichten ohne deklarierten Charset der lokale Zeichensatz verwendet
wird.
> der eine hat dann ISO-8859-1 als Standardzeichensatz der andere
> IBM437.
Eben - und genau deshalb braucht man eine Charset-Deklaration. Nur dann
kann man ggf. lokal korrekt konvertieren.
> Wie soll das unter einen Hut gebracht werden?
Was, wie? Eben doch *durch* die Charset-Deklaration.
Die Frage ist doch genau umgekehrt: Wie soll man eine Nachricht
vernünftig lesen können, wenn man nicht weiß, in welchem Charset sie
vorliegt?
Ich bin jetzt ein bißchen verwirrt, weil wir hier gerade über die
Grundlagen von Zeichensatzkonvertierung und MIME reden, die ich
eigentlich abgehakt hatte und um die es mir auch gar nicht ging.
> Du kannst dann nur noch eine reine Binärnachricht draus machen und
> application/octet-stream setzen und base64-codieren.
Bis auf application/octet-stream alles Transportebene und kein
Zusammenhang zu "TYP: TRANSPARENT", IMO. Ob das b64-, qp- oder gar
nicht codiert ist, ist in diesem Zusammenhang wumpe und zudem eine
Sache, die die MTAs schon aushandeln.
Michael
------------------------------------------------------------------------
FreeXP Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
