ietf-nntp Requirement for timeout close unclear
Russ Allbery
rra at stanford.edu
Thu Jul 5 17:32:38 PDT 2001
greg andruk <gja at meowing.net> writes:
> On Thu, Jul 05, 2001 at 04:25:25PM -0700, Russ Allbery wrote:
>> Hm. Do we have the same problem that SMTP does, namely that if the
>> post is accepted but the response is lost, the client may assume that
>> it needs to send it again, resulting in duplicates?
> Yes, if the client does not supply its own message ID, or if it isn't
> careful to use the same ID on a repost attempt. ISTR that early
> versions of Netscape (or maybe it was Mosaic) had big trouble of that
> kind when they lost track of a connection.
>> If so, how do we fix that?
> Encourage or require clients to generate IDs sensibly?
I think we should say something about this in this standard. I propose:
The client SHOULD NOT assume that the article has been successfully
transferred unless it receives an affirmative response from the
server. Since, however, the affirmative response may have been sent
and lost, the client SHOULD use the same message-id in the article
when resending it or check whether the article was successfully
posted before resending it to ensure that the resend will not result
in a duplicate article.
in the section on POST and:
The client SHOULD NOT assume that the article has been successfully
transferred unless it receives an affirmative response from the
server. A lack of response (such as a dropped network connection or
a network timeout) SHOULD be treated the same as a 436 error
response.
in the section on IHAVE.
--
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the ietf-nntp
mailing list