ietf-nntp Backfill

[Alan Barrett]

Rich Salz said:
> I believe that everyone "just knew" that article numbers were just
> monotonically increasing.  If this is no longer clear to implementors,
> then the RFC must be fixed.

Requiring article numbers to be monotonically increasing is an undue
burden on implementations.  Dealing with non-monotonically increasing
articles at the client side is easy, provided that the overall trend is
for article numbers to increase.

Why it's sometimes difficult for servers to keep article numbers
monotonically increasing:

    If a site wants to keep article numbers in synch between a master
    and slave server, then one of the obvious things to do (given
    today's software) is to run INN in slave mode on the slave server
    and use the xreplic extension on the feed between master and slave.
    If the feed between master and slave is made up of several parallel
    NNTP sessions, or if the list of aticles to be sent is reordered in
    any way due to some transient failure, then articles will sometimes
    arrive at the slave server out of order.

How a client can easily deal with articles that arrive out of order:

    Clients already keep lists of articles that have been read.  When an
    article does not yet exist on the server, clearly that article has
    not been read, and the client should refrain from acting as if the
    article has been read.  This behavious easily deals with articles
    that arrive out of order, but requires the client to maintain an
    ever increasing list of read articles.  Provided the overall trend
    is for article numbers to increase, so that the low water mark never
    (or very seldom) decreases, the client can recover storage space by
    treating all article numbers below the low water mark as having been
    read.

--apb (Alan Barrett)