ietf-nntp RFC 2980 replacement

Jeffrey M. Vinocur jeff at litech.org
Mon Apr 28 20:14:27 PDT 2003


On Sun, 27 Apr 2003, Russ Allbery wrote:

> Jeffrey M Vinocur <jeff at litech.org> writes:
> 
> > Ok, so RFC 2980 could use a replacement, [...]
> 
> 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.

Yes, that was my conclusion as well -- remarkably pleasant, actually, how 
little fuss this may be.


> >     - LIST SUBSCRIPTIONS
> 
> 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.

In my idealized Usenet, where newbies all read news.announce.newusers, I'd 
keep LIST SUBSCRIPTIONS.  And LIST MOTD, although I doubt it gets much 
use, is fundamentally sound.

On the other hand, LIST MODERATORS exposes stuff the client really 
shouldn't care about or ever want to use (hmm, unless someone has 
read-only access to a news server and wants to post to moderated groups by 
sending email directly -- seems farfetched).  And LIST DISTRIB.PATS, well, 
yeah, I agree with you.

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

I glanced at the code when I was writing the previous email, and unless 
we've got really poorly named variables, you're correct.


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

In a flash of slightly twisted inspiration, what about combining them all, 
with the goal being that existing clients continue to work, but new 
clients (with will probably be sending LIST EXTENSIONS anyway) can 
determine via the extensions mechanism whether or not CHECK / TAKETHIS is 
supported.


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

Then the server could error on MODE STREAM, and not list the CHECK / 
TAKETHIS extension (clearly, unlike the general wording in the extensions 
section of the new spec, the compliant client would be required to do LIST 
EXTENSIONS before using these commands).


-- 
Jeffrey M. Vinocur
jeff at litech.org




More information about the ietf-nntp mailing list