ietf-nntp Response code issues

[Clive D.W. Feather]

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

>>>>     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.
> Unless someone speaks up and offers another opinion here, I think we
> should just let the generic failure text cover this.

Um, this is part of the generic failure text. If it goes in, it goes in
just after the bit I've quoted at the top of this message.

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

Yes, I can see that.

On the other hand, I've just re-read something that's thrown a *further*
case at me - what if an implementation forbids AUTHINFO until after MODE
READER? The correct response, according to our current wording, is 480 -
command forbidden for the moment. But it doesn't feel like a 480 case to
me; does it to you?

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

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

>  * Document both 480 and 483, specifically, as generic responses.

>  * Document 48x as a generic response for authentication and data privacy
>    issues.

We could document a separate range for "you're not in the right state", say
47x. Then:
* need MODE READER -> 471
* need authorisation -> 472
* need encryption -> 473
and 480 and 483 can be used as failure codes for authentication and
encryption commands.

Other possibilities:
* Merge AUTH and TLS into the base specification, so that they are special
cases that are allowed generic responses.

* Provide some mechanism for a server to say "I return the following codes
for 'you're in the wrong state and need to invoke this extension'".

I think this needs further thought.

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