possible alternative approach (was: Re: [NNTP] [2501] Reader commands in transit servers and vice-versa)

[Andrew - Supernews]

I can't help thinking that way too much verbiage and complexity is
being spent on this now, especially given the desire to relegate
MODE READER to the dustbin of history.

I'm going to propose the following alternative approach (pretty much
the same in semantics, just described differently):

NNTP can be considered as two closely related protocols, which we'll
call NNRP and NNSP. NNRP is as defined in the base spec, except that
MODE READER is explicitly a no-op. NNSP is exactly identical to NNRP
except that all of the base commands, other than QUIT, IHAVE(?) and
CAPABILITIES, are optional (with a usage note saying that they are
usually not implemented except for a small handful).

Our alternative transit-only port (433) is already registered as
"nnsp". Port 433 connections are assumed to be NNSP. For port 119,
CAPABILITIES (if supported) tells you which.

On an NNRP connection, MODE READER must succeed and do nothing. On an
NNSP connection, MODE READER may be unrecognized or fail, but if it
succeeds, the result is an NNRP connection _in exactly the state it
would be in after the initial banner_.

>From the point of view of the specification, this could all be
documented as follows, without getting into contortions regarding
"mode-switching" and its effects on other commands:

 - an introductory paragraph defining the difference, mentioning
   port 433, etc

 - description of the relevent CAPABILITIES output

 - description of MODE READER.

I don't think there's any need at all to get into an extended
discussion of transit vs. reader servers. All that matters is to point
out that newsfeeding is done using what amounts to a very tiny subset
of the protocol, and under what circumstances MODE READER is needed
(for legacy servers and for new servers based on CAPABILITY output).
Going into too much detail is silly for something like this.

-- 
Andrew, Supernews
http://www.supernews.com