From: stanley@peak.org
Date: Wed Jun 04 2003 - 19:39:50 CDT
From: <stanley@peak.org>
To: "usenet-format " <usenet-format@rkive.landfield.com>
X-Priority: 3
Importance: Normal
X-MSMail-Priority: Normal
X-Mailer: SquirrelMail (version 1.2.5)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Usenet News Support (support@prodigy.net):
> Sorry, I* am not a "reading agent" I am a person, ...
Ok. Not sure why you are sorry about this. Also not sure how you,
as a person, read articles from the disk or wire without some kind of
reading agent in between, since most disks are opaque to human
examination, and the bits on the wire are invisible. It takes some
kind of program.
> and Re: is useful.
For what? Not for correct threading, as we've already discussed.
Perhaps for marking articles as replies, but the presence of the
References header is a more reliable way of knowing this. Not only
does the References header tell you that this article is a reply, but
it tells you explicitly what article it is a reply to.
> Also, which software adds Re: for me? I have never used such.
Well, all of the (t)rn variants I've used have done so, as has nn. I
don't recall with absolute certainty, but I believe that even Netscape
and IE and Outlook do. It's a pretty well established hack. It's not
going to dissappear just because we let RFC2822 define the Subject
header.
> Did you mean "could be modified" to mark replies?
No, I meant what I wrote.
> Let's not confuse possible new features with the real world as it
> exists today.
Would this be the "real world" where you've never used a reply agent
that adds "Re: " to the subject of your replies? Did you actually add
the "Re: " to your email reply by hand?
Seth Breidbart (sethb@panix.com):
> There's other software (admittedly, broken) that breaks the "one
> header defined for threading messages".
No, there is broken software that ignores the one header defined for
this purpose, but that does not break the definition of the header.
> It exists. It gets used. It will continue to exist and be used.
That's nice. It's broken, by your own admission. It's time to fix it.
Fifteen years is a long time.
> ... I want my software to (be able to) do the best thing
> possible when interacting with the result of that (broken)
> software.
The broken software we are talking about are those reading agents
that ignore the References header when threading articles for display
to the user. I'm not sure what software you have that interacts with
this display, but perhaps you ought to program YOUR software to deal
with the References header directly, instead of relying on the output
of admittedly broken reading agents.
>> What broken software _chooses_ to do does not merit MUST or MUST NOT
>> language.
> That depends on how you want to interact with actual reality.
No, that depends on whether you think that writing standards that
cater to people who CHOOSE to ignore those standards is the correct
thing to do. Agents that thread by Subject instead of References were
written that way deliberately, and the author chose to ignore the
best source of information and use a hack, instead. It is time to
make it clear that the hack is obsolete, not to make the hack
mandatory just to keep broken software happy. If that broken softare
cannot properly thread an article with the subject "Re: Re: Sv: Foo",
well, that's too damn bad -- get properly written software, which
means "software that follows the standard as it has existed for almost
two decades", because IT will be able to correctly thread it.
People laugh when they see dates like "May 3, 103", because they know
the code is broken. They don't demand that the C library be changed to
support the broken code. Why should we demand that unstructured
headers have some kind of structure just because broken code exists?