[NNTP] LIST EXTENSIONS and an NNTPv2 capability

Mark Crispin MRC at CAC.Washington.EDU
Tue Oct 26 10:49:48 PDT 2004


On Tue, 26 Oct 2004, Ken Murchison wrote:
> I think where we diverge is that the NNTPv2 proposal follows the KISS 
> principal and only solves the existing problem(s); by putting a line in the 
> sand w.r.t. base functionality and existing extensions which we are 
> standardizing.

I also adhere to this principle.

> 1)  Based on past history of IMAP/POP3/SMTP, few, if any, extensions will 
> have their functionality changed in any significant way.
> 2)  If the functionality *is* changed in a drastic, non-backwards compatible 
> way, then a new extension should be advertised rather than trying to wedge it 
> into the existing extension.
> 3) If the previous two assumptions turn out to be false, then we can always 
> address this issue at a later time.  The existing LIST EXTENSIONS syntax 
> already allows for extension labels to take arguments, which could be used 
> for versioning and/or enabled/disabled flags.

The only thing that I can add to this is a big
 	AMEN!!!!!


>> (2) NNTP's unique (as far as I know) concept of "extensions that aren't
>> available until you do something separate".

This is not unique to NNTP.  As Ken pointed out, TLS will change the 
available extensions, and (at least in IMAP) extensions will change after 
authentication.

> If we're interested in saving roundtrips, then we could always look at Mark's 
> proposal (which I haven't seen get to the list yet) of allowing relevant 
> responses to carry extension info.

Please do.

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