Sabahattin Gucukoglu | 1 May 2011 21:32

[NNTP] Article Reinstatement, Was Article Numbers Becoming Invalid (RFC 3977)

Okay, so I *finally* read through all the postings for the thread which I started.  Sorry about that!  Now I am
happy with the outcome, it confirms my understanding of the specification, and all the errata are good. 
But as far as I can see there is still one more problem ...

Article reinstatement, besides the stated uses of gradual cluster-wide synchronisation (which makes
perfect sense) poses a small problem for many clients using articles as intended, monotonically
increasing unique per-server references to articles.  If a client should not be aware that an article has
been removed pending reinstatement, it has no reason to suspect that the low watermark will ever
decrease.  Even if it wanted to, it could not straightforwardly obtain any articles that were added, and
then removed pending reinstatement, both in the client's absence, when they were finally reinstated.

Example: news.test has 5 messages, min=1 max=5.  Article 1 is removed.  Server indicates on group entry to
news.test, min=2 max=5 no=4.  The client updates its counters to indicate that article 5 was the last
article seen.  Article 1 is replaced.  Client connects, server indicates min=1 max=5 no=5.  How is the
client to ensure the retrieval of article 1?  The low watermark may certainly indicate its presence, but it
can hardly assume that an article was reinstated simply because on this occasion min=1 is the smallest
value seen; the article numbered 1 may already have been fetched under normal conditions, or the
heuristic will not work at all if group expiration on criteria other than number of articles has occurred,
for instance.

Does anybody have any ideas?

Cheers,
Sabahattin


Gmane