Re: ietf-nntp New wording on article numbers

Jeff Coffler <jeff@taltos.com> Sun, 29 December 1996 01:06 UTC

Received: from cnri by ietf.org id aa12412; 28 Dec 96 20:06 EST
Received: from ACADEM2.ACADEM.COM by CNRI.Reston.VA.US id aa16739; 28 Dec 96 20:06 EST
Received: (from majordomo@localhost) by academ2.academ.com (8.8.4/8.7.3) id TAA05279 for ietf-nntp-outgoing; Sat, 28 Dec 1996 19:03:34 -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 TAA05274 for <ietf-nntp@ACADEM2.ACADEM.COM>; Sat, 28 Dec 1996 19:03:32 -0600 (CST)
Received: from jeck.taltos.com (jeck.taltos.com [192.207.47.46]) by academ.com (8.8.4/8.7.1) with ESMTP id TAA02549 for <ietf-nntp@academ.com>; Sat, 28 Dec 1996 19:03:30 -0600 (CST)
Received: from jeck (jeck.taltos.com [204.57.150.1]) by jeck.taltos.com (post.office MTA v2.0 0813 ID# 0-11013) with ESMTP id AAA380; Sat, 28 Dec 1996 17:03:28 -0800
From: Jeff Coffler <jeff@taltos.com>
To: "Clive D.W. Feather" <clive@demon.net>
Cc: ietf-nntp@academ.com
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Subject: Re: ietf-nntp New wording on article numbers
Date: Sat, 28 Dec 1996 17:03:27 -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: <19961229010328375.AAA380@jeck.taltos.com>
Sender: owner-ietf-nntp@academ.com
Precedence: bulk

Hi Clive,

> For my next draft, I've added wording to NEXT saying:
> 
>     A server MIGHT, but SHOULD NOT return an article number greater than
>     the "last" value from the most recent GROUP command for this client.
> 
> How does this look to people ?

I think this looks just dandy.

It's not that this is a religious issue; it's not.  I just think that, as
defined, a protocol should behave consistently.  By caching the info that
was returned in the last GROUP command, the NNTP protocol COULD *EASILY*
behave consistently as well (it's - quite literally - just two or three
'if' statements).

With the above addition, it's clear that it's "better" to cache the last
GROUP command data and act consistently (but not required to do so).

I have yet to find a client that cares about this, by the way ...

	-- Jeff