🚀 go-pugleaf

	- hi; in article, <1302150995snz@nospam.demon.co.uk>,
	        pete@nospam.demon.co.uk responded:
>	v$af$ppint@i-m-t.demon.co.uk "ppint. at pplay" writes:
>>                          KGB enquired:
>> > p.s. Off topic, but my last few messages to this thread have been
>> > difficult to send - I keep getting the message "Error reported by
>> > server. 441 header line too long."  It is just when replying to follow
>> > up posts and my fix is to "reply" to the first post in the thread. Any
>> > ideas anyone??
>>	- it's a software failure triggered by a header line going
>>	over the space allowed for it (which space differs from one
>>	newsreader to another) and failing to trim that header in
>>	the appropriate rfc/usefor-mandated (or even -compatible) way.
>> 
>>	- iiuc, newserver software should not alter the References:
>>	header line of articles it picks up and passes on.
>
>Except in the manner you mention below, of course

	- :-)  i haven't perused the rfcs (etc.) regarding the correct
	handling of the References: header line in particular (as opp-
	osed to header lines in general) by newservers, other than in
	the course of my searching for all references (sorry) to the
	correct formulation and handling of header lines within the rfcs
	(etc.), with a view to deducing how news readers "should" behave
	upon meeting a References: header line that will overflow their
	provision for the size of that header line in the course of their
	generating the headers for the follow-up article they are in the
	process of creating:

	- i was therefore passing on my understanding of the general
	feeling of the rfcs & usefors, and of people who have played with
	newservers and their software, that newservers and other trans-
	porters of news should pass on news articles unmodified, save as
	regards the Path: header line; or else, not at all.

	- i got no sense from the rfcs (etc.) that newserver software
	"should" truncate the References: header lines of any articles
	they were transporting in *any* way - but, as i was not then
	searching for information on how or whether newservers ought to
	behave, i may have overlooked some specification of this.

	- hence, "iiuc"...
>
>>	- the References: header line is the line most likely to
>>	trigger the software failure in newsreaders.
>
>Indeed.  This line is not likely to blow the 1000 character limit for 
>any header line in a busy thread.   And whilst not apparently the case 
>in this thread, Googlegroups Message-Ids are _huge_ so it doesn't take 
>many follow-ups to expose defects in newsreading software. (Google 
>groups have IMO a fairly cavalier attitude to 'quoted-printable' too, 
>but that's another issue...)

	- agreed. (fx: hastily)
>
>>	- the correct (i.e. rfc/usefor-mandated) way to trim the line
>>	is to drop sufficient whole news article-ids from immediately
>>	after the first id, through to e.g. the most recent half dozen
>>	or so message-ids, which should be retained intact and in their
>>	original sequence, thus allowing correctly-designed threading
>>	newsreaders to place your article in its correct place in the
>>	correct branch of the correct thread, and follow-ups likewise.
>
>One is also supposed to insert some extra spaces where msg-ids have 
>been excised, but I've not noticed a newsreader that does this.

	- since the rfcs (etc.) specify no particular number of foldable
	white spaces as the correct separator between message-ids, this
	obligation seems peculiar, as it will signify nothing.
>
>>	- i don't know of a newsreader that handles trimming header lines
>>	correctly - i suspect there isn't one that does - nor of one that
>
>I know of at least one -- YT's hack of Snews :-)  Though I'd be very 
>surprised if there are not others; Turnpike for example.

	- *g*:

">One is also supposed to insert some extra spaces where msg-ids have 
 >been excised, but I've not noticed a newsreader that does this."

	       ...would appear to suffice to rule out your nomination.
>
>>	(also an rfc/usefor correct option) allows the line to continue to
>>	expand indefinitely; though Simple News may do this latter, and it
>>	certainly makes trimming the relevant message-ids manually simple.
>
>Which is what I used to do until I got fed up character counting back 
>in the days when d.i.s.pc used to have _long_ threads...

	- indeed; were i still on the original tiny pcclone 386 i-m-t,
	or were deja-vu's archives still maintained and readily avail-
	able, i should happily've appended my previous article to the
	original thread.
	  we live in somewhat lesser days.
[..]
>>	pp.s. - the spacing between the message-ids in the References:
>>	        header line should be at least one foldable white space,
>>	        but bizarrely appears to be permitted to include comment
>>	        or other text, so long as this is separated from the ids
>>	        between which it is interpolated by at least one foldable
>>	        white space.  i have no idea why this is permitted.
>
>Indeed -- header line space is precious, so why waste it?  My hacked 
>Snews processes only message ids in the required format [<....>].

	- i have the strong feeling that the authors of the rfcs were
	taken by surprise when the topic of the References: header line
	overflowing arose - that they'd not conceived of the possibility
	that it might.  this may reflect the origins and original nature
	of newsgroups, and the likely useful length of discussion threads.

	- or maybe everyone thought "640 should be plenty". ;-)

	- love, ppint.
	[drop the "v", and change the "f" to a "g", to email or cc.]
-- 
"homeopathic compression: throw away the data and transmit the spaces;
 the data to be reconstructed from the spaces by virtue of these having
 remembered its shape. the only compression method more effective with
 increasing original data density." - yr hmbl srppnt, 1st october 2004