ietf-nntp Multiple AUTHINFOs per session

[Jeffrey M. Vinocur]

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().

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?


> All IMO, of course, having written a couple of "industrial-strength"
> servers, and now managing a REAL one :)

So, you didn't answer my original survery -- what does your server do if 
a client that has already authenticated sends AUTHINFO again?


-- 
Jeffrey M. Vinocur
jeff at litech.org