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

Clive D.W. Feather clive at demon.net
Wed Jan 7 09:42:40 PST 2004


Jeffrey M. Vinocur said:
> I don't know why we didn't get a publication announcement, but I've 
> released a new version of the TLS draft; comments please.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-nntpext-tls-nntp-01.txt

Section 2: it's not clear from this document why STARTTLS is forbidden
after a successful authentication has been organised.

Various places: the list returned by LIST EXTENSIONS should not have
leading spaces.

Section 3.1: I would omit 403 and 501 from the list, since they're generic.
That's just a style issue, though.

Section 3.1: The responses should be split into two lists, as with POST in
the base NNTP specification. 580 goes in the second list; the rest go in
the first. That's because (as I understand it) you don't get a 580 until
after a 382.

Section 3.1: The sentence beginning "Clients MUST ..." should be removed,
since the base specification states which responses must be expected.

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.

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.

Section 3.2.2: "... recovery *of the underlying NNTP connection* is
possible ..." or something like that; make it clear you don't mean recovery
of the TLS session.

Section 3.2.2: The second paragraph is in error - it is *not* the state
after the initial connection, but rather the state after the initial
greeting has been sent. Therefore this paragraph becomes:

    Upon successful completion of the TLS handshake, the NNTP protocol
    is reset to the state immediately after the initial greeting
    response line (see 5.1 of [NNTP]) has been sent; no such greeting
    is sent and the next step is for the client to send a command.
    The server MUST discard any knowledge obtained from the client,
    such as the current newsgroup and article number, that was not
    obtained from the TLS negotiation itself. The client MUST discard
    any knowledge obtained from the server, such as the list of NNTP
    service extensions, which was not obtained from the TLS negotiation
    itself.

Section 3.3: Please add an example that involves the 580 response
followed by another command.

Section 4: Delete the reference to the ABNF core rules, since I don't use
them in [NNTP].

Appendix: I suggest you add a formal specification similar to those in
Appendix D of [NNTP].

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



More information about the ietf-nntp mailing list