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

From: John Stanley (stanley@peak.org)
Date: Mon Jun 09 2003 - 11:58:53 CDT


Charles Lindsey (chl@clerew.man.ac.uk):

> Although a few people wanted to remove all mention of "Re: " from
> the draft ...

God damn it Charles, if you cannot bother to understand what other people
are saying, then stop trying to make things up and speak for them.

> Followup agents MUST NOT use any other string except "Re: " as a
> back-reference, and specifically NOT a translation of "Re: " into a
> local language, and they MUST NOT prepend a "Re: " if one is already
> present.

> Although the addition of the back-reference "Re: " is not required,
> it is the normal practice, and followup agents SHOULD do it.

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.)

Now, if you want to read that paragraph and claim that I'm calling for
removing all mention of "Re: " from the draft, I cannot stop you. I can
correct you in public.

 Boris 'pi' Piwinger (3.14@logic.univie.ac.at):

>I really don't see why this should not be mandatory or at
>least a SHOULD. It will do more harm if it is there
>inconsistently.

It does no harm if it is there, if it isn't there, or if it is there three
times. Any USENET client can thread articles properly without anything at
all in the Subject header. If it isn't a USENET client, well, what it does
is not our business and not our problem.

Bruce Lilly (blilly@erols.com) wrote, when Charles asked why news had to
change all the time:

>The reasonable assumption is that when
>resolving a difference where *one* of the many protocols differs
>from *all* of the others, it is likely that the best resolution of
>the discrepancy involves changing the odd man out.

This isn't even an odd-man-out issue. It's an issue of JUSTIFYING the
creation of a difference. The difference between RFC2822 and this draft in
the matter of the Subject header cannot be justified, given the existance
of explicit header information in another mandatory header that this group
is trying to shoehorn into the Subject header. The only excuse for the
difference is to support non-USENET clients when they try to deal with
articles.

Unless you can justify the CHANGE from RFC2822, it should not be made. If
you cannot justify a change from RFC 1036, it should not be made. There
is no reason to be different just to be different, and whining that "it's
news that always has to change" is just ridiculous. Either prove the
interoperability issue, between RFC-conforming USENET clients and agents,
or remove the mandate language. It's that simple.




This archive was generated by hypermail 2.1.7.