🚀 go-pugleaf

kosta@kostis.kk.sub.org (Kosta Kostis) writes:
 > [ganz viel, das mir ein Followup auf hm@hcshh.hcs.de's Artikel
 >  erspart hat ;-)]
 > 
 > Und Deinen dann nicht mehr ganz so frisch gedruckten Text bekommt Dein
 > Kollege in Australien dann per Post oder FAX und darf den ganzen "Senf"
 > abtippen um Änderungen vorzunehmen, richtig?   ;-)

Richtig, auch ein Grund, warum Multimedia Mail erfunden wurde: Um die
Medienbrueche zu beseitigen, die z.B. die kooperative Textbearbeitung
in der Internet-Welt sehr erschweren.

 > In Deutschland finde ich ISO 8859-1 angebracht.

Das ist der Zeichensatz, der in Deutschland am meisten benutzt wird.
Aber der verwendete Zeichensatz muss ***IMMER*** im Header angegeben
werden, wenn er ungleich US-ASCII ist.  Sonst ist der Body nicht
interpretierbar.
Ich halte es auch fuer keine gute Idee, wenn wir MIME fuer Deutschland
so umdefinieren, dass "iso-8859-1" Standard ist, wenn kein Zeichensatz
angegeben ist. Dann funktioniert das ganze naemlich nicht mit Russland
(8859-5) oder Griechenland oder... und ist nicht mehr RFC-konform.

Es kostet nichts, den Newsreader einen entsprechendne Header per
default einsetzen zu lassen.

Die notwendigen Header sind:
    MIME-Version: 1.0		-- Kennzeichnung, dass es sich um eine
				   MIME-konforme Mitteilung handelt
    Content-Type: text/plain; charset=iso-8859-1
				-- Art des Inhalts und Zeichensatz
    Content-Transfer-Encoding: 8bit
				-- Umlaute uncodiert; das ist zwar
				   illegal, aber Praxis.  Legale,
				   aber leider ohne zusaetzliche
				   Software unlesbare Kodierungen
				   siehe RFC1341.

Die Header koennen per Default hinzugefuegt werden mit:

    elm: einfach in ~/.elm/elmheaders untereinander schreiben.
    nn:  Variable "news-header" setzen (nicht ausprobiert)
    rn/trn: Environmentvariable "NEWSHEADER" redefinieren. Das Format
	 ist leider etwas kryptisch, deswegen zitier ich den Header
	 hier mal:

NEWSHEADER="Newsgroups: %(%F=^$?%C:%F)\\nSubject: %(%S=^$?%\"\\n\\nSubject: \":Re: %S)\\n%(%R=^$?:References: %R\\n)Organization: %o\\nMIME-Version: 1.0\\nContent-Type: text/plain; charset=ISO-8859-1\\nContent-Transfer-Encoding: 8bit\\n\\n"

 > Ich finde das "Äußere" sehr wohl richtig. Wer sich noch nicht mal die Zeit
 > nimmt seinen Text in halbwegs ansprechende Form zu bringen, der hat sich
 > wohl auch nicht viel Zeit beim Formulieren des Inhalts gemacht. Wenn der
 > Inhalt nämlich jeweils gut durchdacht ist, kostet die "Aufbereitung" nur
 > einen Bruchteil der vorherigen Arbeit. Schlampige Form ist für mich ein
 > Anzeichen für schlampigen Inhalt...

Genau -- Hellmuth meinte wahrscheinlich, gutes Layout ersetzt bei 
Diplomarbeiten oefters guten Inhalt. 
Aber da es fuer Mail keine Noten gibt, faellt der Anreiz weg... ;-)

 > >> >------------------ ISO?  Nicht immer. Aber immer vfter! -------------------
 > 
 > >> was meint der mensch nur mit "vfter" ????
 > 
 > Der "mensch" kann dafür gar nix. Irgendeine "hirntote" *Software* hat das
 > 8te Bit "gelöscht". [..]

Richtig, vermutlich unido.uucp.  Wie Chris gesagt hat, wird das Newssystem
dort in ca. einem Monat 8-bit-clean (danke!).  Es waere nett, wenn Du
solange auf Umlaute verzichten koenntest, weil je nach Lage des Absenders
1/3 bis 3/4 aller Sites die Umlaute nicht empfangen.

 > Das, was Du da oben ansprichst, gibt es bereits und heißt ODA/ODIF.
 > Ich kann Dir gerne mal ein paar Testdokumente schicken - sind schön
 > lang und 8 Bit binär kodiert. Wird in größeren Firmen teilweise schon
 > in X.400 Netzen eingesetzt.

... und ist auch in MIME als Content-Type standardisiert: 
"Content-Type: application/ODA".  Modulo der Kodierungsprobleme kannst
Du ohne weiteres Mail/News in ODA verschicken!

Um den resultierenden groessten Flame War, den de.* je gesehen hat,
etwas zu reduzieren, empfiehlt sich allerdings ein Format, das
verschieden aufwendig kodierte Versionen alternativ anbietet:

	Content-Type: multipart/alternative; boundary=nextalternative
	Content-Transfer-Encoding: binary

	--nextalternative
	Content-Type: text/plain; charset=us-ascii

	[normaler text]

	--nextalternative
	Content-Type: text/plain; charset=iso-8859-1

	[ISO8859-text]

	--nextalternative
	Content-Type: application/ODA

	[ODA-text]

	--nextalternative--

Hm, wenn ich das so sehe, stellt sich die Frage, ob das den
Flame War wirklich reduzieren koennte... Mal ausprobieren ,-))

CU, Carsten

.........................................................................
Carsten Rossenhövel                  cross@cs.tu-berlin.de, caro@specs.de

It's worth noting that one of the grounds of the suit is that BSDI's
phone numebr was advertised originally as 1-800-ITS-UNIX.  That's
pretty clearly trademark infringment.
                     -- Michael I. Bushnell, Jul1992, in gnu.misc.discuss