From: Thorfinn (thorfinn@tertius.net.au)
Date: Thu Jun 12 2003 - 02:14:26 CDT
On Wed 11 Jun 2003 at 01:02:30PM -0700, in <Pine.LNX.4.53.0306111005070.27539@a>,
John Stanley <stanley@peak.org> wrote:
> J.B. Moreno (planb@newsreaders.com) wrote:
> >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?)
Dunno. But that's also my point - this ambiguity is precisely why we
should have wording in USEAGE about it.
> > ... 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.
Nope. You are ignoring the actual functional difference that exists, as
described below.
[snippage]
> Thorfinn (thorfinn@tertius.net.au) wrote:
> >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.
No, it doesn't constitute a terrible interoperability problem, or even
"harm", to not do it. That's why my position is that we should talk
about it in USEAGE, not USEFOR, and that we don't really need to put
conditions on any Agents except for Followup Agents.
> I can also detect Subject drift, without resorting to the Re: hack. It
> isn't that hard.
No, it's not that hard. But it *isn't* possible to do it without
actually having access to the "Subject: " header of the directly
previous article in the "References: " header.
> 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.
*sigh* It's not a "critical feature". However, the presence of the
"Subject: Re: " mechanism *does* provide a functional difference that
"References: " + "Subject: " does *not*.
It enables someone who has access to an article *without access to its
parent article* to be able to tell if the subject line has been changed.
That situation exists in scorefile syntax - you can't score on "parent
subject", because there's no such header available, and there is no
simple syntax that allows you to do that kind of comparison anyway.
That situation also exists in the fact that netnews propagation is not
perfect, and that newsservers do expire articles, and although parent
articles are rarely missing, they certainly *can* be.
That situation yet again exists when people save a single article within
a thread to an archive file. They may well not store its parent
article, and are in fact quite unlikely to have done so.
So, don't go claiming "there's no functional difference", because *there
is*. It's *not* a big or a terribly commonly occurring functional
difference, I agree. But there certainly *is* one, and it's one that
people *do* make use of in current news reader and followup agents
today.
> >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.
No, it doesn't. And I think it should.
> > 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"?
Probably because "RFC2822 is sufficient" is not the only thing you're
saying. See a bit further down.
> >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?
Because it doesn't talk in enough detail about it, nor is the language
strong enough.
> > 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.
See? There we go. You *do* want to do away with it. "Not necessary"
implies "don't do it." Maybe you don't mean that - and your other
statements sometimes say that you don't. But a statement like "not
necessary" has pretty strong implications of "SHOULD NOT be done" to
most English readers.
That's *stronger* than RFC2822's statement on the "Subject: "...
> 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?
They're *not* redundant (in the sense of providing completely identical
functionality) and you *completely* ignored the point I (and someone
else, I can't remember who) made about scorefile functionality.
They do indeed overlap in functionality very significantly. That's not
necessarily a bad thing. Redundancy is not necessarily a thing that
should be thrown away anyway... redundancy gives more robustness if
things break.
> > 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.
Okay. I've poked RFC2822, just to refresh my memory... Yeps. It says
"MAY" and "ought"... And doesn't say anything about the brokenness of
"Sv: ", and its ilk.
I don't think that language is strong enough, given that there *is* a
functional difference between having a well-adhered to "Subject: Re: "
method, and not. I think we should use RFC2119 language, and we should
do so in USEAGE.
Anyway, that's all I'm going to say on the subject, since any further
argument is likely to just be repetition.
As far as what Charles is waiting on... I dunno, but I'd suggest
"direction from the Chair" is a good thing to wait on at this point.
I suspect that everyone who's going to say something about this issue
has now said what they want to say, rationale included, and at this
point it's up to the chair to rule on what the consensus viewpoint is.
Later,
Thorf
--
<a href="http://tertius.net.au/~thorfinn">thorfinn@tertius.net.au</a>
"Give away the gerbil, sell the gaffer tape."
-- Jai <solitaire*tygger.net> on Open Source business models