[ietf-nntp] draft-ietf-nntpext-tls-nntp-01.txt

[Ken Murchison]

Russ Allbery wrote:

> Clive D W Feather <clive at demon.net> writes:
> 
>>Section 3.2: I would delete the second sentence of the first paragraph,
>>relying on the base specification, or at least the bit before the
>>semicolon. We don't talk about sockets, just connections, and because
>>the connection will switch to the TLS protocol, talking about sending
>>anything else is premature.
> 
> 
> I would delete the part before the semicolon but leave the rest of this,
> since I think it's useful to make no pipelining explicit.

I'm not entirely sure that referring to pipelining is sufficient since 
it doesn't address the completion of TLS.  I think replacing the entire 
second sentence with the following from RFC 2595 makes the most sense:

"Once a client issues a STARTTLS command, it MUST NOT issue further 
commands until a server response is seen and the TLS negotiation is 
complete."

>>Section 3.2.1: Rather than "... it SHOULD do at least one of (1) close
>>..."  I think you are better saying "... it SHOULD keep the connection
>>[text of (2)] or MAY close the connection [text of (1)]". That is, make
>>it clear that (2) is better.
> 
> 
> Why is it obvious to you that (2) is better?  That's not clear to me; I'm
> not sure which of those is better and would want some practical experience
> first to be able to figure that out.

I think I address this in another post.  This situation should never 
happen.  If the server should offer any options which it is not willing 
to accept from the client.  If negotiation succeeds, the server should 
be happy with the outcome.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp