[NNTP] LIST EXTENSIONS (again)

[Russ Allbery]

Ken Murchison <ken at oceana.com> writes:

> Just to clarify the way that I envision that this would work (and the
> way it currently works in IMAP).  If NNTPv3 adds to NNTPv2 and retains
> NNTPv2 functionality, then only NNTPv3 would have to be advertised by
> the server (although there would be no harm in also advertising
> NNTPv2). If NNTPv3 removes functionality from NNTPv2, but the server
> retains this functionality, then both NNTPv3 and NNTPv2 would have to be
> advertised.

Hm.  That strikes me as odd -- how does an NNTPv2 client know if a server
advertising NNTPv3 is okay or not?  This would seem to require that
clients know whether NNTPv3 is backward-compatible when NNTPv3 may not
have even been written when the client was.

I must be missing something.

> Works for me.  The only question that I have is whether these
> capabilities are advertised as arguments to NNTPv2 or as standalone
> extension labels?  The only alternative names that I have for the
> capabilities would be something like "READINGDISABLED" and
> "TRANSPORTDISABLED"

I'd rather make them stand-alone labels.

Jeff's point is well-taken, though, and I'll write a separate reply to
that going into more depth about extension labels, particularly with
relation to commands that the client may not be allowed to issue.

>> One could cut this down by one more command by adding some sort of
>> initial extension advertisement to the greeting, but this worries me
>> for the reasons stated by Clive and Andrew, just in a cleanliness
>> sense.  It's worth considering, though.

> I understand that most folks find this proposal somewhat "distasteful"
> (for lack of a better term), but does anyone have any *technical*
> reasons why this can't work?

I don't.

I'd prefer to include only a subset of extensions in the initial reply
just because NNTP has a response length limit for single-line responses
and existing clients do rely on that.  It may be paranoia, but I know that
particularly with private extensions, extension lists can get rather long.

STARTTLS and AUTHINFO seem like the main ones that should be advertised,
and maybe a POST and IHAVE extension.

> I'm probably not qualified to answer this, but might there be a case
> where "lightweight" reading is offered for free (w/o authentication),
> but more "expensive" commands such as NEWNEWS or OVER or some future
> XSEARCH are only allowed to (paying) customers that authenticate?

Yeah, but in that case, wouldn't you advertise the extensions but reply
with a 480 code to attempts to use them, prompting the client to
authenticate?  That was what I'd been assuming in previous discussions of
extension advertisements, but maybe that's not the best way to do it?

The problem with not advertising extensions that the client is allowed to
use after authentication is that the client then has no idea whether the
extension is available but needs authentication or if it's just not there
at all.  Advertising it and then responding with 480 is annoying in the
terms of round trips, but at least lets the client figure everything out
eventually.

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