Re: ietf-nntp Backfill

[Brian Kantor <[e-mail]>]

The intention of article numbers in NNTP (not stated, because we were
simply providing access to a SEPARATE news system which behaved in this
manner) was that they'd increase monotonically until the news system
admin maybe reset them all to start at one again - which at that time
had never had to happen.  No one expected someone to do something as
unreasonably insane as try to fill in the "holes" left in the numbering
scheme by cancelled and expired articles.

The primary reason for NEXT was that it was clear that there could be
large gaps in the article number ranges, so that articles numbered
1,2,3,42,197,4201 might be the only ones there, and asking the client
to step through them one at a time was a ridiculous thing that only
an feeble programmer might do.

NEXT, as it was intended to be used, had direct knowledge of the
existing numbers in the group, so it could get the next article
whatever its number was.  To be specific, we expected that the GROUP
command would perform a directory search of the group, arrange that in
numerical order, and use that to step through the articles.

Remember that NNTP was written to provide a network interface to an
existing news system (B-news) and much of the behaviour of B-news
was implied in the way we expected NNTP to work.  Article numbers
increased monotonically, and once an article was assigned a number,
that number was never used again.

It was not incorrect behaviour that NEXT might return an article greater
than the highest-article-number as returned by the GROUP command, as
that was common behaviour for the news system - with as many as a
hundred articles coming in a day, you might well get a new one before
you'd finished reading the group.  (snicker)

By the way, the news readers that I'm most familiar with cope with
the case where the GROUP command returns an article number that is less
than the previous minimum article read by simply resetting the 'articles
read list' to null - and warning the user that they've done so on the
assumption that the system admin had reset the article numbers.  No one
expected that to happen more than once a year, though, so the problem
of overlapping numbering for still-extant articles wasn't a matter for
concern - it couldn't happen.  It was a big moment when the article
number fields in the active file had to increase above 5 digits.

Hope that helps.
	- Brian