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