[NNTP] Re: MODE READER

[Andrew - Supernews]

>>>>> "Mark" == Mark Crispin <MRC at CAC.Washington.EDU> writes:

 >> As far as MODE READER is concerned, I personally agree with
 >> you. However, server implementers will tell you otherwise. If you
 >> want to argue for this change, please do so and let's see what
 >> happens.

 Mark> It certainly can be argued that this is a server internal
 Mark> detail which should not burden the protocol.  It also adds an
 Mark> additional RTT (6 by my count).  Consider the normal startup
 Mark> situation:

 [long exchange of commands]

OK, it occurs to me that we can simplify that a lot by allowing the
LIST EXTENSIONS output to indicate one of three explicit conditions:

1) that MODE READER isn't necessary (which will be a very common case)
2) that MODE READER really is necessary (but might fail)
3) that MODE READER isn't possible, and nor are any reader commands (which
will be true for transit servers with no reader support at all, or where
the connecting IP can never obtain reader access)

with the absence of any of the above indications, the existing rule
applies (that the server is allowed to reject reader commands if MODE
READER is not issued first).

In existing practice, ignoring the above proposal, it's actually not
unreasonable for clients to do MODE READER before the first LIST
EXTENSIONS, since the MODE READER shouldn't get a 480 response (and
if it does, you can do LIST EXTENSIONS then before authenticating).
But the spec certainly doesn't lead an implementor to do it that way.

Other issues:

 - the client doesn't have to do LIST EXTENSIONS before STARTTLS if it
   wants to initiate TLS on its own initiative rather than at the
   server's request.

 - if the client doesn't want to initiate TLS but the server wants to
   force it to do so, your suggested exchange doesn't make any sense.
   (It's important that servers not encourage clients to initiate TLS
   unnecessarily, since that leads to overhead that can only be avoided
   by disabling TLS altogether.)

 Mark> Better would be something like the following, which uses an
 Mark> IMAP-like mechanism to carry capabilities in responses, and
 Mark> flushes MODE READER:

There are two fundamental objections to that. First is that you're
assigning semantics to fields which in the deployed specification are
explicitly designated as containing arbitrary non-semantic text. The
second is that you can't just handwave MODE READER out of existence;
if you make it impossible to conform to the spec, then people will
just not bother conforming to the spec and will stick with the
established practice.

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