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

[Clive D.W. Feather]

Jeffrey M. Vinocur said:
>>> Section 3.1: I would omit 403 and 501 from the list, since they're
>>> generic.  That's just a style issue, though.
> *nod*  I do tend to reiterate that sort of thing needlessly.  In this 
> case, though, where it seems realistic that they might actually be used, 
> I think I want to explicitly remind client authors of the possibility.

My practice has been to include them in the running text if there's a
significant point to be made.

501 presumably only happens if the extension isn't supported.

If 403 is likely, you should have some text explaining that the presence of
the extension doesn't guarantee that TLS is available, and therefore a 403
might be returned.

> I kept that on purpose, because I thought the sentence forbidding 483 
> was a bit of a non sequitor otherwise.  For reference:
> 
>      Clients MUST support other response codes by processing them based
>      on the first digit.  However, the server MUST NOT return 483 in
>      response to STARTTLS.  (See section 3.2.1 of [NNTP].)
> 
> Russ, if you still agree on removing it, just say so.

I think all you need is "Notwithstanding section 3.2.1 of [NNTP], the
server MUST NOT return 483 in response to STARTTLS.".

>      Example of a failed attempt to negotiate TLS, with recovery of the
>      underlying NNTP session:
> 
>         [C] GROUP local.confidential
>         [S] 483 Encryption or stronger authentication required
>         [C] STARTTLS
>         [S] 382 Continue with TLS negotiation
>         [TLS negotiation is attempted here]
>         [Following failed negotiation, traffic resumes without TLS]
>         [S] 580 TLS negotiation failed
>         [C] GROUP local.public
>         [S] 211 1234 3000234 3002322 local.public

Looks okay to me.

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

> Feedback welcomed:
> 
>      o  The STARTTLS extension provides connection-based encryption via
>         Transport Layer Security (TLS).
> 
>      o  The extension-label is "STARTTLS".
> 
>      o  The extension-label has no arguments.
> 
>      o  The extension defines one new command, STARTTLS, whose
>         behaviour, arguments, and responses are defined in Section 3.
> 
>      o  The extension does not associate any new responses with pre-
>         existing NNTP commands.
> 
>      o  The extension does affect the overall behaviour of both server
>         and client, in that after successful use of the new command, all
>         communication is transmitted with the TLS layer as an
>         intermediary.
> 
>      o  The extension does not affect the maximum length of commands and
>         initial response lines.
> 
>      o  The extension does not alter pipelining, but the STARTTLS
>         command cannot be pipelined.
> 
>      o  Use of this extension does alter the output from LIST
>         EXTENSIONS; once the new command has been used successfully,
>         this extension can no longer be advertised by LIST EXTENSIONS.
> 
>      o  The extension does not cause any pre-existing command to produce
>         a 401, 480, or 483 response.
> 
>      o  The LISTGROUP command can be used before or after the MODE
>         READER command, with the same semantics.

I think that last one is wrong.

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