ietf-nntp Response code issues

Russ Allbery rra at stanford.edu
Fri Apr 4 12:04:47 PST 2003


Clive D W Feather <clive at demon.net> writes:
> Russ Allbery said:

>>>>>     could live with wording like: For backwards compatibility a server
>>>>>     MAY return 503 instead of 403 and a client SHOULD be prepared for
>>>>>     this. This waiver may be removed in a future revision of this
>>>>>     specification.

>> Unless someone speaks up and offers another opinion here, I think we
>> should just let the generic failure text cover this.

> Um, this is part of the generic failure text. If it goes in, it goes in
> just after the bit I've quoted at the top of this message.

Oh, sorry, I lost track of what we were talking about.  I thought we were
talking about the LIST EXTENSIONS stuff.  I have no strong opinions on
that; I don't think it's particularly necessary, but don't object to it.

> On the other hand, I've just re-read something that's thrown a *further*
> case at me - what if an implementation forbids AUTHINFO until after MODE
> READER?

I'd say it returns 502.

> The correct response, according to our current wording, is 480 - command
> forbidden for the moment.

I think 502 should be used for things that require a mode change.  The
alternative is 500, which older versions of INN use.

> We could document a separate range for "you're not in the right state", say
> 47x. Then:
> * need MODE READER -> 471
> * need authorisation -> 472
> * need encryption -> 473
> and 480 and 483 can be used as failure codes for authentication and
> encryption commands.

This breaks everyone's existing software.  I think that's a non-starter.

> Other possibilities:
> * Merge AUTH and TLS into the base specification, so that they are special
> cases that are allowed generic responses.

> * Provide some mechanism for a server to say "I return the following
> codes for 'you're in the wrong state and need to invoke this
> extension'".

> I think this needs further thought.

I think we're thinking too hard.  :)

480 really is, in practice, a generic response code.  So I think we should
document it as such, since an NNTP client author needs to know about it
even though authentication is in a separate draft.  So as far as that
goes, I agree with what you said a few messages back.

The only real question in my mind is how to handle STARTTLS and the
possibility that a group may not be readable without TLS.  I think the
choices are to use 502, 480, or 483 for that response code.  502 may not
produce the right client behavior, and 502 and 480 both require a bit of
guessing on the part of the client (480 somewhat less so).  483 is
explicit but means we have to add it as another generic response code or
use some sort of language about 48x codes (but excluding 481 and 482).

Personally, I'm leaning towards just documenting 480 as a generic response
code for insufficient authentication or transport security, with a second
choice of documenting 480 and 483 as generic response codes, and
everything else seems less good.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>



More information about the ietf-nntp mailing list