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

[Clive D.W. Feather]

Russ Allbery said:
>> My (clueless?) guess is that existing clients can derive meaning from 48x,
>> but wouldn't have any idea what the problem is if it sees 401.
> Yeah, I would expect that to result in termination of the connection for a
> lot of clients since it got back an unrecognized response code.

Why termination? From ARTICLE, perhaps. But not from (say) OVER.

> I'm still not clear here on why the non-security mode change case requires
> any special measures to be devoted to it.  MODE READER is the *only*
> occurance of this problem, I think we all agree that the MODE READER hack
> was poor form in the first place and certainly don't want to introduce
> more things like it, and while "not allowed until you do X" makes sense
> for values of X that involve security, it really doesn't make any sense
> outside of a security context.

We can't be sure of that.

Remember, when we started this MODE READER was the only occurrence, full
stop. Then someone mentioned authentication. Then someone else mentioned
privacy.

The problem *is* a generic one. We have stated, as a principle, that
extensions MUST NOT issue unknown response codes to base commands before
the client invokes the extension. We have been given examples of extensions
that want to issue new response codes to base commands. Therefore we need
to talk about the question.

Here's an example of an extension that might need this. Remember the HOST
proposal of a few months ago? Well, consider:
(1) A server provides several newsbases, and doesn't want to provide a
    default. It therefore needs to reject some commands until HOST has
    been issued.
(2) A server wants to provide a response to GROUP meaning "I've got it
    on another HOST; you'll need to select that".
In each case, what is the correct response code?

Another example: imagine a server that keeps old local groups in an archive
and only fetches them out on a specific demand. So:

    C: GROUP local.1995
    S: 401 XARCHIVE group needs retrieving
    C: XARCHIVE FETCH local.1995
    S: 491 30 minutes until group is available
    C: XARCHIVE FETCH local.1999
    S: 291 group available

Okay, those might not be the most convincing examples ever, but I'm loath to
say that we will *NEVER* have a situation that affects the base command set
in this way. And that means we need a documented response code.

> I was hoping we could just document MODE READER as a historical wart and
> then expend as little energy as possible on it, in the hope that
> eventually it can go away.  I certainly don't want to use it as a model
> for any future work.

MODE READER is a horrible design, I agree. But don't let that blind you to
the question.

> Maybe I'm missing some hoop other than security or MODE READER?

It's not "is there a hoop?". It's "will there ever be a hoop?".

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