[NNTP] LIST EXTENSIONS (again)

[Dan Riley]

kaih at khms.westfalen.de (Kai Henningsen) writes:
> rra at stanford.edu (Russ Allbery)  wrote on 08.11.04 in
> <87lldbncep.fsf at windlord.stanford.edu>:
> > What would you think of documenting port 433 for transit connections in
> > the standard and saying that transit feeds SHOULD use port 433 instead of
> > port 119?  That to me seems like the most viable way of eliminating MODE
> > READER.

I'd hum for that.

> Something like the following:

I mostly agree with what Kai proposed--it's close to what I was
consider proposing.  I do have a few quibbles...

> * Document that some few servers use both client and transfer access on
>   port 119, and that this case is SHOULD NOT, and that there's an old
>   mechanism of "MODE READER" for coping with this, and that, *if* that is
>   needed, that command needs to be the very first thing sent, and if the
>   server doesn't like that command in that position, not send it at all.

Seems like a chicken/egg problem--how does the client know if the server
likes "MODE READER" or not, if it needs to be the very first thing sent?
I'd prefer:

 * Clients SHOULD NOT send an unsolicited "MODE READER" by default
 * Clients MAY offer an option to send an unsolicited "MODE READER"
 * Clients MAY send "MODE READER" in response to specific 401 and
   502 errors
 * Clients SHOULD send "MODE READER" in response to an advertised
   "MODE READER" capability or extension.

> * And document that standard servers might, to be compatible with
>   pre-standard clients, want to support MODE READER on port 119 as a no-op
>   compatibility command - they ought to accept it whenever any client
>   command is allowed, for maximum compatibility.

At first I liked "MODE READER" as a noop, but on further thought I
think it's a bad idea.  Client issues a "GROUP" command, gets a 502,
issues a "MODE READER", and gets success--how does it interpret that?
Has something changed that means a reader command might succeed, or
hasn't it?  I'd like to hear client authors weigh in on this, but my
current prejudice is that encouraging "MODE READER" as a noop is a
mistake.

I would add:

 * The interaction between "MODE READER" and "AUTHINFO" or "STARTTLS"
   is *unspecified*

which I believe is the only accurate characterization of existing
practice.

> # MODE_READER means if you want reader access, your very next move MUST be
>   to issue MODE READER and reset everything you know. You really cannot
>   have TLS running for that.
> 
> # Servers SHOULD NOT use this extension. It SHOULD NOT be used except
>   while migrating existing transfer peers to 433.

I dislike the way this combines a client MUST with a server SHOULD
NOT.  I'd rather make issuing a "MODE READER" a SHOULD or even a MAY,
not a MUST.

-- 
	  The 10/8 that can be pinged is not the true 10/8.