ietf-nntp Re: Last major open issue (48x return codes)
Russ Allbery
rra at stanford.edu
Thu Oct 2 21:57:33 PDT 2003
Clive D W Feather <clive at demon.net> writes:
> Jeffrey M. Vinocur said:
>>> 401: the client must change the state of the connection in some other
>>> manner. The first argument of the response SHOULD be the
>>> extension-label (see Section 8) of the extension that provides the
>>> necessary mechanism.
>> I can see that SHOULD being really nasty for clients to parse. Can we
>> make it a MUST?
> I'd be happy, but I wasn't sure how it would play here.
It's a brand new return code so we can require anything we want. I think
MUST is correct.
>> Probably then we'd need to do at least one of these:
>> - provide a special first parameter that means "no specific extension
>> is related, please display this string to the user"
> "-" seems the obvious choice (you can't have dash in extension-labels).
Why would you return 401 in this situation rather than just returning 502?
I don't think we should overload a response code for that. If we really
need a separate code for an error not due to a particular extension, let's
use 402 (I don't think we really do).
> What I actually meant was, is there such a thing as a *generic*
> "authorization extension" that justifies its own 48x *generic* response
> and which justifies the use of the word in the description of x8x
> responses?
Yeah, I can't think of any. Authorization is not something the client
does; it's something the server does. All that a client can do is
establish its identity, and then authorization decisions are made by the
server.
I suppose that something like sending a client certificate that shows
delegated authority would be something of a grey area, but I still
consider that to be more authentication and decisions the server makes
based on that information to be the real authorization event.
I can't see how commands for authorization independent of authentication
would be meaningful.
--
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the ietf-nntp
mailing list