[NNTP] Re: MODE READER

[Russ Allbery]

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

>> 502 is existing practice.  503 has the following description:
>> 
>>    If the server recognizes 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 HDR
>>    command (Section 8.6.1) for an example), the response code 503 MUST be
>>    returned.

>> This doesn't sound like the right code to use to me, since we're not
>> talking about optional commands and we're not talking about a client
>> request for command functionality that isn't supported.

> I don't follow. On a reader-only server, IHAVE is a documented command
> that will be rejected by the server because it only handles a subset of
> legitimate cases - it doesn't handle the transit case. Or transit is an
> optional feature that isn't provided.

I think what's making me leery is that, prior to our document, 503 meant
"something went wrong in processing your command that was probably
transient."  This is a somewhat more permanent error than what people have
been using 503 to mean in the past.

503 is, for example, the return code that INN returns to AUTHINFO if it
can't fork an external authenticator, the return code that it returns to
LIST if the active file can't be found, or the return code that it returns
to DATE if localtime() fails.

> 502 doesn't make sense, because it implies that reconnecting can give
> you the appropriate authority.

I'm not sure why it would imply that.  502 means "permission denied"; it
is certainly entirely reasonable for that state to be permanent for that
client.  For example, a read-only reader server is going to return 502 to
POST from now until the end of time, and reconnecting all you want won't
help.

> Indeed. On the other hand, I don't like thinking of "reader-mode" or
> "transit-mode" as an extension, because after all you need to have one
> or the other.

This is true.

> I really really really don't like thinking of the reader commands as an
> extension. Apart from anything else, it will make a real mess of the
> document and confuse the readers.

Well, one problem is that we're talking about extensions, whereas the
closest example to what we're actually trying to do here (IMAP) talks
about capabilities.  You're right that it doesn't make any sense to talk
about reader commands as an extension, but it does make sense to talk
about them as a capability.

I wonder if it might not be worth changing LIST EXTENSIONS to LIST
CAPABILITIES.  It's certainly clearer given what we're now using it for,
it may mean that we could skip the whole business of introducing a version
number entirely because no one has implemented LIST CAPABILITIES before
and thereby defer that discussion until the next time we have to change
the core protocol, and it would let us distinguish between an extension
(something added on to NNTP that isn't defined in the core protocol
document) from a capability (something advertised with LIST CAPABILITIES
that may not necessarily be present, which includes extensions and some
other things).

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