Re: ietf-nntp New wording on article numbers

"Clive D.W. Feather" <clive@demon.net> Sat, 28 December 1996 20:56 UTC

Received: from cnri by ietf.org id aa04108; 28 Dec 96 15:56 EST
Received: from ACADEM2.ACADEM.COM by CNRI.Reston.VA.US id aa13501; 28 Dec 96 15:56 EST
Received: (from majordomo@localhost) by academ2.academ.com (8.8.4/8.7.3) id OAA04157 for ietf-nntp-outgoing; Sat, 28 Dec 1996 14:54:09 -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 OAA04152 for <ietf-nntp@ACADEM2.ACADEM.COM>; Sat, 28 Dec 1996 14:54:07 -0600 (CST)
Received: from office.demon.net (office.demon.net [193.195.224.1]) by academ.com (8.8.4/8.7.1) with SMTP id OAA01602 for <ietf-nntp@academ.com>; Sat, 28 Dec 1996 14:54:05 -0600 (CST)
Subject: Re: ietf-nntp New wording on article numbers
To: Brian Kantor <brian@nothing.ucsd.edu>
Date: Sat, 28 Dec 1996 20:54:04 +0000 (GMT)
From: "Clive D.W. Feather" <clive@demon.net>
Cc: ietf-nntp@academ.com
In-Reply-To: <199612281818.SAA20971@nothing.ucsd.edu> from "Brian Kantor" at Dec 28, 96 06:18:10 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-ID: <851806444.28986.0@office.demon.net>
Sender: owner-ietf-nntp@academ.com
Precedence: bulk

Brian Kantor said:
> Since the article numbers are not transmitted in a binary form, I see
> no reason to artificially restrict the range of article numbers by
> specifying the size or length of the representation.  A specification
> that the numbers are DECIMAL and represent actual article counts should
> be sufficient.  (I.e., we should not force epochal resets of a newsgroup
> article count just because it won't fit in N digits.)

We need to specify the representation used in the protocol (decimal unsigned,
leading zeroes allowed).

If there is no upper limit on article numbers, all client software needs to
implement arbitrary-precision arithmetic "just in case". This is, to my
mind, unreasonable, and so we should put an upper bound.

All reasonable systems can handle unsigned integers of at least 32 bits
(the ISO C Standard requires them to). Therefore 4 294 967 295 (2^32-1)
seems a reasonable limit. [I know I said 999999999 before; I won't embarrass
myself by repeating my reasoning.] I'll address the issue of overflow in
another message.

-- 
Clive D.W. Feather    | Associate Director  | Director
Tel: +44 181 371 1138 | Demon Internet Ltd. | CityScape Internet Services Ltd.
Fax: +44 181 371 1150 | <clive@demon.net>   | <cdwf@cityscape.co.uk>