[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