[NNTP] draft-ietf-nntpext-tls-nntp-02.txt

[Jeffrey M. Vinocur]

On Sep 29, 2004, at 2:59 PM, Russ Allbery wrote:

> Ken Murchison <ken at oceana.com> writes:
>
>> Note that the option of closing the connection is something that is 
>> not
>> present in RFC 3207 (on which most of this text is based).  It was 
>> added
>> by Jeff because he felt that servers may not want to have client 
>> beating
>> on them after a failed TLS.  I never really liked this text and would
>> prefer to just stick with the original RFC 3207 text (just issue 483
>> responses to subsequent commands).  Doesn't the base doc already allow
>> servers to unilaterally terminate the connection and addresses how to 
>> do
>> this?  If so, do we need to address this in the STARTTLS doc?
>
> I'm pretty sure unilateral termination is already allowed, and in any
> event it can happen whether allowed or not so clients have to cope with
> it.  I don't have a problem with sticking to the original text here.
> Jeff, do you still think this is needed?

[ I'm scrambling to keep up with all this traffic. Trying to follow. ]

IIRC, this was because any case where the server can unilaterally close 
the connection makes me worried about a naive client inadvertently 
DOS'ing the server.

I mean, if the client author isn't prepared for a unilateral 
termination to be purposeful (rather than a network glitch dropping the 
connection), the client software might immediately reconnect and repeat 
the same sequence of commands, causing the server to unilaterally 
terminate again, and so on, indefinitely.

This concern seems very real to me, but I could certainly be convinced 
if people disagree.

And if it's real concern, I'm not necessarily sure this is the best 
text to handle it either.

Regardless, I do feel like we're misleading to client authors if the 
spec says only "the server will reject all further commands" when in 
practice servers are quite likely to close the connection, even if 
somewhere in a different document we warn them that the server can 
close the connection at any time.


-- 
Jeffrey M. Vinocur
jeff at litech.org