ietf-nntp Requirement for timeout close unclear

[Clive D.W. Feather]

Russ Allbery said:
>> 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.

You're making the implicit assumption that clients are somehow less
important to get correct than servers. While I can see why, I'm not sure
that it's a valid assumption. After all:

| This is a self-correcting problem, since this causes inability for the
| server to talk to the client, whereas the other way around is not a
| self-correcting problem since the client may appear to be working fine with
| nearly all servers.

Does that make sense ?

>> 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.

I meant "other than after the timeout".

>>>  - 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.

> 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?

Yes.

Nitpick: the raw input code might not be a convenient place to do the
reset; rather, the logical place might be at the point that a line has been
read. Do we want to say "receipt of a significant amount of data", or
"receipt of at least one line", or something like that, or is this too much
detail to worry about ?

> No, an explicit statement of what a terminated connection should mean from
> the perspective of the client.

Fine by me, modulo the ongoing discussion about POST with no message-ID.

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:  +44 20 8371 1138
Internet Expert     | Home:  <clive at davros.org>  | Fax:  +44 20 8371 1037
Demon Internet      | WWW: http://www.davros.org | DFax: +44 20 8371 4037
Thus plc            |                            | Mobile: +44 7973 377646