ietf-nntp RFC 2980 replacement

[Russ Allbery]

Jeffrey M Vinocur <jeff at litech.org> writes:

> Ok, so RFC 2980 could use a replacement, considering how it will become
> even more inaccurate once a bunch of its commands are incorporated into
> the new NNTP spec.  So, a quick rundown of what's currently there;
> correct me if I've gotten anything wrong.

Looking this all over, it sure looks to me like what we want isn't so much
2980bis as a document specifying the MODE STREAM / CHECK / TAKETHIS
extension and then possibly a separate document for XPAT.  (Personally, I
think XPAT is flawed as designed with its whitespace issues, and it would
be better to spend that time on a general HEADERS command as comes up in
news.software.nntp from time to time.)

AUTHINFO will be taken care of separately with the draft that you already
have started.

>     - LIST SUBSCRIPTIONS

>     Do we want an extension for this?  Does anybody actually use it?
>     Anyway, certainly easy to include if desired.

INN also supports LIST MODERATORS and LIST MOTD; I'm not sure if anyone
wants them.  LIST DISTRIB.PATS and LIST MODERATORS actually smell like
extensions added to support inews more than anything else.  LIST MOTD was
supposed to be a replacement for the XMOTD command that (IIRC) tin sent.

> 5.  Commands with equivalents in the new spec:

>     - MODE STREAM

>     I'm not actually very familiar with MODE STREAM, but I believe it
>     has two uses:  (1) check for support for pipelining as is already
>     described in the new spec, and (2) check for support for CHECK and
>     TAKETHIS (since the client can't simply try a TAKETHIS and see it
>     fails), which LIST EXTENSIONS should take care of.  However, do we
>     want some sort of legacy support here?

You're not allowed to send CHECK / TAKETHIS without sending MODE STREAM;
it's an extension negotation command.  (And I believe INN will actually
reject CHECK / TAKETHIS without MODE STREAM first, although I'd have to
check.)  These days, it could probably be replaced by LIST EXTENSIONS, but
I don't know if the additional cleanliness is worth breaking backward
compatibility when what clients are doing now isn't fundamentally broken.

(Sometimes you don't want to allow streaming even if the server software
supports it.)

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>