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

[Russ Allbery]

Apart from the UTF-8 issues (which I think should now be cleared up
because the new UTF-8 RFC was approved), this is the last open issue in
draft-19:

   If the client is not authorized to use the specified facility when
   the server is in its current state, then either the response code 480
   or the response code 502 MUST be returned. The response code 480
   SHOULD be used if a different command (for example, an extension used
   to present credentials) might change the server state so that the
   command is permitted. The response code 502 SHOULD be used if the
   server wishes to indicate that it is necessary to terminate the
   connection and start a new one with the appropriate authority before
   the command can be used. Since it is not always possible to clearly
   distinguish these two cases, a server MAY issue either of these
   response codes for either case. (Note that the server MUST NOT close
   the TCP connection immediately after a 502 response except at the
   initial connection (Section 5.1) and with the MODE READER (Section
   5.2) command.)

   OUTSTANDING ISSUE

      This isn't a complete solution to the 480 issue; what about the
      TLS extension, which uses 483 to mean "you need encryption".
      Should 480 be used for other than "you need authentication"? What
      code should be used to mean "can't do AUTH until after MODE
      READER"?

      Do we need a more generic mechanism for "you must invoke extension
      X to do Y"?

      The best proposal made so far is that all 48x codes, if returned
      from an existing command, mean "unavailable unless some
      authentication or privacy extension is invoked". Does this tie in
      with the issue of permitting existing commands not listed in an
      extension?

      I asked if anyone used 48x with *existing commands* to mean other
      than "you are missing a privacy or authentication extension".
      Effectively the answer is "no".

This is particularly confusing, since there are at least three different
states.  One is that the command is not allowed and never will be allowed
on this connection.  The second is that the command is not allowed but
will be allowed (possibly after authentication as a subcase) after issuing
a MODE READER command.  The third is that the command is not allowed but
will be after authentication (without an intervening MODE READER).

I think that we're all agreed that the appropriate response for the first
case is 502 and the appropriate response for the third case is 480.  The
main questions are what to do about the second case, and what to do when
the required extension isn't authentication but is instead a privacy
layer.

For the latter question, I think reserving 48x codes to mean that a
command is unavailable unless some authentication or privacy extension is
invoked is the best approach.

For the former question, of what to do about the case where a command is
not allowed but may be allowed after issuing MODE READER, I'm not quite
sure what to do.  I'm leaning towards 502 as the closest to the intended
semantics, since 48x indicates that the client should try to autenticate
or build a privacy layer, which won't actually help.  MODE READER is
neither.

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

The implication that 502 might be permanent likely won't be a problem in
practice since in practice nearly all clients issue MODE READER
immediately after connecting if that's what they want to do.

Does anyone have any objections to the above approach?  I'd like to
resolve this issue, get another draft out, and go to last call.  I think
we're ready to kick this out the door.

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