ietf-nntp TLS and AUTHINFO interaction

[Ken Murchison]

Russ Allbery wrote:
> 
> Jeffrey M Vinocur <jeff at litech.org> writes:
> 
> > I was planning on lumping the already-authenticated state in with the
> > already-established-TLS state; in both cases STARTTLS would not appear
> > in list extensions, the client would be expected to know not to try it,
> > and any attempt to try it would be met with 500.  The two cases seem
> > very similar to me.
> 
> Hm... is it kosher to have LIST EXTENSIONS change after authentication?

I don't see why not.  You might have a site policy where HDR isn't
offered to anonymous users because its an expensive command or
something.

But in this case the client shouldn't have to do a LIST EXTENSIONS.  If
the TLS text specifically states that STARTTLS is only available in the
non-authenticated state, the client should know what the deal is ahead
of time.

IMO, I don't think we need too much verbage for this in the draft.  The
text that I quoted in RFC 2595 has been around for a while and no IMAP,
POP3 or ACAP clients seem to have any problems.  In fact, if it were me,
I would have used RFC 2595 as a template and just plugged in the
relevent NNTP stuff.  Since we're most likely talking about
client-server connections rather than peer-peer connections, I think RFC
2595 is more appropriate as a starting point than RFC 3207.

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