ietf-nntp Requirement for timeout close unclear

[Clive D.W. Feather]

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

> 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 client does, but a piece of client software doesn't. And, after all,
we're writing something for the software authors.

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

Who might not be able to fix it.

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

It's an interoperability issue.

> Is this part of the
> SMTP protocol, or the IMAP protocol?  (I honestly don't know if it is.)
> They both have similar issues.

Weren't these timeouts put in RFC 1123, rather than the original protocol
RFCs ?

>>>> And we don't actually say that the server can drop the
>>>> connection.
>> 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.

Indeed.

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

"significant" would be enough for me. Anyone else got a comment ?

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

I don't have an opinion.

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