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

Clive D.W. Feather clive at demon.net
Fri Sep 17 06:17:30 PDT 2004


> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-nntpext-tls-nntp-02.txt

1.1: suggest you replace the last para with the text that's in NNTPAUTH:

     The notational conventions used in this document are the same as
     those in [NNTP] and any term not defined in this document has the
     same meaning as in that one.

2 para 3: s/MUST NOT be used/MUST NOT be relied on/  (the stuff in 11.6
only forbids caching security information).

2 last para: we don't have the concept of a mode change in NNTP. This
paragraph merely repeats the meaning of "This command MUST NOT be
pipelined" in 3.1 and therefore isn't needed.

3.2.1 para 2: in option (1), rather than dropping the connection
immediately it should use the 400 generic response code.

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.

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.

I'm not sure that I ever got an answer.

3.2.1 last para, second bullet: s/client, however/client. However/

3.2.2 first para: will it be clear from the TLS negotiation whether it
succeeded or failed? Note that this would be a good place for the 400 I
mention above.

Is there any benefit in having a response

6 para 7: do you mean "deleting the 382 response" or do you mean "replacing
the 382 response with a 502 response"? If you just delete the response, the
client will sleep forever.

6 para 8: s/retry TLS at a later time/retry TLS later in the session/

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



More information about the ietf-nntp mailing list