ietf-nntp draft-ietf-nntpext-tls-nntp-00

[Ken Murchison]

First a few nits:

section 2:  Example lists PAT as an extension, but I don't believe this
is/will be the case.  You should either remove it or replace it with
HDR.  Also, in the last sentence "mode changes" should probably be "mode
change".


Now to the questions/problems:

-section 4:  You should state that TLS negotiation begins immediately
after the CRLF at the end of the 382 response from the server.  You also
might want to mention that if the client is pipelining commands (per the
description in base-17), that the STARTTLS command MUST be the last
command in a group.


- section 4.1:  If it matters, the use of 483 and 580 in the draft is
inconsistent with INN's implementation.  INN uses 483 to signal that TLS
is already active, and 580 to signal an error in the TLS negotiation.  I
think there should be 4 TLS specific return codes:

382 start TLS negotiation
48x encryption required		(response to AUTHINFO when plaintext not
allowed)
x8x TLS already active		(response to subsequent STARTTLS attempts)
58x TLS negotiation error

Which exact codes are used for the last 3 are up for debate.


- section 4.3:  Why reissue the welcome banner?  What is its purpose? 
None of the other messaging protocols do this.  

- section 4.3:  Instead of flushing the authentication info, why not
just say that the STARTTLS command is only valid in the
non-authenticated state (didn't we already decide that we shouldn't
allow multiple authentications)?  RFC 2595 does this.


- section 5:  I'm not sure that documentating an extension that will be
obsoleted by a TLS extension (IMO this functionality _belongs_ in TLS
and not the application layer), and which can be accomplished by an
existing command (AUTHINFO USER), make much sense.  It seems that this
will be a little used interim extension at best, and uncessary clutter
at worst.  But I'll defer to WG consensus on this.

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