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

[Sabahattin Gucukoglu]

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