On 2024-01-03 11:02, Helmut Richter <
hr.u...@email.de> wrote:
> [ Followup-To: poster
> bei Weiterführung der Diskussion bitte geeignete Newsgruppe wählen ]
[Ich nehme de.comm.software.newsreader. Ist zwar nicht ganz passend, aber
die Alternative wäre IMHO de.comm.protocols.misc und das erscheint mir
zu allgemein.]
> On Wed, 3 Jan 2024, Stefan Schmitz wrote:
>
> [ hier die Header dieses Beitrags ]
>
>> Path:
>>
uni-berlin.de!
fu-berlin.de!
eternal-september.org!feeder3.eternal-september
>> .org!
news.eternal-september.org!
ss32.dont-email.me!.POSTED!not-for-mail
[...]
>> Message-ID: <un3ccl$35mg5$
1...@ss32.dont-email.me>
>> References: <
6560B851...@hrz.tu-chemnitz.de>
>> <uk2orh$3slp3$
3...@dont-email.me> <ukas5n$1gn0p$
1...@dont-email.me>
>> <ukvbjf$1pgl6$
2...@dont-email.me> <ul98n5$3js51$
1...@dont-email.me>
>> <ula9k4$3ot03$
2...@dont-email.me> <
kgtm4k-...@nntp.haselbeck-net.de>
>> <um4meq$1m7c3$
1...@dont-email.me> <
lhch5k-...@nntp.haselbeck-net.de>
>> <umf7d8$3iuia$
1...@dont-email.me>
>> <
slrnuomclu.3s...@trintignant.hjp.at>
>> <
kv0s1q...@mid.individual.net>
>> <
slrnuomft1.48...@trintignant.hjp.at>
>> <
kv11kc...@mid.individual.net> <umk14l$dh0l$
2...@dont-email.me>
>> <un249o$ntk0$
1...@solani.org>
[...]
>> User-Agent: Mozilla Thunderbird
>> Cancel-Lock: sha1:JwH4juz6uetNASrt+ZRCoHLmXaM=
>> In-Reply-To: <un249o$ntk0$
1...@solani.org>
>
> Und der Inhalt:
>
>> Am 02.01.2024 um 23:57 schrieb Ulrich D i e z:
>> > Der "Path:", die "Verschickungskette" eines Postings, wird also
>> > von den Peering-Servern von vorne her ergänzt.
>> >
>> > 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.
RFC 5537, s. 3.4.4:
| The content of the new article's References header field MUST be
| formed from the content of the parent's References header field if
| present, followed by the content of the Message-ID header field of
| the parent. If the parent had a References header, FWS as defined in
| [RFC5536] MUST be added between its content and the Message-ID header
| field content.
Also ja, man muss hinten anfügen. Man darf/muss Referenzen rauslöschen, wenn
der Inhalt zu lang würde:
| 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).
| Trimming means removing any number of message identifiers from its
| content, except that the first message identifier and the last two
| MUST NOT be removed.
Aber die Reihenfolge muss erhalten bleiben:
| An essential property of the References header field, guaranteed by
| the above procedure and REQUIRED to be maintained by any extensions
| to this protocol, is that an article MUST NOT precede one of its
| parents.
>> Warum ist das eigentlich so?
>
> Jetzt ist es so, und wenn man das ändern würde, müsste man nicht nur alle
> auf Servern und privaten Dateien weltweit rumgeisternden Newsbeiträge
> ändern, sondern auch alle Software, die von der Reihenfolge dieser
> Einträge – zu Recht oder in unberechtigtem Vertrauen auf die
> Gepflogenheiten – Gebrauch macht.
ACK.
>> Umgekehrt fände ich es aus Nutzersicht sinnvoller. Dann würde man direkt
>> am Anfang der jeweiligen Kette sehen, von welchem Server das Posting
>> stammt bzw. welches die unmittelbar vorausgehenden Beiträge waren.
>
> Der unmittelbar vorausgehende Beitrag steht ja unter "In-Reply-To:". Es
> geht also nur um ältere Beiträge aus dem Thread.
In-Reply-To ist aber kein Usenet-Header, sondern ein E-Mail-Header.
Thunderbird fügt den ein, weil es ein kombinierter MUA/NUA ist, aber
andere Newsreader müssen den weder erzeugen noch verstehen.
hp