Re: ietf-nntp Backfill

Nat Ballou <NatBa@microsoft.com> Tue, 17 December 1996 00:47 UTC

Received: from cnri by ietf.org id aa23196; 16 Dec 96 19:47 EST
Received: from ACADEM2.ACADEM.COM by CNRI.Reston.VA.US id aa27957; 16 Dec 96 19:47 EST
Received: (from majordomo@localhost) by academ2.academ.com (8.8.3/8.7.3) id SAA00971 for ietf-nntp-outgoing; Mon, 16 Dec 1996 18:45:16 -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 SAA00966 for <ietf-nntp@ACADEM2.ACADEM.COM>; Mon, 16 Dec 1996 18:45:14 -0600 (CST)
Received: from tide03.microsoft.com (firewall-user@tide03.microsoft.com [131.107.3.13]) by academ.com (8.8.3/8.7.1) with ESMTP id SAA04998 for <ietf-nntp@academ.com>; Mon, 16 Dec 1996 18:45:12 -0600 (CST)
Received: by tide03.microsoft.com; id QAA29151; Mon, 16 Dec 1996 16:45:11 -0800 (PST)
Received: from unknown(157.54.17.74) by tide03.microsoft.com via smap (V3.1) id xma029146; Mon, 16 Dec 96 16:45:03 -0800
Received: from IMSMAIL ([157.55.65.201]) by imail2.microsoft.com (8.7.3/8.7.1) with ESMTP id QAA06354 for <ietf-nntp@academ.com>; Mon, 16 Dec 1996 16:45:15 -0800 (PST)
Received: from natba1 - 172.31.178.33 by ims.microsoft.com with Microsoft SMTPSVC; Mon, 16 Dec 1996 16:50:09 -0800
From: Nat Ballou <NatBa@microsoft.com>
To: ietf-nntp@academ.com
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Subject: Re: ietf-nntp Backfill
Date: Mon, 16 Dec 1996 16:46:10 -0800
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1160
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID: <02ac909500011c6IMSMAIL@ims.microsoft.com>
Sender: owner-ietf-nntp@academ.com
Precedence: bulk

> From: Clive D.W. Feather <Clive@on-the-train.demon.co.uk>
> To: Jon Ribbens <jon@oaktree.co.uk>
> Cc: clive@demon.net; ietf-nntp@academ.com
> Subject: Re: ietf-nntp Backfill
> Date: Saturday, December 14, 1996 4:09 PM
> 
> [...]
>
> >> A sensible client needs to allow for the user wanting to mark articles
> >> as unread. Therefore it must be able to cope with the backfilling
> >> strategy, by (for example) maintaining a list of ranges.
> >No. An unread article and an unavailable article are not the same
> >thing.
> 
> Any mechanism for passing the concept "article 1234 is unread" between
> session can equally cope with passing the concept "article 1234 hasn't
> appeared yet". That's what I meant.
> 
> >> Given this, there seems little reason to require that servers be
> >> monotonic.
> >Given that almost every news client in existance requires that
> >servers be monotonic, I would suggest that it would be a very
> >good idea for the new NNTP specification to require it too.
> 
> 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.

Nat