[NNTP] Re: MODE READER

[Mark Crispin]

On Thu, 4 Nov 2004, Ken Murchison wrote:
> The intent of the statement is to allow servers to decide whether to permit 
> AUTHINFO before and/or after MODE READER.

That is an extremely bad design (to put it mildly).

> You're looking from the client's perspective in which the statement seems to 
> say that the client can use AUTHINFO whenever it feels like it.

That is the only reasonable interpretation of:
 	The AUTHINFO commands can be used before or after the MODE READER
 	command, with the same semantics.

> But as long 
> as INN doesn't advertise AUTHINFO before MODE READER, doesn't this solve the 
> problem?

At the cost of considerable client complexity, which will get worse if 
authentication is required for peers as well as clients.

As a client author, I vehemently object to allowing the server to dictate 
the order of a protocol sequence.  In EVERY well-designed protocol, the 
protocol sequence is dictated first by the specification, and then by the 
client.

> Do you have any suggested text which might clarify this?

Yes.  Do not give the server the option of imposing an order on the 
client.  Either leave the order as random (under client direction), or 
impose One True Order and *prohibit* all other orders.

My released client code implements this order, which works on every NNTP 
server that I tested:
 	STARTTLS (if needed - note that plaintext password authentication
 		  requires TLS)
 	AUTHINFO (if needed)
 	MODE READER

To re-confirm, I just verified on an inn server that inn *does* allow 
AUTHINFO before MODE READER.  I also determined that Supernews' NNTP 
server allows AUTHINFO before MODE READER.

Perhaps there are clients which implement a different order.  If so, then 
the *only* choice is to require that servers MUST allow either order.

Life's tough if you're in the server business.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.