Re: ietf-nntp New wording on article numbers

Chris Caputo <ccaputo@alt.net> Sat, 28 December 1996 08:00 UTC

Received: from cnri by ietf.org id aa05948; 28 Dec 96 3:00 EST
Received: from ACADEM2.ACADEM.COM by CNRI.Reston.VA.US id aa03542; 28 Dec 96 3:00 EST
Received: (from majordomo@localhost) by academ2.academ.com (8.8.4/8.7.3) id BAA00461 for ietf-nntp-outgoing; Sat, 28 Dec 1996 01:56:05 -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.4/8.7.3) with ESMTP id BAA00434 for <ietf-nntp@ACADEM2.ACADEM.COM>; Sat, 28 Dec 1996 01:55:56 -0600 (CST)
Received: from baklava.alt.net (root@baklava.alt.net [207.17.118.9]) by academ.com (8.8.4/8.7.1) with ESMTP id BAA23378 for <ietf-nntp@academ.com>; Sat, 28 Dec 1996 01:43:04 -0600 (CST)
Received: from baklava.alt.net (ccaputo@baklava.alt.net [207.17.118.9]) by baklava.alt.net (8.8.4/8.7.3) with SMTP id XAA21213; Fri, 27 Dec 1996 23:42:55 -0800 (PST)
Date: Fri, 27 Dec 1996 23:42:53 -0800 (PST)
From: Chris Caputo <ccaputo@alt.net>
Reply-To: Chris Caputo <ccaputo@alt.net>
To: "Clive D.W. Feather" <clive@demon.net>
cc: IETF NNTP mailing list <ietf-nntp@academ.com>
Subject: Re: ietf-nntp New wording on article numbers
In-Reply-To: <851718764.6954.0@office.demon.net>
Message-ID: <Pine.BSI.3.93.961227230241.15979B-100000@baklava.alt.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-nntp@academ.com
Precedence: bulk

On Fri, 27 Dec 1996, Clive D.W. Feather wrote:
>     Each article has three relevant properties:
[...]
>       - An arrival timestamp, giving the time it arrived at the server.
[...]

I suggest that the concept of an arrival timestamp be replaced with
something that says the server is responsible for article ordering, with
the recommendation being that articles are ordered in the order they are
received.  Since the arrival timestamp is not exposed, we should not
require that server authors handle this issue in a specific way.

>     Article numbers MUST lie between 1 and 999999999 inclusive [this allows
>     one article per second for 31 years]. The client and server SHOULD NOT
>     use leading zeroes in specifying article numbers. If the server loses
>     record of the most recent article number in a group, it MUST reset to a
>     higher article number.

I'd remove the part about one article per second for 31 years.  It could
be said that a million sites posting an article a day will use this range
up in 3 years and it would be just as meaningless. 

If we're gonna stick to 32 bits, I'd say we should at least use the full
32 bits (1 to 4,294,967,295) to give us slightly more leg room.  Our
control.cancel is up to 4 million now and I expect it to pass a billion in
a few years. 

If Usenet (as an example ;-) continues to grow as it has, we may eat this
space pretty quickly in which case we either need to expand the range to
64 bits and/or precisely define how to handle rollovers.  I'd love to see
us do both, but I don't think I have much support in that department.  Or
do I? 

Chris Caputo
President, Altopia Corporation