[NNTP] LIST EXTENSIONS (again)

[Ken Murchison]

Mark Crispin wrote:
> On Tue, 9 Nov 2004, Russ Allbery wrote:
> 
>> That's not a bad idea and wouldn't break existing software that I'm aware
>> of.  I think it's even uglier than MODE READER from a protocol 
>> standpoint,
>> since it means that LIST EXTENSIONS may change as the result of issuing
>> quite a few different commands, but if you really think that's 
>> cleaner, we
>> can at least discuss it.
> 
> 
> Well, I personally don't think that there should be a mode at all; 
> either the protocol should be split into two different port services, or 
> the modality should be abolished.
> 
> I'm just trying to come up with alternative strawman proposals for what 
> could work for inn while relieving clients of the burden.

Correct me if I'm wrong in my logic.

The problem that we're trying to solve at the moment is that at least 
one reader client (Pine and c-client derivatives) does STARTTLS/AUTHINFO 
before MODE READER.  This works in all cases except those in which MODE 
READER is significant (certain INN configs for one).

IMO, the cat is already out of the bag on this one.  We have deployed 
client code which will not work with a presumably small set of deployed 
servers.  We can only hope to fix this going forward.  We have two 
choices: either fix the client or fix the server.

If we fix the server, we have to remove the significance MODE READER so 
it can either be abolished or be used in any order with 
AUTHINFO/STARTTLS.  This will work, but given that INN was designed 
around the use of MODE READER, changing this willmost likely result in a 
non-trivial development effort.

If we simply change the client to use MODE READER before 
STARTTLS/AUTHINFO (which was its intended, although undocumented, 
intent), we solve the problem with a trivial fix and AFAIK don't 
introduce any new compatibilties with deployed servers.

I'm sure I'm going to get some heat from Mark on this, but I thought I'd 
throw it out there.  Please set me straight on why this solution is not 
as simple as it appears.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp