ietf-nntp Re: Last major open issue (48x return codes)

[Clive D.W. Feather]

The comment in the current draft doesn't really cover the full situation,
so here's my attempt to write it all up, based in part on various emails
that went round earlier in the year.

The conceptual error "not authorized to use this facility" has three basic
meanings (these are not Russ's three):

(1) This connection will never be permitted to use this facility; it will
be necessary to start a new one. There's general agreement that this is a
502 response.

(2) This connection has blocked itself from using this facility. For
example, it used MODE READER earlier and is now trying an IHAVE. Since
there's no way back, 502 seems reasonable (Russ supported 502 back in
June; INN apparently uses 500 for this).

(3) This connection can't use this facility until it's changed mode. Among
the commands that can change mode are:
* MODE READER
* MODE STREAM
* AUTH
* STARTTLS
but there may well be others in the future. In some cases two separate
mode changes might be needed (e.g. MODE READER then AUTH).

As I understand it, the existing situations are:
* MODE READER  - nobody uses 502, people use 500 but that's clearly wrong
* MODE STREAM  - no idea
* AUTH         - 480 usually used
* STARTTLS     - 483 documented, but no implementations yet?
Is that right?

I suggested that case 3 was shown by a separate 47x range, with each x
indicating a specific problem, but nobody was keen on that. Russ wrote,
back in April:
> 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

I also suggested that perhaps we need a way for a server to say "these
response codes mean you need to change state".

Russ:
> Introducing a new status code, the most unambiguous option, seems like
> overkill for a "feature" that we're recommending against anyway.

If it were only MODE READER, I'd agree. But Charles put another point
(which I agree with) very well:
> Essentially it is
> saying "I can't let you do that unless you jump through some hoops first"
> (hopefully the accompanying text and/or the value of 'x' will tell you
> which hoop).
> Clearly, the obvious hoops are authentication and privacy, but could there
> be others we have not thought of yet, and should the wording be broad
> enought to cover them in the future?

While a new code would be overkill for MODE READER alone, it is *not*
overkill in general. As a general principle we should have a 5xx code
for "permanently unavailable" and a 4xx code for "you need to jump through
a hoop". This isn't just authentication and authorization, so 48x doesn't
really feel right for such a code. Instead, I suggest that the 40x range is
right, so the generic response should be 401.

However, instead of just stopping there, we should require 401 to *have an
argument* to indicate what the hoop is. This argument would be the name of
the command or extension used to request the facility. For example:

    [C] GROUP misc.test
    [S] 401 MODE READER

    [C] GROUP local.database
    [S] 401 AUTH

    [C] GROUP local.secrets
    [S] 401 STARTTLS (You need at least 3DES encryption)

(The bit in parentheses is a comment and not part of the required response.)

As a transitional/depreciated mode, we could allow 480 for authentication
and, if there are significant implementations, 483 for privacy.

Thoughts on this? I think it's the cleanest suggestion yet.

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646