Path: utzoo!attcan!utgpu!watmath!looking!brad
From: brad@looking.on.ca (Brad Templeton)
Newsgroups: news.software.b
Subject: Re: cancel propagation (was Re: Supersedes problems with rapid-fire articles)
Message-ID: <6233@looking.on.ca>
Date: 31 Aug 89 16:16:15 GMT
References: <5200@looking.on.ca> <536@logicon.arpa> <3246@deimos.cis.ksu.edu> <1989Aug30.174430.20687@anise.acc.com> <1989Aug31.034105.2177@utstat.uucp>
Reply-To: brad@looking.on.ca (Brad Templeton)
Organization: Looking Glass Software Ltd.
Lines: 26
Class: rebuttal

In article <1989Aug31.034105.2177@utstat.uucp> geoff@utstat.uucp (Geoff Collyer) writes:
>RFC 850 did not contain the wording in RFC 1036 requiring that a cancel
>stop spreading when it can't find its target.  We regard this
>requirement as an error in 1036 (see notebook/rfcerrata for a longer
>list).  relaynews never drops a cancel and creates a fake history entry
>for the target if the target is not already in history.  When the
>target article does arrive, it will be rejected as a duplicate.

Geoff, the RFC did not make an error.   If a cancel message arrives
for a message that hasn't arrived yet, you should note the message ID
in the database, as you do.  Then you should throw the cancel away and
NOT propagate it.

Then if the real message shows up, or any duplicates of it, you just
toss them away too.

You never needed to send the cancel message to the downstream sites, because
you *know* you are never going to feed them an article with the specified
message-id.  Why do they need to keep it around in their databases?

Yes, they could get it through a redundant feed, but they will also get the
cancel message through that channel, too.

Sigh.
-- 
Brad Templeton, Looking Glass Software Ltd.  --  Waterloo, Ontario 519/884-7473