From: John Stanley (stanley@peak.org)
Date: Wed Jun 11 2003 - 15:02:30 CDT
Seth Breidbart (sethb@panix.com):
>We (well, some of us) do so aware that there is existing software, and
>if our standard tells too much of it "you're wrong"
I'm interested to know how you come up with that. If we go with RFC2822's
definition of Subject and Re:, just what software is told that it is
wrong?
J.B. Moreno (planb@newsreaders.com):
>First and foremost -- an article with a Subject w/o "Re: " proclaims
>itself as a "new" topic
No, it doesn't. You might assume this, but nothing in the standards as
they stand tells you this, and what you incorrectly infer from something
is hardly a "proclamation". (Proof of point: is this message a "new
subject", or is it simply the same topic without an Re: on the Subject?)
> ... leaving it
> off will cripple people's ability to deal with thread drift as they like.
Which part of this discussion says anything about leaving it off? And
since trn is able to handle this, it must be possible, so the only
crippled ability is for those using non-USENET-aware software.
Boris 'pi' Piwinger (3.14@piology.org):
>I did answer it, you keep ignoring it while not answering
>why we should change what everybody does now.
I would have resorted to strong language here, but I'll try not to.
I do wish you would please stop deliberately misrepresenting what I've
said. I have NEVER said that we should change what people are doing now.
Not once. I've told you that about a dozen times now, and you keep
repeating your lie. You must have some reason for doing so, but I cannot
fathom what it is.
If you are unhappy that you keep seeing me argue this subject, then
realize that as long as people lie about my position on this matter, I
will respond to correct them. Simple concept.
> I don't think we should change the standard for these games.
Neither do I. The standards as they exist currently have NO RFC2119
language regarding the Re: hack. I'll count you on my side in this
discussion then, shall I? I don't think you intended that, but if you
don't know what the standards say, then you ought not to say we shouldn't
change them.
Thorfinn (thorfinn@tertius.net.au):
>Hrm, yes, scorefiles, definitely, now that someone else posted about it.
Well, I don't know about "scorefiles", but I am quite able to kill based
on the References header using trn. The lack or presence of an Re: in the
subject causes no interoperability problems here, in fact, the presence of
a References header is a much better indicator of what things are replies
than any subject hack, for the reasons I've already stated.
I can also detect Subject drift, without resorting to the Re: hack. It
isn't that hard. In fact, trn NEVER shows me the Re: until I'm actually
reading the article, so apparently it really isn't that critical a way of
implementing this feature.
>That's a *lot* easier to do with "Subject: Re: " being well defined.
It is already well defined. It just doesn't have RFC2119 mandates.
> Err, *you*, apparently, at least by implication. If you say:
I'm sorry, more strong language is necessary. "Does not require RFC
2119-style language, it is covered by RFC 2822" says NOTHING about doing
away with it. In fact, if you actually read RFC 2822, you might notice
that "Re: " is described in that document. How can you possibily
imagine that "RFC2822 is sufficient" means "do away with it"?
>2. We MUST NOT say anything about the field text of "Subject: "
And what happens if we don't? Well, RFC2822 does, so by direct reference,
we say exactly what RFC2822 does. Why is RFC2822 not sufficient?
> that implies that "Subject: Re: " is not necessary (because it's
> completely redundant),
No implication, it is a pretty direct statement of that fact. It is
redundant, it is not necessary. By definition, if replies MUST have Re: in
the Subject and MUST have a References header, one of the two is
redundant. We already make the latter requirement, why do we need to make
the former?
> and should be done away with.
No, there is no such inferrence possible, if you read RFC2822. How anyone
can read RFC2822, see the hack defined therein, and infer that I said the
hack should be abolished is simply not paying attention to either what
I've said or to RFC2822.