IETF Logo Mail Archive

Re: ietf-nntp Backfill

markd@mira.net.au Tue, 17 December 1996 00:59 UTC

Received: from cnri by ietf.org id aa23750; 16 Dec 96 19:59 EST
Received: from ACADEM2.ACADEM.COM by CNRI.Reston.VA.US id aa28245; 16 Dec 96 19:59 EST
Received: (from majordomo@localhost) by academ2.academ.com (8.8.3/8.7.3) id SAA01040 for ietf-nntp-outgoing; Mon, 16 Dec 1996 18:56:55 -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 SAA01035 for <ietf-nntp@ACADEM2.ACADEM.COM>; Mon, 16 Dec 1996 18:56:53 -0600 (CST)
Received: from mira.net.au (eplet.mira.net.au [203.9.190.17]) by academ.com (8.8.3/8.7.1) with SMTP id SAA05029 for <ietf-nntp@academ.com>; Mon, 16 Dec 1996 18:56:51 -0600 (CST)
From: markd@mira.net.au
Received: (qmail 16927 invoked from network); 17 Dec 1996 00:56:48 -0000
Received: from bushwire.mira.net.au (203.9.190.24) by eplet.mira.net.au with SMTP; 17 Dec 1996 00:56:48 -0000
Received: (qmail 12200 invoked by uid 999); 17 Dec 1996 00:56:47 -0000
Message-ID: <19961217005647.12198.qmail@bushwire.mira.net.au>
Subject: Re: ietf-nntp Backfill
To: Nat Ballou <NatBa@microsoft.com>
Date: Tue, 17 Dec 1996 11:56:47 +1100 (EST)
Cc: ietf-nntp@academ.com
In-Reply-To: <02ac909500011c6IMSMAIL@ims.microsoft.com> from "Nat Ballou" at Dec 16, 96 04:46:10 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-nntp@academ.com
Precedence: bulk

> > Yet several people at the BOF thought that backfilling was reasonable.
> 
> I did not hear any server people state that backfilling was reasonable
> behavior.  On the contrary, most server implementors thought this was a 
> bug in some implementation.
> 
> I'd like to know exactly what server supports backfilling today.
> If nobody responds, I propose we close this issue and move on.
> We have bigger fish to fry.

I'd be curious to know why too. Does backfilling simply reflect an
underlying allocation scheme that happens to find the first free
number within a range?

Further, backfill most cause confusion for a reader, what if:

	Server				Reader
	------				------
T+0	new article arrives
	allocated # 10
T+1					Reader reads article 10
					notes that #10 is read
T+2	article 10 cancelled
	
T+3	new article arrives
	re-allocated # 10
T+4					Reader never sees the new #10
					as it is marked as read


Or does the reader have to consult the message ids of the article and
track message ids. Ie, a reader history database - ug.


Regards.

v2.8.7 | Report a Bug | By Email