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
