[NNTP] LIST EXTENSIONS (again)

Ken Murchison ken at oceana.com
Tue Nov 9 18:46:37 PST 2004


Mark Crispin wrote:
> On Tue, 9 Nov 2004, Ken Murchison wrote:
> 
>> 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.
> 
> 
> Actually it does introduce a problem.  We have at least one server 
> (Diablo?) in which this will not work.
> 
> I used to do MODE READER first, and had to change my code due to user 
> complaints that it didn't work.

Argh!!!  I didn't realize that we have two contradicting servers, one 
which requires MODE READER before AUTHINFO (INN) and one that requires 
AUTHINFO before MODE READER (Diablo).

Unless this can be worked out with some combination of existing failure 
responses (which I'm sure Mark has tried), we may just have to declare 
some implementation as broken and move on.  Otherwise maybe we are stuck 
trying to remove INN's dependency on MODE READER.

Does anyone know if the Diablo design has the same dependency on MODE 
READER as INN?  Andrew may have covered this, but I don't recall what he 
said.

Hmm, thinking on my feet...

What about this heuristic for INN?  AFAIK, most sites have a list of 
peers that they are willing to accept an NNTP feed from.  When innd 
accepts a connection, it checks the remote hostname/ip against its table 
and if it finds a match, it stays in transit mode.  If it doesn't find a 
match, it automatically switches to reader mode (nnrpd).  I would 
imagine that a feeding host wouldn't also have reading clients 
originating from it.

-- 
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



More information about the ietf-nntp mailing list