[NNTP] LIST EXTENSIONS (again)

[Russ Allbery]

Jeffrey M Vinocur <jeff at litech.org> writes:

> If we're going to start advertising whether reading commands are
> available, and then whether various other commands like NEWNEWS are
> available (and doing such advertising seems very reasonable to me), and
> then we get into whether they're available only after MODE READER, and
> then we get into whether they're available after
> authentication...perhaps we should try to tackle this in some uniform
> way.

I think we may be able to just assume that if AUTHINFO is advertised,
clients know that authenticating may get them more commands.  Likewise
with STARTTLS if a server wants to require TLS before allowing something.

MODE READER is a special case since most servers don't require it, so it's
worthwhile to say that it's needed if it is.  But for the rest, just not
advertising NEWNEWS and POST and advertising AUTHINFO seems okay to me.

This does mean that we need to be clear that a server is allowed to return
480 to a command that isn't advertised, to deal with existing clients that
don't understand the whole capability system.

> Part of my concern is for cleanliness, but part of it is also for its
> effect on behavior.  I mean, suppose the unauthenticated client sees
> that it has general newsreading capabilities (NOREADER is not
> advertised), but doesn't see NEWNEWS advertised.  Suppose the client
> prefers NEWNEWS, but can fall back to alternative core commands if
> NEWNEWS is not available (I believe this is a common client
> implementation choice).  Now the client software has no way of knowing
> (without explicit user configuration) whether it should prompt the user
> to authenticate, or give up on NEWNEWS and start downloading articles
> immediately using the alternative mechanisms.

Yeah, this does concern me as well, but I wonder how many clients really
do reactive authentication and how useful reactive authentication is.

Although we should probably be clear that if we go down the route of
advertising capabilities only when they're available given the current
authentication and privacy state, we're essentially abandoning any attempt
to support reactive authentication (since clients won't try the commands
if they're not advertised).

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