ietf-nntp Requirement for timeout close unclear

[Russ Allbery]

Clive D W Feather <clive at demon.net> writes:

> There's a number of issues to be addressed concerning timeouts. As you
> point out in another message, there's timeouts after an intermediate
> response. Andrew Gierth also asked, a long while ago, for a different
> timeout for the first command from a client.

Yes, INN also implements that.  It's on my list of open standards
conformance issues in INN, which I'll be sending to the list when I finish
(I'm 70% done with the draft and have identified 21 issues so far, most of
which are very minor and some of which it would have been faster to just
fix than to document, but I figured the documentation might be useful).

> And should the client have timeout restrictions as well ?

I don't really see the point of putting timeout restrictions in the
standard in the first place, since I think it's a matter of site
configuration, so I'm not the one to ask.  It doesn't bother me enough to
reopen the previous discussion, though.

> We actually say that servers should give a 400 response to any command
> if they need to terminate the connection, or a 401 to give advance
> warning.

This provision isn't at all useful to me.  It requires that the server
wait for the client to send another command before telling it that the
server is being shut down, which is entirely the wrong timing model for
INN.  I don't object to the provision being there since some other type of
server may find it useful, but it doesn't solve the problem for INN.

> I wouldn't object to us saying that the server MAY send a 400 (or 404,
> perhaps, since that code is unused ?) to mean a timeout-drop, provided
> that we also note that the client might not see it.

I think that Andrew's right and that the best thing to do is to simply
drop the connection without sending anything at all.

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?  If so, how do we fix that?

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