[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