ietf-nntp Response code issues

[Clive D.W. Feather]

Russ Allbery said:
>> 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.)

Ah, I forgot that.

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

I see.

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

Nor to me. And I can't see how to read the parenthesised sentence other
than the way you are. So I now agree - this case is forbidden.

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

Not that that's the definition of 4xx and 5xx in NNTP. But, anyway, let's
return to this lower down ...

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

Right, the boundary is fuzzy here.

If the file active.times is unavailable because the server isn't
maintaining it, 503 is probably right (that is, it's case (D)). If it is
unavailable because some idiot went "chmod 000 active.times", then 403 is
probably right (it's case (A)).

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

That's an obvious case for 403.

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

Okay, based on your comments and the otherwise silence so far, I have
substituted the following wording:

   If the server experiences an internal fault or problem that means
   it is unable to carry out the command (for example, a necessary
   file is missing or a necessary service could not be contacted),
   the response code 403 MUST be returned.  If the server recognises
   the command but does not provide an optional feature (for example
   because it does not store the required information), or only handles
   a subset of legitimate cases (see the <xref target="hdr">HDR
   command</xref> for an example), the response code 503 MUST be
   returned.  Note that where a command is optional (e.g. LIST
   ACTIVE.TIMES) and is not provided by a server, this MAY be treated
   as an unimplemented command (response code 500 or 501) or as a
   working command where the information is not available (response
   code 503).

I think that largely closes the issues in those two "outstanding issues"
bits.

Note the last sentence of the first of those paragraphs. This is an attempt
to standardise what is currently phrased in ways like:

   If the information is available, it is returned as a multi-line
   response following the 215 response code. If the information is not
   available, a 503 response MUST be returned. If the server does not
   recognize the command, a 501 response MUST be returned.
[...]
   Example of LIST ACTIVE.TIMES returning an error where the command is
   recognised but the software does not maintain this information: 
   
      [C] LIST ACTIVE.TIMES 
      [S] 503 program error, function not performed
   
   Example of LIST ACTIVE.TIMES sent to a server that does not recognize
   this command:
   
      [C] LIST ACTIVE.TIMES
      [S] 501 Syntax Error

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

An example, I think, is where extensions are implemented via a loaded
shared library or DLL; if the load fails, you return 403.

> I would
> remove 503 from the explicit list of return codes of LIST EXTENSIONS,
> though.

Done. The relevant descriptive text changed to:

    Following a generic failure response, such as 403, an extension might
    still be available, and the client MAY attempt to use it.

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

Anyone else?

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

Okay, if this is so then - combined with the comments above about
extensions - it says to be that 480 *has* to be made a generic response.
Something like:

   If the client is not authorized to use the specified facility when
   the server is in its current state, but a different command might
   change the server state and permit the command if it is retried,
   then the response code 480 MUST be returned.  If the client is not
   authorized to use the specified facility when the server is in its
   current state, and it is necessary to terminate the connection and
   start a new one with the appropriate authority before the command
   can be used, then the response code 502 MUST be returned. (The
   server MUST NOT close the TCP connection immediately after a 502
   response except at the initial connection and with the MODE READER
   command.)

Does that correctly reflect the difference? If not, what does?

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

Done. I've left the existing example in place as well, but changed it to
use 480.

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