Subject: Re: References

From: John Stanley <[email-masked]>
Date: Fri, 22 Apr 2005 12:52:39 -0700 (PDT)

Russ Allbery <rra@xxxxxxxxxxxx>:

>I don't want to use any sort of SHOULD or MUST in this area (beyond the
>one we inherit from RFC 2822). 

Ok. I'm happy with that. But we cannot then change our minds in mid-stream 
and put a SHOULD NOT or MUST into other pieces of the news standards, 
since that would contradict USEFOR and RFC2822.

>I want to say that, in a Usenet context, a
>followup is *defined* to be a message posted in reply to another message
>with a References header pointing to the message being replied to.

So what? Not "so what, you want to say", but "so what if a followup is 
defined that way?" You can't identify one as such using the RFC2822 
headers, so why bother putting a special name on it? It's like defining 
a "narquark" as "an article posted by a person with a mole on his left 
shoulder." If you cannot identify "narquarks", you aren't able to treat 
them specially, so they are still just "articles" and get treated like any 
other.

In other words, if it is important enough to DEFINE what a followup is
(presumably so it can be treated specially), then it is important enough
to provide a mechanism to identify followups at the point you want to
apply that special treatment. The only person who really knows "this is a
response to somethign else" is the poster. Without a References MUST/MUST
NOT dichotomy, you cannot identify them once they leave his hands. You get
"well, this sorta looks like a followup" and MAYBE it is, maybe it isn't.

(And in case the argument that "it guesses right often enough", I'll point 
out that this is a TECHNICAL standard and TECHNICAL standards don't 
promote guessing, especially when they could promote fact just as easily.)

>In other words, if your news posting software doesn't insert a References
>header, it's still posting well-formed messages.  It's just not posting
>*followups*, by definition.  

Well, I guess we have to disagree here. I don't think you can isolate the 
concept of a "followup" from the intent of the poster. An article that 
someone posts using F in trn, where he puts in a new subject and entirely 
new content, but forgets to remove the References header, is not really a 
followup of any kind. The recipient would treat it as such based on the 
References header, but it really isn't. It's really an incorrectly 
formatted article (today) because it contains a header it is prohibited 
from containing based on its purpose.

>In practice, I don't think there's any need to distinguish, for UI
>purposes, between different reasons why an article cites a previous
>article with References.  

Then "followup" is a meaningless concept, since it cannot be identified 
for special treatment. 

>The function the References header provides is enabling construction of
>threads.  This is closely related to the notion of followups but, to me,
>is not identical to it.

What is a "thread" if there is no "followup"? What is a "thread" when a 
"thread" may contain any collection of articles at all, not just ones that 
are somehow related in the real world?

So, this looks like a complete turnaround in what I'm saying, huh? No 
followups, no threads, References meaningless? Nope. Here's the crux:

Either we say "RFC1036 was right" regarding the References header and
followups and propogate that, with all the implications, into the new
standard, or we say "RFC1036 was wrong" and propogate that, with all the
implications, into the new standard. This half of one, half of the other
attitude is ridiculous. If RFC1036 is right, then Rererences is a
MUST/MUST NOT header, and followup is a valuable concept because we can
identify them at the recipient's end. If RFC1036 is wrong, then References
is a MAY/SHOULD/SOMETIMES header and followup is meaningless because we
cannot identify them.

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Fri, 22 Apr 2005 16:18:24 -0400

> is a MAY/SHOULD/SOMETIMES header and followup is meaningless because we

Me too.

John has been pointing out problems with this all along,
much past the point of getting ignored.  So I want to be on record that
I tend to think this paragraph sums it up.

There is no reason USEFOR should get away with the result of something like a
bad Abbot and Costello routine.