Re: Section_7.02.02

New Message Reply About this list Date view Thread view Subject view Author view

From: Brad Templeton (brad@main.templetons.com)
Date: Fri Nov 05 1999 - 19:10:52 CST


On Fri, Nov 05, 1999 at 11:33:34AM +0000, Charles Lindsey wrote:
> In <87k8nyvwso.fsf@erlenstar.demon.co.uk> Andrew Gierth <andrew@erlenstar.demon.co.uk> writes:
>
>
> However, the question is whether the despammers could make use of ANY
> method of multiple cancels in a single message. If not, there is little
> point in proceeding with Brad's proposal.
>

There are many reasons, regardless of the current despammers. Why would
you design something to do just one when it's trivial to have it do N?
Even if you only use it do do one message at a time, it still works, but
you have the option of more.

Ie:

        Control: multicancel

        <message-id>

Is only trivially longer than
        
        Control: cancel <message-id>
        
        (blank body)

However, it generalizes. And the NoCem works this way as well.
A NoCem is really a cancel that is only excuted by those sites who
subscribe to a particular stream. Does anybody do anything with a
nocem other than ignore it or use it as a bulk cancel? It should be
a control message.

There are other reasons for an efficient bulk cancel. Yes, if you want
to have large numbers of parties issuing identical cancels you want to
use a flood algorithm involving duplicate message-ids. But if you don't
have a large number, then it's pretty inefficient to put one message-id
per message. Indeed, depending on the byte count of your headers, you
need to have many sources to make one at a time more efficient.

There are other ways to do that that make more sense today, such as
multicasting among the cancellers.


New Message Reply About this list Date view Thread view Subject view Author view


This archive was generated by hypermail 2b29.