Re: Off topic - "Quelltext" eines Usenet-Postings, Message-ID und Header

[Peter J. Holzer]

On 2024-01-03 12:20, Stefan Froehlich <Stefan...@Froehlich.Priv.at> wrote:
> On Wed, 03 Jan 2024 12:02:15 Helmut Richter wrote:
>> [ Followup-To: poster
>> bei Weiterführung der Diskussion bitte geeignete Newsgruppe wählen ]
>
> Ich nehme mir die Freiheit, das zu ignorieren.

Ich machs aber trotzdem, nachdem ich schon meine vorige Antwort
umgelenkt hatte.

>>> Am 02.01.2024 um 23:57 schrieb Ulrich D i e z:
>>> > Die "References:", also die "Beantwortungskette" eines
>>> > Postings, werden von den zum Postingschreiben verwendeten
>>> > Clients durch hinten Anfügen verlängert.
>
>> Die Preisfrage ist, ob man beim Anfügen zwingend das Ende nehmen
>> *muss* oder ob die Liste als (ungeordnete) Menge definiert ist, so
>> dass jede Umordnung erlaubt *wäre*, bin ich zu faul zum
>> Raussuchen.
>
> RFC5322 (das ist bei SMTP definiert und wird für NNTP bloß
> übernommen).

Nitpick: Die Message-Formate (RFC 5322 für Mail bzw. 5536 für News) sind
getrennt von den Transport-Protokollen (RFC 5321 für SMTP bzw. 3977 für
NNTP) definiert. Mail muss nicht per SMTP transportiert werden und News
nicht per NNTP, auch wenn das heute fast immer der Fall ist.
Insbesondere sagt SMTP überhaupt nichts über den References-Header, weil
der für den Transport vollkommen unerheblich ist.

Historisch gab es zwar schon in RFC 822 einen "References"-Header, aber
der hatte eine etwas andere Bedeutung. Die moderne Verwendung stammt aus
dem Usenet (RFC 850) und wurde erst später in E-Mail übernommen (RFC
2822).


> Bis RFC 1036 gab es eine Längenbegrenzung für Header, ggf. mussten
> die References dann gekürzt werden. Seit RFC 5536 ist das jedoch
> Geschichte.

Nein, das ist auch in RFC 5537 noch so:

| If the resulting References header field would, after unfolding,
| exceed 998 characters in length (including its field name but not the
| final CRLF), it MUST be trimmed (and otherwise MAY be trimmed).

hp

[Stefan Froehlich]

In de.comm.software.newsreader Peter J. Holzer <hjp-u...@hjp.at> wrote:
> On 2024-01-03 12:20, Stefan Froehlich <Stefan...@Froehlich.Priv.at> wrote:
>> RFC5322 (das ist bei SMTP definiert und wird für NNTP bloß
>> übernommen).

> Nitpick: Die Message-Formate (RFC 5322 für Mail bzw. 5536 für
> News) sind getrennt von den Transport-Protokollen (RFC 5321 für
> SMTP bzw. 3977 für NNTP) definiert.

Ich hatte mir noch überlegt, ob ich das korrigiere, aber irgendwie...

>> Bis RFC 1036 gab es eine Längenbegrenzung für Header, ggf.
>> mussten die References dann gekürzt werden. Seit RFC 5536 ist das
>> jedoch Geschichte.

> Nein, das ist auch in RFC 5537 noch so:

> | If the resulting References header field would, after unfolding,
> | exceed 998 characters in length (including its field name but not the
> | final CRLF), it MUST be trimmed (and otherwise MAY be trimmed).

Hoppla.

Ich hatte mir das in RFC5536 (Netnews Article Format) angesehen, und
dort wird (mit ein paar Unterschieden, die hier keine Rolle spielen)
einfach auf RFC5322 verwiesen, der wiederum keine Längenbeschränkung
und kein Trimmen vorsieht.

Wieso diese Inkonsistenz?

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - die Erhörung der Erotik.</b
(Sloganizer)

[Peter J. Holzer]

On 2024-01-03 13:48, Stefan Froehlich <Stefan...@Froehlich.Priv.at> wrote:
> In de.comm.software.newsreader Peter J. Holzer <hjp-u...@hjp.at> wrote:
>> On 2024-01-03 12:20, Stefan Froehlich <Stefan...@Froehlich.Priv.at> wrote:
>>> Bis RFC 1036 gab es eine Längenbegrenzung für Header, ggf.
>>> mussten die References dann gekürzt werden. Seit RFC 5536 ist das
>>> jedoch Geschichte.
>
>> Nein, das ist auch in RFC 5537 noch so:
>
>> | If the resulting References header field would, after unfolding,
>> | exceed 998 characters in length (including its field name but not the
>> | final CRLF), it MUST be trimmed (and otherwise MAY be trimmed).
>
> Hoppla.
>
> Ich hatte mir das in RFC5536 (Netnews Article Format) angesehen, und
> dort wird (mit ein paar Unterschieden, die hier keine Rolle spielen)
> einfach auf RFC5322 verwiesen, der wiederum keine Längenbeschränkung
> und kein Trimmen vorsieht.
>
> Wieso diese Inkonsistenz?

Gute Frage.

Ich nehme an, für Netnews-Artikel wollte man das nicht ändern, weil es
Probleme mit existierender Software, die sich auf eine Maximallänge von
998 Zeichen verlässt, gegeben hätte oder zumindest hätte geben können.

In E-Mail hatten Header-Felder nie eine Längenbeschränkung, und als man
die Semantik von References: an die im Usenet gebräuchliche angepasst
hat (meiner Erinnerung nach, nachdem etliche MUAs das schon
implementiert hatten) wollte man wohl nicht ohne dringende Notwendigkeit
eine solche Beschränkung nur für diesen speziellen Header einführen.

hp

[Stefan Froehlich]

On Wed, 03 Jan 2024 15:16:45 Peter J. Holzer wrote:
> On 2024-01-03 13:48, Stefan Froehlich <Stefan...@Froehlich.Priv.at> wrote:
>> In de.comm.software.newsreader Peter J. Holzer <hjp-u...@hjp.at> wrote:

[RFC 5537]

>>> | If the resulting References header field would, after unfolding,
>>> | exceed 998 characters in length (including its field name but not the
>>> | final CRLF), it MUST be trimmed (and otherwise MAY be trimmed).

>> Ich hatte mir das in RFC5536 (Netnews Article Format) angesehen,
>> und dort wird (mit ein paar Unterschieden, die hier keine Rolle
>> spielen) einfach auf RFC5322 verwiesen, der wiederum keine
>> Längenbeschränkung und kein Trimmen vorsieht.

>> Wieso diese Inkonsistenz?

> Gute Frage.

> Ich nehme an, für Netnews-Artikel wollte man das nicht ändern,
> weil es Probleme mit existierender Software, die sich auf eine
> Maximallänge von 998 Zeichen verlässt, gegeben hätte oder
> zumindest hätte geben können.

Das ist schlüssig und erscheint auch sinnvoll, ebenso wie das:

> In E-Mail hatten Header-Felder nie eine Längenbeschränkung, [...]

> wollte man wohl nicht ohne dringende Notwendigkeit eine solche
> Beschränkung nur für diesen speziellen Header einführen.

IMO hätte man dann IM RFC 3.2.10 bei den "added restrictions" auch
noch die Notwendigkeit des Trimmens ergänzen sollen.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - die vornehmste Erleuchtung der Nacht!
(Sloganizer)