[NNTP] LIST EXTENSIONS and an NNTPv2 capability

[Mark Crispin]

On Fri, 15 Oct 2004, Clive D.W. Feather wrote:
>> The proposed solution is this:  Specify in our base draft that any server
>> that fully complies with the new specification advertise the NNTPv2
>> capability as part of LIST EXTENSIONS.
> Right, stop here. I don't like this idea. It's a kludge, and an unstructured
> one at that.

It has worked fine in IMAP for 10 years.  Nor has anything with the gothic 
complexity of your proposed STATUS command been necessary.

It is long past time that NNTP interoperate with other messaging 
protocols, and leverage the lessons of these other protocols.

>From the point of view of a messaging client implementor who implements 
NNTP as one of many messaging protocols, what is needed is:
  1) A binary token that indicates if the server complies with a particular
     specification.
  2) For each extension to that specification, a binary token that
     indicates if the server offers that specification.

I certainly do not want or need anything like that STATUS command.

As far as MODE READER goes, the very existance of that command is a 
protocol design wart to work around an implementation design bug.  NNTPv2 
should make it MANDATORY that MODE READER is a no-op in any NNTPv2 
compliant server; in particular it is NOT required of a client, and does 
NOT change any server protocol modes.  The sole purpose of MODE READER 
should be to try to communicate with pre-NNTPv2 servers.

You can't claim to draw a line in the sand between old cruft and new 
goodness if you leave behind these warts.

-- Mark --

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