Reinhard Irmer <[EMAIL PROTECTED]> wrote on 19.03.04:
> Martin Wodrich <[EMAIL PROTECTED]> schrieb:
>> Um das aber zu verstehen muss man die RFCs gelesen haben und vorallem
>> verstehen das sie eben auch sehr viel Unsinn erlauben.
> Wer bestimmt denn bei den RFC-Verfassern, was Sinn oder Unsinn ist?
Keiner. Es gibt neben den RFCs noch die mindestens so wichtige "best
current practice", die sich im wesentlichen an der Vernunft und dem
gesunden Menschenverstand orientiert. Das hat nie eine Mehrheit oder
eine einzelne Person beschlossen, sondern sich einfach als sinnvoll
durchgesetzt.
Deshalb macht man manche Dinge nicht, obwohl sie in keinem RFC
ausdruecklich verboten bzw. sogar explizit erlaubt sind. Du kannst z.B.
absolut RFC2822-konforme Adressen mit Kommentaren usw. bauen, bei deren
Verwendung Du von den meisten zum Teufel gejagt wuerdest, weil die
meisten Programme Probleme damit bekaemen (vielleicht erinnerst Du Dich
noch an den Thread mit "f(Fred) p(erick) age@( Pag)fuck(e)microsoft.com"
der u.a. auch in d.c.s.c seinerzeit aufgegriffen wurde).
Diese Adresse ist allerdings nicht so ganz RFC2822-konform, folgender
To:-Header aber z.B. schon:
----------8<----------
To:A Group(Some people)
:Chris Jones <c@(Chris's host.)public.example>,
[EMAIL PROTECTED],
John <[EMAIL PROTECTED]> (my dear friend); (the end of the group)
----------8<----------
FreeXP haette damit zwar keine Probleme und wuerde alle Adressen korrekt
erkennen, alle anderen XPs und etliche andere Mailreader vermutlich
nicht.
Andererseits macht man und erwartet andere Dinge, obwohl es nirgends im
Sinne einer verbindlichen Vorschrift geregelt ist (wie z.B. die
Konvention, einen Subjectwechsel mit "(was: ...)" kenntlich zu machen
und das alte Subject bei einem Followup zu entfernen).
>> Mit der Folge das es kaum eine Software gibt die alle revanten RFCs
>> vollstaendig umsetzen.
> Das ist dann natuerlich die logische Folge daraus, wenn Konventionen
> nicht so sind, dass ein "sich-daran-halten" einfach zu gestalten ist.
Es ist vor allem eine kaum ueberschaubare Menge an Regeln, die sich in
Teilen auch widersprechen, und bis heute flammt z.B. immer wieder die
Diskussion darueber auf, inwieweit die fuer Mail geltenden Regeln auch
fuer News gueltig sind (oder sein sollten).
Ausserdem entwickelt sich die Realitaet oft schneller als die RFCs. Was
aber kein Freibrief dafuer ist, gegen bereits bestehende, klar
definierte und allgemein akzeptierte Regeln massiv zu verstossen.
> Zugegeben, ich habe diese Konventionen nicht gelesen, ich wuerde sie
> wahrscheinlich auch nicht verstehen, da ich kein Programmierer bin,
Das ist nicht erforderlich, Sachkenntnis reicht. ;) Um zu wissen, wie
man einen Header korrekt parsed und wie das Ergebnis auszusehen hat,
muss man das nicht programmieren koennen.
> aber wuerden sie so verfasst sein, dass sie als eindeutiges Regelwerk
> zu verstehen waeren, dann gaebe es auch keine
> "Interpretationsmoeglichkeiten".
Man ist bei den juengeren RFCs (z.B. 2822) dazu uebergegangen, die ABNF-
Notation als einzig verbindliche Aussagen anzusehen (falls das bei dem
behandelten Thema moeglich ist) und die Prosa drumherum nur noch als
erlaeuternden Text. Da gibt's dann in der Tat kaum noch
Interpretationsmoeglichkeiten.
Aeltere Versionen (822 und Vorgaenger) waren erheblich umfangreicher,
weil auch die Regeln selbst - obwohl auch dort ABNF verwendet wird - zu
einem viel groesseren Umfang in Prosa gehalten waren.
Verstaendlicher sind natuerlich letztere, eindeutiger erstere.
>> FreeXP insbesondere der neue UUZ versucht sich vorbildlich an die
>> RFCs zu halten.
> will heissen: die Entwickler interpretieren nicht lange herum,
> sondern halten sich einfach an die dortigen Formulierungen?
Das waere im Prinzip meine favorisierte Vorgehensweise, die aber nicht
immer funktioniert und auch nicht immer zu den gewuenschten Ergebnissen
fuehrt, wie ich in einigen Diskussionen in d.c.s.n lernen musste.
Michael
------------------------------------------------------------------------
FreeXP Support-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
