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

[Clive D.W. Feather]

Russ Allbery said:
>> (1) We've already reserved x8x for authentication and authorization
>> extensions; expand that to include "privacy".
> That sounds fine.

Done.

>> (2) Allow any existing command to return 48x to mean that such an
>> extension is blocking the action. Possibly limit this to 48[0-3].
> I'd rather not limit it, although I guess with the new 401 response we
> potentially could.  If we do limit it, we could also exclude 481.

Note that this limitation is only for generic responses. It doesn't prevent
extensions using these codes for any purpose once they've been invoked.

[...]

Here's the new text I've put in to replace the 480/502 paragraph in the
previous draft:

   If the client is not authorized to use the specified facility when
   the server is in its current state, then the appropriate one of the
   following response codes MUST be used.

   502: it is necessary to terminate the connection and start a new one
      with the appropriate authority before the command can be used.
      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. See also the
      latter command for historical usage of this response.

   480: the client must authenticate itself to the server (that is,
      provide information as to the identity of the client) before the
      facility can be used. This will involve the use of an
      authentication extension.

   48?: the client must demonstrate to the server that it is authorized
      to use the facility. This will involve the use of an authorization
      extension.

   48?: the client must negotiate appropriate privacy protection on the
      connection. This will involve the use of a privacy extension.

   401: the client must change the state of the connection in some other
      manner. The first argument of the response SHOULD be the
      extension-label (see Section 8) of the extension that provides the
      necessary mechanism.

As you can see, there are two codes to be filled in.

Maybe I'm losing the plot here, but now that I read what I've written I'm
not sure what an "authorization extension" would be. Lack of authorization
means you need to present some kind of credentials to use the command that
just failed. What those credentials are - if not related to identity or
privacy - are going to be command-specific. Aren't they? Does anyone have
an example, or even a sketch, of an authorization extension that I can look
at to see why I'm wrong?

>> (3) Go further, and recommend 480 for authentication, 483 for privacy,
>> and 482 for authorization.
> 482 is already in use, and not for authorization.

Oh.

> INFO PASS out of order (before AUTHINFO USER).  I'd rather
> let it sit fallow for a while in an ideal world rather than reusing it
> right away,

Understood. If I'm right just above, the issue is moot anyway.

>> Query 2: will anyone scream if we change 483 to 481?]
> 481 is already in use for an authentication failure.  This is only in one,
> fairly obscure location, but I think it's slightly better form to let it
> sit fallow for a while rather than reusing it immediately.  

Again, okay. So I'll put 483 in for that case.

>> (6) State that the MODE READER case SHOULD use 401, but historically uses
>> 502.
> Sure, I can live with that.

Here's the text I've put into MODE READER:

   5.2.2 Description

   MODE READER SHOULD be sent by any client that intends to use any
   command in this specification (excluding Section 8) other than IHAVE,
   HEAD, STAT, LIST ACTIVE, or LIST EXTENSIONS. Servers MAY require that
   this command be issued before any commands other than the above are
   sent and MAY reject such commands until after a MODE READER command
   has been sent. Such rejections SHOULD use response code 401 with
   argument "MODE-READER", but for historical reasons response code 502
   MAY be used, even though this situation does not meet the conditions
   for that response.

I haven't yet fixed the examples, but will.

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