Serving agents and duplicates (was: Protocol changes in draft-allbery-usefor-usepro-00)

Russ Allbery <rra@stanford.edu> Fri, 29 December 2006 22:02 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0PoE-0007EM-V8 for usefor-archive@lists.ietf.org; Fri, 29 Dec 2006 17:02:38 -0500
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0PoD-0007hE-HP for usefor-archive@lists.ietf.org; Fri, 29 Dec 2006 17:02:38 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBTLpGJF076044; Fri, 29 Dec 2006 14:51:16 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBTLpGZB076043; Fri, 29 Dec 2006 14:51:16 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f
Received: from smtp3.stanford.edu (smtp3.Stanford.EDU [171.67.20.26]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBTLpFQt076037 for <ietf-usefor@imc.org>; Fri, 29 Dec 2006 14:51:15 -0700 (MST) (envelope-from rra@stanford.edu)
Received: from smtp3.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 641204C913 for <ietf-usefor@imc.org>; Fri, 29 Dec 2006 13:51:15 -0800 (PST)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.stanford.edu (Postfix) with ESMTP id 46B084C0AE for <ietf-usefor@imc.org>; Fri, 29 Dec 2006 13:51:15 -0800 (PST)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 429BCE7C46; Fri, 29 Dec 2006 13:51:15 -0800 (PST)
From: Russ Allbery <rra@stanford.edu>
To: ietf-usefor@imc.org
Subject: Serving agents and duplicates (was: Protocol changes in draft-allbery-usefor-usepro-00)
In-Reply-To: <JAHJs5.FHC@clerew.man.ac.uk> (Charles Lindsey's message of "Mon, 18 Dec 2006 20:04:53 GMT")
Organization: The Eyrie
References: <JA8C4p.Anu@clerew.man.ac.uk> <873b7i9b2m.fsf@windlord.stanford.edu> <JAHJs5.FHC@clerew.man.ac.uk>
Date: Fri, 29 Dec 2006 13:51:15 -0800
Message-ID: <87bqlmgylo.fsf_-_@windlord.stanford.edu>
User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-usefor@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465

Charles Lindsey <chl@clerew.man.ac.uk> writes:
> Russ Allbery <rra@stanford.edu> writes:
>> Charles Lindsey <chl@clerew.man.ac.uk> writes:

>>> 21. [-1] (3.6) No mention of processing cancel messages by
>>> serving/storage agents.

>> The same language is here as for relaying agents, but you may have missed
>> it because it's combined with another similar point:

>>   3.  It SHOULD reject any article that has already been successfully
>>       sent to it or that matches an already-received and honored cancel
>>       message or Supersedes header field following the same rules as a
>>       relaying agent (Section 3.5).

> OK, point taken, but it might be better split out. Moreover, the first
> bit corresponds to step 2 of relaying which is a MUST, as is the matter
> of stale articles (which is also a history file matter).

Good point.  So much for trying to save a bit of length.  :)

I now have:

   3.  It MUST reject any article that has already been successfully
       sent to it, based on the Message-ID header field of the article.
       To satisfy this requirement, a relaying agent normally keeps a
       database of message identifiers it has already accepted.

   4.  It SHOULD reject any article that matches an already-received and
       honored cancel message or Supersedes header field following the
       same rules as a relaying agent (Section 3.5).

which is basically the same text as for relaying agents.

> OK, but people will think it odd that you mention the obscure case of
> cancels which arise first here, but make to mention of the common case.
> Perhaps an extra step to say that it SHOULD then process any control
> messages (including cancels) in acccordance with section 5.

This would need to be added to relaying agents as well.  I don't feel like
it's really necessary, but I don't object if others in the WG would like
it to be added.  (I think that's MAY, not SHOULD; many news servers don't
process control messages at all and unless they want to honor cancels,
there's no need for them to do so.  There are numerous other ways to
maintain an active newsgroup list.)

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>