ietf-nntp Response code issues

[Clive D.W. Feather]

Russ Allbery said:
> 3.1. Response Codes
>   While the part about the server not producing any other responses to a
>   client other than the ones documented in the protocol if the client
>   doesn't use extensions is a very good one, and one we should keep, 480
>   responses need to be an exception to this for historical reasons.
[...]
>   Maybe we can except x8x codes from this rule, but still require that the
>   language down in the discussion of extensions apply (namely that the
>   only documents allowed to change the return status of existing commands
>   are standards-track ones)?

I'm not sure I follow the issue here.

Case (1): server doesn't do authentication. There are no 480 responses.

Case (2): server uses a standard extension to do authentication. This
extension defines the 480 response and when existing commands can return
it. All covered by section 10.

Case (3): server uses a private extension to do authentication. Any use of
480 (or x9x) would be ruled out by your last bit.

I presume case 3 is the one that you're thinking of, so what are you
suggesting? That a server can still return 480 to indicate "authentication
required"? This sounds rather like 502 territory to me.

> 3.1.1. Generic Response Codes
>   INN doesn't use 403 at all.  I have no opinion on whether we should keep
>   it or not.  I don't know of any servers that use it and Andrew's summary
>   of response codes also doesn't mention it, so I'm inclined to drop it
>   and go with the proposed alternate text.

403 seems to have been an invention when we were tidying up during late
2000. The idea was to distinguish temporary failures from permanent ones.

If we go back to RFC 977, it uses 502 for "not permitted" and 503 for
"program fault - command not performed". In our own specification we say:

    4xx - Command was correct, but couldn't be performed for some reason.
    5xx - Command unimplemented, or incorrect, or a serious program error
          occurred.

There are the following generic situations I can think of:
(A) Something external to the server broke (e.g. unable to open a file that
is necessary). This could well be repaired by the next time this command is
tried.
(B) Something internal to the server broke (that is, it went down a code
path where it can't do anything useful because the internal state is
confused). Something similar might work but doing exactly the same thing
might well produce the same problem, at least until the code is fixed.
(C) The information required is available, but you don't have the authority
to access it.
(D) The server understands what you want (unlike 500/501), but the
information required is not available because the server doesn't
implement that option (e.g. HDR with a header not in the overview).

977 seems to be thinking of 502 for C and 503 for the rest.

If I was designing from scratch, I would argue that A should be a 4xx code
and the rest should be 5xx based on our definition. I would use 403, 504,
502, and 503 in that order. I could accept an argument that says there's no
point in distinguishing (A) from (B). That would leave us with what's in
the document right now:
    403 = (A) or (B)
    502 = (C)
    503 = (D)

>   503 should be used for "the requested information is not present or
>   available," I think.  I don't really understand how LIST EXTENSIONS
>   could provoke such a situation, so I have no problem with removing that
>   response from LIST EXTENSIONS.

I think that this was for the case where something external is invoked but
doesn't work. However, I see that as an (A) case.

>   That would make the HDR and LIST uses
>   consistant, and I think that's enough to make it generic (two completely
>   different classes of commands, plus we want future extensions to use it
>   as well).  If we eliminate 403 and remove 503 from LIST EXTENSIONS, that
>   should clear up the confusion.

I think there's benefit in keeping the 403 response as meaning (A) and (B)
with 503 meaning (D). However, to conform with existing practice, I 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.

>   I don't understand 401 at all.  INN doesn't use this, and it's not in
>   RFC 977.  Does anyone know of any server that uses this?  Otherwise, I
>   propose dropping it for the reasons that you state; it's confusing what
>   it actually means and doesn't seem useful.

I hate to say this, but it looks like *I* accidentally invented it! It
first appears in draft 13, in text that I wrote. I agree that, unless
someone sees a need for it, it can go.

[*If* we do want to keep it, then I suggest the definition is:
 - the command does absolutely nothing if it returns 401
 - if the same command it tried again, it will work
 - apart from that, the server can return 401 more than once
and I'll write words.]

> 3.1.1.1. Examples
> 
>   I'm a little worried about the example used for a restricted facility,
>   since it could give people the idea that 502 should prompt
>   authentication, when 502 is generally means either a permanent failure
>   or that the client needs to issue MODE READER.  A 480 response would be
>   returned if authentication would help.

Um, no. 502 (apart from at initial connection or MODE READER) means "you
are not authorised to use this" - this goes back to RFC 977. This is
precisely the time when you should authorise, and I don't know where this
idea of using 480 comes from. Logically 480 means something like "valid
authentication command issued, but you couldn't be authenticated".

>   This isn't a major issue;
>   there's nothing actually *wrong* with the example.  It just might be
>   misleading.  A better example might be trying to use POST, getting 502,
>   and then issuing MODE READER, since that's the sort of situation that
>   actually happens with real servers.

It shouldn't: if POST is forbidden in the current state, you should get
a 440.

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