Re: Google screws up Usenet even MORE
- From: VanguardLH <V@xxxxxxxxx>
- Date: Fri, 8 Apr 2011 05:59:20 -0500
Steve Ackman wrote:
If true (I don't use GG to post), now you have another reason why you
should be plonking all the Google Groupers.
Sometimes you do <ESC> P to see what's going on.
Even with them scored at -9999 you still see them
I don't delete GG posts. And I don't bother scoring them. In Dialog, I
flag them as ignored. I configure Dialog to apply the ignore flag to an
entire subthread so I don't have to bother seeing replies to the ignored
posts. I use a default view that hides all ignore-flagged posts.
My filters flag a post as ignored. The entire subthread starting from
that post gets ignored. I use a view that hides ignored posts.
That way, if there is reference to another post that would otherwise be
hidden, I can use a view that shows all posts to see what was otherwise
hidden. I don't see ignored and hidden posts inadvertently. I have to
elect to unhide the hidden subthreads.
Got an example GG reply post that's missing References?
A recent one in rec.crafts.metalworking for instance.
The post has the following headers (a partial list):
From: KD7HB <co_farmer@xxxxxxxxx>
Subject: Re: Can someone recommend decent soldering/desoldering station
Yep, no References header. The In-Reply-To header is a free-text
header. Its syntax allows it to contain any text. For example:
In-Reply-To: foot-long subs now only $5
is a legal value for this header. You're not guaranteed to be able to
parse anything useful from this header. It is not defined to be a
thread hierarchy traceback header.
RFC 5377 (obsoletes 2822 which obsoleted 822) - ratified 08-Oct-2008
This tightens up the definition of the In-Reply-To header stating it
should contain unique message identifiers. So the In-Reply-To and
References headers are basically to convey the same information.
Obviously most newsreaders won't support threading based on the
In-Reply-To header. Instead they relied on the older documented
Actually, I went back to RFCs 822 and 2822. The definition in RFC 822
was so vague as to be meaningless. The definition in RFC 2822 matches
that in RFC 5377. RFC 2822 was ratified back in April 2001. So this
header has been defined akin to the References header for a decade.
That's way more time than it should take for newsreaders to catch up;
however, many of use old and often abandoned newsreader software which
may only rely on the References header for threading a set of posts.
Looks like I'm lucky in my choice of Newsreader:
"References header now has priority over In-Reply-To header in incoming
emails for threading"
You'll have to discuss the matter with whomever is the dev team for slrn
to see how they handle the absence of the References header but when the
In-Reply-To header is present. There is a mailto link at the bottom of
the project's web page (http://slrn.sourceforge.net/). Maybe you have
to extend it using its s-lang macro language if In-Reply-To isn't
already handled in the absence of References.
Since I ignore (and hide) all GG posts, this new problem won't affect
how I participate in newsgroups. Since the definitions of In-Reply-To
and References are the same (they both are to contain a list of MIDs
that trace back through the parent posts), some newsreaders won't work
that rely only on the References header. Not even Usenet is completely
stagnant when it comes to changing its standards, especially since the
standard that changed was RFC for the Internet Message Format upon which
other RFCs are defined.
And they probably redesigned the whole sickbay too!
I know engineers. They l-o-v-e to change things!
(Star Trek: The Motion Picture, McCoy quote)
- Prev by Date: Re: Google screws up Usenet even MORE
- Next by Date: Re: Google screws up Usenet even MORE
- Previous by thread: Re: Google screws up Usenet even MORE
- Next by thread: Re: Google screws up Usenet even MORE