Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site isis.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!hao!nbires!isis!aburt
From: aburt@isis.UUCP (Andrew Burt)
Newsgroups: net.news
Subject: Re: cleaning up the net -- software solutions proposed
Message-ID: <118@isis.UUCP>
Date: Wed, 17-Jul-85 10:22:38 EDT
Article-I.D.: isis.118
Posted: Wed Jul 17 10:22:38 1985
Date-Received: Sat, 20-Jul-85 02:46:25 EDT
References: <2982@nsc.UUCP> <184@almsa-1>
Reply-To: aburt@isis.UUCP (Andrew Burt)
Distribution: net
Organization: University of Denver Math and Computer Science
Lines: 71
Summary: Use References header instead of included articles;

Maybe I'm just a little groggy this morning, but it strikes me that a majority
of the included articles could be avoided by cleverly using the "References:"
header line to display articles referred to.  Perhaps a field labeled
"See-also:" would be more appropriate, and could indicate explicitly that the
author wished to include the specified article.

Put in at the rn/readnews/etc. level, as an option, a user could request
to see the article most recently posted, or chain backwards through the
references given (References:, See-also:, or both).

Clearly this would hinge upon the availability of older articles on each
system, but this could be worked around I'm sure.  One idea might be to
edit the expiration field of the articles referred to and mark them
as not yet due to expire.  When a subject died down, the articles would
all be expired at more or less the same time.  This also solves the
problem of not being able to get at older articles when you come into the
middle of a discussion.

With this in place, a news reading program could put in the See-also: line
when used with its followup-and-include-article command rather than
doing the text inclusion directly.


I would also like to see a better scheme to keep Subject lines
a) in touch with the subject being discussed and b) the same for
all articles on a given subject.  By b) I mean people who see an article
on subject "Foo Bar" and don't follow up, but post an article with
subject "problems with foo bar".

If I'm interested in foo bar, I want to be able to use, e.g., rn's
ability to track it; if I'm not interested, I want to be able to use,
e.g., rn's ability to kill it.  I don't think that syntactic analysis
of the Subject line will be enough.  Perhaps what would be appropriate
would be (sigh) another header line, say "Topic:", which indicates
the topic of conversation.  (Or maybe we can get people to use Keywords,
although that doesn't mean the same thing to me, at least.)  In the
example case, the Topic would be "foo bar".

News reply programs could query the poster with something like, "Is this
in response to a subject already under discussion", or maybe better,
"Is this a topic you haven't seen discussed recently?"  However it's
phrased, if the user indicates that it relates to a current discussion,
the posting program could guide the user into entering a Topic line that
was current.  (I.e., it goes and looks in the newsgroup at the Topic
lines there.)

As far as my a) goes, the Topic line would be changed (hopefully) by
the poster who begins discussing another topic.  Perhaps multiple
topics is the answer (Topic: foo bar, blech).  And, of course,
news reading programs would need to be able to follow topics (disjoint
perhaps from ability to follow similar subject lines).


On the subject of line count limits -- ugh.  (Ack!)  Fixed numbers of
lines will only inhibit the flow of real information and encourage multiple
postings so people can say their peace.  (Y'know, articles will start off
saying "... Continued from previous article ...")  Think of postings
which are summaries of mail responses to queries ("Reply by mail, I'll
summarize") -- these would be dead.  However, I'm sure other solutions
will be found, so I'm not sweating this one.

				Andrew
-- 

Andrew Burt
University of Denver
Department of Math and Computer Science

UUCP:	{hao!udenva, nbires}!isis!aburt
CSNet:	aburt@UDENVER	(NOT udenva, as above...)
ARPA:	aburt%udenver.csnet@csnet-relay.arpa