[NNTP] LIST EXTENSIONS (again)

Mark Crispin MRC at CAC.Washington.EDU
Tue Nov 9 14:40:29 PST 2004


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.

A third variant (as an inn implementation solution) is to have the 
heuristic to set the mode, but if a command in the other mode is given 
then you just run the other daemon in a subfork.  Since this should never 
happen in real life as long as the heuristic isn't broken, it's alright 
that this be inefficient.

>> Or we can simply define a no-credentials authentication method (ala SASL
>> anonymous) that sets peer mode and declare client mode to otherwise be
>> the default.
> This doesn't help since it's not backward compatible with existing
> clients.

Why?  We're not changing clients, we're changing NNTP peers.  I think that 
we can claim this to be in-charter.

In this strawman, MODE READER becomes a noop.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.



More information about the ietf-nntp mailing list