Hi,
ich grueble seit langem an der Auswertung des Content-Type-Headers herum
und bin jetzt an einem Punkt, wo ich mal etwas Input gebrauchen koennte.
Ich will nachfolgend versuchen, zu erlaeutern, was der UUZ derzeit
(falsch) macht und was mein Problem ist, aber eines schon mal vorweg:
XP-User sind nicht betroffen. :)
Es geht um den Fall einer unmittelbar aufeinanderfolgenden RFC=>ZC=>RFC-
Konvertierung. In beiden Richtungen wird der Header geparsed (derzeit
und unverstaendlicherweise von verschiedenen und auch unterschiedlich
arbeitenden Routinen).
In RFC=>ZC-Richtung werden dabei die fuer XP benoetigten Parameter wie
z.B. "charset=" ausgewertet, der Header aber insgesamt mit dem Prefix
"U-" mit seinem urspruenglichen und vollstaendigen Inhalt geschrieben.
In ZC=>RFC-Richtung passiert prinzipiell dasselbe, allerdings wird da
nicht der komplette Header nach Entfernen des Prefixes "U-"
zurueckgeschrieben, sondern es wird aus den ermittelten und
ausgewerteten Parametern ein komplett neuer Header erzeugt.
Das ist gerade bei text/plain auch richtig so, denn hier darf z.B. gar
nicht der urspruengliche Charset-Parameter uebernommen werden, wenn die
Nachricht vorher in RFC=>ZC-Richtung nach CP437 konvertiert wurde
(frueher wurde er uebernommen, aber eben das fuehrte mitunter zu falsch
als z.B. "UTF-8" deklarierten Nachrichten).
Das Problem ist jetzt, dass beim Parsen in ZC=>RFC-Richtung zwar die am
haeufigsten vorkommenden, aber im Vergleich zur Gesamtanzahl der in
diversen RFCs definierten Parameter nur ein verschwindend geringer Teil
ueberhaupt ausgewertet wird und die nicht ausgewerteten Parameter
anschliessend schlicht verworfen werden.
Bildlich: Von einem Header wie...
----------8<----------
> Content-Type: message/external-body; access-type=ftp; size=2345;
> permission=read; name="mail4you.msg"; site="ftp.freexp.de";
> directory="/bla/blubb/pub/mail/"; mode=local8
----------8<----------
...bleibt nach einer RFC=>ZC=>RFC-Konvertierung nur noch uebrig:
----------8<----------
> Content-Type: message/external-body
----------8<----------
Das ist mir eindeutig zuwenig. :)
Nun dachte ich mir "Schoen, dann werten wir die uebrigen Parameter halt
auch noch aus". Da ich das Chaos aus herumfliegenden RFCs leid war und
drohte, die Uebersicht zu verlieren, habe ich mich hingesetzt, um mir -
und das mache ich ganz selten - vor dem Programmieren erst mal 'ne
"Zeichnung" zu machen, der ich entnehmen konnte, welche Parameter in
welchem Kontext ueberhaupt existieren und daher ausgewertet werden
muessen.
Das vorlaeufige und noch unvollstaendige Ergebnis dieser "Zeichnung"
(ueberwiegend basierend auf RFC2045/2046) mit einigen Anmerkungen fuer
mich haengt an dieser Mail und hat mich selbst verbluefft.
Wie man sieht, ist schon die reine Zahl an Parametern signifikant hoch,
von den inhaltlichen Abhaengigkeiten (wann muss/darf welcher Parameter
unter welchen Umstaenden ueberhaupt verwendet werden) mal abgesehen.
Hinzu kommt, dass permanent neue top level types samt neuer Parameter
bzw. neue Parameter fuer bereits existierende top level types erfunden
und benutzt werden, so dass man vermutlich bis an sein Lebensende mit
dem Nachhalten und Implementieren derselben beschaeftigt waere. Zumal
ich befuerchte, dass da noch vieles bei der IETF und IANA schlummert,
das ich noch gar nicht kenne, und auch Parameter mit dem Prefix "x-"
verwendet werden, die wir schon mal gar nicht alle kennen und auswerten
koennen.
Andererseits hatte das bisherige Erzeugen eines komplett neuen Content-
Type-Headers den Vorteil, dass man damit falsche, unsinnige, redundante
oder fehlende Parameter korrigieren, entsorgen oder ergaenzen konnte
(wenn z.B. der obsolete Parameter "name=" fuer den Dateinamen in
Content-Type verwendet wurde, hat man den Inhalt stattdessen in den
aktuell gueltigen Parameter "filename=" des Headers Content-Disposition
gepackt und so nach aktuellen Standards gueltige Header erzeugt).
Und jetzt bin ich etwas unschluessig, was ich tun soll und wie ich es im
Detail tun soll. Falls mir jemand auf die Spruenge helfen kann und
will...
Wenn man sich entschliesst, den U-Content-Type prinzipiell unveraendert
zu schreiben und dort nur die relevanten Parameter wie "charset="
auszuwerten und ggf. zu korrigieren - was mir derzeit das Sinnvollste
erscheint - dann waere zumindest die gemeinsame Zusammenstellung einer
Liste der Parameter hilfreich, die man als relevant ansieht bzw. die
objektiv fuer den UUZ relevant sind - und zwar eine Liste *nur* dieser
relevanten Parameter.
Bisher wurden da willkuerlich irgendwelche Parameter ausgewertet und
andere wieder nicht - ich sehe da keinen wirkliches Konzept, es sei
denn, das war der aktuelle Stand aller Parameter im Jahre 199x, woher
die Grundlage dieser Routinen wahrscheinlich stammt (was aber auch kaum
sein kann, denn RFC2046 ist aus 1996).
MichaelContent-Type (RFC 2045/2046)
³
ÃÄÄtext/* (Default: plain)
³ ÃÄplain
³ ³ ÀÄcharset= (konvertieren, -uz Win-1252, -zu ISO-8859-1)
³ ÃÄrichtext (RFC 1341)
³ ³ ÀÄcharset= (nicht konvertieren, -uz Wert => CHARSET)
³ ÃÄenriched (RFC 1896)
³ ³ ÀÄcharset= (nicht konvertieren, -uz Wert => CHARSET)
³ ÀÄhtml (RFC 2854)
³ ÀÄcharset= (nicht konvertieren, -uz Wert => CHARSET)
³
ÃÄÄimage/*
³ ³ ÃÄjpeg
³ ³ ÀÄgif
³ audio/*
³ ³ ÀÄbasic
³ video/*
³ ³ ÀÄmpeg
³ ÃÄÄÄÄÄname= (RFC 1341; auswerten, aber nicht erzeugen)
³ ÃÄÄÄÄÄx-filename= (kein RFC; auswerten, aber nicht erzeugen)
³ ÀÄÄÄÄÄx-date= (kein RFC; auswerten, aber nicht erzeugen)
³
ÃÄÄapplication/* (Default: octet-stream)
³ ³ ÃÄoctet-stream
³ ³ ³ ÃÄtype= (Typinformation, ohne technische Bedeutung)
³ ³ ³ ÀÄpadding= (Bit-Padding)
³ ³ ÀÄpostscript
³ ÃÄÄÄÄÄname= (RFC 1341; auswerten, aber nicht erzeugen)
³ ÃÄÄÄÄÄx-filename= (kein RFC; auswerten, aber nicht erzeugen)
³ ÀÄÄÄÄÄx-date= (kein RFC; auswerten, aber nicht erzeugen)
³
ÃÄÄmultipart/* (Default: mixed)
³ ³ ÃÄmixed (Default-Bodypart: text/plain)
³ ³ ÃÄalternative (Default-Bodypart: text/plain)
³ ³ ÃÄdigest (Default-Bodypart: message/rfc822)
³ ³ ÀÄparallel (Default-Bodypart: text/plain)
³ ÀÄÄÄÄÄboundary= (immer Pflicht)
³
ÃÄÄmessage/* (Default: rfc/822)
³ ÃÄrfc/822
³ ÃÄpartial
³ ³ ÃÄnumber= (lfd. Nr. des Nachrichtenteils)
³ ³ ÃÄtotal= (Anzahl der Teile, Pflicht im letzten Teil)
³ ³ ÀÄid= (Message-ID der Nachricht)
³ ÀÄexternal-body
³ ÃÄaccess-type= (Zugriffstyp ('ftp', 'tftp', 'anon-ftp',
³ ³ 'local-file', mail-server')
³ ÃÄexpiration= (Ablaufdatum)
³ ÃÄsize= (Nachrichtengr”áe)
³ ÃÄpermission= (read, read/write
³ ÃÄname= (Dateiname, Pflicht bei access-types 'ftp', 'tftp',
³ ³ 'anon-ftp' und 'local-file')
³ ÃÄsite= (Domain, Pflicht bei access-types 'ftp', 'tftp' und
³ ³ 'anon-ftp')
³ ÃÄdirectory= (Verzeichnis, optional bei 'ftp', 'tftp' und 'anon-ftp')
³ ÃÄmode= (Transfer-Modus, optional bei 'ftp', 'tftp' und
³ ³ 'anon-ftp'
³ ÃÄserver= (Adresse des Servers, Pflicht bei 'mail-server')
³ ÀÄsubject= (Betreff der Mail, optional bei 'mail-server')
³
ÃÄÄmodel/* (RFC 2077, Default: keiner)
³ ³ ÃÄiges
³ ³ ÃÄvrml
³ ³ ÀÄmesh
³ ÃÄÄÄÄÄdimension= (Anzahl der Dimensionen)
³ ÀÄÄÄÄÄstate= ('static', 'dynamic')
³
ÃÄÄ[...to be continued...]
------------------------------------------------------------------------
FreeXP Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
