[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