Re: In tha matter of: Subject-header and "Re: "

From: Usenet News Support (support@prodigy.net)
Date: Mon Jun 09 2003 - 14:10:46 CDT


On Mon, 9 Jun 2003, John Stanley wrote:

> I've yet to see ANY serious argument that this kind of language is
> necessary in a news standard. "My broken USENET-ignorant client cannot
> mark something as a reply when I read news with it" is not sufficient to
> merit RFC whatever MUST or SHOULDs for any of this. It is not an
> interoperability problem, it is a problem of software authors choosing to
> ignore the information they have been given and deciding they want to
> guess at stuff instead. We do NOT have a requirement to support such
> activity, and certainly no authority to pretend that such nonsense rises
> to the level of interoperability issues. (In other words, if software
> authors CHOOSE to be non-interoperable, we have no responsbility to assist
> them in that choice.)

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.
The fact that it is useful to old software which does not understand
references is minor, 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, mangled, turned into in-reply-to, or otherwise not
available is important to any client software trying to present a useful
view to the human reader.

Stop ignoring the human at the end of the chain, that's why we have usenet
at all. And stop pretending that all transport methods are standard
compliant when in the real world they aren't.

The truth is that under some fairly common conditions conditions the Re is
going to make things work better. I fail to see what will work better in
any way without it.

-- 
bill davidsen
  SBC/Prodigy Yorktown Heights NY data center
  Project Leader, USENET news
  http://newsgroups.news.prodigy.com
  Please send usenet-related mail to news-support@prodigy.net



This archive was generated by hypermail 2.1.7.