ietf-nntp Backfill

Chris Caputo ccaputo at alt.net
Tue Dec 17 11:07:24 PST 1996


On 17 Dec 1996, Chris Lewis wrote:
> I consider backfilling (except for epoch reset) to be broken behaviour,
> and it should not be enshrined in the standard.

As another server author, I add my support to the apparent consensus that
this be indicated as broken behavior.

I would like to suggest that the handling of an epoch reset or any case
where a new minimum article number is less than the previous minimum
(essentially an epoch reset and necessary become someone may use the
server long after a reset) be defined in terms of both the server and
client. Should this go into rfc977bis or a future extensions doc or
nowhere? 

Current implementations are handling this in different ways and it would
be nice to have consistency.  A few possibilities that allow a reset to
happen while not having to resort to emptying the group include: 

  - defining a secondary min/max such that during an epoch reset phase the
    message range could be defined by two subset ranges - ex:

        group alt.test 211 100 4294967195 4294967295 200 0 199 alt.test
                           ------------------------- ---------
                             primary count/min/max
                                                   secondary c/m/m

    This would work as long as the client can handle the size (16-bit,
    32-bit, 64-bit) of the numbers the server gives it.  A problem does
    arise when a group holds more at one time than the range can support. 
    Don't laugh. 

  - add the concept of an epoch count that includes the epoch number of
    the max article number and the size of an epoch.  Weird. 

  - allow the server to use article numbers that are greater than what the
    client may support, ie. 64-bit vs. 32-bit.  This would be something
    where the client indicates to the server that it can only handle a
    certain article range (ex. 0 - 2^32-1) and the server handles
    conversion of local article numbers to client friendly article
    numbers.  Of course, this would be specified in a way that doesn't
    actually mention things like 32-bit or 64-bit numbers.

Just a few ideas.

Chris Caputo
President, Altopia Corporation




More information about the ietf-nntp mailing list