ietf-nntp Response code issues

[Russ Allbery]

Clive D W Feather <clive at demon.net> writes:
> 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.

Here's the relevant text from the current draft:

   A server MAY provide extensions to this specification, including new
   commands, new variants or features of existing commands, and other ways
   of changing the internal state of the server.  However, the server MUST
   NOT produce any other responses to a client that does not invoke any of
   the additional features.  (Therefore a client that restricts itself to
   this specification will only receive the responses that are listed.)

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

Yes.

> 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.

Yes, the section 10 wording is fine and allows for that, but the above
paragraph, at least as I read it, does not.  It explicitly says that the
server MUST NOT produce any other responses than the one in this
specification to standard commands, and implementing authentication the
way that it's currently being used involves returning 480 to all sorts of
standard commands.

Maybe the above paragraph was intended to speak specifically to *local*
extensions, as opposed to standardized ones?  If so, that distinction
wasn't clear to me.

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

But it seems to already be ruled out by that paragraph.

> 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.

Existing practice for response codes is that if the client tries to do
something that *would* be capable of doing after it authenticates, a 480
response is returned.  Generally this is to a POST, GROUP, or ARTICLE
command.

If the client tries to do something that it will not be allowed to do no
matter what AUTHINFO commands it sends, like trying to send IHAVE to nnrpd
when the IHAVE-as-POST extension isn't allowed, it gets a 502 response.
This fits the idea of 5xx as a permanent failure and 4xx as a temporary
failure.

> 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.

Yeah, that sounds correct to me.

Whether or not A is a temporary error is somewhat debatable.  For example,
suppose someone sends LIST ACTIVE.TIMES, and the server doesn't maintain
the active.times database.  This is, for INN, the case of a missing file;
if the news administrator touches the file, suddenly LIST ACTIVE.TIMES
starts working.  But in effect that's a configuration change on the
server, and until that configuration change is made, the command is going
to continue to fail.

That's the logic behind why INN uses 503 for this case, I think, and it
always made sense to me.  Of course, internally INN calls this a temporary
error, which is just wrong, but INN's internal names for NNTP status codes
often don't make any real sense other than historical.

So even if 403 were already available, it's not clear to me that it would
be correct for INN to use it in this sort of situation.  I suppose I can
think of situations where it would be useful, though, mostly situations
related to load or to a temporary throttle of the server (and therefore
mostly affecting POST).

> 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)

Agreed, this makes sense to me.  Okay, I see why 403 is in there, and I
think I agree with our previous decision to put it in there.

Unless anyone thinks that adding 403 would confuse or break clients, I
think we should go ahead and keep it, then.

>>   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.

I have a really hard time seeing how LIST EXTENSIONS could ever fail for
any reason outside of a serious internal server error, so for me it would
be more of a (B) thing, but with the above summary that's a distinction
without a difference.  So 403 makes sense to me for LIST EXTENSIONS.  503
really doesn't, to me.  But either way, they're generic codes that can be
returned from any command, so we don't have to worry about that.  I would
remove 503 from the explicit list of return codes of LIST EXTENSIONS,
though.

> 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 have no strong feelings about this one way or the other.  If anyone has
an intuition on the likelihood that this would be needed for backwards
compatibility, please do speak up.  (I'm not as worried as I would be
otherwise about introducing a new response code because NNTP has always
had the provision that clients should figure out unrecognized codes from
the first digit *and* we're adding a new code for an error case, and
treating new 4xx and 5xx codes as errors is pretty reliabily implemented
in all the clients I'm familiar with.)

>> 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".

If we were designing the protocol from scratch, maybe, but that's
definitely not what anything currently does.  See the above summary on the
difference between 502 and 480.  I don't know of any server that returns
502 to a GROUP command to signal the client should authenticate; 480 is
used universally for that purpose so far as I know.

I agree that this isn't what RFC 977 says; this is a case where existing
practice doesn't match the standard.

>>   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.

Good point.  Change that to issuing MODE READER and then trying to use
IHAVE.

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