Header "TYP: TRANSPARENT"
Hi, der ZConnect-Draft sagt zum TYP:-Header: --8<-- Syntax: TYP: Funktion: Die TYP-Information gibt Auskunft ueber die Beschaffenheit des Nachrichtenkoerpers. Definierte Bedeutung haben die Kennungen "BIN" (fuer Binaernachricht), "TRANSPARENT" (fuer Nachrichtenkoerper, in denen keine Umlaute gewandelt werden duerfen), [...] --8<-- Ist das fuer XP bzw. UUZ relevant? Derzeit wuerde der UUZ naemlich 8bit-Zeichen konvertieren, wenn nicht gleichzeitig die Existenz des Headers CHARSET: genau das verhindert. Wenn man das ernst nimmt, muesste man ZC-Puffer ohne CHARSET:-Header, aber mit "TYP: TRANSPARENT" mit dem Zeichensatz IBM437 deklarieren...? Michael FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Header "TYP: TRANSPARENT"
Michael Heydekamp ([EMAIL PROTECTED]) schreibt: > der ZConnect-Draft sagt zum TYP:-Header: [TYP: TRANSPARENT] > --8<-- > Syntax: TYP: > Funktion: Die TYP-Information gibt Auskunft ueber die > Beschaffenheit des Nachrichtenkoerpers. Definierte > Bedeutung haben die Kennungen "BIN" (fuer > Binaernachricht), "TRANSPARENT" (fuer > Nachrichtenkoerper, in denen keine Umlaute > gewandelt werden duerfen), [...] > --8<-- > Ist das fuer XP bzw. UUZ relevant? Derzeit wuerde der UUZ naemlich > 8bit-Zeichen konvertieren, wenn nicht gleichzeitig die Existenz des > Headers CHARSET: genau das verhindert. Genaue Anwendungsfälle sind mir auch nicht bekannt bisher. Spielt wahrscheinlich nur eine Rolle bei Weiterleitung einer Nachricht im Original und vermutlich überwiegend bei PGP- oder generell verschlüsselten Nachrichten. Bei ausgehenden Nachrichten in RFC-Netze würde ich auf CTE binary tippen und CHARSET bliebe der bekannte oder in der Nachricht vorhandene. > 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. Wie und ob bei der Weiterleitung im Original überhaupt TYP: TRANSPARENT beachtet wird, ist mir nicht bekannt. Sollte er beachtet werden und kein CHARSET vorhanden sein, wäre zu vermuten, das es keine Rolle spielen sollte, weil der Header unter ZConnect optional ist. 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. Erstmal gehe ich davon aus, daß hier dann auch in Richtung RFC kein charset gesetzt werden muß. -- Salut _)oachim FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Header "TYP: TRANSPARENT"
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
Re: Header "TYP: TRANSPARENT"
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
Re: Header "TYP: TRANSPARENT"
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
Re: Header "TYP: TRANSPARENT"
Michael Heydekamp ([EMAIL PROTECTED]) schreibt: > Aber lassen wir UTF-8 mal beiseite, darum geht's im Moment nicht. Ja genau, es war ja wohl auch nur als Überlegung gedacht, wenn ich keinen charset habe, ob dann noch UTF-8 was bringt. >> 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). Das war auch meine Überlegung, wenn ich eine Nachricht ohne charset bekomme, dann legt mir die ZConnect-Draft nahe, diese im ZConnect-Zeichensatz anzuzeigen. Ob ich dieser auch noch beim Weiterversand diesen Zeichensatz verpassen darf, ist für mich eine weitere Überlegung. 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. Wenn der Header TYP: gesetzt ist, aber der Bezeichner nicht bekannt ist, wird von einer Binärnachricht ausgegangen. >> 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...? Aber in RFC nicht bekannt. Also liege ich doch nicht verkehrt, daß eine Nachricht ohne CHARSET, aber mit TYP: TRANSPARENT ins RFC-Land als Binärnachricht zu versenden ist. Du hast es doch hier nicht mit einem Versand ins ZConnect-Land zu tun, sondern stellst Dir eher die Frage, was kann ich tun, damit sie unter Umständen wenn sie wieder nach ZConnect zurückkommt, noch dieselbe ist. >>> 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. Tja. >> 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? Genau, da rät Dir der eine zu reinem Ascii, der andere zu IBM437 und der nächste sagt, wenn sie nicht 7-Bit-clean ist, dann nimm meinen Standardzeichensatz ISO-8859-1 > 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. Ich versuche das nur irgendwie einzusortieren. >> 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. Ja und wenn die Nachricht wieder nach ZConnect kommt, hat sie Zeichensatz ISO1 und der TYP: TRANSPARENT steht nirgendwo. -- Salut _)oachim FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Header "TYP: TRANSPARENT"
Joachim Merkel <[EMAIL PROTECTED]> wrote on 21.07.04: > Michael Heydekamp ([EMAIL PROTECTED]) schreibt: >> Aber lassen wir UTF-8 mal beiseite, darum geht's im Moment nicht. > Ja genau, es war ja wohl auch nur als Überlegung gedacht, wenn > ich keinen charset habe, ob dann noch UTF-8 was bringt. Wenn ich wirklich keinen Charset habe, kann ich gar nicht nach UTF-8 codieren, weil ich nicht weiß, welches Zeichen ich gerade codieren soll. UTF-8 kam mir bzgl. IBM437 nur deshalb in den Sinn, weil dort keine verlustbehaftete Konvertierung stattfindet (und insofern der Forderung im ZC-Draft Rechnung getragen wird), und "IBM437" halt zwar kein unzulässiger, aber doch extrem selten verwendeter und vermutlich noch seltener verstandener Charset im RFC-Umfeld ist. >> 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). > Das war auch meine Überlegung, wenn ich eine Nachricht ohne > charset bekomme, dann legt mir die ZConnect-Draft nahe, diese > im ZConnect-Zeichensatz anzuzeigen. > Ob ich dieser auch noch beim Weiterversand diesen Zeichensatz > verpassen darf, ist für mich eine weitere Überlegung. Dürfen tut man schon, wenn nicht gar müssen (letzteres ist ja das, was "TYP: TRANSPARENT" signalisiert, wenn ich's nicht ganz falsch verstanden habe). > Wenn der Header TYP: gesetzt ist, aber der Bezeichner nicht bekannt > ist, wird von einer Binärnachricht ausgegangen. >> TRANSPARENT ist aber doch nicht unbekannt...? > Aber in RFC nicht bekannt. Ok, aber ich bin ja im Moment der Konvertierung erstmal noch auf ZConnect-Seite (dort ist die Quelle). Und da kenne ich den Typ. Den Wert des TYP:-Headers als solchen transportiere ich in der konvertierten RFC-Nachricht ja gar nicht. > Also liege ich doch nicht verkehrt, daß eine Nachricht ohne CHARSET, > aber mit TYP: TRANSPARENT ins RFC-Land als Binärnachricht zu versenden > ist. Weiß nicht... Ich gehe auch nach nochmaliger Lektüre davon aus, daß wir es klarerweise mit einer Textnachricht in IBM437 zu tun haben (angenommen, CHARSET: existiert nicht). Und die darf eben nicht (verlustbehaftet) konvertiert werden. Man müßte wissen, was der genaue inhaltliche Hintergrund dieses Headers ist. Ich bin bisher davon ausgegangen, daß hier jemand z.B. eines der beliebten Bildchen aus Rahmen- und Blockgrafikzeichen gebastelt hat, das bei einer Konvertierung z.B. nach ISO-8859-1 weitgehend zerstört würde. Um das zu verhindern, setzt der User "TYP: TRANSPARENT". Davon ausgehend, nützt ein Binärtransport in den RFC-Raum insofern nichts, als daß bei app/o-s der Parameter "charset=" nicht existiert. Das Zielsystem wüßte daher nicht, in welchem Zeichensatz der Nachrichteninhalt darzustellen ist, geschweige denn, daß es sich überhaupt um Text handelt. Also stellt er die Daten - wenn überhaupt - z.B. auf einem Windows- System im lokalen Charset Win-1252 dar und heraus kommt nur Schrott... Das kann IMO nicht der Sinn von "TYP: TRANSPARENT" sein, zumal dann besser gleich "TYP: BIN" deklariert worden wäre, dann wäre die Absicht wenigstens eindeutig. > Du hast es doch hier nicht mit einem Versand ins ZConnect-Land zu tun, > sondern stellst Dir eher die Frage, was kann ich tun, damit sie unter > Umständen wenn sie wieder nach ZConnect zurückkommt, noch dieselbe > ist. Eher stelle ich mir erstmal die Frage, wie ich sie unbeschadet nach RFC kriege (bzw. ob das überhaupt das ist, was "TYP: TRANSPARENT" inhaltlich will). Aber OK, unter dem Gesichtspunkt Rückkehr nach ZConnect ist das wieder was anderes - da hülfe in der Tat nur binär, weil sonst die Gefahr bestünde, daß sie aus RFC als UTF-8 bei ZConnect ankommt, wo der Inhalt dann vermutlich als nachhaltig geschrottet empfunden wird. :) >> 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? > Genau, da rät Dir der eine zu reinem Ascii, der andere zu IBM437 > und der nächste sagt, wenn sie nicht 7-Bit-clean ist, dann nimm > meinen Standardzeichensatz ISO-8859-1 Deshalb: Bei text/* Charset deklarieren, dann gibt's auch kein Vertun. >>> 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. > Ja und wenn die Nachrich
Re: Header "TYP: TRANSPARENT"
Michael Heydekamp ([EMAIL PROTECTED]) schreibt: > 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). "Macintosh" scheint auch nicht sehr bekannt zu sein. s. Anhang. -- Salut _)oachim MAC_CHAR.PUF Description: Binary data FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Header "TYP: TRANSPARENT"
Joachim Merkel <[EMAIL PROTECTED]> wrote on 24.07.04: > Michael Heydekamp ([EMAIL PROTECTED]) schreibt: >> 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). > "Macintosh" scheint auch nicht sehr bekannt zu sein. s. Anhang. Ich meinte jetzt bei RFC-Mailreadern (mir ist das halt von Mozilla bekannt, daß es "IBM437" nicht kennt, "Macintosh" aber ganz bestimmt). Daß DUUCP damit nix anfangen kann, überrascht mich jetzt nicht. Wenn es wenigstens nur nicht immer den Mist a) konvertieren und b) mit "ISO1" deklarieren würde, dann könnte wenigstens XP solche Nachrichten korrekt anzeigen. Jedenfalls scheint mir der Puffer gründlich kaputtkonvertiert zu sein, Macintosh ist das eher nicht. Michael FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
