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