IETF Logo Mail Archive

Re: ietf-nntp Backfill

Chris Newman <Chris.Newman@innosoft.com> Tue, 17 December 1996 20:27 UTC

Received: from cnri by ietf.org id aa17025; 17 Dec 96 15:27 EST
Received: from ACADEM2.ACADEM.COM by CNRI.Reston.VA.US id aa21455; 17 Dec 96 15:27 EST
Received: (from majordomo@localhost) by academ2.academ.com (8.8.3/8.7.3) id OAA05427 for ietf-nntp-outgoing; Tue, 17 Dec 1996 14:23:30 -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 OAA05422 for <ietf-nntp@ACADEM2.ACADEM.COM>; Tue, 17 Dec 1996 14:23:28 -0600 (CST)
Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by academ.com (8.8.3/8.7.1) with ESMTP id OAA19830 for <ietf-nntp@academ.com>; Tue, 17 Dec 1996 14:23:26 -0600 (CST)
Received: from eleanor.innosoft.com ("port 49403"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.0-8 #8694) id <01ID47C48VMOA8C9QW@INNOSOFT.COM> for ietf-nntp@academ.com; Tue, 17 Dec 1996 12:22:23 -0800 (PST)
Date: Tue, 17 Dec 1996 12:23:10 -0800 (PST)
From: Chris Newman <Chris.Newman@innosoft.com>
Subject: Re: ietf-nntp Backfill
In-reply-to: <199612171937.TAA03237@nothing.ucsd.edu>
To: ietf-nntp@academ.com
Message-id: <Pine.SOL.3.95.961217122020.13274F-100000@eleanor.innosoft.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Content-transfer-encoding: 7BIT
Sender: owner-ietf-nntp@academ.com
Precedence: bulk

On Tue, 17 Dec 1996, Brian Kantor wrote:
> Is it the intention of this committee to make RFC977bis a complete
> specification for the Usenet news system?
> 
> It seems that many of the discussions on here of late have focussed on
> the underlying news storage and retrieval system, not on issues of
> transport, which is the scope of the original RFC977.
> 
> I believe it is time to split the transfer, storage, and reading issues.

It is important to specify the semantics of the data "transferred"
sufficiently that it is interoperable.  I think the discussion of backfill
and the interoperability problems it causes protocol clients is well within
scope.  We do need to specify what happens in storage to the extent that
it impacts protocol interoperability.

v2.8.7 | Report a Bug | By Email