ietf-nntp Requirement for timeout close unclear

[Russ Allbery]

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

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

Yes, but I think you missed my point.

A client generally talks to only one server, or at most a small handful.
If it can't talk to a server, this is immediately obvious to the user of
the client.  It's not a problem that can go unnoticed.

A server generally talks to thousands of clients.  If it can't talk to
some few clients on slow links, the operator of the server may never
notice; it's just another set of timeouts (which are a common occurance).

Accordingly, it may be necessary to say something in the standard about
the latter, since it can be a hard-to-detect problem.  The former, on the
other hand, will cause immediate obvious breakage for the user of the
client.

It may be that this is not a good enough reason to say something.  I don't
know.  I have to admit that I really don't like seeing timeout limits put
into a standard, particularly ones that seem pretty arbitrary and don't
naturally rise out of protocol concerns (there's nothing special about
three minutes).  Clearly, servers and clients should both have
sufficiently long timeouts to not disconnect inappropriately, but does
this really need to be made part of the protocol?  Is this part of the
SMTP protocol, or the IMAP protocol?  (I honestly don't know if it is.)
They both have similar issues.

The right values for timeouts and the like is going to vary a lot
depending on the client software used, the usage patterns of the server,
and the network connectivity between the server and the client.  For
example, I set the client timeout to an hour on my servers because I have
a lot of users using older versions of trn, which get very confused if the
server drops the connection while the client is shelled out to an editor
while the user writes their followup.  An ISP may not be able to afford
that long of a timeout without leaving a bunch of dead connections behind
on the server.

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

Ah.  Hm.  That's one of those common-sense sorts of things that I'm never
sure how much detail to give to.

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

I thought about saying a line of data, but if lines can be arbitrary
length (which is the direction that we want to go), or if there's later
some extension that allows binary messages, the idea of a line pretty much
goes away.  Significant amount of data would work, but I'm not sure it's
worth being that precise.  On the other hand, it's only another three
words.

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

I'm not sure we have the tools required to solve that yet; I think the
best we can do is say something at the SHOULD level and let clients for
which this is a major hardship skip that requirement for right now.

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