ietf-nntp Requirement for timeout close unclear

[Clive D.W. Feather]

Russ Allbery said:
>> The present wording says that the server
>> - may timeout waiting for the client
>> - must not timeout in less than N seconds
>> Both might be reasonable limitations to put on a client.
> 
> I don't understand why either would be meaningful for a client.

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.

> If the
> client times out, it closes the connection, an event that the server
> already has to be able to deal with at any point.

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.

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

>> Possibly. On the other hand, finding a "404 you took too long" in the
>> incoming stream might help in debugging problems.
> Not worth the complexity of out-of-order responses, though, I think.

It might be worth revisiting when we sort out pipelining. On the other
hand, if nobody wants such a response then we can just drop it. Anyone else
interested ?

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

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

I don't like this.

> Does this sound okay to everyone?

No.

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

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