ietf-nntp Multiple AUTHINFOs per session

Ken Murchison ken at oceana.com
Mon Jan 6 08:01:38 PST 2003


"Jeffrey M. Vinocur" wrote:
> 
> On Sun, 5 Jan 2003, Ade Lovett wrote:
> 
> > However, the fact that a new instantiation of the client is being suggested
> > when a client re-authenticates is a blatantly obvious way of killing a
> > server, unless serious amounts of state are saved on a reauth, which kinda
> > defeats the purpose of the whole thing.
> >
> > It's more a case of a solution sounds ok, but then turns out to be
> > inherently unscalable, causing everyone needless pain (the rift between
> > server and client developers is big enough as it is :()
> 
> Whoops, I think we're miscommunicating.
> 
> As I understood Ken, he was saying that we should disallow multiple
> AUTHINFOs because the *client* can start a new session (as you describe),
> not that the server should be handling it internally as a fork().

Yes.  I should have been clearer in my statement.


> Additionally, I certainly don't plan on *requiring* the server to support
> multiple AUTHINFO; it is always going to be permissible for a server to
> return 502 for anything it doesn't want to let the client do.
> 
> The question is whether the NNTP auth spec should *forbid* the client from
> doing multiple AUTHINFO.  I'm torn on this -- there's no tremendously
> useful reason to want it, but on the other hand if an implementation can
> provide it with no extra effort, there's nothing wrong with it.
> 
> How about a compromise?  This draft specifies an AUTHINFO capability to be
> returned by LIST EXTENSIONS.  How about I point out that a server which
> does not want clients to do multiple authentications steps can avoid
> listing that capability after authentication has been performed?

As long as the server isn't required to handle multiple AUTHINFOs, I
don't care one way or the other.

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