ietf-nntp Backfill: not again.

[Jack De Winter]

>> 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. 

I believe that the point was raised (to death) that there is a big
difference between something the protocol should define and something
the client should handle.  Backfill was banned as it was something that
we should be avoiding.  Sure, the clients can handle it, but they
should not have to.  And seeing as master/slave is the only possible
reason for backfill, banning is still the best thing.

>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.

Onerous is making the assumption that the clients will change.  And
from my point of view, the lesser evil is outlawing backfill in all
cases.  It depends on your viewpoint.  

>> 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.

So, perhaps we need to deal with the problem of multiple feeds to a slave
as a paragraph on its own, and deal with the syncronization problem on
its own.  Can we assume that one master may have many slaves but one
slave can only have one master?

>> 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.

I don't like this, but if it is the only alternative, I would accept
it.  I would rather see a command that would allow you to scan the
newsgroup for articles, and get enough information back that you could
figure out if you needed to download another message.  This would also
allow us to see a list of the articles in question, and thus, we could
make an assertation about whether or not to raise the high water mark
on the articles in question.

regards,
Jack

p.s. On a master/slave feed, how do you take care of reinstated and
cancelled articles anyways?
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 576-3873		http://www.wildbear.on.ca/

Author of SLMail for 95 & NT (http://www.seattlelab.com/)