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

[Ken Murchison]

"Jeffrey M. Vinocur" wrote:
> 
> On Mon, 3 Mar 2003, Ken Murchison wrote:
> 
> > "Jeffrey M. Vinocur" wrote:
> >
> > > Is it acceptable to formalize 483 here, even though -- once the SASL stuff
> > > is in place -- both STARTTLS and AUTHINFO SASL will be acceptable actions
> > > for the client to take after receiving 483?
> >
> > Hmm, good point.  I would argue that this is an AUTHINFO specific
> > response code and belongs in the AUTHINFO draft.
> 
> But it's not, really.  A server can implement STARTTLS using 483 and not
> support any form of AUTHINFO at all.  Fun, eh?

I don't follow.  What command other than AUTHINFO would realistically
require the presence of TLS?


> And I don't want to have this draft blocked on the other.

It wouldn't.  AUTHINFO would block on TLS.  It's going to block anyways
because IESG won't allow unprotected plaintext mechs.

> > I do think we should have a "TLS failed" response code.
> 
> Do both the client and server know on which octet normal data resumes
> after a failed negotiation?

They should, since TLS is a handshaking protocol.  None of the other
application protocols have a problem.  
I guess we could just use 403 or 503 for a failed TLS.


> Ok, I'm going to change it to indicate that the server MUST NOT issue a
> banner.  (I hope nobody implements it with the banner in the mean time,
> might confuse clients.)

Are there any implementations other than INN and Cyrus?  ;)


> It's sort of a shame that we don't have a chance to send 200 or 201 again,
> but we don't get to after authentication either so I guess the milk is
> already on the floor.

Can't the client just do MODE READER?

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