ietf-nntp Response code issues

[Russ Allbery]

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

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

Good point.  I keep forgetting that.

The reason why IHAVE is a 502 response after MODE READER with INN is
because the IHAVE command is unimplemented by nnrpd, so it does make some
degree of sense from that direction.  But it exposes the fact that nnrpd
is a separate program from innd; the overall news server does implement
IHAVE.  It's sort of annoying that this ended up being the distinction.

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

I'm guessing most servers won't bother to distinguish between unusual
errors at that level of granularity, but yeah, the principle seems quite
reasonable to me.

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

Yes, that seems fine to me.

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

This also seems fine to me.

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

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

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

There has been additional discussion of this since.  Here's the way that I
view this issue:

I'm sympathetic to your worry about response code creep and every
extension having its own separate generic response code requesting that
people use it, but I do think that authentication and data privacy are
special.  They're special enough that they're singled out in a lot of
other ways and various protocols have made allowances for those issues in
particular.  I'm fairly comfortable singling out authentication and data
privacy for special consideration and letting them grab generic response
codes and then saying no to other things that come along later, since I
really can't think of other things that would arise later that can't in
one way or another be mapped to authentication or data privacy.  But it
would be nice to avoid putting too much detail about such things into the
base specification.

I can think of four different approaches that could be taken here:

 * Change the TLS draft to also return 480 if the level of negotiated data
   privacy is not sufficient.  Clients will just have to guess as to which
   is the problem.  This seems slightly unclean, but I think workable in
   practice.

 * Remove the provision for 483 from the TLS draft and not provide a way
   for the server to tell the client that the data privacy level is not
   sufficient other than just returning a generic error (502, probably).
   Given that data privacy is normally going to be a client option that's
   dealt with immediately after connection, this may be the best approach;
   it's certainly the simplest.

 * Document both 480 and 483, specifically, as generic responses.  If I'm
   wrong about authentication and data privacy being specific cases worth
   singling out, this could be a problem later.

 * Document 48x as a generic response for authentication and data privacy
   issues.  The problem with this is that the other 48x codes are used for
   other things, such as errors returned from authentication commands.

What do people think the best of those four solutions would be?

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