[NNTP] LIST EXTENSIONS (again)

[Andrew - Supernews]

>>>>> "Mark" == Mark Crispin <MRC at CAC.Washington.EDU> writes:

 >> "On servers that require the use of the MODE READER command, the
 >> STARTTLS/AUTHINFO command can only be used after the MODE READER
 >> command."

Complication: a server can potentially require authentication for
_transit_ connections too, in which case the client would do AUTHINFO
without ever doing MODE READER at all. Having authenticated, it would
only do IHAVE. With INN, it could in theory do MODE READER later, but
that would, as a side effect, negate the previous authentication.

 Mark> I have a problem with that choice.

It happens to be logically necessary, since (from the server
perspective) authentication may depend on knowing whether MODE READER
has been done but not the reverse. For example, the set of available
authentication methods may be different.

This happens not to be an issue with Diablo, since the only effect
that MODE READER has on a Diablo reader is to disable some
functionality.

 Mark> Indeed, even though many people use inn servers with Pine,
 Mark> *nobody* has complained about Pine having this order.

It's quite likely that no-one has used it in a situation where it
matters (INN, transfer access _and_ authentication).

I got curious about what other clients were doing. The first two
that came to hand were slrn (because I use it) and knews (because
I recently had to fix its auth code for one of my users). In both
cases, they can cope with _either_ the INN or Diablo behaviour,
because they do this:

 - connect
 - issue MODE READER
 - if the response is 480, then authenticate and redo the command
   (this is generic handling of 480 in any case)
 - if configured to authenticate and not authenticated yet,
   then authenticate now

 Mark> How many inn servers would be broken?  Just a handful?
 Mark> Wouldn't it be easier to fix those handful of inn servers?

There is no "fix".

-- 
Andrew, Supernews
http://www.supernews.com