[ietf-nntp] draft-ietf-nntpext-tls-nntp-01.txt
Ken Murchison
ken at oceana.com
Tue Mar 9 12:19:34 PST 2004
Russ Allbery wrote:
> Ken Murchison <ken at oceana.com> writes:
>
>
>>The server has complete control over the negotiation. Its provides a
>>list of options from which the client can choose. The server should
>>only provide those options that it is willing to accept, and shouldn't
>>have to decide *after* the negotiation is complete whether or not it is
>>happy with the outcome. As a result, I think the case where TLS
>>negotiation is successful but the server then refuses other commands
>>with 483 (or some other code) is, and should be, nonexistent. Either
>>TLS succeeds, or it fails, period. Obviously, if TLS fails, then
>>issuing 483 for subsequent commands makes sense, but the client should
>>already expect this.
>
>
> This makes our lives massively easier. Thank you for the information!
> Given this, I agree that we're worrying too much about this case; the only
> case that we actually have to talk about is the case where TLS negotiation
> fails entirely.
Keep in mind that what I said above is based on my (non exhaustive)
knowledge of TLS and its use in IMAP and POP3. I'd like to get
independent confirmation that the issues brought up in RFC 3207 (and
Jeff's text) are either overkill or don't apply to NNTP.
That being said, I would definitely design a server so that it only
advertises options which it is willing to accept.
--
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
More information about the ietf-nntp
mailing list