Re: ietf-nntp Backfill
Chris Caputo <ccaputo@alt.net> Tue, 17 December 1996 19:14 UTC
Received: from cnri by ietf.org id aa14184; 17 Dec 96 14:14 EST
Received: from ACADEM2.ACADEM.COM by CNRI.Reston.VA.US id aa19475;
17 Dec 96 14:14 EST
Received: (from majordomo@localhost) by academ2.academ.com (8.8.3/8.7.3) id
NAA04802 for ietf-nntp-outgoing; Tue, 17 Dec 1996 13:07:37 -0600 (CST)
X-Authentication-Warning: academ2.academ.com: majordomo set sender to
owner-ietf-nntp using -f
Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by
academ2.academ.com (8.8.3/8.7.3) with ESMTP id NAA04797 for
<ietf-nntp@ACADEM2.ACADEM.COM>; Tue, 17 Dec 1996 13:07:35 -0600 (CST)
Received: from baklava.alt.net (root@baklava.alt.net [207.17.118.9]) by
academ.com (8.8.3/8.7.1) with ESMTP id NAA18315 for <ietf-nntp@academ.com>;
Tue, 17 Dec 1996 13:07:33 -0600 (CST)
Received: from baklava.alt.net (ccaputo@baklava.alt.net [207.17.118.9]) by
baklava.alt.net (8.7.6/8.7.3) with SMTP id LAA16797 for
<ietf-nntp@academ.com>; Tue, 17 Dec 1996 11:07:26 -0800 (PST)
Date: Tue, 17 Dec 1996 11:07:24 -0800 (PST)
From: Chris Caputo <ccaputo@alt.net>
Reply-To: Chris Caputo <ccaputo@alt.net>
To: ietf-nntp@academ.com
Subject: Re: ietf-nntp Backfill
In-Reply-To: <199612171553.JAA15759@academ.com>
Message-ID: <Pine.BSI.3.93.961217101130.11555B-100000@baklava.alt.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-nntp@academ.com
Precedence: bulk
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
- ietf-nntp Backfill Clive D.W. Feather
- Re: ietf-nntp Backfill Jon Ribbens
- Re: ietf-nntp Backfill Rich Salz
- Re: ietf-nntp Backfill Richard Clayton
- Re: ietf-nntp Backfill Clive D.W. Feather
- Re: ietf-nntp Backfill Clive D.W. Feather
- Re: ietf-nntp Backfill Nat Ballou
- Re: ietf-nntp Backfill Brian Kantor
- Re: ietf-nntp Backfill markd
- Re: ietf-nntp Backfill Rich Salz
- Re: ietf-nntp Backfill Stan Barber
- Re: ietf-nntp Backfill USENET news manager
- Re: ietf-nntp Backfill Chrisy Luke
- Re: ietf-nntp Backfill Taz Higgins
- Re: ietf-nntp Backfill Nat Ballou
- Re: ietf-nntp Backfill Chris Lewis
- Re: ietf-nntp Backfill Chris Caputo
- article numbers (was Re: ietf-nntp Backfill) Chris Newman
- Re: ietf-nntp Backfill Brian Kantor
- Re: ietf-nntp Backfill Chris Newman
- Re: ietf-nntp Backfill Clive D.W. Feather
- Re: ietf-nntp Backfill Clive D.W. Feather
- Re: ietf-nntp Backfill Clive D.W. Feather
- Re: ietf-nntp Backfill Jack De Winter
- Re: ietf-nntp Backfill Chris Hall
- Re: ietf-nntp Backfill Mark Sidell
- Re: ietf-nntp Backfill Alan Barrett