[NNTP] LIST EXTENSIONS (again)

[Jeffrey M. Vinocur]

On Nov 5, 2004, at 1:53 AM, Russ Allbery wrote:

> Okay, I've read and I think digested all of the long threads about the
> NNTPv2 label and related issues.  I'm pleasantly surprised that 
> everyone
> agreed that we should have the protocol version advertised; I thought 
> that
> was going to be controversial!

I've also been impressed by the amount of headway we've made; this is 
probably the most functional the WG has been in quite a while :-)

I agree strongly with most of what Russ has said.  A few comments 
follow.


> After Mark's messages, I've been convinced that we should mandate the
> order of the state change commands.  The correct order as near as I can
> tell would be:
>
>     MODE READER
>     STARTTLS
>     AUTHINFO

I agree with that order; I found some of the orders discussed up-thread 
rather odd.


> (Although I'm wondering how often authenticating
> is really going to change anything other than noting that you can no
> longer run STARTTLS or AUTHINFO again, and if clients would really 
> need to
> check there.)

I wonder this as well.  But even if we manage to say something like "no 
previously advertised extensions can be removed except for the 
following" and "clients only need to send LIST EXTENSIONS again if they 
might be interested in some extension not previously advertised," then 
as soon as there's one common extension that becomes available 
mid-session, everything will degenerate into the "must send LIST 
EXTENSIONS" case again.

Also, I have the impression that NNTP sessions are somewhat 
longer-lived than most protocols, and thus that startup overhead is 
relatively less important.  But I could be wrong about that.


> Do we want to get into advertising whether commands are permitted for a
> particular client?  (POST and NEWNEWS are the ones most frequently not
> permitted.)

If we're going to start advertising whether reading commands are 
available, and then whether various other commands like NEWNEWS are 
available (and doing such advertising seems very reasonable to me), and 
then we get into whether they're available only after MODE READER, and 
then we get into whether they're available after 
authentication...perhaps we should try to tackle this in some uniform 
way.

Part of my concern is for cleanliness, but part of it is also for its 
effect on behavior.  I mean, suppose the unauthenticated client sees 
that it has general newsreading capabilities (NOREADER is not 
advertised), but doesn't see NEWNEWS advertised.  Suppose the client 
prefers NEWNEWS, but can fall back to alternative core commands if 
NEWNEWS is not available (I believe this is a common client 
implementation choice).  Now the client software has no way of knowing 
(without explicit user configuration) whether it should prompt the user 
to authenticate, or give up on NEWNEWS and start downloading articles 
immediately using the alternative mechanisms.

And yes, I realize this could also balloon into something quite 
complicated.

-- 
Jeffrey M. Vinocur
jeff at litech.org