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

[Russ Allbery]

Clive D W Feather <clive at demon.net> writes:
> Russ Allbery said:

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

Because you just told it something failed temporarily and it has no idea
what failed.  How is it supposed to proceed?  Particularly since existing
clients aren't really big on the difference between permanent and
temporary failure.

I don't mind throwing out a new response code on the MODE READER case, but
I think it's complete overkill for that particular case.  480, on the
other hand, is simply set in stone.  We can't start using another code for
"need authentication"; we'd just gratuitously break all the clients.

So given that we couldn't use a new code for our single largest user of
this sort of response, I'm leery.

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

Well, I knew about MODE READER and about authentication from the
beginning.  Authentication is just a solved problem; you need to return
480.  I just assumed everyone knew that.

The privacy angle *is* new, which is why we did develop a generic solution
to that problem, namely reserving the 48x response block for "need to
negotiate security features."

> The problem *is* a generic one.

I still don't really believe this.

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

One of the reasons why we said that extensions shouldn't cause new
unknown response codes to be returned for base commands is that this is a
poor design.  There should be a way to avoid this.  Security features are
a special case in that their whole point is to interfere with base
commands; for other extensions, you generally want to introduce a new
command.

> Therefore we need to talk about the question.

I certainly have no problems with that.  I'm just not convinced yet.  :)

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

Okay, this is a good example.  The drawback of using 502 for this
situation is that the client doesn't really know that what's missing is
that it needs to issue a HOST command.  That's the first really good
example I've seen.

So, given that we can't change 480, do we want to introduce a new response
code just for a privacy layer and for this extension (since MODE READER is
kind of irrelevant and it doesn't matter what we use for it)?

One alternative to doing this in this draft is to introduce it with a
later draft, such as the one that introduces HOST.  We *can* amend the RFC
with a later standards-track RFC, after all.

> (2) A server wants to provide a response to GROUP meaning "I've got it
>     on another HOST; you'll need to select that".

This is a bad example, since this is exactly what the people who want HOST
*don't* want to do.  The whole point of HOST is to hide the fact that the
server is actually doing multiple duty.  If they didn't care if people
knew the server was hosting multiple sets of groups, they'd just make all
those groups always available and there wouldn't be any need for this.

> In each case, what is the correct response code?

Right now, the best response code we have for the "must issue HOST first"
case is 502, which sucks because it's lying about being a permanent
failure.

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

Bear in mind that there is no requirement that we future-proof NNTP.  It's
perfectly reasonable to produce additional standards-track documents down
the road amending this one, and the problems with introducing a new code
won't be any worse then than they are now.

(I really, *really* want to get to last call, since what we have is
drastically better than RFC 977 already.)

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