Followups to multiple messages and to individual messages

From: Bruce Lilly (blilly@erols.com)
Date: Fri Mar 19 2004 - 07:39:36 CST


Charles Lindsey wrote:
> In <40584453.4090206@erols.com> Bruce Lilly <blilly@erols.com> writes:

> I was more concerned to know whether that information was essential for
> threading, which is the main application for the References header.

Not essential (and threading itself is not essential; it is a
UA feature), but if a UA threads, some order of presentation
is provided. In the case of a followup to multiple articles,
where does one place the followup? In order to answer that,
one needs to know exactly *which* articles it is a followup
to, and References provides no mechanism to identify the
immediate predecessors (vs. any other ancestors, with the
exception of the root -- if there is a single root). The
alternative is to pick an arbitrary predecessor as *the*
predecessor, or to use some auxiliary information, such
a timestamp for ordering. In order to pick one of the
immediate predecessors, or if auxiliary information is used,
but within subthreads (as opposed to an overall ordering
within the entire thread), then again it is necessary to be
able to identify the immediate predecessors. So while
identification of immediate predecessors cannot be said to
be essential for purposes of protocol or network operations,
in practice it is quite important for threading.

>>If we're going to address followups to multiple messages, we're
>>going to need to examine and modify the draft text related to
>>Newsgroups, Followup-To, Distribution, etc.; the content of
>>those fields may differ among the multiple articles being
>>followed up.
>
>
> Yes you raise some interesting issues which would need to be taken into
> account. I do not think they are insuperable. I would imagine that the way
> one would construct a followup would be to followup to the first article,
> and then to instruct the newsreader to bring other articles into the pool.

Which article among many to be responded to is the "first"?
What do you mean by "pool"? In the case of the simple examples
I provided, would you initialize the followup newsgroups to the
union of the sets of newsgroups in the predecessors (or to the
intersection of those sets, or something else)? What if, as
in my examples, one has Followup-To: poster? Similarly for
distributions (except distributions may be hierarchical with
no clear hierarchy; it is redundant to include any other
distribution with "world". It is also redundant to include a
distribution for the city of Paris, France with the distribution
for the entire country of France (unfortunately, the distribution
naming is not hierarchical, so identifying such redundant cases
is difficult). How would one initialize the Subject field,
given that it is different in each predecessor (in my simple
example)?

In addition to addressing followups, one must consider mailed
responses, and you haven't addressed that issue at all.

> So the headers would start out as from the first article, and then some
> rule would be needed on how to merge the later ones (though by that stage
> the user is well in charge, and in practical cases the articles are likely
> to be from the same thread with the same groups and distributions).

Again, you have glossed over how to determine which article
is "first". Also, you are presuming that selection of articles
to be followed up happens after a proto-article has been prepared,
but there is no reason to presume that. One might select (or "tag")
articles in a character-based (e.g. Pine) or GUI-based followup
agent, then indicate that a followup is to be prepared.

Clearly a followup initiated from a real newsgroup will have at
least that newsgroup in common among all of the articles being
followed up, and that is indeed the case in my example. But
there are likely to be some differences. And distributions may
vary as well. Simply waving your hands about and mumbling
something about "in practical cases" isn't going to be useful
to a developer coding a real followup agent; either there are
clear rules for handling all cases that might arise, or there
will be differences in implementations -- differences that may
lead to unexpected results, up to interoperability problems in
the worst-case scenario.

And that doesn't address virtual newsgroups at all.

> Note that I am not rushing to include such a scheme in the present draft.

"The present draft" is what it is. It might (should) be included
in a future draft, and to do so we need to discuss the issues.

> Somebody raised it, and it is a job that needs doing, so it was worth some
> discussion

IIRC, you raised the issue most recently.

> And if there is an obvious and simple way to do it, then it
> might be included. But we really need to hear from someone who has
> actually implemented a full threader.

Treatment of Newsgroups, Distribution, and Subject have no bearing
a threading.

>>article C may have
>> From: e@f.gov
>> Newsgroups: foo
>> Followup-To: poster
>> Subject: thingamajig
>> Distribution: uk
>> Mail-Copies-To: nobody
>
>
>
>>Side issue:
>>Is the combination of
>> Followup-To: poster
>>and
>> Mail-Copies-To: nobody
>>in article C legal and semantically sensible? The Usefor draft
>>doesn't address those issues (even for the case of article
>>C considered in isolation). Perhaps the two fields should be
>>combined into a single field:

[now who's changing text; I had *two* space characters at the
start of the lines with the indented header field lines (1/2 :-))]

> No, it is too late to do that now.

Why? Mail-Copies-To is first introduced in the Usefor draft.

> The Mail-Copies-To-header is far from ideal, but it arose from 'folklore'
> rather than any formal design effort, so all we could do was to codify
> (and tidy up) the existing practice.

Part of the tidying up process is to examine the implications,
including consistency with (or lack thereof) other header fields,
and potential conflicts with other header fields. And resolving
(rather than sweeping under the carpet) those issues.

> But you are right in that section 8.6 does not address the
> Followup-To: poster situation at all, and it ought to. I have made a note
> to attend to that.
>
> As to the conflict between 'poster' and 'nobody', I am not particularly
> bothered. If the original poster creates such a stupid situation, then the
> worst that will happen when a 2nd poster follows up will be that he sees a
> warning "The OP has requested no mail to be sent to him; do you want to
> send it regardless?". Whereupon the 2nd poster should say "The OP is an
> expletive-deleted idiot and I don't see why I should bother with him".

So, two questions (right to follow up subsequently not waived):
1. Do you think that
      Followup-To: poster
   is reasonable in the absence of any Mail-Copies-To field?
2. Do you think that Mail-Copies-To should be mandatory or optional?

You may wish to reread the draft w.r.t. Mail-Copies-To and defaults
before answering, and/or consider exactly *who* has created the
"stupid situation" for the case of an article with
   Followup-To: poster
and no Mail-Copies-To field. You might also consider that the "2nd
poster" might consult the Usefor draft (or whatever RFC it eventually
becomes (presumably a five-digit one at the rate it's going)), and
that he might very well come to the conclusion that the
"expletive-deleted idiot" is somebody affiliated with that document
(perhaps its Editor). The point is that we really do need to fix
the problems with the conflicts between Followup-To and Mail-Copies-To
(and I believe that the simplest way to so so is to subsume the
functionality of Mail-Copies-To into Followup-To).

And there are numerous other issues peripherally related to followups,
but that will have to wait.

#################################################################
#################################################################
#################################################################
#####
#####
#####
#################################################################
#################################################################
#################################################################




This archive was generated by hypermail 2.1.7.