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

[Russ Allbery]

Ken Murchison <ken at oceana.com> writes:

> I could live with this, but do existing clients do anything useful with
> the text following a 4xx response code?  This would be the first failure
> code to include formmatted data, correct?

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

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.  This really seems like overkill; existing
practice right now is to use various inappropriate response codes and no
one seems to even notice.

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 STREAM isn't actually a mode change, or shouldn't be; there's no
reason to actually require that it be sent before accepting the streaming
commands.  The reason to ask the remote client to send it was so that it
wouldn't start sending twenty TAKETHIS commands before confirming that
TAKETHIS is even supported, but LIST EXTENSIONS can now fulfill that need.
The supported status for all commands should be the same before and after
MODE STREAM.)

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

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