ietf-nntp Requirement for timeout close unclear

[Russ Allbery]

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

> Because if the client times out too quickly waiting for the server
> response it will affect efficiency. Is it sensible for a client to allow
> the server under a second to reply ? I think not.

This is a self-correcting problem, since this causes inability for the
client to talk to the server, whereas the other way around is not a
self-correcting problem since the server may appear to be working fine to
nearly all clients.  As such, it doesn't seem nearly as important to me to
worry about this direction of things.

> And vice versa; nonetheless we put limitations on when the server should
> do that. And we don't actually say that the server can drop the
> connection.

Yes, we do.

    When the timer expires, the server should close the TCP connection
    without sending any response to the client.

>> The difference between the server and the client is that the client is
>> initiating the protocol conversation and is the party permitted to
>> terminate it at any time already,

> We don't say that. Um, we sort of say it under QUIT, but not very
> clearly.

We really shouldn't have to; it's pretty much obvious, particularly given
the description of the greeting phase and the fact that there's a QUIT
command.

>>  - The minimum duration is a SHOULD rather than a MUST; I think this is
>>    more correct per RFC 2119 and in general makes more sense.  There's
>>    nothing particularly special about three minutes to warrant a MUST.

> On the contrary, it's an interoperability issue. If it's a MUST then the
> client author can rely on having 3 minutes before the timeout
> happens. With this SHOULD they can't.

Both SHOULD and MUST deal with interoperability problems.  SHOULD deals
with problems that don't necessarily cause things to break when ignored
and which aren't always appropriate for every implementation.  I believe
that the lower limit of three minutes is exactly such a case.

>>  - POST and IHAVE are mentioned explicitly and handled the same as any
>>    other timeout, which keeps things simple and should already do the
>>    correct thing with existing implementations.

> This means that a client MUST NOT take more than 3 minutes to send a
> message with POST or IHAVE, since the timer could expire in the middle
> even though the message is arriving. This puts an absolute limit of 600k
> on an article posted via a modem, even if everything goes perfectly and
> the poster gets the full 33k6 on the connection.

Good point.  I propose this text instead:

    An NNTP server MAY have an inactivity autologout timer.  Such a timer
    SHOULD be of at least three minutes duration, with the exception that
    there MAY be a shorter limit on how long the server is willing to wait
    for the first command from the client.  The receipt of any command
    from the client during the timer interval SHOULD suffice to reset the
    autologout timer.  Similarly, the receipt of any data from the client
    while in the midst of sending a multiline message to the server (such
    as during a POST or IHAVE command) SHOULD suffice to reset the
    autologout timer.  When the timer expires, the server SHOULD close the
    TCP connection without sending any response to the client, including
    when the client is in the middle of sending a multiline message to
    the server.

Does that sound better?

>> I believe we should also include my previous recommendations for new
>> wording for the POST and IHAVE command descriptions.

> I've forgotten what that was. If it was the handling of response codes,
> then I've already suggested what I think is a better way.

No, an explicit statement of what a terminated connection should mean from
the perspective of the client.  Here's that proposed text again.  For the
section on POST:

    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.

and for the section on IHAVE:

    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.

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