From: John Stanley (stanley@peak.org)
Date: Mon Jun 09 2003 - 15:21:35 CDT
On Mon, 9 Jun 2003, Usenet News Support wrote:
> I know you will continue to misunderstand this, "Re" is not only for the
> convenience of software, it is useful to the humans using the software.
I know you will continue to refuse to answer the question, but FOR WHAT
PURPOSE that is NOT better served by the mandatory References header?
If it is so critically vital that humans using the software MUST see an
"Re: " at the start of the subject, why have the clients YOU have chosen
to use chosen NOT to implement this marking on their own? The way you put
it, you'd think that "Re: " was already mandatory (it isn't) and that
someone dies if the Subject of a reply doesn't contain one. You chose
your own clients, why have you chosen ones that fail you in such a
critical way, and why should WE change things just because you made a poor
choice of clients?
And just what is is about that "Re: " at the front of the Subject that
cannot be shown some other way by a USENET-conforming reading client, that
it justifies the difference from RFC2822? Can you not understand anything
else but "Re: " at the front of a subject? Can you really not understand
the article tree that trn shows the "human"? Can you really not understand
that the presence of a References header means that the article is a
reply? And, God forbid, do you REALLY not understand what "In reply to: "
at the front of a subject means, to the point that it must be PROHIBITED?
> The fact that it is useful to old software which does not understand
> references is minor, ...
And THAT software is exactly the excuse being used for making it
mandatory. Your USENET-ignorant client that cannot show you that an
article is a reply is somehow our problem for us to fix.
> the fact that it is useful to hint at threading after
> a post has been through a few mail-to-news-to-mail steps and the
> references at lost, ...
We are not responsible for what mail systems do to USENET messages. We are
not responsibile for messages that pretend to be USENET messages, such as
replies that lack the mandatory References header. We ARE responsible for
justifying any differences between the generic message standard (RFC2822)
and this draft, and "broken software doesn't work" isn't adequate. It's
broken, so we already know it doesn't work. Fix it. Problem solved. And
you've had 15 years to fix it.
> Stop ignoring the human at the end of the chain,
I'm not ignoring anything, including the MANDATORY References header,
which your USENET-ignorant client software is ignoring. Stop trying to
make client display issues into interoperability issues. If the client you
use doesn't display things the way you want, talk to the client author.
It's not our job to design his UI for him. And yes, showing the HUMAN the
"Re: " at the start of a reply subject IS a user interface issue.
> And stop pretending that all transport methods are standard
> compliant when in the real world they aren't.
Stop pretending that failure to insert a References header is just a
simple failure of standards compliance. It's a fifteen year old mandatory
header. Stop pretending that a client that doesn't understand USENET
message format is a failure of the transport method.
What other failures in transit do you want to try to correct by insertions
in the Subject header? Well, some tranports convert the date into
user-unfriendly timezones. Let's make it mandatory that the user-friendly
date be in the Subject, too, ok? [I've just elided an entire paragraph of
other tranport and injector actions that should be recorded in the Subject
header, too, if we really worry about user interface and transport
problems. You're welcome.]
Once you start down the path of catering to deliberately non-USENET
software, you open the floodgates to all kinds of hacks. That's the wrong
direction to go. Fewer hacks is good, especially when the hacks are there
ONLY to support USENET-ignorant and USENET-broken software (and, to be
pedantic, HUMANS who choose to use such software).
> The truth is that under some fairly common conditions conditions the Re is
> going to make things work better.
The truth is, under some fairly common conditions, the References header
contains ALL of the information that the "Re: " hack contains, plus more,
and under some fairly common conditions, relying on the "Re: " hack will
get things completely wrong. And, the truth is, the things that will "work
better" are things that are USENET-ignorant and have chosen to be that
way.
> I fail to see what will work better in
> any way without it.
Who the fuck keeps talking about doing without it, other than you and
Charles? I've explained the best I know how that NOBODY is talking about
getting rid of "Re: " -- other than you -- so you'll have to find someone
else to help. The best I can do is repeat that there is a significant
difference between "RFC2822 language is sufficient for Subject" and "get
rid of Re:". If you don't understand RFC2822 language, well, find a
dictionary, just please stop misrepresenting my position.