Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site glacier.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!decwrl!glacier!reid From: reid@glacier.ARPA (Brian Reid) Newsgroups: net.sources.bugs,net.news,net.news.adm Subject: A proposal for a consistent REPOST scheme Message-ID: <3473@glacier.ARPA> Date: Fri, 24-Jan-86 16:17:46 EST Article-I.D.: glacier.3473 Posted: Fri Jan 24 16:17:46 1986 Date-Received: Sun, 26-Jan-86 04:05:04 EST Reply-To: reid@glacier.UUCP (Brian Reid) Organization: Stanford University, Computer Systems Lab Lines: 65 Xref: watmath net.sources.bugs:654 net.news:4552 net.news.adm:495 Reposting is a nuisance. The net is flooded with a lot of requests for reposting, and (invisibly) the mail system is flooded with the replies. The one time I asked for a copy of something I got 40 copies, all by mail. Repostings are needed for 2 reasons: (1) The original copy got lost, and never made it to a particular segment of the net (this happens a lot when big software systems are posted from leaf nodes). (2) The person asking for the repost did not save a copy of the original. The right thing to do for repostings is to repost. But nobody wants to repost because they are afraid that somebody else has reposted, and we don't want to flood the net with copies. So the requested repostings get sent by mail. There was an analysis by Chuq von Rospach about a year ago that showed that it was cheaper (in terms of cost to the net) to post something instead of mailing it if it is going to go to more than 15 or 20 people. The right thing to do is for each reposting request to have a serial number or a Repost-request-ID. Anyone who sees that request and who would like to be helpful should be encouraged to repost, **BUT**, with the Message-ID of the reposting being the Repost-request-ID of the request. That way if 15 people repost something, the net is not flooded with 15 copies, because all 15 of them will have the same Message-ID, and the inews software will think that they are all the same message and will not propagate it to or through a site that already has one. This scheme will handle, perfectly, the case in which somebody wants a copy of an old message. The protocol would be that the request for reposting is given a Message-ID, allocated from the name space of the poster's machine, and posted to the newsgroup in which the original message appeared (this is what people do anyhow right now, even though they are not supposed to). The "repostnews" and/or "RPnews" programs would do 2 things: (1) Post the requested article under the Message-ID used by the Repost-request (2) Send out a "cancel" control message on the reposting request. (yes I know that this involves cancelling a message that was posted by somebody else, but the software can cope). I believe that this scheme will do an optimal job of handling the case of a person asking for an old posting. If people respond fast enough then the request will not even propagate very far. The case of 200 people asking for an immediate reposting of something that didn't get through is a bit harder to handle, because you don't want to have to go through the task of figuring out which one of those 200 requests should be the one to determine the Message-ID of the reposting. The only sensible thing to do here is to repost the article under its original message-ID, but with an "R" in front of it. So for example if I posted a Squid Body Weight computation program with Message-ID: 12345@glacier.ARPA, and John@greipa wanted a copy, he would post "Request repost of Squid program", not knowing its message id, and then smith@decwrl could put up another copy as "Message-ID: R1234@glacier.ARPA". The reason for not doing distant-past reposting by old-MessageID is that many people trim the netnews headers from things that they post, so the old Message-ID is not always available. I believe that all of this algorithm can be easily implemented in a simple "repost" program, which I propose to write and post in the next week or two unless I hear wild complaints about the idea in the interim. -- Brian Reid decwrl!glacier!reid Stanford reid@SU-Glacier.ARPA