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