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

[Clive D.W. Feather]

Russ Allbery said:
>> 3.2.1 para 2: in option (1), rather than dropping the connection
>> immediately it should use the 400 generic response code.
> No, because at the successful conclusion of the command, it's the client's
> turn, at least as we've currently laid out the specification.

Yes, but (a) see below and (b) the server can respond with a 400 to the
*next* command.

>> However, it appears from discussions back in March that this situation
>> can never happen because it's the server which decides what offer in the
>> first place. So all this text can be deleted.
> This also sounds correct to me, and deleting text is even better.

Which makes it moot.

>> Also back in March, I wrote:
>> | However, I'm a little bothered by the asymmetry between TLS failure,
>> | where the *server* moves next (issuing a response code), and success,
>> | where the *client* moves next (issuing a command). If this isn't cast
>> | in stone, then I would strongly suggest making it always the
>> | server. This has an additional benefit: you can specify that, after
>> | TLS negotiation ends successfully, both sides return to the NNTP
>> | initial connection state with the server issuing an initial
>> | greeting. I suspect this will make things easier for client design.

>> 3.2.2 first para: will it be clear from the TLS negotiation whether it
>> succeeded or failed?
> Yes.

Okay.

>> Note that this would be a good place for the 400 I mention above.
> I don't see how.  580 doesn't mean that the connection is closing, whereas
> 400 does, does it not?

That's the point. The server then has a choice, something like this:

    If the TLS handshake fails in such a way that it is possible to
    recover the underlying NNTP session, the server will send a
    response (without encryption), beginning with the first post-
    handshake octet. If the server is willing to continue the connection
    the response code 580 MUST be used; if not, the response code 400
    MUST be used and the server MUST then close the connection.

So we get four cases:
* succeeded: no response, client's turn
* failed, session recovered, server will continue     -> 580 response
* failed, session recovered, server will not continue -> 400 response
* failed, session can't be recovered, close connection (?)

> The other minor wording changes look good to me.  Does everyone think that
> with the above issues resolved, we're ready to go to last call on this
> document?

Yes.

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |