ietf-nntp Backfill: not again.

[Alan Barrett]

> I don't !@#$!#$ believe it.  Backfill was discussed to death here on
> the list *after* the IETF meeting.

Sorry.  I was out of circulation for a while.

> A master could split its feed for a slave into multiple processes and
> such that the slave got 12, 13, 15, 16 from proc-A and then got 14
> from proc-B. If the slave is handling newsreaders, then *the site that
> is doing this is misconfigured.*

It would be nice if people who make assertions like that would explain how
to correctly configure a master/slave site. 

*If* such sites are misconfigured, then I think we can deduce that a
properly configured master/slave site will satisfy one of the following
conditions: 

A)  A master must not split its feed for a slave into multiple
    processes, or
B)  The slave may receive articles out of order, but must then use
    special methods to hide that from its newsreader clients, or
C)  The master/slave set must use special methods (outside NNTP) to
    ensure that articles arrive at the slave in order.

I claim that those conditions are too onerous (hence, it's not
reasonable to declare that sites that fail to satisfy them are
misconfigured).  (A) is too onerous because news load is ever
increasing, multiple parallel feeds are becoming the norm, and it's easy
to run out of round-trip time or bandwidth or some other resource if you
try to send a huge newsfeed over a single NNTP connection.  (B) and (C)
are too onerous because we don't understand how to do them.

> Once a client has seen 13, been told 14
> doesn't exist, and then got 15, *the client should not be expected to
> try later on to see if 14 might exist.*

I understand why people would like to say that.  However, I believe that
we do understand how to build clients that can cope with this new problem. 

It seems to me that we have a choice between declaring that servers must
do stuff that is very onerous or not yet understood (while clients carry
on as they are), or declaring that clients must adapt slightly to the new
reality of how servers work in practice.  I think the choice is clear: we
must choose the lesser of the two evils, and make the clients adapt.

If there is a third choice, that of telling servers to do new stuff that
is well understood, not too onerous, but not widely implemented, then I
would go for the third choice.

> At most, one newsreader did this because of a misinformed
> implementation at a large ISP, but that's it.

I suspect that many large ISPs have this problem, even if they are
not aware of it.  More precisely:  I believe that there is a high
probability that articles will sometimes reach the slave out of order
at every site that implements master/slave servers using any of the
following common software or configuration tools:

     innfeed (which inherently wants to use multiple parallel feeds,
              and which deals with temporary problems by spooling
	      old articles to be offered again later, but which
	      offers new articles in preference to old articles
	      whan the temporary problem is cleared up), or
     nntplink in any mode other than logfile mode (which deals with
	      temporary problems by spooling old articles to be offered again
	      later by a separate cron-driven parallel process), or
     parallel feeds configured in the newsfeeds file (with articles in
	      different newsgroups, or articles of different sizes, or
	      whatever, being sent over different feeds),

or a number of other things that I haven't thought of or haven't written
down.

> XREPLIC should not be part of the RFC because crossposted articles make
> it all too easy to exceed the NNTP command-line length limit.

Fine.  The Xref header can carry the same information.

--apb (Alan Barrett)