431 for TAKETHIS

[Russ Allbery]

Don Lewis <Don.Lewis at tsc.tdk.com> writes:

> Innfeed doesn't implement this, but if it got an rejection or deferral
> response to a TAKETHIS, it could abort the article transmission.  Doing
> this in the rejection case can save quite a bit of bandwidth in the case
> of large articles if the receiver scans the headers for whatever it
> doesn't want to receive as the article is being received.

True, but I believe it would be a violation of the NNTP protocol to do so
(insofar as streaming is even part of the NNTP protocol, which I realize
is rather iffy).  The problem with aborting the transfer of an article is
that you've now sent, claiming to be a copy of the article with message ID
<blah>, an article which isn't actually all of <blah>.  This to me seems
dangerously likely to cause a truncated version of the article to get
propagated in the case of some obscure bugs or error conditions.

Premature abort on TAKETHIS or IHAVE would be nice, but I think it would
be tricky to implement and document in a way not prone to that problem.
That's a bit of a different problem than deferral, though.  For the
deferral case, I think it's wasted effort for a case that's likely to
happen only with a small handful of articles, because it only is an issue
in the case where you have a peer who's gone into no-CHECK mode, and if
you're accepting enough to put a peer in no-CHECK mode, you've almost
certainly not got other peers sending you any sizeable percentage of
articles at nearly the same time.

-- 
Russ Allbery (rra at stanford.edu)         <URL:http://www.eyrie.org/~eagle/>